toga-ai 1.0.732 → 1.0.733

package/knowledge/1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md

@@ -530,6 +530,20 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   a new line is actually created. Full root cause, the prod cleanup migration, and the
   deploy-fix-before-cleanup sequencing live in the
   [Compass ODP Duplicate PO-Line Cleanup](../../../clients/compass-usa/workflows/odp-duplicate-po-line-cleanup.md).
+- **Customer-PO created from a sales order was missing `dateOrder` and had `cost` hardcoded 0 (both
+  fixed 2026-09-01, shared, `library` only).** In `syncSalesOrderFromNetsuite`
+  (`library/app/api/toga2.php`), the "create the customer PO" `POST /purchase-orders` branch
+  (~L1961) never set `dateOrder`, so every customer PO built from a sales order had
+  `PurchaseOrders.dateOrder` NULL. Fix: add
+  `'dateOrder' => App_Date::convertToTimezone($nsOrder->tranDate, 'Y-m-d', 'America/New_York')`
+  (the same expression that sets the SO's own `dateOrder` at ~L1394). Separately, all **three**
+  PO-item creation sites (`POST /purchase-order-item-sales-order-items`, ~L1863/1937/2051) sent
+  `'cost' => 0`; because this PO is the customer PO **for** the sales order, the PO line's cost is
+  the SO line's price — changed to `'cost' => $salesOrderItem['price']` (`$itemPrice`, from the
+  NetSuite rate or amount/qty fallback built ~L1223, always present). **Both are INSERT-ONLY:** the
+  create branches run only when the PO / line does not already exist and nothing PUTs `dateOrder` or
+  `cost`, so re-syncs and a second SO sharing the same customer-PO number never overwrite them.
+  **Existing NULL/`cost=0` rows are NOT backfilled** — new records only.
 - **⚠ A single un-deletable renumbered line could freeze the entire SALES_ORDERS section (fixed
   2026-08-17).** When NetSuite renumbers a line, `syncSalesOrderFromNetsuite` renumbers by
   **DELETE `/sales-order-items/{uuid}` then re-create in the per-item loop**. Its "pinned row" guard
@@ -881,9 +895,43 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   `'catalog' => ['name' => 'Agilant']` on the inventory-adjustment item-create. Stops all new duplicates.
   The one-time cleanup of the accumulated ~4,300 duplicate part numbers across all 17 clients is the
   [NetSuite duplicate-Items dedup workflow](../workflows/netsuite-duplicate-items-dedup.md).
+- **⚠ Inventory-adjustment `/units` reconciliation missed an existing unit on a serial-CASE mismatch →
+  1062 dup-key freeze (fixed 2026-09-01, shared, `library` only).** In
+  `syncInventoryAdjustmentFromNetsuite` (`library/app/api/toga2.php` ~L5985) the PHP lookup of existing
+  units was keyed by the **returned** unit serial (`$thisLookupUnitsBySerialNumber[$unit->serialNumber]`,
+  stored `'n/a'`) but looked up with the NetSuite serial **uppercased** via `strtoupper` (`'N/A'`). **PHP
+  array keys are case-sensitive; the `Units.itemId_serialNumber` unique key is case-insensitive** — so
+  the existing unit was missed, re-INSERTed, and collided MySQL **1062** ("Duplicate entry '560-N/A'")
+  → `EV-10` → the section aborted (fail-loud, no per-record try/catch) and froze at `1-RUNNING`. **Fix:**
+  key the lookup by `strtoupper($unit->serialNumber)` so it matches the uppercased NetSuite serial;
+  section self-heals on deploy (mode→IDLE, watermark advances). The `Items.uuid=$uuidItem` scoping was
+  left intact deliberately — copying the fulfillment "serial-only" lookup would be wrong for the shared
+  `'N/A'` placeholder serial (it would reuse another item's placeholder unit). **Durable lesson: when a
+  PHP lookup mirrors a case-insensitive DB unique key, normalize the KEY the same way you normalize the
+  probe — case-fold both, not one.**
+- **Diagnosis playbook (durable) — localize a frozen inventory-adjustment section without NetSuite
+  access.** The 2026-09-01 NYCHH freeze above was diagnosed purely from DB logs, and item-matching was
+  *ruled out* (item 560 / partNumber B11B242201 is the only Agilant-catalog item for that part — no
+  duplicate second-catalog item, `$uuidItem` resolved correctly; the inventory-adjustment item-create
+  already stamps catalog `Agilant`). Chain: **`Client_<Id>.Parameters`** (localize the stuck section:
+  `1-RUNNING` + frozen watermark) → **`Logs.Event` filtered by `clientId`** (crash `file:line`, the
+  chain `toga2.php → common_sync_togasupply.php → sync*FromNetsuite`, plus the `transactionId`) →
+  **`Logs_<Client>.Api` on that `transactionId`** (the untruncated `EV-*`/MySQL rejection + payload).
+  A "silent freeze" here is a serial/data collision, not necessarily a catalog/item-matching problem —
+  read the untruncated Api-log rejection before assuming item matching.
 
 ## Change history
 
+- 2026-09-01 — **Customer-PO `dateOrder`/`cost` fixes + NYCHH inventory-adjustment serial-case unfreeze
+  (shared, `library` only, working-tree — not yet committed/deployed).** `syncSalesOrderFromNetsuite`
+  now sets the customer PO's `dateOrder` from the SO `tranDate` (was always NULL) and its PO lines'
+  `cost` from the SO line `price` (was hardcoded 0) across all three PO-item create sites — both
+  INSERT-only, no backfill of existing rows. `syncInventoryAdjustmentFromNetsuite` now keys the `/units`
+  reconciliation lookup by `strtoupper($unit->serialNumber)` so a case-mismatched serial (`'n/a'` vs
+  `'N/A'`) matches the case-insensitive `Units.itemId_serialNumber` unique key — was missing the
+  existing unit and 1062-colliding, freezing NYCHH `INVENTORY_ADJUSTMENTS` at `1-RUNNING` (watermark
+  frozen 2022-12-28). Ruled out item-matching as the cause (single Agilant-catalog item, `$uuidItem`
+  correct). All three benefit every togasupply client. (jcardinal)
 - 2026-09-01 — **TRUE-81576: stopped runaway duplicate `ShippingCarriers` creation (worker + library).**
   `common_sync_togasupply.php` now seeds the carrier lookup from its own paged `GET /shipping-carriers`
   loop instead of harvesting carriers out of the `/shipping-methods` loop — a carrier with zero

package/knowledge/clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md

@@ -6,7 +6,7 @@ project: Library
 client: nychh
 type: client-feature
 status: active
-updated: 2026-08-30
+updated: 2026-09-01
 owners: [jcardinal]
 files:
   - library/app/api/toga2.php
@@ -134,11 +134,22 @@ Both are framework-level NetSuite facts — full detail on
   **`mainline='F'` is the WRONG filter** — NetSuite sometimes marks the first real fulfilled line
   `mainline='T'`.
 
-## Two shared-engine fixes in `syncInventoryAdjustmentFromNetsuite` (surfaced here, affect any client)
+## Three shared-engine fixes in `syncInventoryAdjustmentFromNetsuite` (surfaced here, affect any client)
 
-Both are in the shared library method — see also the
+All in the shared library method — see also the
 [per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md):
 
+- **(c) Serial-CASE mismatch missed the existing unit → 1062 freeze (fixed 2026-09-01).** The `/units`
+  reconciliation lookup was keyed by the **returned** unit serial (`$unit->serialNumber`, stored `'n/a'`)
+  but probed with the NetSuite serial **uppercased** via `strtoupper` (`'N/A'`). PHP array keys are
+  case-sensitive but `Units.itemId_serialNumber` is a **case-insensitive** unique key, so the existing
+  unit (id 546, itemId 560, serial `'n/a'`) was missed and re-INSERTed → MySQL **1062**
+  ("Duplicate entry '560-N/A'") → `EV-10` → section aborted (no per-record try/catch). This froze NYCHH
+  `INVENTORY_ADJUSTMENTS` at `1-RUNNING`, watermark stuck 2022-12-28 (integration was recently
+  restarted). **Fix:** key the lookup by `strtoupper($unit->serialNumber)`. The `Items.uuid=$uuidItem`
+  scoping was **kept deliberately** — copying the fulfillment "serial-only" lookup would be wrong for the
+  shared `'N/A'` placeholder serial (would reuse another item's placeholder unit). Section self-heals on
+  deploy. `library` only, working-tree, not yet committed/deployed.
 - **(a) Prune-order FK violation.** The stale-item prune deleted an `InventoryAdjustmentItem` while
   its child `InventoryAdjustmentItemUnits` still referenced it (FK **RESTRICT**, no cascade) → MySQL
   **1451** → `EV-11`. **Fix:** delete the child units (`/inventory-adjustment-item-units/{uuid}`)
@@ -197,9 +208,29 @@ this feature on the scheduled cron.
 - **Empty lookups drop or duplicate items.** The item loop filters to known warehouses and creates
   items on lookup-miss, so any manual/diagnostic invocation must seed the warehouse/item/manufacturer
   lookups (the harness does).
+- **A frozen NYCHH `INVENTORY_ADJUSTMENTS` section is NOT necessarily an item-matching / two-catalog
+  problem (verified 2026-09-01).** When the section stuck at `1-RUNNING`, item matching was suspected
+  (wrong of two intentional catalogs). Verified in prod it was fine: item **560**
+  (uuid `4c7b93d2-…`, partNumber **B11B242201**, HYBRID) is the Agilant-catalog item and the **only**
+  item with that part number — no duplicate second-catalog item, `$uuidItem` resolved correctly, and the
+  inventory-adjustment item-create already stamps catalog `Agilant`. The freeze was purely the serial-CASE
+  bug (fix (c) above). **Diagnosis chain (no NetSuite access):** `Client_Nychh.Parameters` (localize the
+  stuck section) → `Logs.Event` `clientId=3` (crash `toga2.php:6080` via
+  `common_sync_togasupply.php:1180` `syncInventoryAdjustmentFromNetsuite`, + `transactionId`) →
+  `Logs_Nychh.Api` on that `transactionId` (untruncated `EV-10`/1062 rejection + payload).
 
 ## Change history
 
+- 2026-09-01 — **Unfroze NYCHH `INVENTORY_ADJUSTMENTS` — serial-CASE mismatch in the `/units` lookup
+  (shared `library`, working-tree, not yet committed/deployed).** `syncInventoryAdjustmentFromNetsuite`
+  keyed the units lookup by the returned serial (`'n/a'`) but probed with the uppercased NetSuite serial
+  (`'N/A'`); PHP array keys are case-sensitive while `Units.itemId_serialNumber` is case-insensitive, so
+  the existing unit was missed, re-INSERTed, and 1062-collided → `EV-10` → section aborted at
+  `1-RUNNING` (watermark frozen 2022-12-28). Fixed by keying on `strtoupper($unit->serialNumber)`; kept
+  the `Items.uuid=$uuidItem` scoping (the shared `'N/A'` placeholder makes serial-only wrong here). Ruled
+  out item-matching / two-catalog as the cause (item 560 / B11B242201 is the only Agilant-catalog item,
+  `$uuidItem` correct). Diagnosed entirely from `Parameters` → `Logs.Event` (clientId 3) → `Logs_Nychh.Api`
+  by `transactionId`, no NetSuite access. (jcardinal)
 - 2026-08-30 — Verified that NYCHH adjustments with a NULL `itemFulfillmentId`/`itemFulfillmentItemId`
   are **correct, not a bug**: 0 of 27 NYCHH adjustments populate NetSuite `custbody_stock_adjustment`
   (~1 in 40 account-wide), so most carry no link. Confirmed the shim's scalar SuiteQL read of the field

package/knowledge/clients/nychh/profile.md

@@ -187,4 +187,9 @@ table views. Client-specific DB change-sets live in `dbchanges2/Client_Nychh/`.
   path on any branch, and neither is in the working tree — so the transfer-order **custom-field
   write permission** and the **stage status identifier** are, like the ACL layers above, prod/local
   state with no file behind them. Rewrite them before anyone builds a fresh environment.
+- 🚨 **OPEN, not investigated (found 2026-09-01): recurring api2 `1054` errors for NYCHH.**
+  `Logs.Event` **issueId 64**, `clientId 3`: *"Database Error Occurred Error #: 1054 Unknown column
+  'vendor.uuid' in 'where clause'"* on a `PurchaseOrders` GET (`_Query->getFoundRows` via
+  `V2.php processRoutePairs`), several occurrences ~2026-09-01 12:29. Flagged for a future look; no
+  change made. Likely a TableView/query join referencing `vendor.uuid` that isn't in scope.
 - This profile is a starting point; expand as more NYCHH-specific behavior is captured.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.732",
+  "version": "1.0.733",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",