A manufacturing order backlog management system is useful only if the open balance, promised dates, inventory allocations, production orders, and customer replies still agree after a sales order is shipped in several parts. In a Thai factory, sales may maintain an Excel backlog while ERP records sales documents, MES records production orders, and WMS records individual shipments. Each view can be internally correct and still give the customer a different answer. This guide turns backlog state, integration, RFP requirements, and FAT/SAT into testable procurement requirements.
Start with a quantity invariant for every sales order line
The core rule is latest approved ordered quantity = confirmed shipped quantity + approved cancelled quantity + unshipped balance. Define “confirmed shipped” at a single business event. Picking started, a shipment planned, and a production order completed are not necessarily shipment confirmation. Treat returns, credit notes, and invoice corrections as separate events instead of silently rewriting a historical shipment. If the ordered quantity changes, retain the previous and current order versions and show which version the reconciliation uses.
Every quantity in this article is an illustrative assumption, not a real project result. If a customer orders 1,000 units, 600 units are confirmed shipped, and 100 units are formally cancelled, the unshipped balance is 300. If 200 more units have been picked, the unshipped balance remains 300. The screen can show “200 of the 300 open units are being prepared for shipment.” Subtracting picked stock too early obscures the open obligation if the shipment is stopped.
| Quantity or state | Illustrative value | Meaning |
|---|---|---|
| Approved order quantity | 1,000 | Quantity on the current approved sales line |
| Confirmed shipped | 600 | Cumulative shipment confirmation events |
| Approved cancellation | 100 | Formally cancelled units |
| Unshipped balance | 300 | Customer obligation still open |
| Picked within open balance | 200 | A subset of the open balance, not another subtraction |
Keep the quantity in a defined base unit. Document conversions and rounding for boxes and pieces, kilograms and grams, or lengths and pieces. A display total can match while the physical product does not. Identify substitute items, free spares, kits, and customer specific packs with their own detail references. The point of shipment confirmation may be warehouse issue, carrier handover, or another event depending on the company’s contract and accounting policy. The invariant is a design principle for this project; it does not claim to describe any vendor’s internal data model.
Show open balance, allocation, and promise separately
An open balance of 300 does not mean 300 can be delivered tomorrow. At minimum, show the unshipped balance, stock allocated to it, production linked to it, still unpromised units, and units being prepared for shipping as different values. A customer promise is an approved commitment; it is not the same as physical stock. Inventory reservation can be automatic or manual and may include on hand or ordered inventory depending on configuration. Microsoft’s reservation guidance explicitly distinguishes these cases and batch handling.[2]
Store requested date, customer confirmed promise date, latest forecast date, planned ship date, and actual shipment confirmation date separately. Overwriting a requested date with a revised promise destroys evidence of what the customer asked for and what sales communicated. A forecast change is not automatically a notified and approved change in commitment. If sales, production planning, and warehouse keep separate spreadsheets, nominate a single authoritative view for the customer response.
This article focuses on the open obligation and its state after partial shipment. The process for revising quantity, date, or specification is covered in our manufacturing order change control guide. A broader factory RFP for due date control is covered in the delivery date management system guide.
Model one sales line with several fulfillment lines
Where one sales line is delivered in several installments, retain the commercial parent line and represent its delivery schedules and shipment details underneath it. In Microsoft Dynamics 365, a delivery schedule divides the original quantity into delivery lines with separate dates, quantities, delivery methods, and warehouse dimensions.[1] Microsoft’s direct delivery guidance explains splitting the remainder into a new line when part of an order has already been delivered.[3] The goal here is a common business meaning, not a mandate to copy a particular product configuration.
Suppose the 300 open units are promised as 200 on October 12 and 100 on October 20. The two promised quantities add to 300; the already shipped 600 and cancelled 100 must not be counted again in those open delivery lines. If only 150 of the first 200 units ship, keep 50 open on that schedule and agree a new date with the customer. Do not silently pull forward the second installment merely to make a dashboard appear balanced. Preserve who changed the promise and when.
Each fulfillment line needs a sales line ID, sequence, order version, scheduled quantity, requested date, confirmed date, ship to location, warehouse, delivery method, priority, and approval status. Each shipment detail needs actual quantity, lot, and shipment event ID. If a line mixes multiple destinations or currencies, let the business decide whether the commercial line should be split first. Reports must not sum the parent and child quantities as if both were independent sales.
Figure 1 shows one sales line split into two delivery schedules and multiple confirmed shipments, with the remainder returning to the open balance. The quantities are illustrative.
Assign a system of record to each ERP, MES, and WMS event
One possible split is ERP for the commercial order, MES for production orders and actuals, and WMS for allocation, picking, and shipment confirmation. Real installations overlap. Define which system first confirms each business event instead of relying on product names. ISA-95 provides a reference for exchanging information between enterprise activities and manufacturing operations.[6] It does not automatically assign every WMS function to one level.
| Event or data | Choose the authoritative source | Effect on the open balance |
|---|---|---|
| Sales line and approved cancellation | Commercial order management or ERP | Revises ordered and cancelled quantities |
| Confirmed date and quantity | Approved sales and planning workflow | Revises the open delivery schedules |
| Production order and completion | Production management or MES | Updates supply outlook, not shipped quantity |
| Stock reservation and picking | Designated ERP or WMS source | Changes an open balance subset, not the balance itself |
| Confirmed shipment | One designated WMS or ERP event | Increases confirmed shipped quantity |
| Customer response | Approved sales communication record | Preserves promise version and notification time |
Never count the WMS confirmation and the ERP shipment document as two shipments. If one drives the other, carry a shared event reference and specify which event is the unique confirmation. Completed MES output may still be under quality hold and unavailable to promise. Define whether a returned delivery reopens the original sales line or creates a replacement order. This choice should be visible in the business process, not hidden in interface code.
Keep backorders visible and actively planned
The existence of an open balance does not guarantee that anybody has scheduled its next delivery. Oracle’s partial shipment example shows an order quantity of 10, shipment of 6, and a separate movement or shipment plan for the remaining 4. It also describes a manual step when a backorder event does not flow between systems.[4] The lesson is practical: an integration that receives the shipment but creates no next action for the remainder can leave a customer obligation stranded.
Oracle’s Order Management guide also describes a partial shipment followed by a backordered remainder.[5] These are product examples, not universal defaults for a Thai plant. The testable requirements are that the remainder stays linked to its original line, a named owner must re-promise it, and unpromised open quantities appear in an exception queue.
An open balance is not automatically a backorder. A later installment in a customer approved delivery schedule is a planned open delivery line. If a supply shortage prevents the original fulfillment and the remainder must be rescheduled, it may be treated as a backorder. A remainder past its confirmed date is late. A useful worklist therefore separates on schedule, unpromised, at risk, and overdue balances. Show the oldest unfulfilled promise date, next planned delivery, and notification state. A single “orders with balance” KPI would wrongly classify normal scheduled deliveries as failures.
Link stock allocation and production orders to the relevant installment
Specify whether stock is reserved for the whole sales line or for each fulfillment line. With 300 open and 200 reserved, show “open 300, reserved 200, unreserved 100.” Do not show “open 100”: the customer is still waiting for all 300. If a reserved lot is blocked by quality, a stock count discrepancy, or expiry, release or revise the reservation and trigger a review of the customer promise.
For make to order production, link the appropriate production order to each delivery schedule. If one production order supplies several customer orders, use an allocation table. Planned, released, started, completed, quality pending, and booked into stock have different confidence as supply sources. Planned production must not be presented as physical stock. Changes in yield, equipment availability, or inspection can change the outlook, so a revised customer promise needs authorized review.
In mixed make to stock and make to order operations, distinguish on hand stock, ordered material, work in process, and projected finished goods even when shown on one screen. When a job is moved to a different line or subcontractor, detect duplicate reservation against the old job. When a promise changes, specify whether planning and allocation update automatically or create a pending approval task.
Design the customer answer as one traceable screen
A sales representative needs more than “how many units are open?” The real questions are: how many units have been committed for which dates; are those commitments backed by stock or production; and what changed since the last reply? Show customer, order and line, item, ordered quantity, cumulative confirmed shipments, cancellations, open balance, in preparation, reserved and unreserved quantities, promise schedule, forecast, last update, notification state, and exception reason. Keep the default view concise and allow drill down to shipment, allocation, and production evidence.
The customer response history should contain the recipient, timestamp, language, quantity and date communicated, source version, approver, and communication channel. For Thai, Japanese, and English users, keep one underlying timestamp but localize display. If the commitment is a date rather than an exact time, label it as a factory local date; avoid a timezone conversion shifting it by a day. Record changes in delivery destination or transportation as part of the response context.
Figure 2 shows an ERP sales line, MES production order, and WMS reservation and shipment events feeding one open balance view. Only one source confirms each event to avoid double counting.
Make retries idempotent and handle out of order messages
If a factory connection drops and WMS resends “shipment confirmed, 200 units,” the recipient must not add 200 twice. Use a source event ID, document ID, line ID, and version to apply an event once. An HTTP or transport success does not necessarily mean the receiving business transaction committed. Define acknowledgement, retry, quarantine, manual replay, and reconciliation. Keep an audit record of duplicate events that were ignored.
Order matters too. If an approved cancellation arrives first and an older promise update follows, “last message received wins” can undo the cancellation. Include the original sales line ID, version, occurrence time, and transmission time. Quarantine stale versions. If a physical shipment and cancellation happen near the same time, check whether goods actually left before changing the order ledger. Do not rewrite event history merely to make the invariant look true.
An interface contract must describe the business event, trigger, keys, units, owner, acknowledgement, timeout, retry, ordering, exception queue, replay rights, daily reconciliation, and audit log. For batch interfaces, make the data freshness visible on screen. A dashboard that looks live but shows yesterday’s balance can cause a more serious customer error than a visibly delayed report.
Reconcile discrepancies every day
Daily reconciliation should test the quantity invariant at each order line and compare unique shipment events across ERP and WMS. Billing may occur on another date; avoid demanding artificial same day invoice equality. Separate not received, duplicate, quarantined, and awaiting approval. Every exception needs an owner, deadline, and replay decision.
| Difference | Detection | First investigation |
|---|---|---|
| Double shipment | Duplicate event or detail ID | Retry and receiver’s idempotency key |
| WMS shipment absent from ERP balance | Event reconciliation | Undelivered message, quarantine, unit conversion |
| Negative open balance | Invariant and bound check | Shipment against an old order version |
| Promises exceed the open balance | Sum delivery schedules | Retained old version or duplicate schedule |
| Customer reply differs from screen | Compare response version with latest version | Notification pending or manual correction |
Set thresholds by factory and contract. A green aggregate indicator cannot tell a salesperson which customer is affected. Before holidays, prioritize balances with near term promises and stuck exception events. Manual fixes must preserve the source event, reason, and approver so the next automatic sync does not silently reverse them.
Keep splits, cancellations, and returns distinct
A long lived open balance needs to show why the quantity changed. A partial shipment is fulfillment. A cancellation is an approved reduction of the obligation. A return is a reverse physical flow after fulfillment. Treating all three as a negative adjustment can produce the same number while representing very different obligations. Show the change from yesterday as new order, revision, confirmed shipment, cancellation, return, and reopened obligation, with the source document and approval behind each change.
For example, if 100 units were ordered and 60 shipped, 40 remain. Cancelling 10 of the 40 produces shipped 60, cancelled 10, and open 30. Returning 10 of the already shipped 60 is different. If the customer requires replacement, create or reopen a fulfillment obligation and link it to the original order and return. If a refund settles the matter, do not mechanically increase the unshipped balance by 10. The decision also affects inspection, whether returned goods may reenter stock, and billing correction. Name the person who may reopen a backlog line before the first return occurs.
Give every split schedule an immutable identity
A delivery line number based only on its screen position can be confused after sales reorders dates. Use a stable schedule ID, a parent sales line ID, and a version. If a 200 unit schedule becomes 150 and 50, show how the old line closed and how the two new lines refer to it. Do not reuse IDs or erase the old line. Link a shipment to the schedule version in force when it happened, so later changes to the promise cannot change the provenance of an actual shipment.
If two factories supply one sales balance, keep plant allocation separate from the customer promise. A plan for 120 units from Thailand and 80 from another site must not appear as two customer promises of 200 each. If one plant slips by 50, review the whole customer commitment. Deleting a production job at one site does not cancel the commercial obligation. This is why sales line, delivery schedule, supply allocation, and shipment detail are separate levels of record.
Recalculate the open balance at migration
Migrating only the current balance from an old spreadsheet loses the evidence of shipment and cancellation. For every open order, reconcile approved ordered quantity, formal cancellations, cumulative confirmed shipments, open balance, delivery schedules, promise versions, and references to reservations and jobs. Recompute the balance from events where possible. If the old system overwrote corrections and cannot show history, mark the start value as unverified and record which physical count, shipping document, or customer confirmation authorized it.
At cutover, decide separate freeze times for order revisions and shipment confirmations. Freezing sales while the warehouse continues to dispatch will produce a stale shipment total. Complete final extraction, delta import, invariant reconciliation, and a representative customer response test before making the new system authoritative. If an emergency shipment is permitted during the freeze, prepare a paper document, a duplicate prevention ID, and an owner for later entry. Put these boundaries into the RFP so a vendor prices a correct day one balance rather than only a master data import.
Three balances of 50 that need different actions
Imagine three illustrative orders, each with 50 units open. Order A has a confirmed delivery next month and reserved inventory. Order B is due today, but material is short and the production job has not started. Order C has 50 units picked but blocked by quality. A screen showing only “open 50” cannot tell sales whom to contact first. A needs routine monitoring; B needs re-planning and customer communication; C needs a quality decision and an alternative lot. Keep cause, next action, owner, deadline, and customer notification state with each line.
Prioritization should consider time to promise, customer agreement, alternative supply, and contractual impact, as well as quantity. Automatically taking stock from another order can breach that customer’s promise. Separate a proposed reallocation from its execution and show the before and after effects to an approver. Tune alert thresholds by plant, and watch the number and age of unresolved alerts so a serious late order is not buried in routine notifications.
Put a state diagram and realistic data into the RFP
“Show the order backlog” is not enough for comparable vendor proposals. Supply a sample sales line, delivery schedules, reservations, production order, and shipment details. Include normal and exception state transitions and an example spanning several plants, warehouses, or deliveries if your business needs them. For a demonstration, use one sequence: 1,000 ordered, 600 shipped, 100 cancelled, 300 open, 200 reserved, then another 150 shipped. The final open balance is 150. These are illustrative test numbers only.
Ask each vendor to state whether each requirement is met through standard features, configuration, development, integration, or a manual control. “Possible” should come with a screen, API, report, audit log, or test evidence. Assign the next action after an exception to sales, planning, or warehouse. Compare the full cost of data cleanup, interfaces, testing, onsite training, early support, and later changes, not just subscriptions.
Ten questions to include in an RFP
- Which events update the quantity invariant, and how are corrections preserved?
- How is the remainder represented after a partial shipment?
- Are requested, promised, forecast, and planned ship dates distinct?
- How do reservations and production orders link to an installment?
- Who is alerted when quality hold or downtime threatens a promise?
- Where is the one authoritative ERP/MES/WMS shipment confirmation?
- How are retries, duplicates, reversal of order, and network outages handled?
- How are Thai, Japanese, and English customer replies approved and retained?
- How are returns, cancellations, substitutions, and destination changes modeled?
- Which FAT/SAT and post go live evidence proves the balance is correct?
Test the boundary cases in FAT and SAT
FAT should exercise the quantity invariant and transitions in a controlled environment: zero and small quantities, numeric limits, unit conversion, split shipment, rejection of over shipment, cancellation, return, duplicate events, old versions, and reversed messages. A negative balance guard alone is insufficient; users need to know why a transaction was rejected or held. Intentionally make planned, reserved, and shipped quantities disagree and confirm the screen does not claim unsupported availability.
SAT should run through ERP order, MES job, WMS picking and shipment, and the sales response with real factory roles and devices. Cover shift handover, network outage and retry, label scanning, multiple warehouses, and an urgent customer enquiry. Use controlled test customer data while preserving production like permissions and workflows. The acceptance sheet should list expected balance, actual balance, difference, event ID, evidence, reviewer, and severity of any open defect.
| Test | Illustrative action | Example pass condition |
|---|---|---|
| Partial ship | Order 100, confirm 60 shipped | Shipped 60, open 40, next action remains |
| Cancel | Cancel 10 from open 40 | Shipped 60, cancelled 10, open 30 |
| Retry | Send the same shipment event twice | Shipped stays 60; duplicate recorded |
| Reversed order | Send an old promise version later | Current promise retained; stale event quarantined |
| Quality hold | Block a reserved lot | Open balance unchanged; impact on promise flagged |
| Connection loss | API reply disappears after WMS confirmation | Retry applies the shipment once and reconciles |
All numbers in the table are illustrative test values, not general pass rate standards. Critical cases should pass individually before go live. A minor display defect may be carried over only when it cannot mislead the customer response and has an owner and fix date.
Figure 3 shows a partial shipment and connectivity failure test. A retried WMS shipment event must affect the ERP order balance once, and the customer response must match.
Define the pilot and stabilization exit
Start with one product family and plant where split deliveries occur often and where the responsible teams can work together. Do not choose only easy orders; include cancellations, stock shortages, quality holds, production delay, and retries. If an Excel comparison sheet remains temporarily, define the period, authoritative source, input owner, and retirement condition so duplicate work does not become permanent.
After go live, review balance discrepancies, overdue unpromised units, revised customer replies, interface exception age, and manual adjustments daily. These measures are diagnostic, not guaranteed benefits of installation. Some differences only appear at month end or stock count. Completion should mean the Thai factory team can investigate, replay, approve, and notify customers without depending on the original project team for every incident.
Conclusion: preserve the open obligation through every shipment
Manufacturing backlog management depends on keeping ordered, confirmed shipped, cancelled, and open quantities consistent. Every partial shipment must leave the correct remainder, with its promise, allocation, production, and next shipment still visible. Define the ERP/MES/WMS event owner and event ID so retries and outages do not double count. Preserve customer communication as well as internal records. A useful first step is to select one real split shipment and map where its quantity and dates differ across the sales spreadsheet, ERP, MES, and WMS.
TOMAS TECH can help Thai factories define their backlog and split delivery requirements, ERP/MES/WMS event boundaries, RFP, and FAT/SAT. Even before choosing software, you can discuss an order backlog management project and share the current order to shipment flow.
Frequently asked questions
How is backlog management different from a delivery date management system?
Delivery date management covers procurement, production, and dispatch dates across the plant. Backlog management focuses on the quantity and promise still owed on a sales line after partial shipment or cancellation. The two should connect, but a schedule dashboard cannot be trusted if the underlying open quantity has no owner.
What is the open balance after a partial shipment?
It is the approved ordered quantity less confirmed shipments and formal cancellations. Picking, reservation, planned shipping, and production completion change the state or supply outlook of the balance; they do not themselves reduce the unshipped obligation. Define one business moment for shipment confirmation.
Does backorder always mean late?
No. A later installment in an approved split delivery is a planned open delivery line, not automatically a backorder. A shortage that requires rescheduling a remainder may be managed as a backorder. A balance past its confirmed date is overdue. Keep these states distinct.
What matters most in ERP, MES, and WMS integration?
Choose one authoritative shipment confirmation event and use event and sales line IDs to detect duplicates and stale messages. Do not count MES completion or WMS picking as shipment twice. Require daily reconciliation and a replay path for quarantined events.
What should FAT/SAT prove for an order backlog system?
Run an order through split shipment, cancellation, promise revision, reservation changes, outage, and retry. Confirm the quantity invariant and customer response. FAT tests logic and interface edge cases; SAT tests real devices, operators, shifts, and warehouses.
Primary references
- Microsoft Learn, Delivery schedules.
- Microsoft Learn, Reserve inventory quantities.
- Microsoft Learn, Direct deliveries.
- Oracle Help Center, Backorder/Partial Ship.
- Oracle, Ship Order Lines in Shipment Sets.
- ISA, ISA-95 Standard.
Sources checked on October 8, 2026. All quantities, dates, and test values in this article are illustrative; they are not vendor results, legal thresholds, or promised implementation outcomes.
