Recovering from External Units

The recovery is the moment goods come back from a subcontractor. Done right, it closes the loop on the dispatch cleanly: the Step is marked Done, the cost lands, the Batch can continue to the next operation. Done sloppily, the Batch sits indefinitely in a half-state and the cost rollup misses the supplier's charges.

The flow

The subcontractor delivers goods back to your factory.
Your receiving team counts and inspects.
A dispatcher (or warehouse staff) opens the Logistics App, goes to Logistics, picks the Batch from the Recovery Queue.
They post a Handoff OLE from the external operation back to the next internal operation (or to a holding area).
Any units missing or damaged get a separate Scrap OLE.

What GarmentFlow does on recovery

When the Handoff OLE submits:

The Batch Operation Step for the external operation moves to Done.
Recovery Date on the Step is set.
The receiving operation's Step moves to Pending, ready for the next dispatcher / production staff to pick up.
Stock moves from the External Unit's warehouse back into the receiving warehouse (Stock Ledger reflects).
If the cost source is a Blanket Order or PO, the consumed quantity is debited against it; the cost lands on the Step's Actual Cost field.

Reconciling the dispatch and recovery

A Batch's External Step shows dispatched quantity and recovered quantity side-by-side. They should match (modulo intentional scrap). When they don't:

Recovered > Dispatched — usually a counting error. Reconcile and document.
Recovered < Dispatched with no Scrap entries — units are unaccounted for. Either chase the subcontractor for the missing units or post a Scrap OLE for the difference with reason captured.
Recovered < Dispatched with Scrap entries adding up — the math works. The Batch's quantity is honest about what's continuing.

The discipline: account for every unit. GarmentFlow's job is to make discrepancies visible; resolving them is human work.

When the cost lands

Three timings depending on cost source:

Blanket Order: cost is locked to the BO rate. The Step's Actual Cost is computed at recovery as recovered_qty × BO_rate.
Purchase Order: same idea, but against the PO rate. Cost is also locked.
Purchase Invoice: the Step's Actual Cost remains an Estimated Cost until the supplier's invoice is booked as a PI. When the PI lands (often days or weeks after recovery), the Actual Cost updates.

If a PI lands after the Batch has Completed, the Batch's cost can still update — intentionally. You want the truth, not just the close-of-month snapshot.

A working example

Tuesday morning. AquaWash's truck arrives with the 320 units they had since Thursday. The receiving clerk counts 318 in the boxes. Two units are missing.

The dispatcher:

Opens the Logistics App, taps Logistics, picks Batch B-2026-0418 from the Recovery Queue.
Records the recovered quantity as 318. Sets the destination operation to Finishing.
Submits the Handoff OLE.
Then creates a Scrap OLE for the 2 missing units with remark "AquaWash short delivery — escalated."

GarmentFlow:

The Wash Step on the Batch moves to Done with Recovery Date = today. The Step's Actual Cost = 318 × $0.85 (the BO rate) = $270.30, debited against Blanket Order BO-2026-12.
The Finishing Step moves to Pending.
The Scrap OLE reduces the Batch's effective output to 318.
The supplier-management team gets the escalation for the 2 missing units. AquaWash either makes good on the next consignment or credits the cost.

Two days later, AquaWash's invoice arrives via email — it bills for 320 units, not 318. The PI is created referencing the Blanket Order; the discrepancy is flagged by the three-way match. The team requests a credit note for the 2 units. The credit note lands. The Batch's cost rollup ends up reconciling at $270.30, exactly as expected.

That whole cycle — dispatch, work, recover, scrap, invoice, credit — is auditable from the Batch and the External Unit. Every step left a record.

What to do next

For the supplier's view of all of this, head to The Supplier Portal.