A delivery-time calculation sounds like a simple feature: a customer places an order, the system checks stock, and it returns a promised date. Most teams write that logic straight into the ERP's scripting layer without stepping back first. The trouble is that "check stock and return a date" hides several decisions that are easy to get wrong once the order cannot be filled from a single place — and those mistakes usually surface only once, in production, when a customer calls asking why the promised date was wrong.
One path only — the XOR split
Before writing a line of code, the underlying process can be drawn as an EPK (Ereignisgesteuerte Prozesskette / event-driven process chain): a sequence of events and functions connected by explicit gateways. The first gateway here is an XOR split (exclusive-or): for a given order, exactly one of three paths is taken:
- It can be fulfilled from a single warehouse.
- It must be split across several warehouses.
- It is not available at all.
Drawing this as an explicit branch, rather than leaving it implicit in a chain of if-statements, forces you to name all three outcomes before any of them is coded.
When it splits — the AND join
The split path is where most of the real complexity sits. Once an order is divided across multiple warehouses, an AND join (paralleles UND) applies: each involved warehouse runs its own pick time and shipping time, and these run in parallel, not one after another. Modeling this explicitly matters because a warehouse process is not a single relay race — warehouse A does not wait for warehouse B to finish before it starts.
The pitfall the model caught: MAX, not SUM
Because the two warehouse processes run in parallel, the total delivery time for a split order is the maximum of the per-warehouse times — the customer receives the full order only once the slowest shipment arrives — not the sum of all of them. A naive implementation that simply adds up every warehouse's time would systematically overstate delivery time on every split order. This is exactly the kind of error that is cheap to catch on paper, while drawing the AND gateway, and expensive to catch after the module has already gone live.
Still not the final answer: calendar corrections
Even after the raw MAX (or single-warehouse) time is computed, it is not yet the number to show the customer. Working-day and cut-off-time corrections still need to be applied — an order placed after the daily cutoff effectively starts on the next working day, and weekends or holidays shift the count further. Skipping this step, or getting the calendar logic wrong, is a separate and equally common source of an incorrect promised date.
Put together, this one small module surfaced three concrete pitfalls:
- Treating parallel warehouses as sequential.
- Using SUM instead of MAX for split deliveries.
- Mishandling the working-day/cut-off logic.
None of them are exotic — they are the kind of mistake any developer can make while typing code directly. The practical takeaway for a workshop building or specifying its own ERP logic is simple: for any process with more than one possible path, sketch it first — even roughly, on paper, with its splits and its parallel steps marked — before anyone writes the calculation in code. It costs an hour, and it is far cheaper than a wrong delivery date in front of a customer.
Nguyễn Hải Minh
I build custom software and data solutions for manufacturing ERP systems, including INFOR, for clients in Germany. As a Staatlich geprüfter IT-Techniker (Fachrichtung Informatik) and Informationselektroniker, I combine deep technical skill with business-systems thinking to help manufacturers automate operations and optimize cross-border import and export.
More about the author →