Shipments

The Shipments module is where the order’s outbound side is worked: the per-leg record that draws down the finished-goods record on the platform, and the customer-facing commercial shipment that carries the vessel, the bill of lading, and the link to the commercial invoice.

​

The platform is a system of record

GarmentFlow tracks shipment positions on paper. The platform does not observe physical movement, does not know where goods physically are, and does not control who picks them up or where they go. Every “shipment” on the platform is a record the team writes; every “movement” is a book entry. This frame governs how to read every record on the page. When the page says “the outbound leg draws the finished-goods record down,” what happens on the platform is the record falls. What happens off the platform — whether goods left a factory, sat in a yard, or arrived with a customer — is the team’s own business. The platform watches the team type a date, not a truck roll across a dock.

​

Two records, two jobs

The module carries two distinct records that often live side by side on the same customer order. Keep the distinction.

• Outbound shipment — the per-leg outbound record on the order. One per distinct (customer order × ship-to) on a factory order, auto-seeded when the factory order is issued. The record the team works as the leg moves from being noted as planned to being noted as shipped; the record whose shipped status draws the finished-goods record down.
• Commercial shipment — the customer-facing commercial document for the batch. Carries the vessel or flight, the bill of lading or air waybill, the carrier, the tracking number, and the link to the order’s commercial invoice for the batch. Created by hand from the order’s Shipments sub-tab once the team is ready to book the carrier.

The two records are not the same thing. The outbound shipment is the operational record of the leg; the commercial shipment is the document the customer reads. They surface on different sub-tabs on the order — the Shipments sub-tab for the commercial shipment, the Outbound sub-tab for the outbound shipment — and behave differently on every dimension below. See Orders for how the order detail’s sub-tabs are laid out.

​

Outbound shipment — the per-leg record

The outbound shipment is the per-leg outbound record on the order. Each one covers a single (customer order × ship-to) on a single factory order; the record carries the vendor, the dates, and the per-line planned and actual quantities. The team works it from the order detail’s Outbound sub-tab.

​

Where it comes from

Outbound shipments are normally auto-seeded when an upstream factory order is issued. The first time a factory order moves from Draft to Issued, the platform creates one draft outbound shipment per distinct (customer order × ship-to) on the factory order — with one line per (order × style × ship-to) carried over from the factory-order lines. Retention rows on the factory order are excluded from the seed; they are worked separately. The seeding rule is documented end-to-end on Production — Issuing seeds the outbound skeleton; this page describes the outcome the team sees. Re-issuing a factory order does not duplicate the legs — the seeding respects the (factory order × order × ship-to) grain, so a re-issue lands on the existing drafts rather than creating new ones.

​

The manual-add path

The Outbound sub-tab also lets the team add a leg by hand, for one-off legs not covered by the factory-order seeding. Use the Add button at the top of the sub-tab: pick the vendor and save. The hand-added leg lands as a draft with no ship-to text, then takes lines and quantities as the team fills them in. A hand-added leg behaves identically to an auto-seeded one once it carries lines: same statuses, same dates, same effect on the finished-goods record when it is marked shipped. The path exists for legs that arise outside the factory-order skeleton — a one-off sample-batch leg, an after-the-fact correction, a leg the team wants on the record before the factory order it belongs to is built.

​

Dates

Each leg carries three dates the team works against. None of them are computed by the platform; the team enters them as the leg progresses.

• Expected ship date — the date the team expects the leg to ship. Editable on both Draft and Shipped. No side effects on its own.
• Actual ship date — the date the leg actually shipped. Setting it on a draft leg moves the leg to Shipped in the same write and records the outbound issue that draws the finished-goods record down (see Effect of marking a leg shipped below). Clearing it on a Shipped leg is refused — the team uses Unlock instead, which reverses the recorded issue and returns the leg to Draft.
• Received date — the date the team noted the leg as received, for example when the customer confirms delivery against the carrier’s proof of delivery. Editable on both Draft and Shipped. It is a tracking field only: setting it has no effect on the leg, the order, the commercial shipment, or the finished-goods record. The team records the date for their own audit; the platform shows it back.

​

Status

An outbound shipment has only two statuses: a draft pair, no further states. The team does not promote the leg through a multi-step lifecycle the way the commercial shipment goes.

• Draft — the leg is being worked. Vendor, lines, and dates are editable. Auto-seeded legs land here; hand-added legs land here.
• Shipped — the leg has been marked shipped by recording an Actual ship date. The leg’s lines, vendor, and ship-to are then frozen. The team can still edit Expected ship date, Received date, and notes.

Moving a leg from Draft to Shipped is set by recording the Actual ship date — not by a separate status control. The platform reads the date and flips the leg in the same write. Unlocking a Shipped leg returns it to Draft and reverses the finished-goods record draw-down.

​

Effect of marking a leg shipped

When a draft outbound shipment is marked shipped — by recording its Actual ship date — the platform records an outbound issue against the finished-goods record for every line on the leg. The finished-goods record falls by the line’s actual quantity for the line’s style; when the line carries a per-size split, the issue is recorded per size and the finished-goods record falls per size. The record being drawn down is the same finished-goods record the Production hub’s finished-goods stock view reads off. The companion record — the receipt of finished goods coming back from the factory, which the team books on the Subcontracting tab — is what brings that record up. Together the receipt side and the outbound side keep the finished-goods record net-correct. Unlocking a Shipped leg writes a compensating return on the finished-goods record, so the record returns to where it was before the leg was marked shipped. The original outbound issue stays on the record as audit, the compensating return offsets it, and the net is zero.

​

Per-size split on a line

A line on an outbound shipment can optionally carry a per-size split. When the team enters the per-size quantities under a line, the line’s actual quantity is set from the sum of the split — the split is the entry, and the total reads off it. The finished-goods record is then drawn down per size when the leg is marked shipped, so the per-size finished-goods record stays correct down to each size. A line without a split records the outbound issue against the style as a whole.

​

Lines and over-allocation

Each outbound shipment line corresponds to one leaf line on the upstream factory order — one style going to one ship-to. The line carries a Planned qty and an Actual qty. The team is not blocked if the planned quantities on the legs add up to more than the factory order’s quantity for the leaf; the line shows a soft over-allocated warning so the team can spot the mismatch, but the save is allowed. Production can carry small overages, and the platform leaves the call to the team.

​

Lifecycle

• Delete is allowed only on Draft legs. A Shipped leg cannot be deleted; the team unlocks it first (which reverses the finished-goods record draw-down) and then deletes the Draft.
• Edit the vendor or the lines is allowed only on Draft legs. A Shipped leg’s vendor and lines are frozen.
• A factory-order leaf with outbound shipment lines on it cannot be deleted — the platform refuses the delete so out-shipped history can’t silently drop. Cancel the upstream factory order instead.

​

Where it lives

Outbound shipments live on the order detail’s Outbound sub-tab — one card per leg, each showing the vendor, the three dates, the lines with their planned and actual quantities, and the Unlock control on Shipped legs. They do not appear on the Production hub’s outbound view (which shows the commercial shipment list — see the next section).

​

Commercial shipment — the customer-facing document

The commercial shipment is the customer-facing commercial document for a batch of the order’s goods. It carries the vessel or flight, the bill of lading or air waybill, the carrier, the tracking number, the batch label the team writes onto the documents, and the link to the shipment’s commercial invoice. The team works it from the order detail’s Shipments sub-tab.

​

When the team creates one

A commercial shipment is always created by hand. There is no auto-seeding the way the outbound shipment has — when the team is ready to book the carrier for a batch, they open the Shipments sub-tab on the order, click Add Shipment, and fill in the logistics. The platform assigns the shipment its Shipment no. automatically — a year-stamped auto-assigned identifier with a per-batch suffix — so the number is guaranteed unique without the team typing it.

​

Status

A commercial shipment moves through four statuses, set by the team as the batch moves through booking and delivery.

• Planned — the team’s planning record. The carrier and the dates can still be worked.
• Booked — the batch has been booked with the carrier.
• In transit — the batch has been recorded as shipped. Setting this status advances the order’s work phase from Bulk production to Shipped (see order lifecycle). This is the only status whose change moves the order forward on the work-phase spine.
• Delivered — the batch has been recorded as delivered to the customer.

The four-status flow runs Planned → Booked → In transit → Delivered. The team advances the status as the batch progresses; there is no auto-progression.

​

What the first commercial shipment does to the order

The first commercial shipment the team adds against an order in the production commercial status also flips the order’s commercial status to shipping — the platform writes the change itself in the same write that creates the shipment. The order’s two-dimensional lifecycle distinguishes the commercial status (where the deal is) from the work phase (where the work is); the commercial-status flip on first shipment is the deal moving forward, and the in transit work-phase advance described above is the work moving forward. The two changes are independent and may happen at different times. See order lifecycle. A subsequent shipment on the same order does not re-flip the commercial status; only the first one does.

​

Fields

Group the commercial shipment’s fields by purpose.

​

Identity

• Shipment no. — the shipment’s permanent business identifier. Assigned by the platform when the shipment is created and never changes.
• Batch no. — the per-order shipment count, set by the platform from the number of existing shipments on the order. The first shipment on an order is batch 1; the second is batch 2; and so on.

​

Logistics

• Shipping mode — the transport mode. The picker offers sea, air, express, DHL, and FedEx; the value drives nothing in the platform, but it prints on the documents and the team filters by it on the global list.
• Vessel name / Vessel flight — the vessel or flight identifier the batch is on.
• BL number — the bill of lading number for sea shipments.
• AWB no. — the air waybill number for air shipments.
• Tracking number — the carrier’s tracking number, optional and free-text.
• Shipment batch — the human-readable batch label the team writes onto the documents, free-text. Distinct from Batch no., which is the numeric per-order count.
• Account party — the account party named on the bill of lading or air waybill, free-text.

​

Dates

• Ship date — the planned ship date for the batch.
• ETA date — the expected time of arrival, customer-side.
• ETD date — the expected time of departure.
• ETC date — the expected time of completion.

All four dates are user-set on create and edit. None of them are computed or propagated by the platform.

​

Destination

• Destination — the destination this batch is going to. Defaults to the order’s destination at create; editable per shipment, so a batch going to a different destination from the order’s default can carry its own. The platform saves a freshly-typed destination to the tenant destination lookup, so the same value is one pick on the next shipment.
• Notes — free-text notes on the shipment.

​

Lines — per-size shipped quantities

Each commercial shipment carries one line per size shipped on the batch. Each line records the Qty shipped for the size; the per-size shipped quantities drive the order’s Shipment Progress card on the Order Overview and the shipped-versus-ordered rollup on the order’s size grid. Over-shipping is refused. Saving a line whose Qty shipped would push the size’s cumulative shipped total above the size’s ordered quantity is rejected; the platform names the offending sizes on the rejection so the team can correct. The guard reads the cumulative shipped total across every commercial shipment on the order, not just the current one. Deleting a line returns the per-size shipped quantity to where it was before the line was added — the order’s progress reads back down to match.

​

Shipment-detail sheet

Each commercial shipment also exposes a shipment-detail sheet — a per-style, per-colour list of the goods on the batch, with six size columns (XS, S, M, L, XL, XXL) and one row per style × colour. The team can edit the detail rows directly on the shipment card; the sheet is exportable as a spreadsheet with the order, style, colour, country, purchase-order number, the six size columns, the total, and the logistics fields (shipping mode, air waybill, ETD, ETC, ETA) on each row. The shipment-detail sheet is a separate surface from the per-size lines described above — the two are not synchronised, by design. The per-size lines drive the order’s shipped-versus-ordered rollup; the detail-sheet drives the packing spreadsheet the team sends to the customer or to the freight forwarder. The team fills both when both are needed.

​

Per-destination packing list

A commercial shipment can split into multiple destinations when one batch ships to several receivers. Each destination carries its own name, address, country, and contact, plus its own per-size quantity rollup. The packing list PDF can be generated against the shipment as a whole or against any one destination — useful when each receiver needs its own packing slip on its own copy.

​

Commercial invoice

A commercial shipment is the anchor for the shipment-type commercial invoice on the order. The team raises the invoice from the order’s Invoices sub-tab against the shipment; the invoice picks up the shipment’s per-size lines, the order’s customer and currency, and offsets the order’s deposit against the shipment’s portion of the order value. The full behaviour of the invoice — invoice types, deposit offset, status lifecycle — lives on the Finance module guide. An outbound shipment is not the anchor for an invoice; only the commercial shipment is.

​

Lifecycle

• Delete is allowed only on Planned or Booked shipments. A shipment that has moved to In transit or Delivered cannot be deleted; this protects the order-phase advance the In transit transition fired from being unwound. Deleting a Planned or Booked shipment returns its per-size shipped quantities to the order.
• Edit is allowed throughout the lifecycle — the logistics fields, the dates, the destination, and the lines all stay editable. The four statuses gate delete, not edit.

​

Where it lives

The same commercial shipment is reachable from three places:

• The order detail’s Shipments sub-tab — the per-order view, with the full per-shipment card, the per-size editor, the shipment-detail sheet, and the per-destination packing list controls.
• The global Shipments list reachable from the main navigation — every commercial shipment across the tenant, with column-level filters on the carrier fields, the status, and the dates. Used when the team is working a shipping queue across orders.
• The Production hub’s Subcontracting tab — the same global list, embedded inside the hub for the floor’s outbound view. The list shown there is the commercial-shipment list, not the per-leg outbound shipments described above.

The per-leg outbound shipments only appear on the order detail’s Outbound sub-tab; the commercial shipments appear on the three surfaces above.

​

How the two records relate

The two records work the same (customer order × ship-to) leg from two angles. The outbound shipment is the operational record of the leg — the record whose shipped status draws the finished-goods record down. The commercial shipment is the customer-facing document for the leg — the record that carries the carrier, the bill of lading, and the invoice. The team works them on different sub-tabs because they are different records with different lives:

• The outbound shipment is auto-seeded from a factory order; the commercial shipment is always added by hand.
• The outbound shipment moves through Draft → Shipped; the commercial shipment moves through Planned → Booked → In transit → Delivered.
• The outbound shipment draws the finished-goods record down; the commercial shipment advances the order’s work phase to Shipped and flips the order’s commercial status to Shipping on the first one.
• The outbound shipment carries no commercial document; the commercial shipment carries the packing list, the shipment-detail sheet export, and the commercial invoice anchor.

The team typically fills the outbound shipment first — as the factory’s leg is worked — and creates the commercial shipment later, when the carrier is booked. Nothing on the platform forces an order between the two; either record can exist without the other on the same order.

​

Numbering

• Outbound shipments use a per-order count — the first outbound shipment on an order is shipment 1, the second is shipment 2, and so on. The number is set by the platform on create and does not change.
• Commercial shipments use an auto-assigned year-stamped identifier with a per-batch suffix that counts within the order. The number is set by the platform on create and does not change. The Batch no. field on the same shipment is the per-order batch count (1, 2, 3 …) that the team reads on the card; the suffix in the identifier and the Batch no. field hold the same number.

Both numbers are assigned on create and never edited.

​

Best practices

• Let the auto-seeded outbound legs do the work. Issuing a factory order sets up the outbound legs the team will work; treat the Add button on the Outbound sub-tab as the one-off path, not the default one.
• Record Actual ship date only when the leg has truly shipped. The date is the trigger that draws the finished-goods record down — if the leg is delayed, leave the date blank and the leg in Draft.
• Use Unlock rather than delete-and-recreate if a leg was marked shipped by mistake. Unlock reverses the finished-goods record draw-down cleanly; delete-and-recreate is refused on Shipped legs anyway, and unlock is the path the platform supports.
• Set the commercial shipment’s Destination deliberately. Editing it overrides the order’s default destination for this batch only — useful when a batch is going to a different port from the order’s default. The destination on the commercial shipment is what prints on the packing list.
• Cap the per-size lines at the ordered quantity. The over-ship guard refuses a save that would push the cumulative shipped total above the ordered quantity for a size — split the batch across two shipments if the team needs to record short and long shipments separately.
• Use the shipment-detail sheet for the packing spreadsheet, the per-size lines for the order’s progress. The two surfaces are not synchronised; fill both when the order needs both, and treat each as what it is.

​

Related pages

• Orders — the order detail’s Shipments and Outbound sub-tabs and where the two records live on the order.
• Production — Issuing seeds the outbound skeleton — the factory-order side that seeds the outbound shipments.
• Production — The inventory ledger — the finished-goods record the outbound shipment draws down, and the receipt-of-finished-goods side that brings it back up.
• Order lifecycle — the work-phase advance the commercial shipment fires, and the commercial-status flip on the first shipment.
• Finance — the commercial invoice the commercial shipment anchors.