Matching NCR’s Partial Shipment Workflow in an Open-Source Store

When an order contains several products, customers expect the dispatch process to make sense even if items leave the warehouse at different times. A sofa may be ready today while matching cushions are still in transit from a supplier. An open-source ecommerce system must represent that reality clearly rather than treating the order as a single all-or-nothing event.

NCR Retail Online connected online selling with retail inventory and business management processes. Since the product was discontinued, retailers moving to Magento, WooCommerce, or another platform need to reproduce important operational behaviour, including split fulfilment, stock allocation, shipment notifications, invoicing, and returns.

The key is to design a workflow around order lines rather than around the order header alone. Each product line needs its own fulfilment status, warehouse assignment, quantity available, quantity dispatched, and tracking information. The customer should still see one coherent order, while staff can manage several deliveries underneath it.

This approach suits Australian retail conditions, where a business may sell from a shop in Melbourne, a warehouse near Sydney, and a supplier in Brisbane. It also supports practical expectations such as Australia Post or courier tracking, GST-inclusive prices, click and collect, and delivery estimates that change when stock is split across locations.

Define the shipment model before choosing extensions

A partial shipment begins with a single customer order that contains multiple lines or quantities. The system then creates one or more shipment records linked to that order. For example, two lamps can be dispatched from a Sydney store, while a dining table ships later from a Melbourne distribution centre.

The order should retain its commercial identity, including the original billing details, GST calculation, payment record, and total value. Each shipment should separately record packed items, dispatch date, carrier, tracking code, freight charge, and warehouse or store location. This separation prevents a common error: marking the whole order as complete when only part of it has left the business.

A practical status model might include “pending allocation”, “partially allocated”, “ready to pick”, “partially shipped”, “shipped”, and “complete”. These statuses should be calculated from shipment and line quantities instead of being changed manually by staff. If a customer ordered five units and three have been sent, the line should show three dispatched and two remaining.

For homewares sellers, product combinations make this especially important. A home décor catalogue may contain bulky furniture, fragile accessories, and supplier-direct products in the same basket. Those items will rarely share the same delivery timetable, packaging method, or fulfilment location.

Build allocation rules around Australian stock realities

The allocation engine decides which stock is reserved for an order and which location should fulfil it. In an open-source platform, this can be handled through native multi-source inventory features, a warehouse extension, or custom middleware connecting the store to a point-of-sale or ERP system.

Useful rules include “ship from the closest available location”, “prioritise the primary warehouse”, and “keep a bundle together where possible”. Retailers should also define what happens when one unit is available in-store but the remaining units are on purchase order. The system may split the line, hold the full quantity, or offer the customer a choice.

Australian delivery geography makes these rules commercially significant. A parcel sent from Perth to regional Queensland may have a very different delivery window from one sent within Melbourne. Stock should therefore be allocated with freight zones, carrier cut-off times, warehouse capacity, and public holidays in mind. A same-day promise that works in inner Sydney may be unsuitable for a rural address.

Click and collect needs its own path. A store can reserve an item for collection without creating a courier shipment, while a second item in the order may be delivered to the customer’s address. The customer account should show both fulfilment methods, and staff should receive a collection-ready notification only for the relevant line items.

Connect payment, tax, and customer notifications

Payment handling is one of the areas where a copied workflow can fail. Most retailers authorise the total at checkout, then capture payment when goods are dispatched. Others capture immediately, especially where payment providers or marketplace rules require it. The selected method must be compatible with split shipments and partial refunds.

A shipment-level process should never duplicate the original charge. If an order worth A$240 is dispatched in two instalments, the system needs a clear capture policy, such as A$140 at the first dispatch and A$100 at the second. Payment records should show the relationship between each capture, shipment, refund, and credit note.

GST also needs careful treatment. Australian prices are generally displayed inclusive of GST to consumers, and tax invoices must contain the required business and transaction details. A partial dispatch does not automatically mean the tax treatment is identical for every product, particularly when a business sells taxable goods alongside GST-free categories or uses different legal entities. Tax configuration belongs in the platform and accounting integration rather than in a notification template.

Customer communication should be event-based. The first email can confirm that part of the order has shipped and identify the dispatched items. A later message can provide the remaining tracking details. The customer portal should display a single order with separate delivery cards, avoiding vague language such as “your order is on its way” when only one carton has left the warehouse.

Where the business sells products with specialised commercial rules, a clearly documented calculation model is useful. The explanation of contribution mechanics illustrates why a system should record how a value is derived, rather than presenting only a final number. The same principle applies to freight allocation, discounts, refunds, and shipment totals.

Implement the workflow in Magento or WooCommerce

Magento can support a sophisticated partial fulfilment design through its inventory sources, reservations, shipment entities, APIs, and extension ecosystem. A developer can configure source selection, create shipments against selected quantities, expose tracking data in the account area, and connect orders to an ERP or retail management system.

WooCommerce can achieve the same outcome, but the implementation often depends more heavily on plugins and custom development. Products, order items, stock quantities, fulfilment records, and tracking data must be kept consistent across the storefront, warehouse system, and payment gateway. A plugin that merely changes the order status is not enough if it cannot record which quantity was shipped.

In either platform, avoid using one status field to represent every operational event. Keep separate fields or records for allocation, picking, packing, dispatch, delivery, cancellation, and return. This makes reporting more reliable and allows support staff to answer precise questions, such as whether an item is waiting for stock, packed but uncollected, or lost in transit.

A specialist integration partner can reduce risk when the store must communicate with NCR Counterpoint or another retail back office. For instance, retail integration support can be relevant when inventory, customer records, orders, and fulfilment events need to move between systems without creating duplicate sales or stock movements.

Test migration, exceptions, and operational reporting

A partial shipment workflow should be tested with realistic scenarios rather than a single successful order. Include orders with one line split across several shipments, products allocated from multiple stores, backordered items, cancelled quantities, failed payments, damaged goods, customer collection, and a shipment that is returned to sender.

Migration testing also needs historical order behaviour. Determine whether old NCR orders will remain visible in the new customer account, whether tracking links will be preserved, and whether open backorders will be imported as active orders or recreated manually. A carefully managed cutover is described in guidance on avoiding migration downtime, which is particularly relevant when the storefront must continue trading during the change.

Reports should distinguish ordered, allocated, shipped, delivered, returned, and refunded quantities. Warehouse teams need pick and pack queues by location, while finance teams need shipment-level payment and tax information. Management may also want to measure split-shipment frequency, delivery cost per order, stockout rates, and the number of customers receiving multiple parcels.

Australian privacy obligations should be considered in customer and tracking data flows. The Privacy Act 1988 and the Australian Privacy Principles affect how personal information is collected, stored, accessed, and shared with couriers or integration providers. Access controls, audit logs, secure API credentials, and limited retention of delivery data should form part of the implementation rather than being added after launch.

The safest migration path is to document the current NCR workflow, map each event to a Magento or WooCommerce record, and run parallel tests before switching live traffic. Begin with one representative order containing a split quantity, one backordered product, and two fulfilment locations; then verify inventory, payment, tax, notifications, tracking, and refund records from checkout through final delivery.