toga-ai 1.0.884 → 1.0.885

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

@@ -6,8 +6,8 @@ project: Database Changes
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-16
-owners: [bala]
+updated: 2026-09-24
+owners: [bala, jcardinal]
 files:
   - dbchanges2/Client_Nychh/2026-09-09c - UpdateLocationShippingAddresses.sql
   - dbchanges2/Client_Nychh/2026-09-09a - DeleteTestContacts.sql
@@ -59,7 +59,7 @@ The Create Transfer Order screen picks a **Target Contact** from `Contacts` thro
 
 - **🚩 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).
-- **🚩 OPEN — is location 2 "NYC Health + Hospitals" a real delivery place?** Destination on **1,832 of 1,939** NYCHH transfer orders (next highest Coney Island at 27), so it behaves as a **catch-all destination**. Every one of those 1,832 has `createdByUserId` **NULL** — none created by a person on the Create Transfer Order screen. They come from the automated NetSuite import (277 on 2026-08-29, 1,528 on 2026-08-30, then 1–3/day). Its address was set to NetSuite's value (**1400 Pelham Parkway South, Bronx NY 10461**) at the developer's direction, but that is **Jacobi Medical Center's** address. Still with the PM: is this a real receiving place, or should the import pick the actual hospital? **Do not treat its address as settled**; see [the NetSuite transfer-order import](./netsuite-transfer-order-import.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.
 - **⚠ An `Addresses` row can be shared by several locations** (ids 1 and 2 shared `Addresses.id = 1` here). Always check before an in-place UPDATE; insert + repoint the junction instead.

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

@@ -6,7 +6,7 @@ project: Library
 client: nychh
 type: client-feature
 status: active
-updated: 2026-09-21
+updated: 2026-09-24
 owners: [jcardinal, bala, rgirish]
 files:
   - library/app/api/toga2.php
@@ -119,6 +119,14 @@ Verified in production 2026-09-02 (while building the **outbound** push): on a N
 
 **Deploy:** the library change (the skip) is deployed and verified over many cron cycles; the worker change (the missing 3rd arg + two stale-comment fixes) is the current fix — **redeploy worker** to pick it up.
 
+#### FIX written 2026-09-24 (NOT deployed) — import overwrote the user's destination with catch-all location 2
+**Root cause (proven):** the outbound push sends every NYCHH TO under client-level customer **28908**; the real site is only on the NetSuite **ship-to**. The stocking-SO branch of `syncTransferOrderFromNetsuite()` resolves destination from `entity` → `Locations.c_netsuiteInternalCustomerId` → 28908 → **location 2**, and the change-check PUTs it over the user's choice on any later NetSuite update (e.g. status). Proof: TO **1962** / SO **290951** (internal 7520216) — `Logs_Nychh.Api` **3391680** front-end POST dest 23 (Segundo Ruiz Belvis), **3407179** import PUT (API "Agilant") dest 2.
+- **Keep existing destination** when `entity == $clientConfiguration['netsuiteCustomerInternalId']` AND `$clientConfiguration['isParentCustomer'] === true` AND the TO already has one. `isParentCustomer` gate: for a single-customer client the client-level customer IS the real destination.
+- `common_sync_togasupply.php` sets `$clientConfig['netsuiteCustomerInternalId']` from the fetched client record. Missing key → old behavior.
+- **New NetSuite-entered TOs under the client customer** (same gates, no existing TO): `resolveTransferOrderDestinationFromShipTo()` (+ `normalizeShipToText`, `getShipToLocations` = `GET /locations` depth 3, static per-run cache per client uuid; failure/empty logged, not cached). Match = 5-digit zip equal AND location line1 == or word-prefix of NS addr1 (addr1 can carry extra text, e.g. Queens "8268 164th St Goethels Ave and Parsons Blvd"); street words abbreviated (Parkway→PKWY, South→S…). Shared buildings (Harlem/Renaissance 506 Lenox; Segundo Ruiz Belvis/Gotham Health Belvis 545 E 142nd) → tie broken by location name inside NS addressee. Client-level location never picked. No/ambiguous match → keep location 2 + `error_log` grep `resolveTransferOrderDestinationFromShipTo:` (no throw — would freeze the section). CTO AGREE; runner-up = NetSuite addressbook-id mapping (needs new field) — revisit if logs show many misses.
+- **Unproven live:** depth=3 `/locations` returning `primaryLocationAddress.address` for the Agilant API role. Check the log grep after deploy.
+- **Data repair SQL handed to dev (not run):** TO 1962→23, 1959→24, 1960→24, 1961→9, 1966→20 (NS 291004, ship-to Queens), guarded `AND destinationLocationId = 2`.
+
 ### Item-fulfillment transfer-order line link
 `ItemFulfillmentItems.transferOrderItemId` must populate so the 2.0 stock-out quantity calc can tie a fulfillment back to its transfer-order line. In `syncItemFulfillmentFromNetsuite`:
 - added `itemFulfillmentItems.transferOrderItem.uuid` to the GET `fields` allowlist,
@@ -209,7 +217,7 @@ Found by a fleet sweep of `NETSUITE_EXECUTION_MODE_*` across all 22 netsuite cli
 
 ## Gotchas / known issues
 
-- **🚩 The import sends almost everything to catch-all destination location 2 "NYC Health + Hospitals" — 1,832 of 1,939 transfer orders**, next highest Coney Island at 27, and **every one has `createdByUserId` NULL** (277 on 2026-08-29, 1,528 on 2026-08-30, then 1–3/day). Whether that location is a real receiving place or the import should resolve the actual hospital is **open with the PM**; its address is currently Jacobi's. Do not assume the destination is correct: [location shipping addresses](./location-shipping-addresses.md).
+- **Location 2 count (1,832 of 1,939) is not a real ship pattern** — at least partly the 2026-09-24 overwrite bug + NetSuite-entered orders under 28908. Location 2 address is now 55 Water St 10041. See the destination fix above.
 - **Real-TrnfrOrd item receipts are disabled — see the DEFERRED section above.** A receipt whose `createdFrom` is a real Transfer Order is skipped by design; do not read that as the importer being broken.
 - **Order 128829 (no location anywhere) is unresolved** — see the origin-resolution section. Do not assume the importer is broken if this single order is stuck; every located order imports.
 - **Routing mode is declared by the wrapper and there is NO fallback.** If a future client should route transfer orders by the stocking flag, add `const TRANSFER_ORDER_DETECTION_MODE = App_Api_Toga2::TRANSFER_ORDER_DETECTION_MODE__STOCKING_FLAG;` before its `require_once 'common_sync_togasupply.php';` — and confirm that client actually sets `custbody_stocking_order` in NetSuite. Omitting the mode no longer lands everything in SalesOrders; it **throws** (deliberate — see the shared engine doc).
@@ -219,6 +227,8 @@ Found by a fleet sweep of `NETSUITE_EXECUTION_MODE_*` across all 22 netsuite cli
 ## Change history
 - 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)
+
 ## Related
 - [NetSuite → TOGa Supply per-client sync (engine)](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md)
 - [toga2 API client and bridge](../../../1.0/apps/library/features/toga2-api-client-and-bridge.md)

package/knowledge/clients/nychh/profile.md

@@ -18,7 +18,7 @@ project: _Underscore
 client: nychh
 type: profile
 status: active
-updated: 2026-09-23
+updated: 2026-09-24
 owners: ["jcardinal", "apeterson", "bala", "akhokhani"]
 files:
   - dbchanges2/Client_Nychh/2026-09-02a - TransferOrderNetsuitePushInterceptor.sql
@@ -66,7 +66,7 @@ TOGA 2.0 client on `_underscore`, prod schema `Client_Nychh`. Supply-chain / ful
 - **Worker tiers:** `worker2` (2.0) runs the NYCHH asset-tag backfill; `worker`/`library` (1.0) run the NetSuite→TOGa Supply sync and the asset-tag verification/backfill diagnostics.
 
 ## Key features (this client)
-- **All 24 shipping locations shared ONE address until 2026-09-09 — the head-office Accounts Payable bill-to (50 Water St).** Each location had its own `Addresses` row (261-303) but they held identical values, and locations 1 + 2 shared `Addresses.id = 1`. `Client_Nychh/2026-09-09c - UpdateLocationShippingAddresses.sql` backfilled each from its NetSuite customer's `defaultshipping` address (applied + verified in prod: 22 distinct addresses over 24 locations). It only ever showed on the **transfer-order** screens, because `TransferOrders` has no ship-to column while `SalesOrders` carries its own `shipToAddressId`. 🚩 Still open: catch-all destination **location 2 "NYC Health + Hospitals"** (1,832 of 1,939 transfers, all `createdByUserId` NULL) currently holds **Jacobi's** address, and Bellevue/Jacobi carry NetSuite customer ids (29275 / 31917) that no longer exist. See [location shipping addresses](./features/location-shipping-addresses.md).
+- **All 24 shipping locations shared ONE address until 2026-09-09 — the head-office Accounts Payable bill-to (50 Water St).** Each location had its own `Addresses` row (261-303) but they held identical values, and locations 1 + 2 shared `Addresses.id = 1`. `Client_Nychh/2026-09-09c - UpdateLocationShippingAddresses.sql` backfilled each from its NetSuite customer's `defaultshipping` address (applied + verified in prod: 22 distinct addresses over 24 locations). It only ever showed on the **transfer-order** screens, because `TransferOrders` has no ship-to column while `SalesOrders` carries its own `shipToAddressId`. Catch-all **location 2 "NYC Health + Hospitals"** now at 55 Water St 10041; its big TO count was mostly an import overwrite bug (fix 2026-09-24, see [NetSuite TO import](./features/netsuite-transfer-order-import.md)), and Bellevue/Jacobi carry NetSuite customer ids (29275 / 31917) that no longer exist. See [location shipping addresses](./features/location-shipping-addresses.md).
 - 🚨 **sandbox-client (`Core` + `Client_Nychh`) was reset from PRODUCTION again on 2026-09-04** — second reset in two days (first, 2026-09-03, over the stale `purchase-orders` TableView). Every "verified on <date>" sandbox-client claim in this profile dated **before 2026-09-04 now describes whatever prod had**. The 2026-09-01 → 2026-09-03 `dbchanges2` migrations may need re-running on sandbox-client. Re-read the environment before trusting any sandbox state; procedure + re-run order in [Targeting the right database](../../2.0/apps/dbchanges2/workflows/targeting-the-right-database.md).
 - **Transfer orders push OUT to NetSuite as $0 sales orders - LIVE and verified 2026-09-08.** NYCHH is the first and only client on that path; switched on purely by its `transfer-orders` (record 312) `POST`/`POST` interceptor row. NetSuite SO **289187** (id 7463537) was created from it. **The NetSuite customer is the CLIENT - 4490 / 28908 - on every transfer order, never the destination location** (a first cut sent the destination and put SO 7462031 on sub-customer 33674 "CHS"; `Locations` 1-26 are "Shipping" type mapping to sub-customers under 4490, and the bug hid because almost every order picks location 2, whose id *is* 28908). Origin location is still the NetSuite **warehouse**, and `TransferOrders.description` now goes out as the NetSuite `memo`, shown as **ORDER DESCRIPTION**. See [TransferOrder → NetSuite push](./features/transfer-order-netsuite-push.md).
 - **Transfer orders closed in NetSuite never reached the Closed stage - 18 stuck on `Pending`, oldest 2022 (fix written 2026-09-08, NOT deployed).** The 1.0 sync skips a `Closed` order before the transfer-order branch, so the importer's `case 'Closed'` was dead code. Two NYCHH gates make this confusing to verify: the transfer-order status refresh is nested inside `IS_ENABLED_INTEGRATION_SALES_ORDERS` (Jeff enabled the feeds 2026-08-28 `b063f05f` and disabled sales orders, POs, invoices and item receipts on 2026-09-03 `2b321e9d` - where every NYCHH cursor stops), and the seek cursor never re-reads a passed order. 🚨 **Their `NETSUITE_LAST_SYNC_CURSOR_ITEM_RECEIPTS` is stale at 2024-08-06**, so re-enabling that feed replays ~2 years. See [NetSuite → TransferOrders import](./features/netsuite-transfer-order-import.md).

package/package.json

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