Transfer detail

One transfer end to end: what was asked for, what left, what the gate saw, what arrived, what was counted, what the ledger did about it, and who owns the difference

RT-20260725-HQ319-BAS-2 HQ_319→BAS Short receive replenishment PTX 220301 Porterex D-2026-0725-104

3 lines · 120u dispatched 3 cartons · 25.7 kg AED 28,400.00 Dispatched 25-07-2026 11:05 GST Arrived 26-07-2026 08:55 Residue 20u · AED 9,860 at TRANSIT Receiving Fatima Al Zaabi · BAS

State timeline 10 of 14

Draft

24-07 11:20

Ramesh Kumar · HQ_319

Requested

24-07 11:35

3 lines · 124u asked

Approved

24-07 14:02

Aisha Rahman · hold 120u placed

Picked

25-07 08:14

2 pickers · MC3390xR-02

Packed

25-07 09:48

3 cartons · 25.7 kg

Dispatched

25-07 11:05

FXR90 gate 120 of 120 · OUT pairs posted

In transit

25-07 12:30

Porterex · Al Quoz hub

Partial receive

26-07 09:12

receipt 1 · 98 intact, 2 damaged

Received

not reached

would need residue 0

Short receive

28-07 11:40

receipt 2 final · residue 20u · drift opened

Reconciled

pending

needs a disposition on D-2026-0725-104

Lost

04-08 11:05

automatic if unresolved

Cancelled

unreachable

pre-dispatch only (R-07.4)

Rejected

unreachable

destination accepted what arrived

Custody

Location: TRANSIT
Stock type: IN_TRANSIT_INTERNAL
Holder: Porterex
Residue: 20u · AED 9,860
Postings: 10 posted · 2 pending
Pairs: 5 balanced · 1 open

SLA

Lane: HQ_319 to BAS
Lane SLA: 34h
ETA: 26-07 21:00
Arrived: 26-07 08:55 early
Receive SLA: 24h breached
Elapsed: 4d 03h
Bucket: critical over 96h
Lost horizon: 04-08 11:05 · 6d 20h

Parties

Created: Ramesh Kumar
Approved: Aisha Rahman
Picked: Ramesh Kumar, Joel Fernandes
Packed: Joel Fernandes
Dispatched: Joel Fernandes
Receiving: Fatima Al Zaabi

Linked

ops2 rt_code: RT-0418
rfid shipment: SH-0725-14
AWB: PTX 220301
Request: TRQ-20260724-BAS-2
Drift case: D-2026-0725-104
Damage: DMG-2026-0726-77
Reverse: none

Four systems, four reference formats. ops2 mints RT-NNNN, rfid-app holds a nullable VARCHAR(20) that cannot even store this transfer's reference. i3 joins through transfer_external_refs and never parses a sibling's key.

Route and carrier stages

The nine canonical AWB stages mirrored from ops2 · the exception at 27 Jul is the carrier admitting the piece count changed

1 exception

stage recorded carrier exception Stages delivered_to_wh, received_at_wh and dispatched_outbound do not apply to a store lane

Lines

Six quantities per line, each written by a different event · in flight = dispatched - received - damaged - rejected is a stored generated column and the database refuses a line where the parts exceed the whole

3 lines1 short

#	SKU and title	From bin	To bin	Stock type move	Req	Appr	Pick	Pack	Disp	Recd	Dmg	In flight	Unit AED	Total AED	Line state
1	MSR31-07 Signature Strap 42 Noir	HQ319/A3	BAS/FL-2	STOCK→IN_TRANSIT_INTERNAL→STOCK	60	60	60	60	60	60	0	0	245	14,700	settled
2	MST-CRM-42-BLK Maison Ceramic 42 Black	HQ319/B1	BAS/CER-1	STOCK→IN_TRANSIT_INTERNAL→held	24	20	20	20	20	0	0	20	493	9,860	variance · short
3	MIN-2159 Linen Kaftan One-size	HQ319/D2	BAS/TEX-1	STOCK→IN_TRANSIT_INTERNAL→STOCK + QUARANTINE	40	40	40	40	40	38	2	0	96	3,840	settled
Totals					124	120	120	120	120	98	2	20	.	28,400	residue 20

Quantity waterfall

Where the 124 units originally asked for ended up · the red step is the only one that is not an accounting fact yet

RequestedApprovedPickedPackedDispatchedReceivedAt TRANSIT

Ledger contract. Dispatch posted 3 pairs, 6 rows: -q @ HQ_319/STOCK with +q @ TRANSIT/IN_TRANSIT_INTERNAL, all in one transaction. Receipt posted 3 more pairs, 6 rows, out of TRANSIT and into BAS. The remaining 20 units have no receipt, so they have no pair, so nothing was posted for them. v2's version of this footer claimed "no stock is ever untracked" while crediting the destination with the full shipped quantity on a courier callback.

Cartons

3 master cartons, 25.7 kg · 3 scanned out through the HQ_319 gate, 2 scanned in at BAS · a carton may sit on only one open transfer at a time and i3 enforces that with a partial unique index, not a Python check

CTN-220301-01 opened

Contents1 SKU · 60u

Weight12.4 kg

Dims60 x 40 x 35

Scanned out25-07 11:05

Scanned in26-07 09:12

CTN-220301-02 never arrived

Contents1 SKU · 20u

Weight8.1 kg

Dims45 x 30 x 25

Scanned out25-07 11:05

Scanned innever

CTN-220301-03 opened

Contents1 SKU · 40u

Weight5.2 kg

Dims40 x 30 x 20

Scanned out25-07 11:05

Scanned in26-07 09:14

ops2's iwms_transfers has no line table at all: quantities are derived at ship time from SUM(master_cartons.qty_current) and receipt is recorded per carton, never per unit. That is why a partially full carton arriving short is invisible to ops2, and why the receive count has to be i3's own.

Pick, pack and scan log

Every scan that touched this transfer, in order · pick and pack come from the MC3390xR handhelds, the dispatch gate is the FXR90 at the HQ_319 exit door, the receive side is an RFD40 sled at BAS

18 scans3 unmatched

Time GST	Phase	Kind	Actor	Device	Carton	SKU	Bin	Qty	Manifest	Note
25-07 08:14:02	Pick	barcode	Ramesh Kumar	MC3390xR-02	CTN-220301-01	MSR31-07	HQ319/A3	20	match
25-07 08:17:40	Pick	barcode	Ramesh Kumar	MC3390xR-02	CTN-220301-01	MSR31-07	HQ319/A3	20	match
25-07 08:22:11	Pick	barcode	Ramesh Kumar	MC3390xR-02	CTN-220301-01	MSR31-07	HQ319/A3	20	match
25-07 08:31:55	Pick	barcode	Joel Fernandes	MC3390xR-05	CTN-220301-02	MST-CRM-42-BLK	HQ319/B1	20	match
25-07 08:44:03	Pick	barcode	Joel Fernandes	MC3390xR-05	CTN-220301-03	MIN-2159	HQ319/D2	20	match
25-07 08:49:27	Pick	barcode	Joel Fernandes	MC3390xR-05	CTN-220301-03	MIN-2159	HQ319/D2	20	match
25-07 09:31:12	Pack	qr	Joel Fernandes	MC3390xR-05	CTN-220301-01	.	.	60	match
25-07 09:38:44	Pack	qr	Joel Fernandes	MC3390xR-05	CTN-220301-02	.	.	20	match
25-07 09:47:08	Pack	qr	Joel Fernandes	MC3390xR-05	CTN-220301-03	.	.	40	match
25-07 11:04:51	Dispatch gate	rfid	system	FXR90-319-A	CTN-220301-01	MSR31-07	.	60	match
25-07 11:04:53	Dispatch gate	rfid	system	FXR90-319-A	CTN-220301-02	MST-CRM-42-BLK	.	20	match
25-07 11:04:56	Dispatch gate	rfid	system	FXR90-319-A	CTN-220301-03	MIN-2159	.	40	match
25-07 11:05:02	Dispatch gate	qr	Joel Fernandes	MC3390xR-05	.	.	.	3	match
26-07 09:12:18	Receive gate	rfid	Fatima Al Zaabi	RFD40-BAS-1	CTN-220301-01	MSR31-07	BAS/FL-2	60	match
26-07 09:14:02	Receive gate	rfid	Fatima Al Zaabi	RFD40-BAS-1	CTN-220301-03	MIN-2159	BAS/TEX-1	38	match
26-07 09:16:31	Receive count	manual	Fatima Al Zaabi	.	CTN-220301-03	MIN-2159	BAS/QTN-1	2	no match	2 units cracked in transit, routed to QUARANTINE
26-07 09:21:07	Receive count	manual	Fatima Al Zaabi	.	CTN-220301-02	.	.	0	no match	carton not present on the pallet, logged as absent
28-07 11:39:44	Audit	manual	Aisha Rahman	.	CTN-220301-02	MST-CRM-42-BLK	.	0	no match	final sweep of the BAS stockroom before closing the receipt

The three unmatched rows are not errors. Two are receive counts a human made outside a scan (damage and absence) and one is the audit sweep. matched_manifest is NULL where the phase has no manifest to match against, and NULL is never rendered as a failure.

RFID gates, both ends

The two ends are not symmetric and the page says so · the source read is automatic and immutable, the destination read is an operator action that can simply not happen

source 100%destination 82%

Dispatch gate · FXR90-319-A100%

HQ_319 exit door · automatic · Bearer auth over the IoT connector · 25-07 11:04:51 to 11:04:58

EPC	SKU	Ant	RSSI	Carton	Manifest
E280 6894 0000 4021 8F3C	MSR31-07	A2	-52	01	match
E280 6894 0000 4021 8F41	MSR31-07	A2	-49	01	match
E280 6894 0000 4022 1B07	MST-CRM-42-BLK	A1	-61	02	match
E280 6894 0000 4022 1B12	MST-CRM-42-BLK	A1	-58	02	match
E280 6894 0000 4022 1B29	MST-CRM-42-BLK	A3	-67	02	match
E280 6894 0000 4031 04A8	MIN-2159	A2	-55	03	match
E280 6894 0000 4031 04B3	MIN-2159	A2	-53	03	match

7 of 120 reads shown · 120 manifest EPCs, 120 read, 0 unmatched, 0 unexpected. The gate proves all three cartons physically left HQ_319, which is what makes the carrier exception on 27 Jul attributable rather than arguable.

Receive scan · RFD40-BAS-182%

BAS stockroom · operator scan, not a gate · Fatima Al Zaabi · 26-07 09:12 to 09:16

EPC	SKU	Carton	Bucket	Read at
E280 6894 0000 4021 8F3C	MSR31-07	01	intact	09:12:18
E280 6894 0000 4021 8F41	MSR31-07	01	intact	09:12:19
E280 6894 0000 4031 04A8	MIN-2159	03	intact	09:14:02
E280 6894 0000 4031 04B3	MIN-2159	03	damaged	09:16:31
E280 6894 0000 4022 1B07	MST-CRM-42-BLK	02	not scanned	never
E280 6894 0000 4022 1B12	MST-CRM-42-BLK	02	not scanned	never
E280 6894 0000 4022 1B29	MST-CRM-42-BLK	02	not scanned	never

7 of 120 EPCs shown · 98 intact, 2 damaged, 20 never read. The 20 unread EPCs are the whole of CTN-220301-02. Because receipt is per EPC, the drift case names which twenty serials, not just a count. rfid-app records S18 transfer discrepancy as PARTIAL precisely because it has a count and no item list.

Manifest reconciliation

Four counts that should agree, and the one place they stop agreeing

verified at the gate counted intact damaged never counted, held at TRANSIT

There is exactly one FXR90 in the estate and it is at the HQ_319 exit door. A store-to-store lane therefore reports gate compliance as n/a, never 0%, and a dead gate never blocks a dispatch. It does always appear on the page (MIN-2269).

Receipts

Two receive events against one transfer · partial receipt is native, not a workaround · each event posts its own pairs and each bucket posts a different one

2 receiptsfinal closed with residue

Receipt 1seq 126-07-2026 09:12 GST · Fatima Al Zaabi · RFD40-BAS-1 · cartons scanned 2 of 3posted 3 pairs

Intact

TRANSIT out, BAS STOCK in

Damaged

TRANSIT out, BAS QUARANTINE in, DMG-2026-0726-77

Short

not declared yet, receipt not final

Over

a transfer cannot create units

Wrong SKU

would spawn a reverse transfer

Photos 4 · condition note "carton 02 not on the pallet, driver could not account for it" · is_final = false, so the transfer moved to partial receive and stayed open for two more days while BAS and Porterex looked for the carton.

Receipt 2seq 2 · final28-07-2026 11:40 GST · Aisha Rahman · manual · cartons scanned 0 of 1 remainingposted 0 pairs

Intact

nothing further arrived

Damaged

Short

posts nothing. Residue stays at TRANSIT and opens D-2026-0725-104

Over

Wrong SKU

This is the receipt that matters. It closed receiving, moved the transfer to short receive, and wrote no ledger row at all. v2's inspect tab told the operator "totals must equal shipped qty (27u)". In i3 the totals are allowed to be short, because pretending otherwise is how 20 units become invisible.

Receipt method is one of qr_scan, rfid_sled, grn, manual, api. A carrier callback is not on that list: ops2's transfer-deliver webhook carries {transfer_ref, delivered_at, actor} and no quantities whatsoever, so it can stamp arrival and nothing else.

Ledger trace

Every row this transfer wrote, in the two halves it was written as · 6 pairs, 12 rows, one open claim · a pair that does not sum to zero cannot be committed, the constraint trigger aborts the transaction

5 balanced1 unposted

dispatchline 1 · MSR31-07 · 60u · 25-07 11:05:04pair 4c81-77afsum 0

out	HQ_319	STOCK	-60	bal 552	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:1:dispatch:out
in	TRANSIT	IN_TRANSIT_INTERNAL	+60	bal 60	counterpart HQ_319	transfer:RT-20260725-HQ319-BAS-2:1:dispatch:in

dispatchline 2 · MST-CRM-42-BLK · 20u · 25-07 11:05:04pair 4c81-77b0sum 0

out	HQ_319	STOCK	-20	bal 368	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:2:dispatch:out
in	TRANSIT	IN_TRANSIT_INTERNAL	+20	bal 20	counterpart HQ_319	transfer:RT-20260725-HQ319-BAS-2:2:dispatch:in

dispatchline 3 · MIN-2159 · 40u · 25-07 11:05:04pair 4c81-77b1sum 0

out	HQ_319	STOCK	-40	bal 144	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:3:dispatch:out
in	TRANSIT	IN_TRANSIT_INTERNAL	+40	bal 60	counterpart HQ_319	transfer:RT-20260725-HQ319-BAS-2:3:dispatch:in

receive 1line 1 · MSR31-07 · 60u intact · 26-07 09:12:44pair 9d02-1e5csum 0

out	TRANSIT	IN_TRANSIT_INTERNAL	-60	bal 60	counterpart BAS	transfer:RT-20260725-HQ319-BAS-2:1:receive:1:out
in	BAS	STOCK	+60	bal 74	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:1:receive:1:in

receive 1 · damagedline 3 · MIN-2159 · 38 intact and 2 damaged · 26-07 09:16:52pair 9d02-1e5d, 9d02-1e5eboth sum 0

out	TRANSIT	IN_TRANSIT_INTERNAL	-38	bal 22	counterpart BAS	transfer:RT-20260725-HQ319-BAS-2:3:receive:1:out
in	BAS	STOCK	+38	bal 41	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:3:receive:1:in
out	TRANSIT	IN_TRANSIT_INTERNAL	-2	bal 20	counterpart BAS	transfer:RT-20260725-HQ319-BAS-2:3:damage:1:out
in	BAS	QUARANTINE	+2	bal 2	counterpart TRANSIT	transfer:RT-20260725-HQ319-BAS-2:3:damage:1:in

no pair existsline 2 · MST-CRM-42-BLK · 20u · never receivedbalance held at TRANSITresidue 20

There is nothing to show here, and that is the correct output. The dispatch pair for line 2 is above and it balanced. No receive pair was ever written because nothing was ever counted. The 20 units sit at TRANSIT under IN_TRANSIT_INTERNAL with counterpart_location_id = BAS, so the intended destination is still on the row.

              out_at_source(HQ_319) = -120

              in_at_dest(BAS)       = +100

              at_transit            = +20

              -120 + 100 + 20       = 0   AC-07.1a holds, the transfer is unbalanced only in the sense that it is not finished

12 rows, 6 pairs, one held claim. Compare INV1's live engine: it posts the deliver leg from line.qty, the requested quantity, so this transfer would have credited BAS with 120 units and the 20 missing ones would have left no trace at all in 35,574 rows of transfer history.

Discrepancy and drift case

The two halves never balanced, so a case owns the difference · this module raises the case and never resolves it, module 13 posts the closing pair

D-2026-0725-104P1 · 4d open

Case: D-2026-0725-104 · opened 28-07 11:40 by the receipt finaliser
Kind: transfer_variance · short
Delta: -20 units · AED 9,860
SKU: MST-CRM-42-BLK · Maison Ceramic 42 Black
Serials named: E280 6894 0000 4022 1B07 and 19 more · the full list is on the case
Evidence: FXR90 gate read at 11:04:53 proving departure · Porterex exception at 27-07 16:20 reporting 2 of 3 pieces · receipt 1 condition note · receipt 2 final with 0 scanned
Held at: TRANSIT · IN_TRANSIT_INTERNAL · counterpart BAS
Alert: transfer.stale_in_transit P2 raised 27-07 12:00, escalated to transfer.lost_horizon_reached P1 on 04-08 if unresolved · dedupe key transfer:stale:RT-20260725-HQ319-BAS-2
Claim insurance: Porterex claim PX-CLM-11402 filed 28-07 · finance tracks recovery separately from stock

Countdown

6d 20h

until the lost horizon converts the residue to LOST_IN_TRANSIT automatically. That conversion is a pair at TRANSIT, not a write-off. A write-off needs finance and lands on HQ_319's books, not BAS's.

96h elapsed of the 240h horizon

Available dispositions

Each posts a different pair. None of them is a bare adjustment and none of them edits an existing row.

Found at destination

The carton turns up at BAS. Receipt 3 is recorded normally and the residue closes.

-20 @ TRANSIT / IN_TRANSIT_INTERNAL
+20 @ BAS / STOCK

Approver: store manager at BAS

Returned to source

Porterex returns the carton to HQ_319. The units go back where they came from.

-20 @ TRANSIT / IN_TRANSIT_INTERNAL
+20 @ HQ_319 / STOCK

Approver: ops manager

Write off as lost recommended

Two steps, deliberately. The first is automatic at the horizon and is reversible by a compensating pair. The second needs finance.

step 1 (auto at horizon)
-20 @ TRANSIT / IN_TRANSIT_INTERNAL
+20 @ TRANSIT / LOST_IN_TRANSIT

step 2 (finance)
-20 @ TRANSIT / LOST_IN_TRANSIT
+20 @ HQ_319 / WRITTEN_OFF

Approver: finance · master plan decision D8 is still open on who signs

Note what is not on this list: there is no "adjust to match" and no "mark received". INV1's reject path deducts destination STOCK and adds destination DEFECTIVE after delivery already put the goods into STOCK, which is a condition change dressed up as a reversal. i3 refuses to offer a button that invents or destroys a unit.

Activity

State transitions, ledger posts, webhook receipts and carrier callbacks in one stream · 14 events

Draft created, 3 lines staged24-07 11:20

Ramesh Kumar at HQ_319 · from request TRQ-20260724-BAS-2 · 124 units asked for

Submitted for approval24-07 11:35

state draft to requested · lane HQ_319 to BAS requires approval, role >= manager plus transfers.approve

Approved, 120 of 124 units24-07 14:02

Aisha Rahman · line 2 cut from 24 to 20, HQ_319 held only 20 sellable · unposted hold placed, BAS available unchanged, HQ_319 available down 120 and sellable untouched

Picked, 120 units25-07 08:14

Ramesh Kumar and Joel Fernandes · MC3390xR-02, MC3390xR-05 · 6 pick scans across 3 bins

Packed, 3 cartons sealed25-07 09:48

Joel Fernandes · CTN-220301-01 12.4 kg, -02 8.1 kg, -03 5.2 kg · labels printed on the ZT411R

Gate verified, 120 of 120 EPCs25-07 11:04

FXR90-319-A at the HQ_319 exit door · automatic · 0 unmatched, 0 unexpected · this is the immutable proof of departure

Dispatched, 3 pairs posted, 6 rows25-07 11:05

HQ_319/STOCK down 120 and TRANSIT/IN_TRANSIT_INTERNAL up 120, one transaction · hold released · AWB PTX 220301 assigned · lost horizon set to 04-08 11:05

ops2 transfer-ship webhook accepted25-07 11:05

HMAC verified · idempotency ops2:transfer:ship:RT-0418 · 202 · the 15-minute reconciliation poller found no gap this cycle

Carrier in transit, Al Quoz hub25-07 12:30

Porterex webhook · stage in_transit · 3 pieces on manifest · ETA 26-07 21:00

Arrived at BAS, 2 cartons signed for26-07 08:55

stage delivered_to_store · posted nothing · arrived_at stamped, state stayed in_transit until a count existed

Receipt 1, 98 intact and 2 damaged26-07 09:12

Fatima Al Zaabi · RFD40-BAS-1 · 3 pairs posted, 6 rows · damage incident DMG-2026-0726-77 raised to module 09 · state in_transit to partial receive

Stale alert raised, P227-07 12:00

alert.raise transfer.stale_in_transit · dedupe transfer:stale:RT-20260725-HQ319-BAS-2 · blast 20u, AED 9,860, 1 SKU, 2 locations · no Slack call from this module, module 01 owns delivery

Carrier exception, 2 of 3 pieces27-07 16:20

Porterex webhook · stage exception at the Abu Dhabi sort · this is the moment CTN-220301-02 left the chain of custody, and it arrived 29 hours after the goods were already missing

Receipt 2 final, short 20, drift opened28-07 11:40

Aisha Rahman · 0 pairs posted · state partial receive to short receive · drift.open_requested emitted, case D-2026-0725-104 created · residue 20u still at TRANSIT

Every row above is derived from transfer_state_transitions, transfer_postings, transfer_awb_stages and events_raw. Nothing here is a log line: replaying the source events reproduces this list exactly, and replaying them twice produces no new rows.

This transfer is still a draft.

No lines, no cartons, no scans, no ledger. A draft is the only state in which lines are freely editable, and it holds nothing: no ledger row, and not even a hold at the source. Add lines, then submit for approval.

Pick from the live grid Back to transfers

No scans match that filter.

The scan log is filtered to phase receive_gate and device FXR90-319-A. The FXR90 is at the HQ_319 exit door and only ever produces dispatch_gate rows. There is no receive gate anywhere in the estate.

Device map

Could not load the manifest.

Retry, or work from the printed manifest and record the receipt when the service returns. Nothing queued here is lost: receive posts carry an idempotency key and replay cleanly.

Error id tdt-4f18b2 · 29-07-2026 14:41:22 GST

Service health

Read-only trace.

Receiving needs role >= manager, the transfers.receive feature flag, and BAS in your rota-effective locations. A manager at MCC cannot receive a transfer into BAS, because the rota decides the location set and the JWT carries no per-persona payload (L11).

Who can do what Approvals

Posting is paused while the pair registry is reindexed.

The deferred constraint trigger on transfer_postings is being rebuilt. Reads are live and this trace is complete. A receive recorded now is queued with its idempotency key and drains in order. Estimated finish 15:10 GST.

Job status Notify me

Transfer posting is gated until GATE 3 holds.

This transfer, its lines, its scans and its gate reads are all recorded in shadow mode and will replay in order once the gate closes. GATE 3 has held 4 of the 7 days required. The page is correct and the module is finished; the phase is not.

Gate status board GATE 3 detail All transfers

Transfer detail

This transfer is still a draft.

No scans match that filter.

Could not load the manifest.

Read-only trace.

Posting is paused while the pair registry is reindexed.

Transfer posting is gated until GATE 3 holds.

Connected to