Partial Deliveries in an Order App: Keep the Remainder Visible
An order should not become “complete” merely because its first parcel has left. If your team sometimes sends goods in stages, specify quantities and delivery records for each order line, then show what remains outstanding. Decide separately whether “dispatched”, “delivered” and “closed” mean different things in your business.
This is a planning guide for a custom order or operations app. It concerns fulfilling one order in several parts, not changing many orders in bulk or deciding when stock is reserved. The recommendations below are proposed requirements, not claims that a particular platform supplies them automatically.
Start with the promise, not the parcel
Keep the original order visible alongside its subsequent fulfilment. Staff need to distinguish the quantity requested, the quantity cancelled and the quantity still due. A delivery record should identify which order lines and quantities it covers, rather than merely storing a tracking number against the whole order.
For a hypothetical equipment supplier, a customer might receive the main machine first and its accessory later. The first dispatch should not hide the accessory from the outstanding-work list. Equally, it should not leave staff wondering whether the main machine needs sending again.
Shopify's official FulfillmentOrder reference illustrates a useful separation: fulfilment orders represent intended work, while a Fulfillment represents ongoing or completed fulfilment work. It also describes grouping items by the location expected to fulfil them. That is evidence for Shopify's model, not a requirement to reproduce its API in your app.
Agree the event that moves a quantity forward
Ask the team to describe the real handover. Does a quantity count as dispatched when a label is printed, when someone confirms packing or when the carrier takes it? Those are different events. Choose one deliberately and label intermediate states honestly.
If delivery confirmation matters, record it separately from dispatch. A tracking number is a reference to a shipment, not your business's definition of successful receipt. Decide who or which trusted integration can confirm each event and what staff should see while confirmation is unavailable.
A correction also needs a defined meaning. Voiding a label before goods leave is different from discovering that goods already sent were recorded against the wrong line. Require a correction path that preserves the explanation without pretending a physical shipment was undone.
Give the remainder an owner and an outcome
An outstanding balance needs more than a small number in the order detail. Decide where staff find it, who follows it up and whether there is an agreed next action. Distinguish a target dispatch date from a confirmed commitment; do not let a guessed date become a customer promise.
Ask whether the remainder can be cancelled, substituted or sent from another location. Substitution should identify what the customer actually agreed to receive, rather than silently relabelling the original item. If you allow an order to close with some goods not supplied, require a clear reason and a visible cancelled balance.
Do not bundle payment or invoicing assumptions into this feature. Whether partial delivery permits invoicing, changes a refund or meets a contract is a separate business and professional-advice question. The delivery screen should not invent those rules.
Make customer updates describe the part, not the whole
Specify what an update says: which items have left, which remain and where the tracking link applies. If there are several parcels, a single “Track your order” button can be ambiguous. Ask for wording that identifies the relevant shipment and does not imply that all goods are on their way.
Agree whether staff can resend a notification without creating another dispatch. Recording physical progress and sending a message should be separate actions. If the message fails, the team needs an honest communication status, not a second shipment record created to try again.
Rehearse a split order before accepting the feature
Use fictitious goods and addresses in the acceptance tests. Demonstrate a first dispatch, an outstanding remainder, a later dispatch and a cancelled remainder as separate cases.
Also require these outcomes:
- A shipment cannot consume more than the currently eligible quantity unless an explicitly approved exception applies.
- Competing staff actions cannot quietly record the same remaining goods twice.
- Cancelling the remainder leaves earlier dispatches visible.
- Correcting an erroneous entry follows the agreed history and physical-goods policy.
- Each customer update identifies the relevant items and shipment.
- A notification retry does not create extra fulfilment work.
- The order only closes under the agreed completion or cancellation rule.
These are acceptance requirements, not a complete concurrency or integration design. The developer must demonstrate how all stock-changing and shipment-recording interfaces honour them.
For an order-management app discussion, bring an anonymised description of one genuinely split delivery, without customer data. The important question is what happens to the unfulfilled promise after the first parcel leaves.
Source boundary
Shopify, FulfillmentOrder: https://shopify.dev/docs/api/admin-graphql/latest/objects/FulfillmentOrder
The reference supports the distinction between intended fulfilment work and ongoing or completed fulfilment, including location grouping. The proposed dispatch events, remainder ownership, corrections, customer messages and acceptance rules above need separate implementation and testing. They are not verified Shopify capabilities or legal advice.