per-engineer front door — design & rollout plan →
All 112 client tables that were empty on both stacks in every one of the six tenant pairs. Empty-vs-empty proves the schemas agree and nothing about data, so this page answers what a pair cannot: what each table is bound to server-side, and what is actually stopping a row from travelling. Every column is computed — our maps and inbound maps are read live from the repo, the legacy column from the extracted BizTalk maps and the two live registries, the counts from a census of FMP360TST across all organisations.
Recomputed 2026-08-04 evening. The union moved to 163 parity-proven / 2 differed / 119 structure-only (from 164 / 6 / 114). One pair closed 6 of these tables outright — TaxRates, StockLevelTypes, StockLevelTypes_MaterialMutationReasons, OperationalPropertyDefinitions, CustomFieldAssetTypes, Materials_QuoteLineFeatureTypes_Mandatory. Two more () left this page for the differed bucket, both attributed: all six were SEEDED today and proven by the clean wilchem pair (261/261 equal, 90 non-empty, delta 0.15 h). Nine gomocha closures reverted with F128 and are re-provable once org 76 is quiet.
The one actionable row on this page: legacy accepts the message, our stack has no consumer for it. Everything else here is bound on both sides or bound on neither.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| MaterialReservationMutations | device -> server: MSG_MaterialReservationMutation — no consumer on our stack | nothing | — | — | Legacy ingests this as a Gateway import, not a BizTalk map, which is why it appears in no .btm and no XSD. The inbox table dbo.MaterialReservationMutations was created 2026-07-13 and DROPPED 2026-07-20 on a 'no Horizon consumer' premise that no longer holds now that reservations are in scope — establish the consumer before re-adding it. |
Our stack has a producer path and legacy has the matching one. A row WOULD travel; the pair is empty because no row reached those six engineers.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| Activities_Characteristics | order <- dbo.fv_activity_characteristic (4 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 13 | — | 13 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Activities_Files | FILE channel — fv_sendfile + fv_sendfileactivity (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientDebrief.xsdFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| AssetDebriefs | order <- dbo.fv_debrief_serviceobject (28 cols) · msg-assetdebrief -> dbo.fv_debrief_serviceobject · msg-debrief -> dbo.fv_debrief · msg-debrief -> dbo.fv_debrief_serviceobject | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ AssetDebrief_To_TMP_DebriefServiceobjectbtm↑ Debrief_To_TMP_Debrieffv_commtable DAssetDebrief.xsdDebrief.xsdWorkOrder.xsd | 131,235 | — | 131235 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneRENDER-PROVEN (server -> device): 2 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| Assets_ContactPersons | order <- dbo.fv_person_serviceobject (6 cols) · quote <- dbo.fv_person_serviceobject (6 cols) | btm↓ Quote_To_IWMS_Quotebtm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AQQuote.xsdWorkOrder.xsd | 1,996 | — | 1996 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Assets_Files | FILE channel — fv_sendfile + fv_sendfileserviceobject (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientAssetFile.xsdDebrief.xsdFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| Audits_AssetFeatures | order <- dbo.Audits_AssetFeatures (11 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 3 | — | 3 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Contracts_Assets | order <- dbo.fv_contract_serviceobject (4 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 96,077 | — | 96077 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneORDER-CORPUS PROVEN: identical row counts on 2 of 2 compared order entries and NEVER differed on any of them. Oracle: 897 legacy MSG_WO entries from 115 captured device-facing responses across five days and all six paired engineers, matched to our ledger payloads on the SET of WorkOrders ids. 772 of the 875 comparable entries matched exactly on every table. A WIRE claim — not delivery, not display.ORDER-WIRE PROVEN (legacy = ours, exact): 2 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 2 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| Contracts_Skills | order <- dbo.fv_contractcapability (4 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 4 | — | 4 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Crews_WorkOrders | order <- dbo.Crews_WorkOrders (8 cols) · msg-crew -> dbo.Crews_WorkOrders · MSG_Crew (CrewMapper) | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ MAP_IWMS_Crew_To_TMP_Crewfv_commtable ACrew.xsdMasterData.xsdWorkOrder.xsd | 19 | — | 19 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Customers_Skills | order <- dbo.fv_customercapability (4 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 7 | — | 7 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| FileTypes_AttachmentsEntityTypes | masterdata <- dbo.FileTypes_AttachmentsEntityTypes (7 cols) | btm↓ MasterData_To_IWMS_MasterDatafv_commtable no SendWith* blockfv_commengdata armedMasterData.xsd | 27 | 15,073 | 27 source rows, armed on 15073 engineer rows (5026 unsent) — but not for the six paired engineersArmed (15,073 rows fleet-wide) and delivered by NEITHER stack — our ledger has never rendered it for anyone and legacy ships zero. Armed-but-unsent residue, not a parity gap. |
| HistoryItems_Files | FILE channel — fv_sendfile + fv_sendfilehistory (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| InformationLines | order <- dbo.fv_informationline (6 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 72,552 | — | 72552 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| LineItems_MaterialMutations | order <- dbo.iwms_LineItems_MaterialMutations (4 cols) · msg-debrief -> dbo.iwms_LineItems_MaterialMutations | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debrieffv_commtable DDebrief.xsdWorkOrder.xsd | 134,139 | — | 134139 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| MaterialReservations | order <- dbo.MaterialReservation (11 cols) | fv_commtable A | 173 | — | 173 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneServer-side the name is SINGULAR (MaterialReservation) and it rides the ORDER channel as an fv_commtable SendWithActivity block — a lookup keyed on the client's plural spelling misses it. 173 rows exist, only 9 sit on an activity with any engineer and 0 on the paired engineer 808 (F119), which is why the pair sees 0 = 0.RENDER-PROVEN (server -> device): 1 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog).BOTH STACKS WITHHELD IT: reservation qty 1 on the live activity; legacy 0 / ours 0. Agreement, not a gap — the open question is the send set, not the map. |
| Messages_Files | FILE channel — fv_sendfile + fv_sendfilemessage (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| OperationalHours | order <- dbo.OperationalHours (10 cols) | btm↓ Quote_To_IWMS_Quotebtm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ AssetDebrief_To_TMP_DebriefServiceobjectbtm↑ Debrief_To_TMP_Debrieffv_commtable AWorkOrder.xsd | 136 | — | 136 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneORDER-WIRE PROVEN (legacy = ours, exact): 2 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 3 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| OperationalPropertyValues | order <- dbo.iwms_OperationalPropertyValues (6 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 0 | — | source table EMPTY across every TST organisation — nothing to deliver |
| Payments | order <- dbo.iwms_Payments (10 cols) · msg-debrief -> dbo.iwms_Payments · msg-deposit -> dbo.iwms_Deposits · msg-deposit -> dbo.iwms_Payments | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debriefbtm↑ Deposit_To_TMP_Depositfv_commtable no SendWith* blockDebrief.xsdDeposit.xsdWorkOrder.xsd | 59 | — | 59 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneBOTH STACKS WITHHELD IT: iwms_Payments row 52.00 created 12:28:20 on the live activity; legacy 0 / ours 0. Agreement, not a gap — the open question is the send set, not the map. |
| ProjectInfo | order <- dbo.ProjectInfo (10 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderfv_commtable AWorkOrder.xsd | 13,635 | — | 13635 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| QuestionListDebriefs | quote <- dbo.fv_debrief_questionlist (7 cols) · msg-quote -> dbo.fv_debrief_questionlist | btm↓ Quote_To_IWMS_Quotebtm↑ Quote_To_TMP_Quotefv_commtable DQQuote.xsd | 488,370 | — | 488370 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Questions_Files | FILE channel — fv_sendfile + fv_sendfilequestion (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| QuoteGroups | order <- dbo.QuoteGroups (8 cols) · quote <- dbo.QuoteGroups (8 cols) · msg-quote -> dbo.QuoteGroups | btm↓ Quote_To_IWMS_Quotebtm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Quote_To_TMP_Quotefv_commtable AQQuote.xsdWorkOrder.xsd | 132 | — | 132 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneORDER-CORPUS PROVEN: identical row counts on 2 of 2 compared order entries and NEVER differed on any of them. Oracle: 897 legacy MSG_WO entries from 115 captured device-facing responses across five days and all six paired engineers, matched to our ledger payloads on the SET of WorkOrders ids. 772 of the 875 comparable entries matched exactly on every table. A WIRE claim — not delivery, not display.ORDER-WIRE PROVEN (legacy = ours, exact): 8 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 8 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| QuoteLineFeatures | order <- dbo.QuoteLineFeatures (13 cols) · quote <- dbo.QuoteLineFeatures (14 cols) · msg-quote -> dbo.QuoteLineFeatures | btm↓ Quote_To_IWMS_Quotebtm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Quote_To_TMP_Quotefv_commtable AQQuote.xsdWorkOrder.xsd | 0 | — | source table EMPTY across every TST organisation — nothing to deliver |
| QuoteLines | order <- dbo.QuoteLines (13 cols) · quote <- dbo.QuoteLines (13 cols) · msg-quote -> dbo.QuoteLines | btm↓ Quote_To_IWMS_Quotebtm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Quote_To_TMP_Quotefv_commtable AQQuote.xsdWorkOrder.xsd | 437 | — | 437 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneORDER-CORPUS PROVEN: identical row counts on 2 of 2 compared order entries and NEVER differed on any of them. Oracle: 897 legacy MSG_WO entries from 115 captured device-facing responses across five days and all six paired engineers, matched to our ledger payloads on the SET of WorkOrders ids. 772 of the 875 comparable entries matched exactly on every table. A WIRE claim — not delivery, not display.ORDER-WIRE PROVEN (legacy = ours, exact): 56 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 56 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| QuoteStatusHistoryItems | quote <- dbo.QuoteStatusHistoryItems (9 cols) · msg-quote -> dbo.QuoteStatusHistoryItems | btm↓ Quote_To_IWMS_Quotebtm↑ Quote_To_TMP_Quotefv_commtable no SendWith* blockQuote.xsd | 1,266 | — | 1266 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
| Quotes_Files | FILE channel — fv_sendfile + fv_sendfilequote (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientFilesToClient.xsdQuote.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| Rates | masterdata <- dbo.Rates (17 cols) · order <- dbo.Rates (18 cols) · msg-debrief -> dbo.Rates | btm↓ MasterData_To_IWMS_MasterDatabtm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Map_ClientNewWorkOrder_OrderWebService_AddOrderbtm↑ Debrief_To_TMP_Debriefbtm↑ NewWorkOrder_To_Canonicalfv_commtable ADebrief.xsdMasterData.xsdNewWorkOrder.xsdWorkOrder.xsd | 1,668 | — | 1668 source rows and NO fv_engdata_* arm table — the per-engineer master-data registry has no entry, so nothing is selectedPAIR-PROVEN gomocha/808 2026-08-04: legacy 3 = ours 3. the three subcontractor rates on P2595418:2 — Extra allowance 50, Working hours 40/60min, Travel time 10.ORDER-WIRE PROVEN (legacy = ours, exact): 3 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 3 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| Signatures | order <- dbo.fv_debrief_signature (5 cols) · msg-debrief -> dbo.fv_debrief_signature · msg-quote -> dbo.fv_debrief_signature | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debriefbtm↑ Quote_To_TMP_Quotefv_commtable DActivityStatus.xsdDebrief.xsdQuote.xsdWorkOrder.xsd | 736,391 | — | 736391 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneRENDER-PROVEN (server -> device): 1 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| TimeSlices | order <- dbo.fv_labour (12 cols) · msg-debrief -> dbo.fv_labour | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debrieffv_commtable DDebrief.xsdWorkOrder.xsd | 3,529,869 | — | 3529869 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneRENDER-PROVEN (server -> device): 3 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog).ROUND-TRIP PROVEN (device -> server): 3 row(s) in dbo.fv_labour from a real device action (Windows client, engineer 6060). 3 activity-linked labour rows from the MSG_Debrief at 13:27:14, applied with no error. |
| TimeSlices_LineItems | order <- dbo.iwms_LineItems_labour (5 cols) · msg-debrief -> dbo.iwms_LineItems_labour | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debrieffv_commtable DDebrief.xsdWorkOrder.xsd | 202,691 | — | 202691 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneORDER-WIRE PROVEN (legacy = ours, exact): 1 row(s) on BOTH sides for order ba725642 on engineer 808 (org 76) — legacy's own captured device-facing JSON against our ledger payload for the same order. That comparison matched 28 of 28 tables and 2,323 of 2,323 rows with zero differences. A WIRE claim for one order on one engineer: not delivery, not display, and not yet repeated on a second order.RENDER-PROVEN (server -> device): 1 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| TravelItems | order <- dbo.TravelItems (8 cols) · msg-debrief -> dbo.TravelItems | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Debrief_To_TMP_Debrieffv_commtable DDebrief.xsdWorkOrder.xsd | 466,924 | — | 466924 rows exist; the block rides an order/quote and none of the paired engineers' orders carried oneRENDER-PROVEN (server -> device): 1 row(s) of this client table are present in the payload of MSG_WO a1fa54c3 (engineer 6060, org 76, 2026-08-04 20:25 UTC) — the payload IS the wire message, so the map, the collector and the render all work for this table. It is NOT a parity claim (no legacy half was captured) and NOT a delivery claim (the message is still Pending behind a 712-message backlog). |
| WorkOrders_Files | FILE channel — fv_sendfile + fv_sendfileserviceorder (FileProducer -> FilesToClientMapper) | btm↓ FilesToClient_To_IWMS_FilesToClientFilesToClient.xsd | — | — | a file must be linked to the entity and queued for the engineer; none of the paired engineers had one pending |
| WorkOrders_WorkOrders | order <- dbo.fv_serviceorder_serviceorder (5 cols) | btm↓ ServiceOrder_To_IWMS_WorkOrderbtm↑ Map_ClientNewWorkOrder_OrderWebService_AddOrderfv_commtable ANewWorkOrder.xsdWorkOrder.xsd | 30,164 | — | 30164 rows exist; the block rides an order/quote and none of the paired engineers' orders carried one |
Device-authored. The inbound map/mapper names the server table each block writes to, so the only thing missing is the device action that creates the row.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| AssetDebriefs_Files | device -> server: MSG_AssetFile (AssetFileMapper) | AssetFile.xsdDebrief.xsd | — | — | device-authored; the round trip has not driven this action yet |
| AssetFeatureDebriefs | msg-assetfeaturedebrief -> dbo.fv_debrief_serviceobjectfeature (12 cols) · msg-debrief -> dbo.fv_debrief_serviceobjectfeature (11 cols) | btm↑ AssetFeatureDebrief_To_TMP_DebriefServiceobjectFeaturebtm↑ Debrief_To_TMP_DebriefAssetFeatureDebrief.xsdDebrief.xsd | — | — | device-authored; empty until the debrief/quote action that creates it runs |
| ContactPersonDebriefs | msg-contactpersondebrief -> dbo.fv_debrief_person (19 cols) | btm↑ ContactPersonDebrief_To_TMP_DebriefPersonContactPersonDebrief.xsd | — | — | device-authored; empty until the debrief/quote action that creates it runs |
| Deposits | msg-deposit -> dbo.iwms_Deposits (6 cols) | btm↑ Deposit_To_TMP_DepositDeposit.xsd | — | — | device-authored; empty until the debrief/quote action that creates it runs |
| InterruptItems | msg-debrief -> dbo.fv_activitystatus (3 cols) | btm↑ Debrief_To_TMP_DebriefDebrief.xsd | — | — | device-authored; empty until the debrief/quote action that creates it runs |
| MaterialMutationHeaders | device -> server: MSG_MaterialMutation (MaterialMutationMapper) | btm↑ MaterialMutation_To_TMP_MaterialMutationMaterialMutation.xsd | — | — | device-authored; the round trip has not driven this action yet |
| ProblemRegistrations | msg-debrief -> dbo.ProblemRegistrations (8 cols) · msg-debrief -> dbo.fv_debrief (3 cols) | btm↑ Debrief_To_TMP_Debrieffv_commtable DDebrief.xsd | 466,318 | — | device-authored; empty until the debrief/quote action that creates it runs |
| TimeSheets | msg-startshift -> dbo.fv_labour (8 cols) | btm↑ StartShift_To_TMP_StartShiftDebrief.xsdStartShift.xsd | — | — | device-authored; empty until the debrief/quote action that creates it runsROUND-TRIP PROVEN (device -> server): 4 row(s) in dbo.fv_labour from a real device action (Windows client, engineer 6060). 7 MSG_StartShift messages applied to 4 shift rows (13:23:00-13:32:00 closed, 13:33 open) — the apply is keyed, not per-message. Also 1=1 on the 2026-08-03 Android round trip. The pair still reads 0=0 because engineer 808 had no open shift at capture time. |
Shipped by the dynamic per-tenant path on both stacks (fv_commengdata arm over dbo.CustomTable_*). Nothing to implement. VERDICT (2026-08-04): class R — 20 of 22 hold zero rows on all 37 organisations, and the two that hold rows sit on orgs 127 and 238, which have 21 and 60 active engineers but no device credentials in tenant-credentials.json. Deliverable, not deliverable to us — and seeding a paired org would prove our own delivery of invented data, not these tenants.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| CustomTable_AssetAction | per-tenant custom table — dbo.CustomTable_AssetAction via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 6 | 224 | 6 rows, armed on 224 engineer rows — but only on organisations none of the six pairs coverThe 6 rows sit on organisations 127 and 238, neither of which is paired. Pair an engineer on 127 rather than seeding onto a paired tenant. |
| CustomTable_Code2 | per-tenant custom table — dbo.CustomTable_Code2 via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 2,262 | the data table is EMPTY on every TST organisation — declaration is not population, and 2262 arm rows change nothing |
| CustomTable_ExaminationCondition | per-tenant custom table — dbo.CustomTable_ExaminationCondition via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 320 | the data table is EMPTY on every TST organisation — declaration is not population, and 320 arm rows change nothing |
| CustomTable_General_Support_Type | per-tenant custom table — dbo.CustomTable_General_Support_Type via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 104 | the data table is EMPTY on every TST organisation — declaration is not population, and 104 arm rows change nothing |
| CustomTable_LinePayments | per-tenant custom table — dbo.CustomTable_LinePayments via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 0 | the data table is EMPTY on every TST organisation — declaration is not population, and 0 arm rows change nothing |
| CustomTable_NewTable | per-tenant custom table — dbo.CustomTable_NewTable via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 20 | the data table is EMPTY on every TST organisation — declaration is not population, and 20 arm rows change nothing |
| CustomTable_Officelocations | per-tenant custom table — dbo.CustomTable_Officelocations via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 30 | the data table is EMPTY on every TST organisation — declaration is not population, and 30 arm rows change nothing |
| CustomTable_Optical_Failure | per-tenant custom table — dbo.CustomTable_Optical_Failure via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 70 | the data table is EMPTY on every TST organisation — declaration is not population, and 70 arm rows change nothing |
| CustomTable_OrderAction | per-tenant custom table — dbo.CustomTable_OrderAction via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 2 | 80 | 2 rows, armed on 80 engineer rows — but only on organisations none of the six pairs coverThe 2 rows sit on organisation 127, which is not paired. Same remedy as CustomTable_AssetAction. |
| CustomTable_Order_Type | per-tenant custom table — dbo.CustomTable_Order_Type via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 84 | the data table is EMPTY on every TST organisation — declaration is not population, and 84 arm rows change nothing |
| CustomTable_ST | per-tenant custom table — dbo.CustomTable_ST via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 30 | the data table is EMPTY on every TST organisation — declaration is not population, and 30 arm rows change nothing |
| CustomTable_UnitCode | per-tenant custom table — dbo.CustomTable_UnitCode via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 64 | the data table is EMPTY on every TST organisation — declaration is not population, and 64 arm rows change nothing |
| CustomTable_VehicleColour | per-tenant custom table — dbo.CustomTable_VehicleColour via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 28 | the data table is EMPTY on every TST organisation — declaration is not population, and 28 arm rows change nothing |
| CustomTable_VehicleCondition | per-tenant custom table — dbo.CustomTable_VehicleCondition via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 0 | the data table is EMPTY on every TST organisation — declaration is not population, and 0 arm rows change nothing |
| CustomTable_VehicleType | per-tenant custom table — dbo.CustomTable_VehicleType via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 15 | the data table is EMPTY on every TST organisation — declaration is not population, and 15 arm rows change nothing |
| CustomTable_Vehicle_Condition | per-tenant custom table — dbo.CustomTable_Vehicle_Condition via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 35 | the data table is EMPTY on every TST organisation — declaration is not population, and 35 arm rows change nothing |
| CustomTable_code1 | per-tenant custom table — dbo.CustomTable_code1 via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 2,110 | the data table is EMPTY on every TST organisation — declaration is not population, and 2110 arm rows change nothing |
| CustomTable_code3 | per-tenant custom table — dbo.CustomTable_code3 via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 1,080 | the data table is EMPTY on every TST organisation — declaration is not population, and 1080 arm rows change nothing |
| CustomTable_code4 | per-tenant custom table — dbo.CustomTable_code4 via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 2,110 | the data table is EMPTY on every TST organisation — declaration is not population, and 2110 arm rows change nothing |
| CustomTable_nights | per-tenant custom table — dbo.CustomTable_nights via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 0 | the data table is EMPTY on every TST organisation — declaration is not population, and 0 arm rows change nothing |
| CustomTable_schedule_type | per-tenant custom table — dbo.CustomTable_schedule_type via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 30 | the data table is EMPTY on every TST organisation — declaration is not population, and 30 arm rows change nothing |
| CustomTable_test | per-tenant custom table — dbo.CustomTable_test via fv_commengdata | fv_commtable no SendWith* blockfv_commengdata armed | 0 | 0 | the data table is EMPTY on every TST organisation — declaration is not population, and 0 arm rows change nothing |
Empty on both sides is the CONTRACT, not a gap: excluded by name, declared in a schema no map fills, or backed by no server table at all.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| AppointmentStatusTypes | — none on either stack — | MasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decorationDeclared in MasterData.xsd, populated by no .btm leg, no server table. See AppointmentTypes. |
| AppointmentStatuses | — none on either stack — | WorkOrder.xsd | — | — | declared in WorkOrder but populated by no .btm leg and no registry row — wire schema decorationDeclared in WorkOrder.xsd, populated by no .btm leg, no server table. See AppointmentTypes. |
| AppointmentTypes | — none on either stack — | MasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decorationDeclared in MasterData.xsd, populated by no .btm leg and backed by no server table. The appointment data itself reaches the device through Appointments (fed from fv_activity, parity-proven on all six tenants). |
| AssetStatusTypes | — none on either stack — | MasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| AssetTypes_Skills | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDataMasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| AttachmentsEntityTypes | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDatafv_commtable no SendWith* blockMasterData.xsd | 5 | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| DiagnosticRequests | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDataMasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decorationThe master-data map names source table dbo.DiagnosticRequests and OBJECT_ID says it does not exist on TST (F115). The declaration is unbacked: bind it to the real source or drop it. |
| QualityCodes | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDataMasterData.xsd | 0 | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| RateTemplates | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDatafv_commtable no SendWith* blockMasterData.xsd | 210 | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| SurchargeCodes | — none on either stack — | btm↓ MasterData_To_IWMS_MasterDataMasterData.xsd | 2 | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| UserStatusTypes | — none on either stack — | MasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| WaitItems | — none on either stack — | Debrief.xsd | — | — | declared in Debrief but populated by no .btm leg and no registry row — wire schema decoration |
| WarehouseTypes | masterdata <- dbo.fv_warehousetype (3 cols) | btm↓ MasterData_To_IWMS_MasterDatafv_commtable no SendWith* blockfv_commengdata armedMasterData.xsd | 140 | 1,499 | excluded by MasterDataQuery.ExcludedDataTables on both stacksfv_warehousetype is one of MasterDataQuery.ExcludedDataTables, so NEITHER stack ships it (F58). Empty-equal is the contract here, not a shortfall — the source holds 140 rows. |
| WorkOrderStatusTypes | — none on either stack — | MasterData.xsd | — | — | declared in MasterData but populated by no .btm leg and no registry row — wire schema decoration |
| WorkOrderStatuses | — none on either stack — | WorkOrder.xsd | — | — | declared in WorkOrder but populated by no .btm leg and no registry row — wire schema decoration |
The client declares the table and owns its contents. No legacy schema, map or registry mentions it, so there is nothing to bind.
| Client table | Our binding | Legacy declares it via | Source rows | Arm rows | Why the pair is empty |
|---|---|---|---|---|---|
| AddressTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| AssetCollections | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Assets_AssetCollections | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| AutoSaveCache | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Bugs | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| GroupTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Groups | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Groups_Roles | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| LineItemStatusTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| LocalizedItemTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| LocalizedSections | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| LocallyRegisteredMaterials | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| NotificationStatusTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Notifications | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Offdays | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| PublicHolidays | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| QuoteLinePrices | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this tableThe client declares the table but nothing on the sync channel fills it — quote pricing in Horizon is a Core.Api request/response path (RequestPrices / PricingService), not a delivered entity. |
| ResendActions | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Rights | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this tableThe client's whole authorisation model (Rights, Roles, Groups, Users_* and their junctions) is client-side: MSG_User carries a Users block and nothing else, so no rights or roles are delivered by either stack. |
| Rights_Groups | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Rights_Roles | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Rights_Users | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Roles | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Schedules | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Schedules_PublicHolidays | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| TimeSliceStatusTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| UserTypes | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Users_Groups | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Users_Roles | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Users_Schedules | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| Versions | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this table |
| WorkOrderDebriefs | — none on either stack — | nothing | — | — | absent from every legacy message schema, every .btm, fv_commtable and fv_commengdata — the client owns this tableReferenced only by the client's own data-cleanup routine. No legacy schema, map or registry mentions it — debrief data reaches the server through the MSG_Debrief blocks instead. |