From 591fc5cf109312c8c8e533f609fac0bff349b69f Mon Sep 17 00:00:00 2001 From: lorentz Date: Sat, 11 Jul 2026 07:16:38 -0400 Subject: [PATCH] fix(12): CR-01 widen partner_cost/partner_cost_total to NUMERIC(14,4) to stop silent precision loss --- .../095_pax8_order_items_partner_cost_numeric.sql | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 migrations/095_pax8_order_items_partner_cost_numeric.sql diff --git a/migrations/095_pax8_order_items_partner_cost_numeric.sql b/migrations/095_pax8_order_items_partner_cost_numeric.sql new file mode 100644 index 0000000..e91a1f0 --- /dev/null +++ b/migrations/095_pax8_order_items_partner_cost_numeric.sql @@ -0,0 +1,14 @@ +-- Fix: pax8_order_items.partner_cost / partner_cost_total were declared +-- NUMERIC(12,2) (migration 093), but real PAX8 per-unit partner costs carry +-- 3-4 decimal digits of precision (e.g. cost: 22.176, cost: 0.0182 -- +-- live-verified sample values from 12-02-SUMMARY.md, exercised in +-- lib/services/pax8-sync-service.test.ts). Postgres silently rounds values +-- that exceed a column's declared scale rather than rejecting them, so +-- NUMERIC(12,2) was quietly corrupting partner-cost data on every insert +-- (22.176 -> 22.18, 0.0182 -> 0.02). This is the same class of fix as +-- migration 094 (there the column was too narrow in *kind*; here it's too +-- narrow in *scale*). Widen to match quantity's NUMERIC(14,4); existing +-- 2-decimal-scale rows convert losslessly. + +ALTER TABLE pax8_order_items ALTER COLUMN partner_cost TYPE NUMERIC(14,4) USING partner_cost::numeric; +ALTER TABLE pax8_order_items ALTER COLUMN partner_cost_total TYPE NUMERIC(14,4) USING partner_cost_total::numeric;