Shipment planning and handoff records
Blank planning templates for an agreed warehouse workflow.

General
- Agree the location, scope, reporting interval and person updating each record.
- Keep SKU, order, parcel, barcode and tracking references as text. Preserve leading zeros.
- Use cm and kg. Dates: YYYY-MM-DD. Timestamps: include a timezone, for example 2026-10-06T09:00:00+08:00.
- Unknown is different from zero. Use "unknown" for missing values; zero means a known value of none. Leave cells intentionally blank only where the instructions say not to repeat a value or where a field does not apply. Do not calculate a balance or shipment total until the required inputs are known.
- The files are not Shopify, Amazon or Walmart import formats. Map them to your agreed reporting method first.
- Keep customer addresses and personal data in the agreed secure order system; the parcel template uses references.

Inventory brief
Use one row per SKU or variant within each supplier/PO delivery. Keep the corresponding supplier reference and inbound tracking reference with that row.
Product length (cm), Product width (cm), Product height (cm) and Unit weight (kg) are single-unit reference inputs. In Required prep or Special handling, state whether they describe the bare product or its current sellable-unit packaging, and whether they are estimated or measured. Do not treat these fields as final transport measurements.
For the freight calculator and release record, use the outside dimensions of the finished packed carton and its gross weight, including packaging. Calculate different carton measurement groups separately.
Approved label file and Label version refer to the approved product-label file for that SKU and variant. UPC/GTIN or FNSKU is used only where applicable to the agreed marketplace instructions. Keep carton receiving and carrier label files separate from these product-label fields.
Record Shipment plan reference together with Shipment plan version. When the approved plan changes, review the affected carton allocation and receiving labels before release; keep the final carton details in the dispatch record. A previous release decision must be explicitly reviewed for the affected stock and cartons after a product, packing, label or plan change. Retain the original decision and record either a new approval or an explicit confirmation that covers the current versions and quantity. Identify which stock is affected; do not assume unaffected stock needs a new hold.

Supplier receiving and discrepancy record
One row per actual delivery receipt, SKU, variant and receiving location. Give each delivery its own receipt_reference, retain supplier_order_reference and inbound_tracking_reference, and use that same receipt key when updating its count or decision.
expected_units means the agreed quantity expected in this delivery, not the whole purchase-order total. Keep the purchase-order total in the source order or separate reconciliation. If the expected quantity for this delivery is not known, enter "unknown"; do not infer a shortage by comparing a partial delivery with the whole purchase order.
received_units is the physically counted quantity for this receipt. A later recount updates this receipt record; it is not a second receipt. record_updated_at identifies when the row was last revised. Do not add old and revised copies together.
Record discrepancies and affected quantities against the same receipt. Do not repeat the received quantity in additional rows for each issue or action; retain the detailed evidence and decisions in the linked photo, approval or exception record. affected_units describes the issue and is not an additional receipt or an automatic stock deduction.
An illustrative purchase order for 100 units arrives in two agreed deliveries: receipt R-01 expected 60, received 60; receipt R-02 expected 40, received 40. Received total = 60 + 40 = 100. Do not enter the purchase-order total of 100 as the expected quantity on both delivery rows.

Carton and dispatch handoff record
One row per SKU within a carton. Use shipment_reference plus carton_number as the unique carton key; carton numbers can repeat in different shipments. Use an unambiguous SKU for each variant and record the actual units_in_carton on each SKU line.
Enter length_cm, width_cm, height_cm and gross_weight_kg on one SKU row only for each carton; leave these cells intentionally blank on its other SKU rows. Those measurements describe the finished packed carton, not the individual product. Unknown required carton measurements must be marked "unknown" on the carton's measurement row.
Group by the unique shipment/carton key before counting cartons or calculating volume and gross weight. Reconcile units across the SKU lines separately. Do not count repeated carton, label or tracking references as additional cartons.
A mixed carton with two SKU lines and a gross weight of 12 kg is one carton weighing 12 kg, not two cartons weighing 24 kg. For example, its SKU lines can contain 30 units and 20 units while its packed measurements appear on the first line only.
product_label_reference and label_version identify the approved product-label file and version for the SKU on that line. They are not the carton receiving-label version.
receiving_label_reference and receiving_label_version identify the approved marketplace receiving-label file for the carton. shipment_plan_reference and shipment_plan_version identify the approved plan covering that carton. Keep these carton-level references and versions consistent across all SKU rows with the same unique shipment/carton key, while product-label references can differ by SKU.
If a platform label or shipment plan does not apply, use the agreed not-applicable mapping, such as "N/A", for those fields. Keep the applicable shipment/carton key and carrier tracking and handoff references; not applicable is different from unknown or not yet approved.
product_change_reference links an affected SKU line to the applicable product, component or packing change record; recheck_reference links it to the findings after the agreed work. These references may differ between SKU lines in the same carton. Where several changes apply, use an agreed consolidated reference that retains each underlying change and check. Use the agreed not-applicable mapping only when no change or recheck applies; unknown or pending approval is not N/A.
release_approval_reference must identify the final decision covering the actual carton contents, quantities and current product/packing instructions, label files and shipment plan. A product-change decision or completed rework job alone is not that release approval. Keep the carton-level release reference consistent across its SKU rows and retain any supporting SKU or batch approvals. Review affected cartons again after a change; unresolved affected stock remains identifiable in the agreed hold record.
Keep the final contents, current label files, shipment plan and release approval aligned before handoff. An entered tracking reference or planned label does not establish carrier collection or destination receipt. units_in_carton describes packed contents and can be recorded before collection. Packed quantities, labels and release approvals do not reduce physical stock. Count the units as dispatched_units in the stock balance only after actual carrier handoff is recorded with the corresponding evidence; reconcile the completed handoff to the carton/SKU quantities. Keep carrier_handoff_date unknown until that event occurs.

Product change approval and release record
One row per change_reference, SKU, variant and affected batch. Split rows when the affected product or batch differs. affected_qty is the scope of the proposed change, not an additional receipt, dispatch or release. Keep the quantity_unit explicit; components and finished sets are different quantities.
decision, decision_owner, decision_date and approved_version document the specification or change decision and its conditions. An approved sample or new version does not establish that the work was completed, the agreed recheck passed or the stock may be dispatched. A change still awaiting a decision has no approved version; use "unknown" for a pending reference rather than inventing approval.
change_completion_reference identifies evidence of the work actually completed on the affected stock. recheck_reference identifies the agreed method, coverage, findings, checked quantities, acceptance criteria and unresolved quantities. findings_reference can retain the evidence used to decide the proposed change; keep the later recheck distinguishable. Sample coverage must not be described as every unit checked.
release_qty is the quantity actually authorized by the final release decision, in quantity_unit; it is not the proposed affected quantity or the quantity already dispatched. Record release_approval_reference and release_approval_date (YYYY-MM-DD) only for an actual decision covering the current version, identified batch and quantity. Until the decision exists, use "unknown" for these pending values; use 0 only if a real decision authorizes no units.
Record conditions, next_review and status for unresolved stock and identify its owner in the linked decision or hold record. If a changed instruction affects a prior release approval, retain that approval and record the new review before the next handoff. A specification approval cannot silently carry forward an older release decision.
Update the same change/SKU/variant/batch row when its review progresses. Retain old copies as history, not additive quantities. If there are several partial releases, link a release register listing their unique approvals and quantities; release_qty is the total authorized within the selected current record, and its release reference identifies that register. Do not total historical copies or overlapping releases. The same stock may appear in several change records; their release quantities are approval scopes, not additive stock movements. Reconcile authorized stock by SKU, batch and unique release reference in the linked register. Use the dispatch record to reconcile the packed contents against the completed handoff; do not count prepared carton rows as actual dispatches.
Illustrative example only: a change affects 100 units. Approval of the new packing method does not release 100 units. After the agreed checks, the final decision authorizes 80 and keeps 20 held. Record affected_qty = 100, release_qty = 80 and the supporting check and release references; dispatch can still be pending. Do not put 80 in dispatched stock until it physically leaves.

Quote inputs and fee scope
Use record_type = shipment_input for product and packing inputs, and record_type = charge_scope for one quoted work item. Keep project_reference and quote_version consistent for the scope being reviewed.
On shipment_input rows, leave charge_reference, charge_item and fee terms blank. Identify the SKU and variant or describe the representative packed configuration in variant_specification. State what the units quantity represents there, especially for components or finished sets. Packed dimensions and gross weight describe that finished package or configuration; these quote inputs are not additive shipment totals or a final carton manifest.
Enter shared project context, such as supplier_count, monthly_orders, storage_period and returns_location_request, once on a shipment_input row per project and quote version. Other product rows leave that shared context intentionally blank. sales_channel and destination_country may be repeated as needed to identify the relevant route, but their presence does not create another shipment.
On charge_scope rows, use one unique charge_reference per work item and scope within the project and quote version. Describe the work and its scope in charge_item, included_work, excluded_work and billing_event; identify SKU only when the fee is specific to that SKU. A project-wide charge is entered once, not once per product.
Charge rows leave product quantities, supplier_count, monthly_orders, units_per_order and packed measurements intentionally blank. Keep billing_unit, minimum_charge, currency, validity and the agreed fee inclusions with the charge. This file records scope; use the approved quote and its charging quantities for costs rather than multiplying or summing product input rows.
Record approval_reference only when an actual approval exists. A quote version, validity date or charge reference does not establish approval. Keep a revised version distinct and compare within the selected version rather than adding versions together.
An illustrative project has one shipment_input row for 100 product units and three charge_scope rows for receiving, labeling and dispatch. Product quantity is still 100, not 300. Each fee has its own charge reference and its agreed charging basis.

Stock balance record
One row per SKU, variant, location, batch (where used) and reporting period.
Use the same unit throughout: components and finished sets need separate SKU records.
Closing physical units = opening physical units + received units - dispatched units - completed removal units + signed adjustment units.
Use completed_removal_units only for approved removals or disposal physically completed during the reporting period. Record the source evidence and approval reference. Approved removals awaiting completion remain held and part of physical on-hand stock; approval alone does not reduce the balance.
A correction may be positive or negative; record its reason, source evidence and approval reference.
Stock still inbound is recorded separately and is not part of physical stock at the location.
Divide closing physical stock into mutually exclusive buckets: held, reserved and available for a new release. Do not count the same unit in two buckets.
Reserved stock remains physically on hand until dispatched; creating a reservation is not an outbound stock movement.
Returned goods physically received may be part of on-hand stock while still held pending inspection or approval. Do not treat them as available automatically. Approving restock changes their availability; do not add the same physical receipt a second time.
A transfer leaves the origin when handed over and remains inbound to the destination until actually received. Keep location records separate.

Illustrative example only
Opening 100; received 40; dispatched 20; completed removal 5; adjustment 0.
Closing physical stock = 100 + 40 - 20 - 5 + 0 = 115.
Held 10; reserved 30; available for a new allocation = 115 - 10 - 30 = 75.
If another 20 units are still inbound, closing physical stock is still 115.
Agree how your reporting system maps these categories; the example is not a completed customer record.

Order and parcel record
One row per order line within a parcel. Use the same parcel reference on all lines belonging to that parcel.
A single order can have several parcels, and a single line's quantity can be split between parcels.
For each order line, reconcile dispatched quantities across parcel rows with the approved quantity. Record remaining unfulfilled quantities in your order workflow.
Enter packed_length_cm, packed_width_cm, packed_height_cm and gross_weight_kg on one row only per unique parcel_reference; leave these cells intentionally blank on its other SKU rows. Use the finished packed parcel, including packaging. Mark an unknown required measurement as "unknown" on the selected measurement row. Repeated order-line rows do not create extra parcels, volume or gross weight.
Enter a parcel's total shipping quote and total billed shipping amount on one row only; leave these cells blank on its other SKU rows. Group by unique parcel reference before totaling charges or parcel counts.
Keep warehouse handoff, first physical carrier scan and delivery as separate timestamps. Label creation alone is not a physical scan.
Do not mark the whole order delivered just because one parcel was delivered.
Record any approved split and its effect on packaging, cost and customer tracking updates.

Return disposition record
Use one row per SKU and approved action within a return reference, with a distinct action reference. Split rows if quantities require different actions.
Record receiving location, quantity, condition, check scope and photo evidence before recording the approved action.
Tie handling costs to the action and quote reference. Do not repeat the same whole-return fee across several SKU/action rows.
Keep received quantity and remaining held quantity at the return/SKU level in your reconciliation; repeated references across action rows are not extra receipts.
Use actual_processed_units for the quantity actually handled, and record the resulting stock movement after completion. A proposed action is not a completed movement.
Customer refund decisions and carrier claims remain separate. A refunded item may still be held pending a warehouse decision.
Confirm the local receiving address and permitted handling before customers send returns.

Linked filled examples
The examples/ directory contains receiving-example.csv, dispatch-example.csv, stock-example.csv and order-parcel-example.csv with the same headers as the corresponding blank templates. They contain fictional learning data; all approvals, checks, tracking events and evidence references are illustrative. Start actual work in the blank templates.
Read examples/README.txt for the common SKU, receipt, carton, parcel and stock references and expected totals. Dispatch and parcel rows describe the same physical handoff, so count that outbound stock once. Import identifier columns as text before loading the files and confirm SKU 000101 and carton 0001 retain their leading zeros.

Returned-unit component check record
Use one row per component actually checked within an identified returned product unit. returned_unit_reference identifies that physical product unit; return_reference plus returned_unit_reference is the unique returned-unit key. Keep component_sku and the expected_set_spec_version with each component row. Repeated unit references are not additional returned products.
received_component_units is the count observed for that component in this checked unit, not the quantity across the whole return or a sample multiplied by the return quantity. Use 0 only when the agreed check confirms that none of the expected component is present. An unchecked component or an unknown count is "unknown", not 0. State the actual check_scope and opening_authorized basis; checking a sample does not establish the condition of every returned unit.
Enter held_product_units on one component row only per unique returned-unit key; use a known value of 0 or 1 and leave it intentionally blank on the other component rows. If the hold status is pending or unknown, enter "unknown" on that one row. Components are not additional finished-product units, and their counts cannot be added to held_product_units.
When loose components cannot be reliably associated with a particular returned unit, record the unresolved association in the linked evidence or exception record. Do not assign them to a returned_unit_reference arbitrarily or report them as that unit's verified contents. Keep the affected units identifiable for the agreed review.
The component check records observations and proposed_disposition. A finding, approval_reference or inventory_movement_reference alone does not establish a completed stock movement. Reconcile any approved and completed action through the return disposition and stock records, with its actual quantity and action_completed_at; do not count the physical return receipt again.

Fulfillment pilot checklist
Use one row per order line within a parcel in the selected pilot. Identify the line with order_line_reference and use pilot_reference plus order_reference plus parcel_reference as the unique parcel key. A parcel containing several SKU lines remains one parcel; a split order can have several parcel keys.
units is the quantity for this order line in this parcel. Reconcile quantities across parcels against the approved quantity for the same order line, and retain unfulfilled quantities in the order workflow. Do not repeat the whole ordered quantity on each split parcel row or combine historical copies of a pilot result as new shipments.
Enter packed_length_cm, packed_width_cm, packed_height_cm, gross_weight_kg, quoted_amount and billed_amount on one row only per unique parcel key; leave those cells intentionally blank on its other SKU rows. Use finished packed parcel measurements, including packaging, and mark an unknown required measurement or amount as "unknown" on the selected row. Group by the unique parcel key before counting parcels, summing gross weight or totaling parcel fees; repeated SKU lines do not create more shipping charges.
Keep parcel-scoped warehouse_dispatch_at, carrier_handoff_at, first_physical_scan_at, delivered_at, carrier_service and tracking_reference consistent across all rows for the same parcel. These are separate actual events: label creation is not a physical carrier scan, and delivery of one parcel does not establish delivery of the entire split order. Include a timezone in every timestamp; use "unknown" until an event has occurred or its time is confirmed.
stock_approved_at records the actual approval covering the stock for that SKU line; retain the supporting stock decision in decision_reference or its linked record. order_accepted_at covers the order acceptance and must be consistent for that order within the selected pilot. Neither approval nor acceptance is proof of dispatch. Keep the agreed estimate_clock_start, estimate_day_basis and destination_charge_scope explicit, and retain the final quote and billing evidence so a parcel fee is counted once.

FBA shipment change record
Use one current SKU line per new_shipment_id plus new_carton_id within the selected change_reference and current change version. Keep earlier files as dated history rather than combining old and current rows. sku_text identifies an unambiguous SKU and variant; new_quantity is that SKU's actual packed quantity in the current new carton. Group by the new shipment/carton key before counting current cartons.
label_version refers to the current product-label version for the SKU; product_label_reference identifies its file. approved_barcode_text is the approved product barcode value, not a carton receiving label. receiving_label_reference and receiving_label_version identify the current carton receiving-label file and version; shipment_plan_reference and shipment_plan_version identify the current approved plan. Keep these carton-scoped receiving and plan references consistent across all SKU rows for the same new shipment/carton key. Use the agreed N/A mapping only where a field does not apply; unknown or pending approval is not N/A.
Enter final_length_cm, final_width_cm, final_height_cm and final_gross_weight_kg on one SKU row only per new shipment/carton key; leave them intentionally blank on its other SKU rows. These measurements describe the finished packed carton including packaging. Unknown required measurements are "unknown" on its measurement row. Repeated SKU lines do not create additional cartons, volume or gross weight.
old_quantity and quantity_held describe the source SKU in the old_shipment_id plus old_carton_id scope. If that source is split across several current new-carton rows, enter each source total once and leave those fields intentionally blank on the other current rows for the same old shipment/carton/SKU key. Do not add repeated source totals, or treat quantity_held as an additional received or dispatched quantity. Retain the detailed source-to-current quantity mapping, including splits and merges, in evidence_reference. When a current SKU line combines several old cartons, retain all original source keys and their quantities in that linked mapping; do not invent a single original carton or duplicate the current packed quantity merely to list its sources. Use intentionally blank source quantity cells when their separate source totals are held in that mapping, and reconcile new quantities and unresolved held quantities against it.
approved_by identifies the person approving the change or work scope; it does not establish the final permission to release the current packed stock. release_approval_reference must identify the actual final decision covering the current carton contents, quantities, product-label files, receiving labels and shipment plan. Record release_date_YYYY-MM-DD only when that final decision exists. Keep the carton-level release reference and date consistent across the carton rows, and retain any supporting SKU or batch approvals. A pending decision remains "unknown"; after a relevant change, review the earlier release decision before the next handoff.
check_coverage, check_result and evidence_reference must distinguish the agreed checking method, actual coverage and unresolved items; a sample result is not evidence that every unit was checked. Keep unresolved affected stock identified for the agreed hold and decision process. A prepared new carton row, carrier_reference_text or release approval does not establish actual carrier handoff. Reconcile the completed handoff through the dispatch record and its evidence before counting those quantities as dispatched stock. Count only the selected current unique new shipment/carton keys for current preparation totals; archive old carton records for traceability.