toga-ai 1.0.889 → 1.0.891

package/knowledge/1.0/apps/library/INDEX.md

@@ -25,3 +25,4 @@
 | [NetSuite Sync Alert Monitor (App_SystemMonitor_NetSuiteIntegration)](features/netsuite-sync-alert-monitor.md) | 1.0 monitor `App_SystemMonitor_NetSuiteIntegration` — flags stale per-client NetSuite sync checkpoints (>48h) to ClickUp; open when a sync-stale alert is missin |
 | [Startech PC Matic B2B Sync (library)](features/startech-pcmaticb2b-sync.md) | PC Matic B2B bidirectional ticket sync between TOGaDesk 1.0 and TOGA 2.0 (`App_Api_Toga2`); open for ticket-type maps, StarTech client onboarding, and the V1 th |
 | [App_Api_Toga2 — TOGa2 API Client & 1.0↔2.0 Sync Bridge](features/toga2-api-client-and-bridge.md) | `App_Api_Toga2` — the 1.0-side client for the TOGa2/api2 REST API + cross-framework sync routines (`send`/`authenticate`, options DSL, `syncWithToga`/`syncWithT |
+| [Transfer order ↔ PO link reconcile (both directions, header + line, from NetSuite)](features/transfer-order-purchase-order-link-reconcile.md) | `App_Api_Toga2::reconcileTransferOrderPurchaseOrderLinks()` makes one TO's PO links (upstream + downstream, header + line) match NetSuite; open before touching |

package/knowledge/1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md

@@ -0,0 +1,63 @@
+---
+title: "Transfer order ↔ PO link reconcile (both directions, header + line, from NetSuite)"
+framework: "1.0"
+repo: library
+project: Library
+client: shared
+type: feature
+status: active
+updated: 2026-09-24
+owners: [jcardinal]
+files:
+  - library/app/api/toga2.php
+  - library/app/api/netsuite/rest.php
+  - dbchanges2/_modules/netsuite/2026-09-24a - TransferOrderDownstreamPoBridgeAcl.sql
+  - worker/crons/toga2/netsuite/process_netsuite_order.php
+related:
+  - ../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md
+  - ../../worker/features/netsuite-togasupply-per-client-sync.md
+  - ../../worker/workflows/reprocessing-one-netsuite-order.md
+  - ../../../clients/nychh/features/netsuite-transfer-order-import.md
+  - ../../../clients/growrk/features/transfer-order-flow.md
+  - ../../../2.0/apps/_underscore/features/acl-permission-chain.md
+---
+
+`App_Api_Toga2::reconcileTransferOrderPurchaseOrderLinks()` makes one TO's PO links (upstream + downstream, header + line) match NetSuite; open before touching any TO↔PO bridge write or when TO PO links look wrong.
+
+## Summary
+- One public method owns every TO↔PO bridge write in the 1.0 NetSuite sync. For one TO it makes both directions match NetSuite: creates missing rows, deletes wrong rows, throws on ACL gaps.
+- Direction rule + table/record ids: [bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md). Short form: upstream (customer PO → TO) = 325/329; downstream (TO → vendor PO) = 326/330.
+- Constant `App_Api_Toga2::TRANSFER_ORDER_PO_LINK_TABLES[<direction>]` holds the table/route names. Use it; never hardcode.
+- Prod-verified 2026-09-24 (all clients with NetSuite TOs: NYCHH, GroWrk, Elite, Adyen).
+
+## How it works
+Signature: `reconcileTransferOrderPurchaseOrderLinks(&$nsOrder, array &$cfg, array &$lookupCustomer = []): void`.
+
+Callers:
+- `syncTransferOrderFromNetsuite()` — after `retireStaleSalesOrderForTransferOrder()`, for **every** `TRANSFER_ORDER_DETECTION_MODE`, not only STOCKING_FLAG.
+- `syncPurchaseOrderFromNetsuite()` — when a PO's `createdFrom` is a TO (re-runs the reconcile for that TO).
+- `linkTransferOrderPurchaseOrders()` — kept as a thin public wrapper (old callers).
+
+Expected sets, from NetSuite only:
+- **Upstream:** `otherRefNum` split on `' + '` → `findCustomerPurchaseOrderByNumber` under `$cfg['importCustomerPurchaseOrdersOnVendor']`. Missing customer PO → **created** (header + lines). TO line with no matching PO line → a new PO line is created (on NYCHH this adds stock-in — expected).
+- **Downstream:** `App_Api_Netsuite_Rest::listPurchaseOrderIdsCreatedFromOrder($orderId)` (SuiteQL on `transactionline.createdfrom`). A vendor PO not yet in Toga is skipped here; the PO sync imports it later and reconciles again.
+
+Line matching (per direction):
+1. Same item `uuid`, then `partNumber`.
+2. Keep an existing link if still valid (Supply-created TO lines keep the PO line the user picked).
+3. Prefer equal quantity; each PO line used once.
+4. A TO line with NetSuite `createdPo` pairs only inside that PO.
+
+Deletes are logged: grep `reconcileTransferOrderPurchaseOrderLinks` in the worker log.
+
+`retireStaleSalesOrderForTransferOrder()` moves the old SO's links by direction: upstream SO links → 325/329, downstream (`SalesOrders_PurchaseOrders` / `SalesOrderItems_PurchaseOrderItems`) → 326/330.
+
+## Gotchas
+- **Direction comes from the NetSuite relationship, never the vendor name.** GroWrk raises real vendor POs on a vendor named "Growrk" (NS PO 7522688 `createdfrom` SO 7515828).
+- **ACL first.** 326/330 had no API-role ACL anywhere → 403 `EZ-1`. `_modules/netsuite/2026-09-24a - TransferOrderDownstreamPoBridgeAcl.sql` seeds the 4-layer chain + field grants 2214-2216 (326) and 2230-2232 (330), roles by NAME (`API` = id 3 in all 37 prod client DBs). Must run **before** the library deploy.
+- **Repair model = re-process, not SQL.** Fix the code so a re-run heals, then reset cursors / replay ([per-client sync](../../worker/features/netsuite-togasupply-per-client-sync.md)) or run [process_netsuite_order.php](../../worker/workflows/reprocessing-one-netsuite-order.md) for one order. No data-repair SQL.
+- **Pre-2026-09-24 upstream rows were polluted.** The old `linkPurchaseOrderToTransferOrder` path (PO `createdFrom` a TO) and old `retireStale` wrote vendor POs into 325/329. `Client_Nychh` before fix: ~533/1,593 rows in 325 and 3,981/5,893 in 329 were vendor POs; GroWrk/Elite a few. Example: NYCHH TO id 11 (NS SO 71759 / internal 1582638) had vendor POs 49338 + 49324 upstream and its real customer PO EIT0005971 was never imported. After re-process: EIT0005971 created (PO id 1005, 20 lines, customer 28908) upstream; 49324 lines 1-15 + 49338 lines 1-5 downstream; 0 vendor rows upstream.
+- Stale test: `test/@Bala/tests/netsuite_transferorder_payload_tests.php` "PO number from the column" case fails since the `TransferOrders.purchaseOrderId` drop ([transfer-orders page](../../../2.0/apps/toga25-supply/features/transfer-orders-page.md)).
+
+## Change history
+- 2026-09-24 — Created: two-direction reconcile replaces the upstream-only linker; fixed vendor POs written upstream; 326/330 now live + ACL'd. Prod-verified. (jcardinal)

package/knowledge/1.0/apps/worker/INDEX.md

@@ -21,4 +21,5 @@
 | [isFulfillable Multi-Client Backfill (all togasupply clients)](workflows/isfulfillable-multi-client-backfill.md) | One-time backfill catching up `Items.isFulfillable` on existing items across all 17 togasupply clients; open when running/re-running it or deciding whether rema |
 | [Deduplicating NetSuite duplicate Items across client DBs (recursive MERGE)](workflows/netsuite-duplicate-items-dedup.md) | Per-client cleanup collapsing duplicate `Items` rows (same `partNumber`) to one canonical via recursive MERGE; open before running it — and read the catalog-bli |
 | [Onboarding a Client to the NetSuite TOGa Supply Sync](workflows/onboarding-client-to-netsuite-togasupply-sync.md) | How to add a new TOGa 2 client to the per-client NetSuite → TOGa Supply importer; open when onboarding a client, and read the vendor-seed / ACL / Parameters-see |
+| [Re-processing one NetSuite order (process_netsuite_order.php operator CLI)](workflows/reprocessing-one-netsuite-order.md) | Run the real SO/TO sync + its vendor POs for ONE NetSuite order on ONE client, without touching cursors; open to heal or debug a single order. |
 | [Tracing a 1.0 worker cron run in production (no stdout, silent skips)](workflows/tracing-a-worker-cron-run-in-production.md) | How to answer "did this cron run, and what did it do?" on the 1.0 worker tier (no usable stdout, skipped runs leave no trace); open before concluding a cron "ne |

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

@@ -820,15 +820,15 @@ order number, line count *and* total quantity.
 
 1. move `ItemFulfillmentItems`: `salesOrderItemId` → `transferOrderItemId`,
 2. move `PurchaseOrderItems_SalesOrderItems` → `PurchaseOrderItems_TransferOrderItems` (upstream),
-3. **(b2)** move `SalesOrderItems_PurchaseOrderItems` → `PurchaseOrderItems_TransferOrderItems`
-   (downstream — added 2026-09-18),
+3. **(b2)** move `SalesOrderItems_PurchaseOrderItems` → `TransferOrderItems_PurchaseOrderItems`
+   (downstream → downstream 330; before 2026-09-24 it wrongly went to upstream 329),
 4. `DELETE` the `SalesOrderItem`;
 
 then at header level:
 
-5. **(d2)** collapse **both** `SalesOrders_PurchaseOrders` (downstream) **and**
-   `PurchaseOrders_SalesOrders` (upstream) onto `PurchaseOrders_TransferOrders`
-   — upstream added 2026-09-18,
+5. **(d2)** move `PurchaseOrders_SalesOrders` (upstream) → `PurchaseOrders_TransferOrders` (325) and
+   `SalesOrders_PurchaseOrders` (downstream) → `TransferOrders_PurchaseOrders` (326; before 2026-09-24
+   it wrongly went to 325),
 6. **(e)** repoint `ItemFulfillments.salesOrderId` → `transferOrderId` (the fulfillment **header**,
    added 2026-09-18),
 7. `DELETE` the `SalesOrder`.
@@ -844,10 +844,11 @@ returns no `totalRecordCount` (see the ACL shape below). Consistent with the 202
 policy. **A stale transfer-order Invoice no longer freezes the run — it is now DELETED up front
 (2026-09-21, below);** the old per-line `InvoiceItems` throw is kept only as a safety net.
 
-**Bridge direction is PO-FIRST, confirmed from NYCHH data rather than guessed.** The naming rule is
-`<source>_<created from it>`. `Client_Nychh` populates `PurchaseOrderItems_TransferOrderItems` (98
-rows) and `PurchaseOrders_TransferOrders` (45); the TO-first siblings are **0 in every client**. Same
-rule as the [SO↔PO bridge direction doc](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md).
+**Both TO↔PO directions are real (corrected 2026-09-24).** Naming rule `<source>_<created from it>`:
+PO-first 325/329 = upstream customer PO; TO-first 326/330 = downstream vendor POs. The old "TO-first
+is dead" reading came from the bug that wrote vendor POs upstream. After retirement,
+`syncTransferOrderFromNetsuite` runs the [TO↔PO link reconcile](../../library/features/transfer-order-purchase-order-link-reconcile.md),
+which fixes both directions. Rule: [bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md).
 
 **⚠ It needs the three-layer ACL grant first.** Without `AclFieldPermissions` on records 29/325/329
 the bridge existence checks return **200 + `WZ-1` with no `meta.totalRecordCount`** and the method
@@ -1087,6 +1088,11 @@ discovered per-client.
 
 ### Manual operator scripts (built for Elite, reusable pattern)
 
+**One order, any client:** [process_netsuite_order.php](../workflows/reprocessing-one-netsuite-order.md)
+(`<client> --tranid=|--id=`) — real SO/TO sync + its vendor POs, no cursor writes, refuses while the
+scheduled wrapper runs. Uses `NETSUITE_SYNC_LOOKUPS_ONLY` (early return after LOOKUPS in
+`common_sync_togasupply.php`).
+
 Two CLI scripts written for the Elite backfill live under
 `test/@srija/Elite Testing/Service Requests/` (they are operator tools, **not** scheduled crons —
 do not add them to `cron.worker.sync.json`):
@@ -1202,6 +1208,13 @@ library (or vice versa) crashes GroWrk and Adyen on their next sync run.
 
 ## Gotchas / known issues
 
+- **⚠ Sales-order downstream LINE links were deleted on every PO re-sync (fixed 2026-09-24).** In
+  `syncPurchaseOrderFromNetsuite` `$incomingSalesOrderItemUuid` was initialized null and never
+  assigned, so the existing-line branch deleted every `SalesOrderItems_PurchaseOrderItems` link and
+  never re-created it (Elite prod: 55 of 97 SO-linked vendor POs had no line links). Now assigned; the
+  nested link is stripped from the existing-line PUT; deletes are logged
+  (`syncPurchaseOrderFromNetsuite: DELETE`). Any cursor-reset replay before this fix lost line links.
+
 - **PLATFORM FACT: NO TOGA client fulfills NetSuite item groups (bundles).** Every client fulfills the
   **member items individually**. This is the load-bearing safety assumption behind the IA dedup's
   empty-serials delete branch (see [NYCHH IA→fulfillment link](../../../clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md))
@@ -2071,6 +2084,7 @@ library (or vice versa) crashes GroWrk and Adyen on their next sync run.
   [NetSuite Sync Alert Monitor](../../library/features/netsuite-sync-alert-monitor.md).
 
 ## Change history
+- 2026-09-24 — TO↔PO links: two-direction reconcile (vendor POs no longer upstream; retireStale moves downstream SO links to 326/330); fixed SO downstream line-link deletes on PO re-sync; new `process_netsuite_order.php` + `NETSUITE_SYNC_LOOKUPS_ONLY`. (jcardinal)
 - 2026-09-22 — **The `Logs.Issue` 589 doom-loop's framework root cause is now fully explained and has
   tooling, but this sync is NOT yet patched.** Three independent reasons the 2006 reconnect was dead
   (warning path, `$connections` cache never cleared, `$link` captured above the retry loop); prod

package/knowledge/1.0/apps/worker/workflows/reprocessing-one-netsuite-order.md

@@ -0,0 +1,52 @@
+---
+title: "Re-processing one NetSuite order (process_netsuite_order.php operator CLI)"
+framework: "1.0"
+repo: worker
+project: Worker
+client: shared
+type: workflow
+status: active
+updated: 2026-09-24
+owners: [jcardinal]
+files:
+  - worker/crons/toga2/netsuite/process_netsuite_order.php
+  - worker/crons/toga2/netsuite/common_sync_togasupply.php
+  - library/app/api/netsuite/rest.php
+related:
+  - ../features/netsuite-togasupply-per-client-sync.md
+  - ../../library/features/transfer-order-purchase-order-link-reconcile.md
+  - ../../../clients/nychh/features/netsuite-transfer-order-import.md
+---
+
+Run the real SO/TO sync + its vendor POs for ONE NetSuite order on ONE client, without touching cursors; open to heal or debug a single order.
+
+## Summary
+- Manual CLI, **not scheduled** — never add to `cron.worker.*.json`.
+- Writes no cursor, no execution mode. Fail-loud: any error stops the run.
+- Preferred repair model: fix the code so re-processing heals, then re-run (one order here, or a cursor rewind for history — [per-client sync](../features/netsuite-togasupply-per-client-sync.md) "Replaying one order"). No SQL data repair.
+- Supersedes the NYCHH-only `probe_import_single_order_hh.php` / `relink_transfer_order_pos_hh.php` (not in the repo).
+
+## How it works
+From the `worker/` directory:
+```
+php crons/toga2/netsuite/process_netsuite_order.php <client> --tranid=<NS order #>
+php crons/toga2/netsuite/process_netsuite_order.php <client> --id=<NS internal id>
+```
+`<client>` = the wrapper suffix of `sync_togasupply_<client>.php` (e.g. `hh`, `growrk`, `elite`). Pass exactly one of `--tranid` / `--id`.
+
+Steps the script runs:
+1. Refuses if `sync_togasupply_<client>.php` is running (`ps -ef`) — two writers can duplicate links.
+2. Defines `NETSUITE_SYNC_LOOKUPS_ONLY` and requires the wrapper → `common_sync_togasupply.php` builds config + lookups, then returns before any section.
+3. `--tranid` → `App_Api_Netsuite_Rest::findSalesOrderIdByTranId()` (format-validated).
+4. Refuses an order whose customer / end-user customer does not map to this client.
+5. Closed → `deleteClosedOrderFromNetsuite`; TO (detection mode) → `syncTransferOrderFromNetsuite` (includes the [two-direction PO link reconcile](../../library/features/transfer-order-purchase-order-link-reconcile.md)); else → `syncSalesOrderFromNetsuite`.
+6. `listPurchaseOrderIdsCreatedFromOrder()` → `syncPurchaseOrderFromNetsuite` for every vendor PO created from the order.
+
+Verify: grep the PHP error log for `reconcileTransferOrderPurchaseOrderLinks` and `syncPurchaseOrderFromNetsuite: DELETE`.
+
+## Gotchas
+- A TO skipped by the sync (out-of-scope customer) prints `NOT imported` — read the error log, not a script bug.
+- Needs `IS_ENABLED_INTEGRATION_TRANSFER_ORDERS` true in the wrapper for TO routing; otherwise the order syncs as a sales order.
+
+## Change history
+- 2026-09-24 — Created; prod-verified on NYCHH TO 11. (jcardinal)

package/knowledge/2.0/apps/_underscore/INDEX.md

@@ -48,7 +48,7 @@
 | [Recursive Item Fulfillments (upstream mirroring)](features/recursive-item-fulfillments.md) | Engine that mirrors a downstream ItemFulfillment up the SO→PO→SO chain onto every customer-facing SO; open when touching IF creation, bundle scaling, or upstrea |
 | [Sales-order denial reason (`ApprovalDecisions.note`) — capture, the denial-details card, and the read-only workflow mode](features/sales-order-denial-reason.md) | Map of the SO approval denial reason (`ApprovalDecisions.note`) — where it is written, read, and displayed; open when building any denial-reason display, banner |
 | [Sales-order \"PO Number\" sourcing — one surface element, `_purchaseOrders`, tenant SQL underneath](features/sales-order-po-number-sourcing.md) | How the SO modal "PO Number" field is sourced (one surface element → `_purchaseOrders` calc field → tenant SQL); open before touching PO-number display, the ups |
-| [SO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)](features/sales-order-purchase-order-bridge-direction.md) | The two SO↔PO bridge tables mean opposite things (upstream = customer PO, downstream = vendor PO); open when an SO↔PO query returns an empty array or before cho |
+| [SO↔PO and TO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)](features/sales-order-purchase-order-bridge-direction.md) | The two SO↔PO (and two TO↔PO) bridge tables mean opposite things (upstream = customer PO, downstream = vendor PO); open when an SO/TO↔PO query returns an empty |
 | [Per-client sales-order status filter (Surface FILTER_SET → table meta `filterOptions`)](features/sales-order-status-filter-surface.md) | Per-client status-filter dropdown on the sales-orders table, driven by a Surface `FILTER_SET`; open when the offered statuses are wrong for a tenant or when onb |
 | [Shipping Carriers & Carrier Account Numbers (records, matching, duplication, deletion)](features/shipping-carriers-and-accounts.md) | Per-client `ShippingCarriers` / `ShippingCarrierAccountNumbers` model, how the syncs match/create carrier rows, and the duplication + blank-carrier + pagination |
 | [_String helpers — ASCII-safe HTML entity encoding (and the parseBetween trap)](features/string-html-entity-helpers.md) | `_String` static string utilities: use `encodeToAsciiHtmlEntities` for any dynamic text going into a 2.0 email; open when escaping email text or parsing substri |

package/knowledge/2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md

@@ -1,12 +1,12 @@
 ---
-title: "SO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)"
+title: "SO↔PO and TO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)"
 framework: "2.0"
 repo: _underscore
 project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-09-18
+updated: 2026-09-24
 owners: [apeterson, bala, jcardinal, rgirish]
 files:
   - _underscore/Model/Client/PurchaseOrders/SalesOrder.php
@@ -15,7 +15,9 @@ files:
   - _underscore/Model/Client/SalesOrder.php
   - _underscore/Trait/Netsuite/SalesOrder.php
   - library/app/api/toga2.php
+  - _underscore/Model/Client/TransferOrder.php
 related:
+  - ../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md
   - ./sales-order-po-number-sourcing.md
   - ./recursive-item-fulfillments.md
   - ./fulfillable-item-propagation.md
@@ -24,7 +26,7 @@ related:
   - ../../../clients/nychh/features/po-number-upstream-direction.md
 ---
 
-The two SO↔PO bridge tables mean opposite things (upstream = customer PO, downstream = vendor PO); open when an SO↔PO query returns an empty array or before choosing a bridge/child key.
+The two SO↔PO (and two TO↔PO) bridge tables mean opposite things (upstream = customer PO, downstream = vendor PO); open when an SO/TO↔PO query returns an empty array or before choosing a bridge/child key.
 
 ## Summary
 
@@ -44,6 +46,17 @@ Read the name as **"`<source>`\_`<thing created from it>`"**. The *first* table
 | `PurchaseOrderItems_SalesOrderItems` | **UPSTREAM** | an SO line created **FROM** a customer PO line | `purchase-order-item-sales-order-items` |
 | `SalesOrderItems_PurchaseOrderItems` | **DOWNSTREAM** | a vendor PO line created **FROM** an SO line | `sales-order-item-purchase-order-items` |
 
+**Transfer orders follow the same rule (live in both directions since 2026-09-24):**
+
+| Header table | Line table | Direction | Meaning | `Core.Records` |
+|---|---|---|---|---|
+| `PurchaseOrders_TransferOrders` | `PurchaseOrderItems_TransferOrderItems` | **UPSTREAM** | TO created FROM the customer PO (NetSuite `otherRefNum`) | 325 / 329 |
+| `TransferOrders_PurchaseOrders` | `TransferOrderItems_PurchaseOrderItems` | **DOWNSTREAM** | vendor PO created FROM the TO (NetSuite PO line `createdfrom`) | 326 / 330 |
+
+The only writer is the 1.0 [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md). Reading side: `_Model_Client_TransferOrder._purchaseOrderNumbers` (FIELD_SQL, `GROUP_CONCAT` of upstream PO numbers, Core RecordField 2633) — the `TransferOrders.purchaseOrderId` column (RecordField 2143) was dropped platform-wide 2026-09-24. A TO can have several POs, so read the calc field; a bridge join multiplies list rows.
+
+**⚠ Pick the direction from the NetSuite relationship, never from the vendor name.** GroWrk raises real vendor POs on a vendor named "Growrk" (NS PO 7522688 `createdfrom` SO 7515828). Customer PO = `otherRefNum`; vendor PO = a PO whose line `createdfrom` is the order.
+
 The 1.0 Compass NetSuite sync deletes these **item-level** link rows in **both** directions when it prunes a NetSuite-removed SO line — see [NetSuite → TOGa Supply per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md) (2026-09-15).
 
 ## How it works
@@ -83,7 +96,13 @@ All **35** prod client schemas contain all four tables (`SalesOrders`, `Purchase
 - **⚠ Do NOT paper over the direction with an `ojoin` on a shared single-record fetch.** Tempting because it works in one place: the TOGa Supply NYCHH orders **list** joins the upstream bridge and is correct — but only because NYCHH's upstream bridge happens to be **1:1** (823 rows / 823 distinct sales orders, max 1 PO per SO). The same join in the shared `fetchOrdersDetails` (`toga2-supply/src/pages/Orders/api/OrdersApi.ts:397`) breaks three tenants: **Compass** has up to **6,440** downstream POs on one sales order (row multiplication on a single-record fetch), **Compass Canada's upstream bridge is empty** (735 of 788 would drop to **zero**), and **Prudential** has only **1,868 of 26,843** orders upstream (92% populated would become 7%). A scalar `GROUP_CONCAT` calculated field is the right mechanism precisely because it collapses many POs without multiplying rows.
 - **⚠ When you DELETE a sales order, you must move BOTH directions of BOTH bridges — fixing one and missing its sibling is the default failure (2026-09-18).** Elite's stale-SalesOrder retirement shipped handling only `SalesOrders_PurchaseOrders` (downstream header) and `PurchaseOrderItems_SalesOrderItems` (upstream line), and failed on prod against the two siblings it skipped — `PurchaseOrders_SalesOrders` (upstream header) and `SalesOrderItems_PurchaseOrderItems` (downstream line). **Neither direction is "the main one":** on the same 218 orders, upstream dominated at header level (**218 vs 123**) while downstream was the rare one at line level (**7 vs 669**), so you cannot skip a direction because it looked empty on another tenant. The bridge FKs are `RESTRICT`, so a missed sibling is a hard FK error rather than silent — but you only find it one blocker at a time. **Enumerate instead:** query `information_schema.KEY_COLUMN_USAGE` for every FK referencing the parent, then count rows on the affected records, before writing any delete code. Details on the [per-client sync engine doc](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
 
+- **⚠ Before 2026-09-24 the 1.0 sync wrote vendor POs into the UPSTREAM TO tables** (325/329) — from `syncPurchaseOrderFromNetsuite` (PO `createdFrom` a TO) and from `retireStaleSalesOrderForTransferOrder`. Same class of bug as a transposed child key. Fixed by the reconcile, which deletes the wrong rows on re-process.
+
+## Change history
+- 2026-09-24 — Added TO↔PO bridges (325/329 upstream, 326/330 downstream now live), the name-vs-relationship rule, `_purchaseOrderNumbers`, and the vendor-PO-upstream bug. (jcardinal)
+
 ## Related
+- [TO↔PO link reconcile (1.0)](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md)
 - [Sales-order PO Number sourcing](./sales-order-po-number-sourcing.md)
 - [Recursive Item Fulfillments](./recursive-item-fulfillments.md)
 - [isFulfillable propagation](./fulfillable-item-propagation.md)

package/knowledge/2.0/apps/toga25-supply/features/transfer-orders-page.md

@@ -55,6 +55,7 @@ files:
   - toga25-supply/src/pages/Inventory/viewModel/useInventoryPageViewModel.tsx
   - toga25-supply/src/layout/ItemFulfillmentModal/useItemFulfillmentModalViewModel.tsx
   - _underscore/Model/Client/TransferOrderItem.php
+  - toga25-supply/src/pages/TransferOrders/view/TransferOrderRecordModalLayout/helpers/resolveDetailSlot.ts
 related:
   - ./surface-frontend.md
   - ./meta-driven-table-data.md
@@ -227,7 +228,7 @@ Three params, all addressing Inventory grouping `posByItems` level 0 (`fetchSlug
 - **The filter chip is set through `URLSearchParams.set`, with the value `"includes:" + encodeURIComponent(number)`** — mirroring the serializer in `hooks/useServerTableUrlState.ts` exactly. Hand-writing the query string double-encodes, or breaks a value containing `:` or `,`. The key's middle segment is the **column id from the table meta** (`customerPurchaseOrder`), not the record field name — renaming that `TableViewFields` column breaks the link with nothing to warn you.
 - **`purchase-orders=<uuid>` is the active-row param**, named **exactly** the table slug (`activeRowUuid = searchParams.get(slug)`). That level's `rowInteraction` is the default `"expand"`, so setting it **opens the child sub-table inline on page load** — the same thing a row click does. Omitted when the uuid is unknown; the filter alone still lands on the row, collapsed.
 
-The uuid is read off the record (`transferOrder.purchaseOrder.uuid`, already in the record fetch — no API change), **not** off the surface: the surface says *which number to show*; the route it navigates to is FE wiring (the config/logic boundary, [frontend standard](../../../standards/frontend.md) §20).
+Since 2026-09-24 the number is `_purchaseOrderNumbers` (calc field, upstream bridge, may be several joined) and the uuid is `purchaseOrdersTransferOrders.purchaseOrder.{uuid,number}` (`hooks/useTransferOrderRecord.ts`, `helpers/resolveDetailSlot.ts`). **api2 returns a lone child as an object, not an array** — normalize both shapes. The link renders **only when exactly 1 PO**. The uuid is read off the record, **not** off the surface: the surface says *which number to show*; the route it navigates to is FE wiring (the config/logic boundary, [frontend standard](../../../standards/frontend.md) §20).
 
 > ⚠ **Never `onClose()` before `navigate()`.** See the gotcha below — it races two navigations and silently strips the params the link is made of.
 
@@ -335,8 +336,8 @@ This closes both **required POST changes** recorded on 2026-09-02: `number` is n
 - header: `purchaseOrdersTransferOrders: [{ purchaseOrder: { uuid } }]` → bridge `PurchaseOrders_TransferOrders` (record **325**; inherent child of 312 via row 151).
 - each `transferOrderItems[]` line: `purchaseOrderItemsTransferOrderItems: [{ purchaseOrderItem: { uuid } }]` → bridge `PurchaseOrderItems_TransferOrderItems` (record **329**; inherent child of 313 via `dbchanges2/Core/2026-09-23d`). Source: `TransferOrderDraftLine.purchaseOrderItemUuid` ← `PurchaseOrderItemRow.purchaseOrderItemUuid`.
 - V2 auto-sets each bridge's parent-side FK; payload supplies only the other side. Engine: [nested-relationship-writes](../../api2/features/nested-relationship-writes.md).
-- Direct `purchaseOrder: { uuid }` (`TransferOrders.purchaseOrderId`) is **kept** — the record modal's PO deep link reads `transferOrder.purchaseOrder.uuid`.
-- Use 325/329, never the reverse-named twins 326 `TransferOrders_PurchaseOrders` / 330 `TransferOrderItems_PurchaseOrderItems` (0 rows in prod; dead).
+- No direct `purchaseOrder` in the POST — `TransferOrders.purchaseOrderId` (RecordField 2143) was **dropped platform-wide 2026-09-24**.
+- Write 325/329 (upstream: TO created FROM the customer PO). 326/330 are the **downstream** twins (vendor POs created FROM the TO), written only by the 1.0 NetSuite sync — [bridge direction](../../_underscore/features/sales-order-purchase-order-bridge-direction.md).
 
 **FKs go out as nested `{ uuid }` objects under the field name WITHOUT the `Id` suffix** — `contact: { uuid }`, `createdByUser: { uuid }`. Each is omitted entirely when absent rather than sent as `null`: a location can have no contact, and an SSO session can lack a user uuid.
 
@@ -523,7 +524,7 @@ Money (Unit Value / Total / Total Value) and Target Contact are **dropped for v1
 
 ~~⚠ `TransferOrders` carries **no contact FK at all** today, so the Target Contact element's `valueKey` is a **placeholder**~~ — **closed 2026-09-01.** `TransferOrders.contactId` (FK `Contacts`) exists and RecordField **2561** is granted to roles 1 and 3, so the element has a real binding and enabling it is now genuinely a one-row client override.
 
-The items table's **PO column is order-level**: `TransferOrderItems` has no line-level PO column (line PO link lives in bridge 329 since 2026-09-23, not bound to the column), so the column binds the parent order's `purchaseOrder.number` and repeats on every row. For NYCHH it resolves NULL because their PO links are **upstream** — see [NYCHH PO direction](../../../../clients/nychh/features/po-number-upstream-direction.md). It is left visible in Core (neutral default; other tenants populate `TransferOrders.purchaseOrderId` normally). **The header's PO value is now a link into Inventory** (above); for NYCHH it is the same null, so nothing renders there for this tenant yet.
+The items table's **PO column is order-level**: `TransferOrderItems` has no line-level PO column (line PO link lives in bridge 329, not bound to the column), so the column (`columnKey po`) binds the parent's `_purchaseOrderNumbers` and repeats on every row. Core `SurfaceElements` valueKeys (transfer-order-details role `purchaseOrder`, transfer-order-items `po`) → `_purchaseOrderNumbers` since 2026-09-24. NYCHH transfer-orders TableView column repointed to RecordField 2633 (join 185 on 2143 deleted). **The header's PO value links into Inventory** (above) when there is exactly one PO.
 
 ### Entry point #2 — the Inventory page's "Create Transfer Order" button (2026-09-03)
 
@@ -623,3 +624,6 @@ Library-side detail: [blox API client](../../toga-blox/features/api-client.md).
 - **`_Model_Client_Item` has no `name` field** — the item title/description live in `partNumber`, `title`, `description`, `longDescription` (`Item.php:39-45`). Binding `name` yields nothing.
 - **`Client_Nychh` `AclFieldPermissions` on the Location address fields (Core RecordFields 70–74) exist for roles 1 (Base) and 2 (Developer) but NOT role 3 (API).** Irrelevant to the UI, relevant to any integration reading those fields.
 - **Core `RecordFields` 2499/2503 (record 351) and 2504 (record 312) have `name` NULL** — added by an earlier migration without names, so a name-based lookup on them finds nothing.
+
+## Change history
+- 2026-09-24 — `TransferOrders.purchaseOrderId` dropped; PO read from `_purchaseOrderNumbers` + upstream bridge; Create POST no longer sends `purchaseOrder`; deep link only for exactly 1 PO. (jcardinal)

package/knowledge/2.0/apps/worker2/features/netsuite-transferorder-outbound-push.md

@@ -6,7 +6,7 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-09-23
+updated: 2026-09-25
 owners: ["bala", "jcardinal"]
 files:
   - worker2/Worker/Netsuite/SalesOrder.php
@@ -79,12 +79,13 @@ Nothing beyond this list. A transfer order has no shipping cost, ship method, te
 | `otherRefNum` | the PO number (developer's explicit requirement) |
 | `memo` | `TransferOrders.description` — the NYCHH custom form renders it as **"ORDER DESCRIPTION"** |
 | `shippingAddress` | the **destination** Location's `primaryLocationAddress.address` (added 2026-09-09, live 2026-09-14). Key **omitted** when the destination has no address — and **omitting it is a bug, not a safe default**: NetSuite then ships to the customer's default site. |
+| `shippingAddress.attention` | the TOGA delivery contact (`transferOrder.contact`): `firstName + ' ' + lastName` (empty parts dropped), fallback `contact._name`. Set only when both an address and a name exist; no contact → attention untouched. Name only, no phone (developer decision). `resolveTransferOrderContactName()`; the address is **cloned** first so the Location's address object is not mutated. Live in prod 2026-09-25. |
 | `externalId` | `toga-to-<transfer order uuid>` |
 | line `item` / `quantity` | each transfer-order item |
 | line `rate` | **0** — the zero-value part |
 | line `location` | the **origin** warehouse. **`location` is NOT a ship-to** — NetSuite never uses a line's location for delivery. |
 
-**Missing data ABORTS the order — never sends a partial one.** Each throws with a named message: **no origin location, no destination location, no lines, no PO number**. Mirrors the sales-order push's missing-mapping rule. **PO # is mandatory on the NetSuite order form**, which is why a missing PO number is fatal rather than omitted. `resolvePurchaseOrderNumber()` reads the PO number from the **`purchaseOrdersTransferOrders` header bridge first** (written by the Create Transfer Order modal since 2026-09-23), falling back to the direct `purchaseOrderId` column. See [SO↔PO bridge direction](../../_underscore/features/sales-order-purchase-order-bridge-direction.md).
+**Missing data ABORTS the order — never sends a partial one.** Each throws with a named message: **no origin location, no destination location, no lines, no PO number**. Mirrors the sales-order push's missing-mapping rule. **PO # is mandatory on the NetSuite order form**, which is why a missing PO number is fatal rather than omitted. `resolvePurchaseOrderNumber()` reads the PO number **only** from the upstream `purchaseOrdersTransferOrders` header bridge (325; the `purchaseOrderId` column was dropped 2026-09-24) and joins several POs with `' + '` — the same separator the inbound importer splits `otherRefNum` on. See [SO↔PO bridge direction](../../_underscore/features/sales-order-purchase-order-bridge-direction.md).
 
 **`description` → `memo` cannot leak into a plain sales order.** `memo` is sent only from the transfer-order shape. There is **no `memo` RecordField and no `memo` column anywhere** in the sales-order path.
 
@@ -193,12 +194,14 @@ Stub detail: `_Model_True` is stubbed with **only** the `FIELD_*` / `FIELDOPT_*`
 - **The Create Transfer Order modal must (a) drop `"number"` from the POST and (b) send `transferOrderItems` NESTED in the same POST.** If it posts lines in separate calls afterwards, `postPost` reads **zero lines** and the push aborts — the trigger would then have to move. See [Transfer Orders page](../../toga25-supply/features/transfer-orders-page.md).
 - **dev-sandbox metadata is incomplete** (record 325 + its RecordFields + both inherent-child rows).
 - **The -8 tax-group list is a snapshot (2026-09-14).** Re-run the check before onboarding any new client; **34283 Yale New Haven Health** and **2661 Endeavor Health** will fail on their first order.
-- **Undecided: should the delivery contact go into the NetSuite `attention` field?** NetSuite ship-to addresses carry a person on the first line (order **289193** shows *Frederick Roberts*, the Bellevue delivery contact). `TransferOrders.contactId` exists as an FK on `_Model_Client_TransferOrder` but **nothing in worker2 or toga2-supply reads it**.
+- **Delivery contact → `attention`: shipped 2026-09-25** (row above). In `Core.WorkerJobs.parameters` the FK arrives expanded as `transferOrder.contact` {firstName, lastName} — **no `contactId` key, `contact._name` never present**; no ACL/depth change was needed. toga25-supply's Create Transfer Order modal sets `TransferOrders.contactId` on every order it places. No length cap on attention (NetSuite ~99 chars) — same as other fields.
 - **Undecided: disable the customer name-search fallback for transfer orders?** `resolveNetSuiteCustomerId()` falls back to a SuiteQL search by company **name** when the destination has no customer id, and NYCHH's `Health & Hospitals` vs `NYC Health + Hospitals` are close enough to attach an order to the wrong NetSuite account.
 - **Decided and shipped 2026-09-08:** `description` goes out as `memo`, renders as "ORDER DESCRIPTION" on the NYCHH form. Still undecided: the TA number / `customerIdentificationNumber` into custom fields. **`contact` and `createdByUser` cannot be sent** — they need a NetSuite employee/contact id, which NYCHH `Contacts` do not carry.
 
 ## Gotchas
 
+- **Stale test (2026-09-24):** `test/@Bala/tests/netsuite_transferorder_payload_tests.php` "PO number from the column" case now fails — the column is gone; rewrite it against the bridge.
+
 ### ⚠ The customer's NetSuite tax item must be AVATAX, or every create 400s
 
 **Symptom.** Every transfer order create fails with NetSuite HTTP **400**:
@@ -256,6 +259,10 @@ When the payload omits the ship-to address the create **succeeds**, so it looks
 - **A NetSuite HTTP 400 naming a tax code is a CUSTOMER data problem, not a payload problem.** Check the customer's `taxitem` first; do not pin the tax fields in the payload (ignored) and do not drop the address to make the error go away (silently ships to the wrong site).
 - **`git diff --stat` after any programmatic full-file write to `_underscore`.** A full-file write with an editor default flipped CRLF → LF on `_underscore/Model/Nychh/TransferOrder.php` — content identical, git reported it modified with no content hunks. Restored with `git checkout --`. Standing rule: [2.0 backend PHP standards](../../standards/backend-php.md).
 
+## Change history
+- 2026-09-24 — `resolvePurchaseOrderNumber()` bridge-only (column 2143 dropped); multiple POs joined with `' + '`. (jcardinal)
+- 2026-09-25 — delivery contact name sent as `shippingAddress.attention`. (jcardinal)
+
 ## Related
 
 - [Toga → NetSuite Sales-Order Push](./netsuite-salesorder-outbound-push.md) — the shared outbound worker this reuses; read first.

package/knowledge/INDEX.md

@@ -4,8 +4,8 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 1.0 framework
 
-- **library** (Library) _(framework core)_ — 27 doc(s) → [1.0/apps/library/INDEX.md](1.0/apps/library/INDEX.md)
-- **worker** (Worker) — 38 doc(s) → [1.0/apps/worker/INDEX.md](1.0/apps/worker/INDEX.md)
+- **library** (Library) _(framework core)_ — 28 doc(s) → [1.0/apps/library/INDEX.md](1.0/apps/library/INDEX.md)
+- **worker** (Worker) — 39 doc(s) → [1.0/apps/worker/INDEX.md](1.0/apps/worker/INDEX.md)
 - **dbchanges** (Database Changes) _(framework core)_ — 1 doc(s) → [1.0/apps/dbchanges/INDEX.md](1.0/apps/dbchanges/INDEX.md)
 - **worker1.5** (Worker 1.5) — 0 doc(s) → [1.0/apps/worker1.5/INDEX.md](1.0/apps/worker1.5/INDEX.md)
 - **togadesk** (TOGa Desk) — 13 doc(s) → [1.0/apps/togadesk/INDEX.md](1.0/apps/togadesk/INDEX.md)

package/knowledge/clients/elite/features/netsuite-togasupply-sync.md

@@ -6,7 +6,7 @@ project: Worker
 client: elite
 type: client-feature
 status: active
-updated: 2026-09-18
+updated: 2026-09-24
 owners: ["snaredla", "jcardinal", "rgirish"]
 files:
   - worker/crons/toga2/netsuite/sync_togasupply_elite.php
@@ -339,6 +339,11 @@ ships to **all 22 clients** carrying `netsuite` in `_modules.txt` and is written
 [ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md). **Run so far
 on `Client_Elite` only.**
 
+> **2026-09-24:** `linkPurchaseOrderToTransferOrder` is gone — replaced by the two-direction
+> [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md).
+> Some of the 325/329 rows counted above were **vendor** POs (wrong direction); re-processing moves
+> them to downstream 326/330 (ACL: `_modules/netsuite/2026-09-24a`).
+
 ### Elite's stale SalesOrder backfill — RUNNING, 218 → 187 (2026-09-18)
 
 Enabling transfer-order detection left **218** Elite `SalesOrders` that duplicate a `TransferOrder`
@@ -445,6 +450,7 @@ Elite's PO backfill just did. **NOT FIXED** (shared file, 22 clients). Full root
   rewinding `NETSUITE_LAST_SYNC_DATETIME_SALES_ORDERS`.
 
 ## Change history
+- 2026-09-24 — TO↔PO links now via the two-direction reconcile; some upstream rows were vendor POs; SO downstream line links were being deleted on every PO re-sync (55 of 97 SO-linked vendor POs had none) — fixed. (jcardinal)
 - 2026-09-18 — **Stale-SalesOrder backfill is live: 218 → 187.** The retirement method needed
   four more FK dependencies before it would run (fulfillment **header** `salesOrderId`, the
   upstream `PurchaseOrders_SalesOrders`, the downstream `SalesOrderItems_PurchaseOrderItems`, and

package/knowledge/clients/elite/profile.md

@@ -17,8 +17,8 @@ project: Worker
 client: elite
 type: profile
 status: active
-updated: 2026-09-21
-owners: [snaredla, apeterson, tcox, bala, rgirish]
+updated: 2026-09-24
+owners: [snaredla, apeterson, tcox, bala, rgirish, jcardinal]
 files:
   - worker2/Worker/Elite.php
   - worker2/Worker/Sync/ServiceRequest.php
@@ -74,9 +74,9 @@ Elite's app scope. Elite-specific config, the still-owed `Countries` cleanup, an
 `Apis` rows hazard are in [netsuite-togasupply-sync](features/netsuite-togasupply-sync.md).
 **As of 2026-09-08 Elite carries all 22 `_Trait_Netsuite_*` trait models** (`_Model_Elite_*`), the
 last three being Contact, TransferOrder and TransferOrderStage — code-only, no migration needed,
-because the `_modules/netsuite` opt-in had already seeded the columns. **Transfer orders remain off**
-(`IS_ENABLED_INTEGRATION_TRANSFER_ORDERS` false, 0 rows in prod), and the shared sync method carries
-GroWrk-specific rules that must be verified before Elite enables it.
+because the `_modules/netsuite` opt-in had already seeded the columns. **Transfer orders are on in the 1.0 sync** — prod `Client_Elite` has **218 TransferOrders**
+(verified 2026-09-24; the earlier "0 rows" note was stale). The 2.0 `_Trait_Netsuite_TransferOrder`
+method still carries GroWrk-specific rules. TO↔PO links: [TO↔PO link reconcile](../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md).
 
 **⚠ 2026-09-08: Elite's sales-order sync was blocked for 4 days** by a transfer-order 400 `EV-12` —
 `Client_Elite.CustomRecordFields` id 72 had `isIdentifier = 0` on

package/knowledge/clients/growrk/features/transfer-order-flow.md

@@ -6,8 +6,8 @@ project: _Underscore
 client: growrk
 type: client-feature
 status: active
-updated: 2026-09-16
-owners: ["rgirish"]
+updated: 2026-09-24
+owners: [rgirish, jcardinal]
 files:
   - _underscore/Model/Client/TransferOrder.php
   - _underscore/Model/Client/TransferOrderItem.php
@@ -142,8 +142,13 @@ Full plan saved at `/Applications/AMPPS/www/transfer-order-plan.md`.
 - **NS identification: both conditions required.** `holdInvoice=true` alone is not a safe signal — must also confirm `total === 0`.
 - **⚠ An ABSENT NetSuite `total` reads as `0.0` and can misclassify a real order (open, unfixed).** The 1.0 detection branch does `$total = isset($nsOrder->total) ? (float) $nsOrder->total : 0.0;`, so a NetSuite REST response with a missing/blank total — a transient API failure, not a genuine $0 order — collapses to `0.0`; combined with the hold flag set, a **non-zero order is classified as a transfer order**. Pre-existing, carried unchanged through the 2026-09-03 mode refactor, and raised with the developer. If you see an unexpected TransferOrder for GroWrk, check this first.
 - **The mode is now mandatory in the launcher.** Removing/forgetting `TRANSFER_ORDER_DETECTION_MODE` in `sync_togasupply_growrk.php` makes `isTransferOrder()` **throw** — GroWrk's sync will fail loud, by design, rather than silently reclassify.
+- **⚠ Bridge direction (2026-09-24).** `PurchaseOrders_TransferOrders` / `PurchaseOrderItems_TransferOrderItems` = UPSTREAM (TO created FROM the customer PO); `TransferOrders_PurchaseOrders` / `TransferOrderItems_PurchaseOrderItems` = DOWNSTREAM (vendor PO created FROM the TO). Written by the 1.0 [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md). **Never infer direction from the vendor name** — GroWrk raises real vendor POs on a vendor named "Growrk" (NS PO 7522688 `createdfrom` SO 7515828). Prod `Client_Growrk` had 701 TransferOrders and a few vendor POs wrongly upstream before the fix.
+
+## Change history
+- 2026-09-24 — Added bridge-direction gotcha + the "Growrk" vendor trap. (jcardinal)
 
 ## Related
+- [TO↔PO bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md)
 
 - [Recursive item fulfillments](../../../2.0/apps/_underscore/features/recursive-item-fulfillments.md)
 - [worker2 architecture](../../../2.0/apps/worker2/architecture.md)

package/knowledge/clients/nychh/features/location-shipping-addresses.md

@@ -6,7 +6,7 @@ project: Database Changes
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-24
+updated: 2026-09-25
 owners: [bala, jcardinal]
 files:
   - dbchanges2/Client_Nychh/2026-09-09c - UpdateLocationShippingAddresses.sql
@@ -58,7 +58,7 @@ The Create Transfer Order screen picks a **Target Contact** from `Contacts` thro
 ## Gotchas
 
 - **🚩 OPEN — two contacts have no location link.** **Erald Velmishi** (Central Office) and **Harry Ho** (Community Care) got no `Contacts_Locations` row because **neither facility exists in `Locations`**. They will not appear in the Target Contact dropdown anywhere until the locations are created.
-- **🚩 OPEN — nothing reads the chosen contact.** `TransferOrders.contactId` is a real FK on `_Model_Client_TransferOrder`, but **no code in worker2 or toga25-supply reads it**. NetSuite ship-to addresses do carry a person on the first line (order **289193** shows *Frederick Roberts*, the Bellevue delivery contact), so wiring the contact into the NetSuite `attention` field is the obvious next step — **undecided, not implemented**. See [transfer-order → NetSuite push](../../../2.0/apps/worker2/features/netsuite-transferorder-outbound-push.md).
+- **Chosen contact → NetSuite `attention` (2026-09-25).** The Create Transfer Order modal sets `TransferOrders.contactId`; the worker2 push sends the contact's name as ship-to `attention` (as order **289193** shows *Frederick Roberts*). This is a *person* on the ship-to, not the AP bill-to tell below. See [transfer-order → NetSuite push](../../../2.0/apps/worker2/features/netsuite-transferorder-outbound-push.md).
 - **Location 2 "NYC Health + Hospitals" = client-level catch-all; address now 55 Water Street, 10041** (was Jacobi's 1400 Pelham). Its 1,832-of-1,939 TO count is largely an import bug (overwrote user destinations) + NetSuite-entered orders under 28908; fix + ship-to matching in [the NetSuite transfer-order import](./netsuite-transfer-order-import.md).
 - **⚠ Two locations carry NetSuite customer ids that no longer exist.** **Bellevue Hospital Center → 29275** and **Jacobi Medical Center → 31917**; neither id is in the NetSuite `customer` table, so their addresses came from other sources rather than a `defaultshipping` row. The ids need correcting; until then any NetSuite lookup keyed on them returns nothing.
 - **⚠ A location's address surfaces ONLY on transfer orders for this client.** Sales orders carry their own `shipToAddressId`, so "the address is fine on the order screens" says nothing about the location record.

package/knowledge/clients/nychh/features/netsuite-transfer-order-import.md

@@ -16,10 +16,13 @@ files:
   - _underscore/Model/Nychh/TransferOrderItem.php
   - worker/crons/toga2/netsuite/sync_togasupply_hh.php
   - worker/crons/toga2/netsuite/common_sync_togasupply.php
-  - worker/crons/toga2/netsuite/relink_transfer_order_pos_hh.php
+  - worker/crons/toga2/netsuite/process_netsuite_order.php
   - dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql
   - dbchanges2/Client_Nychh/2026-09-16a - TransferOrderBridgeAcl.sql
+  - dbchanges2/_modules/netsuite/2026-09-24a - TransferOrderDownstreamPoBridgeAcl.sql
 related:
+  - ../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md
+  - ../../../1.0/apps/worker/workflows/reprocessing-one-netsuite-order.md
   - ../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
   - ../../../1.0/apps/library/features/toga2-api-client-and-bridge.md
   - ../../../1.0/apps/library/features/netsuite-suiteql-rest-shim.md
@@ -47,7 +50,7 @@ Route by the custom NetSuite checkbox **`custbody_stocking_order`** (internal id
 - **CHECKED** = a *stocking order* (stock comes **IN**) → `Client_Nychh.SalesOrders`.
 - **UNCHECKED** = a *transfer order* (stock goes **OUT**) → `Client_Nychh.TransferOrders`.
 
-`App_Api_Toga2::isTransferOrder()` was rewritten to read this flag through a new private `isStockingOrder()` that normalizes NetSuite's `'T'`/`'F'` / bool / int representations. A new private `linkPurchaseOrderToTransferOrder()` mirrors the existing sales-order PO linker (below).
+`App_Api_Toga2::isTransferOrder()` was rewritten to read this flag through a new private `isStockingOrder()` that normalizes NetSuite's `'T'`/`'F'` / bool / int representations.
 
 **Routing mode is declared per client — there is NO default (2026-09-03).** The old boolean `IS_ENABLED_TRANSFER_ORDER_STOCKING_FLAG_ROUTING` is **gone**. NYCHH's wrapper now sets
 
@@ -58,33 +61,21 @@ const TRANSFER_ORDER_DETECTION_MODE = App_Api_Toga2::TRANSFER_ORDER_DETECTION_MO
 in `worker/crons/toga2/netsuite/sync_togasupply_hh.php`. `isTransferOrder()` **throws** if the mode is undefined or not in the `TRANSFER_ORDER_DETECTION_MODES` allowlist — see the shared [per-client sync — transfer-order detection mode](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
 
 ### PO ↔ order bridge links (header + line)
-A single NetSuite PO is bridged to whichever order table the order landed in, at both header and line level; links are idempotent (line matching is by shared item `uuid`):
+Owned by the shared [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md) (2026-09-24; replaced `linkPurchaseOrderToTransferOrder`). Direction rule: [bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md).
 
-| Order routed to | Header bridge | Line bridge |
+| Order routed to | Upstream (customer PO) | Downstream (vendor PO) |
 |---|---|---|
-| stocking → SalesOrders | `PurchaseOrders_SalesOrders` | `PurchaseOrderItems_SalesOrderItems` |
-| transfer → TransferOrders | `PurchaseOrders_TransferOrders` | `PurchaseOrderItems_TransferOrderItems` |
-
-`linkPurchaseOrderToTransferOrder()` is the new transfer-order counterpart to the existing sales-order linker. See [SO↔PO bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md) for the bridge naming convention.
-
-#### The bridge links were never being created — three stacked causes, fixed + prod-verified 2026-09-16
-The PO↔TO bridge links (header **and** line) were silently never forming for NYCHH. Three independent faults, peeled in order; the last was the real blocker:
-1. **Linking only ever ran from the `PURCHASE_ORDERS` section, which never runs for NYCHH.** The links depended on the PO section, so a transfer-order import created none. **Fix:** a new **public** `App_Api_Toga2::linkTransferOrderPurchaseOrders()` now runs on **every** transfer-order import/retry from inside `syncTransferOrderFromNetsuite()`. It is **idempotent** — re-running an import repairs any missing link. In `TRANSFER_ORDER_DETECTION_MODE__STOCKING_FLAG` mode it finds the customer PO by the NetSuite **PO #** (`otherRefNum`, split on `' + '`) under the `clientConfiguration['importCustomerPurchaseOrdersOnVendor']` vendor (the synthetic **Agilant** vendor), then calls `linkPurchaseOrderToTransferOrder` for the header (`PurchaseOrders_TransferOrders`) and line (`PurchaseOrderItems_TransferOrderItems`) links.
-2. **`linkPurchaseOrderToTransferOrder` read the TO line items from the wrong place, so line links never formed.** It read `$transferOrder->transferOrderItems`, but **api2 NEVER inlines that collection at any depth** (`transfer-orders` has no `InherentRecordChildren` row — same root cause as the idempotency bug), so it was always empty. **Fix:** read TO items via `getTransferOrderItemsByUuid` (the reliable direct `GET /transfer-order-items` query). Also lowered the TO existence GET to `depth=1` and added `recordsPerPage=1000` to the PO-items GET.
-3. **ROOT CAUSE — an ACL gap, not code.** The NYCHH **API** role had **no write ACL** on the two bridge records **325** (`PurchaseOrders_TransferOrders`) and **329** (`PurchaseOrderItems_TransferOrderItems`), so the link POST failed api2 **EZ-3 / WZ-2** ("no fields in which you are authorized to write"). The working **sales-order** bridge (record **276**, `PurchaseOrders_SalesOrders`) already had the grant, which is why SO links worked and TO links did not. **Also key: on CREATE, api2 `isPermitted()` DENIES a record permission that has no `AclLogicGroups` chain — a bare `AclRecordPermissions` row is inert** (the standard four-table chain rule — see [ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md)).
-
-**Fix migration:** `dbchanges2/Client_Nychh/2026-09-16a - TransferOrderBridgeAcl.sql` seeds the full four-table chain (`AclRecordExpressions` `'all'` → `AclRecordPermissions` full CRUD → `AclLogicGroups` AND → `AclLogicGroupExpressions`) **plus** `AclFieldPermissions isWritable = 1`, for roles **Base** and **API**, on records **325** and **329**, mirroring the working record 276. Guarded/re-runnable, roles resolved by name, fresh random v4 uuids, `Core` ids hardcoded (no `Client_*`→`Core` JOIN — the cross-cluster rule). The only writable fields a bridge POST touches are the row `uuid` + the two FK columns. **Data facts:** Core bridge record ids **276**=`PurchaseOrders_SalesOrders`, **325**=`PurchaseOrders_TransferOrders`, **329**=`PurchaseOrderItems_TransferOrderItems`; Core `RecordFields` **2210**=uuid/**2211**=purchaseOrderId/**2212**=transferOrderId (rec 325), **2226**=uuid/**2227**=purchaseOrderItemId/**2228**=transferOrderItemId (rec 329); `Client_Nychh` roles **1**=Base, **2**=Developer, **3**=API, **4**=Public. Reviews: `cto` AGREE (four-table chain), `sql-reviewer` SAFE TO MERGE.
-
-**ACL failures are now LOUD in the linker.** Both bridge existence checks **THROW** when their GET returns no `meta->totalRecordCount` (an ACL **read** gap) instead of silently skipping the create; the create POST already throws on a write-fail (EZ-3/WZ-2). So any future ACL gap stops the run rather than quietly producing zero links.
-
-**Verified in prod:** link `PurchaseOrderItems.id = 589` ↔ `TransferOrderItems.id = 7155` created for PO **EIT0012548** ↔ TO **284624** (NetSuite SO **7326440**).
-
-#### PO discovery for a NYCHH transfer order — `otherRefNum` + Agilant vendor, NEVER `createdPo`
-For NYCHH the SO **line-level `createdPo` is NULL**; the PurchaseOrder is the **customer PO** (`otherRefNum`, the NetSuite "PO #" field) imported against the synthetic **Agilant** vendor. So PO discovery from a transfer order must use `otherRefNum` + the Agilant vendor — never `createdPo`. NetSuite proof: SO **7326440** `tranid` 284624, `otherrefnum` EIT0012548; its lines' `createdpo` are all null; in NetSuite it links only to an invoice + item fulfillment (there is **no** PurchaseOrder record on the SO itself).
-
-#### Operator tools for this path (manual CLI, NOT scheduled)
-- **`worker/crons/toga2/netsuite/probe_import_single_order_hh.php`** — imports/relinks **one** NetSuite order by internal id for NYCHH. Builds lookups by requiring `common_sync_togasupply.php` with all `IS_ENABLED_INTEGRATION_*` false, fetches via `fetchSalesOrderByIdFull`, routes via `isTransferOrder`, runs `syncTransferOrderFromNetsuite`, then prints diagnostics (`[diag]` PO lookup, `[trace]` header-link POST response) and verifies header + line links. No cursor writes / no process lock.
-- **`worker/crons/toga2/netsuite/relink_transfer_order_pos_hh.php`** — backfills links for **all** existing `Client_Nychh` transfer orders. Pages every `TransferOrders` row, fetches each NetSuite order for its PO #, runs only the link step (`App_Api_Toga2::linkTransferOrderPurchaseOrders` — no re-import), idempotent, per-order `try/catch` that logs + collects failures (a sanctioned operator-tool exception to fail-loud), with a live progress bar + counts + end summary. Optional first arg = limit.
+| stocking → SalesOrders | `PurchaseOrders_SalesOrders` / `PurchaseOrderItems_SalesOrderItems` | `SalesOrders_PurchaseOrders` / `SalesOrderItems_PurchaseOrderItems` |
+| transfer → TransferOrders | 325 `PurchaseOrders_TransferOrders` / 329 `PurchaseOrderItems_TransferOrderItems` | 326 `TransferOrders_PurchaseOrders` / 330 `TransferOrderItems_PurchaseOrderItems` |
+
+NYCHH specifics:
+- Customer PO = NetSuite `otherRefNum` (split on `' + '`) under the synthetic **Agilant** vendor (`clientConfiguration['importCustomerPurchaseOrdersOnVendor']`). SO lines' `createdPo` is NULL for these (proof: SO 7326440 / tranid 284624 / otherrefnum EIT0012548).
+- Vendor POs (e.g. Amazon CC, Uline) exist too → downstream 326/330. Before 2026-09-24 they were wrongly written upstream: ~533/1,593 rows in 325, 3,981/5,893 in 329. Re-processing deletes them.
+- A missing customer PO is now **created** (header + lines) — adds stock-in via new PO lines. Verified TO id 11 → PO EIT0005971 (id 1005, 20 lines, customer 28908).
+- api2 never inlines `transfer-orders.transferOrderItems` (no `InherentRecordChildren` row) → read TO lines via `getTransferOrderItemsByUuid`.
+- ACL: 325/329 by `Client_Nychh/2026-09-16a - TransferOrderBridgeAcl.sql` (Base + API, 4-table chain + field grants); 326/330 by `_modules/netsuite/2026-09-24a`. Roles: 1 Base, 2 Developer, 3 API, 4 Public. RecordFields 325 = 2210/2211/2212, 329 = 2226/2227/2228, 326 = 2214-2216, 330 = 2230-2232 (id fields not granted). Chain rule: [ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md).
+- Missing ACL is loud: existence GETs throw on no `meta->totalRecordCount`.
+- One-order repair: [process_netsuite_order.php](../../../1.0/apps/worker/workflows/reprocessing-one-netsuite-order.md) `hh --tranid=<n>`. Old `probe_import_single_order_hh.php` / `relink_transfer_order_pos_hh.php` are superseded.
 
 ### Transfer-order origin/destination location resolution
 `TransferOrders.originLocationId` is **NOT NULL**, so a missing origin fails the V2 insert with **EV-10** ("originLocationId cannot be null"). Two fixes were needed:
@@ -199,21 +190,11 @@ Two NYCHH-specific gates, both of which bit during this work:
 
 WARNING: NYCHH's `NETSUITE_LAST_SYNC_CURSOR_ITEM_RECEIPTS` is stale at **2024-08-06** - re-enabling item receipts replays about two years unless it is rewound forward first.
 
-## ⚠ OPEN (2026-09-18) — NYCHH sync is 2.5 YEARS behind on a 403 EZ-1 from records 326/330
-
-Found by a fleet sweep of `NETSUITE_EXECUTION_MODE_*` across all 22 netsuite clients. NYCHH was the worst: `NETSUITE_LAST_SYNC_CURSOR_PURCHASE_ORDERS` at **2024-02-16** and `NETSUITE_LAST_SYNC_CURSOR_INVOICES` at **2024-02-22**.
-
-**⚠ The mode read `864000-RUNNING` the whole time and was taken as "healthy, in progress".** That reading was wrong — a full window with a 2.5-year-old cursor is **broken, not busy**. Always pair the execution mode with the cursor; neither is a health signal alone.
-
-**Error:** `GET /v2/transfer-order-items-purchase-order-items` → **403 `EZ-1`**.
-
-**Root cause — a different ACL gap from Elite's.** Records **326** (`transfer-orders-purchase-orders`) and **330** (`transfer-order-items-purchase-order-items`) — the **TO-first** direction — have **zero** `AclRecordPermissions` rows. The `2026-09-17a` module migration only covered the PO-first siblings **325/329**. The error shape differs from Elite's silent `200 + WZ-1`: `EZ-1` means the **record** layer is missing, `WZ-1` means the record layer is fine and the **field** layer is empty — use the code to pick which layer to fix.
-
-**Red herring:** the envelope reports `api: "Agilant"`, which looks like a different API needing different grants. It is not — NYCHH's Agilant API carries `roleId` **1 and 3**, so roleId 3 is still correct.
-
-**Fix prepared, ⚠ NOT YET RUN:** client-scoped SQL, 5 statements, same four-layer chain and `NOT EXISTS` guards as `2026-09-17a` — permissions for 326/330, `'all'` expressions, logic groups, logic-group expressions, and 6 field grants (**2214/2215/2216** for 326; **2230/2231/2232** for 330; `id` **2213/2229** deliberately excluded, matching 325/329). Chain mechanics on the [ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md).
-
-**Not NYCHH-only.** 326/330 were never in the module migration, so any client whose sync touches the TO-first bridges will hit the same 403.
+## RESOLVED (2026-09-24) — 403 `EZ-1` on records 326/330 froze PO + INVOICES (cursors 2024-02)
+- `GET /v2/transfer-order-items-purchase-order-items` → 403 `EZ-1`: 326/330 had no `AclRecordPermissions` (only 325/329 were seeded). Fixed by `_modules/netsuite/2026-09-24a` (all NetSuite clients).
+- `EZ-1` = record layer missing; `WZ-1` (200) = field layer missing. Use the code to pick the layer.
+- `864000-RUNNING` with a years-old cursor is **broken, not busy**. Always pair execution mode with the cursor.
+- Envelope `api: "Agilant"` is a red herring: that API carries roleIds 1 and 3.
 
 ## Gotchas / known issues
 
@@ -225,6 +206,7 @@ Found by a fleet sweep of `NETSUITE_EXECUTION_MODE_*` across all 22 netsuite cli
 - **`custbody_stocking_order` must reach the shim.** `fetchSalesOrderById()` now carries the field via `customFieldList`; a missing custom field read returns null → the order routes as a transfer order (unchecked = transfer). Verify the field is populated in NetSuite before trusting the split.
 
 ## Change history
+- 2026-09-24 — PO links now via the shared two-direction reconcile; vendor POs moved off upstream 325/329 onto downstream 326/330; 326/330 ACL fixed (403 EZ-1 resolved); missing customer POs are created; new `process_netsuite_order.php`. Prod-verified. (jcardinal)
 - 2026-09-21 — Fixed issue 587 (`ITEM_FULFILLMENTS` freeze): transfer-order fulfillment line was matched by `lineNumber` (= NetSuite stable `tl.id`) vs the shim's `orderLine` (= source `linesequencenumber`), which diverge on edited orders. Added `c_netsuiteLineUniqueKey` (new trait + Nychh model, `_modules/netsuite/` column/registration); match by it first, fall back to `lineNumber`. Needs a SALES_ORDERS cursor rewind on deploy. (jcardinal)
 
 - 2026-09-24 — Keep user destination on client-customer TOs (parent clients); ship-to → Location match for new NS-entered TOs. Not deployed. (jcardinal)

package/knowledge/clients/nychh/features/po-number-upstream-direction.md

@@ -6,8 +6,8 @@ project: _Underscore
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-16
-owners: [apeterson, bala]
+updated: 2026-09-24
+owners: [apeterson, bala, jcardinal]
 files:
   - _underscore/Model/Client/SalesOrder.php
   - _underscore/Trait/Netsuite/SalesOrder.php
@@ -42,9 +42,12 @@ Symptom that looked like a bug and was not: the sales-order modal's PO Number ca
 - ✅ **The open consequence is addressed on `_beta` — and NOT with a per-tenant override.** The shared `_purchaseOrders` field read the **downstream** table only (`_underscore/Model/Client/SalesOrder.php:349`), so once the modal bound to `_purchaseOrders` NYCHH resolved it without an `EV-8` and got `null`. Rather than a NYCHH-specific field, the **base** field became a `COALESCE` of downstream-then-upstream, which fixed every upstream tenant at once: NYCHH went from 64 to **819 of 819** orders resolving a PO, with **no existing value changed** for any tenant. It sits on `_beta` / the sandbox branches, **not `_production`** — see [PO Number sourcing](../../../2.0/apps/_underscore/features/sales-order-po-number-sourcing.md) for the exact commits. NYCHH is also not the only upstream tenant: all 22 clients on `_Trait_Netsuite_SalesOrder` write upstream.
 - 🚨 **Still open for NYCHH specifically: the 64 both-direction orders.** Downstream-first makes the modal show the **vendor** PO while the list keeps showing the **customer** PO. A `_Model_Nychh_SalesOrder` override preferring upstream was offered and not built. Decide which one NYCHH should see before treating either surface as authoritative.
 - **The NYCHH orders list is not a template.** Its table-view join through the upstream bridge is safe **only** because NYCHH's upstream bridge is coincidentally 1:1 (823 rows / 823 distinct sales orders). Copying that join into a shared single-record fetch breaks Compass (up to 6,440 POs on one order), Compass Canada (empty upstream bridge) and Prudential (1,868 of 26,843 upstream).
-- **The transfer-order items table inherits the same blank.** `TransferOrderItems` has no line-level PO, so that column binds the **parent order's** `purchaseOrder.number` and repeats on every row — and for NYCHH it resolves NULL, because their PO links are upstream and `TransferOrders.purchaseOrderId` is not populated for this tenant. The column is deliberately left visible in the Core surface (neutral default; other tenants do populate it). See [Transfer Orders page](../../../2.0/apps/toga25-supply/features/transfer-orders-page.md).
+- **Transfer orders (fixed 2026-09-24).** `TransferOrders.purchaseOrderId` was dropped platform-wide; TO PO number = `_purchaseOrderNumbers` (upstream bridge 325, `GROUP_CONCAT`). The Supply header + items `po` column read it. See [Transfer Orders page](../../../2.0/apps/toga25-supply/features/transfer-orders-page.md).
 - Do not "fix" this by adding downstream rows. The direction is correct for NYCHH's business model; the shared field is what was incomplete.
 
+## Change history
+- 2026-09-24 — TO PO number now `_purchaseOrderNumbers` (column 2143 dropped). (jcardinal)
+
 ## Related
 - [SO↔PO bridge direction](../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md)
 - [Sales-order PO Number sourcing](../../../2.0/apps/_underscore/features/sales-order-po-number-sourcing.md)

package/knowledge/clients/nychh/features/transfer-order-inventory-quantities.md

@@ -6,7 +6,7 @@ project: _Underscore
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-16
+updated: 2026-09-24
 owners: [jcardinal, apeterson]
 files:
   - _underscore/Model/Nychh/Item.php
@@ -79,7 +79,7 @@ The item-level bridges mirror the header-level SO↔PO direction split documente
 
 Verified 0 SO lines map to >1 PO line, so PO-line `received` **cannot double-count**. Optional deferred hardening (not done): a `UNIQUE(purchaseOrderItemId, salesOrderItemId)` on the bridge as defense-in-depth.
 
-- **⚠ PO-level outbound reads 0 until a separate backfill.** `_qtyCommitted` depends on `PurchaseOrderItems_TransferOrderItems`, which is currently **empty (0 rows)** in prod — so PO-level outbound reads 0 until the transfer-order import populates that bridge. Separate import gap, not this change.
+- **PO-level outbound reads `PurchaseOrderItems_TransferOrderItems` (329, upstream customer-PO lines).** Populated in prod since 2026-09-16; until 2026-09-24 it also held ~3,981 **vendor** PO lines (wrong direction), now moved to 330 by the [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md). The reconcile also creates missing customer-PO lines, which adds stock-in.
 
 #### The override is NOT on every branch — NYCHH PO-line quantities differ per environment
 Verified 2026-09-01 with `git ls-tree` against each `origin/` branch of `_underscore`:
@@ -227,11 +227,14 @@ Discovered 2026-08-28 while standing the Transfer Orders UI up locally: beyond t
 
 - **A custom field is writable/searchable ONLY when BOTH the model declares it (via the NetSuite trait on the client-override model) AND the ACL/metadata rows exist.** Declaring without the ACL row, or granting the ACL without the declaration, each fails with its own error — see the peeled sequence above.
 - **These quantity overrides are NYCHH-only.** They live on `_Model_Nychh_Item` and `_Model_Nychh_PurchaseOrderItem`; do not lift them to the base `_Model_Client_*` — other clients do not have the stocking/transfer two-branch model.
-- **A 0.00 quantity for NYCHH is expected today, not a bug.** Stock-in reads inventory-adjustment links that are not backfilled yet, and PO-level outbound reads a still-empty `PurchaseOrderItems_TransferOrderItems` bridge (see above).
+- **A 0.00 quantity for NYCHH is expected today, not a bug.** Stock-in reads inventory-adjustment links that are not backfilled yet.
 - 🚨 **Every NYCHH PO line reads `_qtyReceived`/`_qtyOnHand`/`_qtyAvailable` = 0.00 right now**, in sandbox **and** production, because `InventoryAdjustmentItems.itemFulfillmentItemId` is NULL on 100% of rows and the override INNER JOINs on it. Blocks the Create Transfer Order picker; needs an integration/data decision, not code. See the OPEN BLOCKER section.
 - **⚠ `_Model_Nychh_PurchaseOrderItem` is on `_production`/`_sandbox-client` but NOT on `_beta`/`_sandbox-dev`** — so NYCHH PO-line quantities are genuinely different numbers per tier. Establish the deployed `_underscore` branch before comparing environments or trusting a repro.
 - **Never eliminate a tenant model override by `ls`-ing your working tree.** Use `git cat-file -e origin/<deployed-branch>:Model/<Slug>/<Model>.php`. This exact mistake cost a session — and a *passing* drift check on the base `Model/Client/` file is what made it feel safe.
 
+## Change history
+- 2026-09-24 — 329 no longer empty; vendor PO lines moved off it to 330. (jcardinal)
+
 ## Related
 - [ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md)
 - [V2 API error codes](../../../2.0/apps/api2/features/v2-api-error-codes.md)

package/knowledge/clients/nychh/features/transfer-order-netsuite-push.md

@@ -6,7 +6,7 @@ project: _Underscore
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-23
+updated: 2026-09-24
 owners: ["bala", "jcardinal"]
 files:
   - _underscore/Model/Client/TransferOrder.php
@@ -203,11 +203,13 @@ email, which must fire *after* this push writes `number` back. The `POST` row ab
 
 ## Data + metadata state (2026-09-02)
 
-- **Prod 2026-09-23:** `PurchaseOrders_TransferOrders` (325) = **1,592 rows**; `TransferOrders.purchaseOrderId`
-  set on 10 rows. The Create Transfer Order modal now writes 325 (header) + 329 (lines) in its single POST
-  ([transfer-orders-page](../../../2.0/apps/toga25-supply/features/transfer-orders-page.md)). An order
-  with no PO link still makes `resolvePurchaseOrderNumber()` return null → push aborts by design.
-- Reverse-named twins 326 / 330 have 0 rows — dead; never read or write them.
+- PO number comes **only** from upstream bridge 325 (customer PO). `TransferOrders.purchaseOrderId` was
+  dropped 2026-09-24. The Create Transfer Order modal writes 325 (header) + 329 (lines) in its single POST
+  ([transfer-orders-page](../../../2.0/apps/toga25-supply/features/transfer-orders-page.md)). No 325 row →
+  `resolvePurchaseOrderNumber()` returns null → push aborts by design. Several POs → joined with `' + '`.
+- 326 / 330 (downstream, vendor POs created FROM the TO) are **live** since 2026-09-24 — written by the
+  1.0 [TO↔PO link reconcile](../../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md).
+  Never read them for the PO # sent to NetSuite; that is the customer PO (325).
 - Prod `InherentRecordChildren` ids: 150 = 312→313, 151 = 312→325, 152 = 312→357; added 2026-09-23
   (`Core/2026-09-23d`): 17→325, 18→329, 313→329.
 - RecordFields: 325 = 2209 id / 2210 uuid / 2211 purchaseOrderId / 2212 transferOrderId; 329 = 2225 / 2226 /
@@ -226,6 +228,7 @@ email, which must fire *after* this push writes `number` back. The `POST` row ab
     It may also need record ACL rows for 325 — untested; an `EZ-1` would be the symptom.
 
 ## Change history
+- 2026-09-24 — PO # bridge-only (purchaseOrderId column dropped); 326/330 no longer dead (downstream vendor POs). (jcardinal)
 
 - 2026-09-17 — Noted that record **312 now carries a second `PUT` interceptor row**
   (`2026-09-15a - TransferOrderEmails.sql`), because the Submitted notification email must fire

package/knowledge/clients/nychh/features/transfer-order-notification-emails.md

@@ -6,7 +6,7 @@ project: Worker
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-23
+updated: 2026-09-24
 owners: ["bala", "rgirish", "jcardinal"]
 files:
   - worker2/Worker/Client/Nychh/TransferOrderEmails.php
@@ -266,6 +266,7 @@ loaded out of the dbchanges2 file so an unresolved `{placeholder}` fails a test.
 unescaped values and both detail-box defects were all found there, not in production.
 
 ## Change history
+- 2026-09-24 — `TransferOrderEmails` reads PO numbers from upstream bridge 325 (column `purchaseOrderId` dropped). (jcardinal)
 - 2026-09-23 — Submitted template put on review hold; missing REVIEW row → job failure note. (jcardinal)
 
 - 2026-09-23 — **The greeting now addresses whoever raised the order, not the site contact.**

package/knowledge/clients/nychh/profile.md

@@ -103,7 +103,7 @@ TOGA 2.0 client on `_underscore`, prod schema `Client_Nychh`. Supply-chain / ful
 - 🚨 **`Client_Nychh.TransferOrders` HAS production data — 1,927 rows (verified 2026-08-31 on `reader1.client.database.togahub.com`).** The transfer-order *tables and data* have been live in prod for a while (the 1.0 NetSuite importer writes them); only the **2026-08-28 UI vertical** (TableView, Core surfaces, nav override) is new. An earlier version said transfer orders were "local only … not yet run on sandbox-client or production", and that stale line produced a wrong recommendation — that a prod-to-local restore would *wipe* the transfer-orders feature. **Never infer prod state from this repo or from a migration's run status; read prod.** Restoring or overwriting `Client_Nychh` destroys real transfer-order rows.
 - **The Transfer Orders SCREEN is NYCHH-only and new (2026-08-28).** NYCHH is the first — and today the only — tenant with a `transfer-orders` TableView (`Client_Nychh/2026-08-28a`, which also seeds the ACL chain for record 351 that the Status column silently depends on) and the one `SurfaceOverrides` row that reveals the nav item (`2026-08-28b`, client-wide, matching how this tenant grants Sales Orders and Inventory — NYCHH does not scope navigation by role). The Core surfaces and stage colour tokens are **shared/neutral**, hidden for every other client until they opt in. The seven migration files were **committed 2026-08-31** (`dbchanges2` commit `1c3fe2e`, branch `TRUE-80852`, pushed); run order is **`Core/` → `Client/` fan-out → `Client_Nychh/`**, because the client files reference Core record ids and the NYCHH TableView/ACL need the columns the fan-out files add. Run state per environment must be **verified against that environment**, never assumed from the repo. **beta is blocked** because it lacks the `TransferOrderStages` table. The **Create Transfer Order** modal was reworked 2026-09-01 and its data layer is wired, but 🚨 **the item picker shows zero selectable lines for NYCHH** — see the availability blocker below. See [Transfer Orders page](../../2.0/apps/toga25-supply/features/transfer-orders-page.md).
 - 🚨 **The transfer-order ACL + schema on prod/sandbox are UNTRACKED (2026-08-28).** Record and field ACL for records 312/313, their logic-group/expression chain, and the `TransferOrderItems.dtCreated`/`dtUpdated` columns were all hand-applied when the NetSuite TransferOrder POST was enabled — **no `dbchanges2` file creates any of it**, so a fresh environment can reproduce neither the UI nor the importer. Reconstructed in `Client_Nychh/2026-08-28c` (ACL, faithful — role 2 deliberately excluded) and `Client/2026-08-28b` (columns; root cause is the blank client template, which affects **every** tenant). See [transfer-order inventory & quantities](./features/transfer-order-inventory-quantities.md).
-- **Create Transfer Order links POs (2026-09-23)** — one POST writes header bridge 325 + line bridge 329 (Core `2026-09-23d` inherent children). Prod 325 has 1,592 rows; 326/330 twins are dead. See [transfer-order push](./features/transfer-order-netsuite-push.md).
+- **Create Transfer Order links POs (2026-09-23)** — one POST writes header bridge 325 + line bridge 329 (Core `2026-09-23d` inherent children). 325/329 = upstream customer PO, 326/330 = downstream vendor POs (live since 2026-09-24, see [TO↔PO link reconcile](../../1.0/apps/library/features/transfer-order-purchase-order-link-reconcile.md)). `TransferOrders.purchaseOrderId` dropped 2026-09-24 → read `_purchaseOrderNumbers`. See [transfer-order push](./features/transfer-order-netsuite-push.md).
 - **Two-branch inventory quantities + TransferOrder V2 enablement** — NYCHH-only on-hand/available/fulfilled/backordered model on `_Model_Nychh_Item`, plus the client-override models + ACL rows that let a NetSuite TransferOrder POST succeed. See [transfer-order inventory & quantities](./features/transfer-order-inventory-quantities.md).
 - 🚨 **OPEN BLOCKER — every NYCHH PO line reports availability 0, in sandbox AND production (verified 2026-09-01).** The deployed `_Model_Nychh_PurchaseOrderItem` sources stock-in from inventory adjustments and `INNER JOIN`s `InventoryAdjustmentItems.itemFulfillmentItemId`, which is **NULL on 100% of rows** (292/292 sandbox, 317/317 prod). So `_qtyReceived` / `_qtyOnHand` / `_qtyAvailable` are all `0.00` for every purchase-order line, and the **Create Transfer Order item picker has nothing to show**. Needs an **integration / data-owner decision** — backfill the FK, or change the override's stock-in source (base PO item receipts return real numbers today). Not a frontend or ACL defect, and **not** fixed by `Client/2026-09-01a`. See [transfer-order inventory & quantities](./features/transfer-order-inventory-quantities.md).
 - 🚨 **`_Model_Nychh_PurchaseOrderItem` is NOT on every `_underscore` branch (verified 2026-09-01).** `Model/Nychh/PurchaseOrderItem.php` exists on **`_production`** and **`_sandbox-client`** but is **absent from `_beta`** and **`_sandbox-dev`**. Because `_underscore` is pulled at deploy by branch, NYCHH PO-line `_qty*` values are **different numbers per tier**: prod/sandbox-client run the inventory-adjustment formula (0.00 until the NetSuite link is backfilled), beta/sandbox-dev fall back to the base item-receipt formula and report real quantities. **Never eliminate a tenant override by `ls`-ing your working tree** — use `git ls-tree -r --name-only origin/<branch>`. That mistake cost a full session chasing a non-existent "API returns 0" bug. See [transfer-order inventory & quantities](./features/transfer-order-inventory-quantities.md).

package/package.json

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