Logistics execution scope arguments are usually had as feature lists — which system does shipping, which does transport, where warehouse management sits, and which of them should own the carrier selection nobody wants to touch. That framing produces a diagram everyone signs and an integration that degrades quietly within a year. The question that actually determines whether a boundary holds is narrower and considerably less comfortable to ask out loud: for each master object in the stack, which single system is allowed to change it. A copy is harmless and often unavoidable. A second editor is neither, and the day two systems both hold an editable product master is the day somebody in your team starts arbitrating differences by hand, usually at the point a chassis is already on the line. Book an architecture review.
Draw the Boundary Around Ownership, Not Around Features
What LES actually covers, where it already overlaps itself, what an event contract has to carry, and the three questions that reveal a duplicated master before it costs you a weekend.
What Logistics Execution Actually Contains
Worth setting out, because a great deal of scope confusion comes from people meaning different things by the same three letters.
Inventory maintenance and goods movements — receipts, issues and stock transfer orders, and the flow of goods through the building.
Outbound deliveries, picking and packing, shipping document creation and shipment tracking.
Transportation planning, freight cost calculation, carrier selection and route determination.
The useful thing to notice is that the overlap problem exists inside a single vendor's stack before anyone adds a third-party system. Transportation appears both here and in the dedicated transport application, which is the more capable of the two and supersedes it — so a plant running both has already made a scope decision whether or not anybody wrote it down.
Two processes sit underneath all three components and are worth naming because they are where the boundary is tested: goods receipt and goods issue. Everything else is arrangement around those two moments. A chassis arriving on a transporter is a receipt. The same chassis leaving the yard against a shipment is an issue. If two systems both believe they own the record of those moments, the divergence will not appear in a design review — it will appear in a count.
There is an honest gap worth stating. The published integration material describes what data moves and through which platform, but it does not delineate where the responsibilities of the core ERP end and those of warehouse, transport or execution begin. That boundary is left to the implementation, which means it is left to whoever is drawing the diagram — and it is why two sites running the same products can end up with genuinely different answers.
One Owner, One Direction
This is the entire architectural question rendered as a picture.
Integration documentation describes transferring master data such as products, business partners and organisational structures into the execution layer, alongside transactional data like deliveries, purchase orders and material documents. That transfer is normal and necessary. What makes it safe or dangerous is whether the receiving system treats what it received as a reference it reads or as a record it owns. The first is a cache. The second is a fork.
The failure is rarely dramatic at the moment it is created. Someone needs a field the ERP does not have, adds it locally, and for several months nothing happens. The divergence surfaces when a part number is changed at the source and the execution layer carries on using its own version — correctly, by its own lights, against a chassis that was built to a different specification.
How many of your master objects have two editors?
Most architecture diagrams show the arrows and not the permissions, so the answer is usually unknown until something diverges. In thirty minutes we will walk your master objects one at a time and mark which have a single owner and which are waiting to disagree.
Who Should Own What
A starting position rather than a universal answer, but the shape holds for most plants. Swipe the table sideways on mobile.
| Object | Owner | Why it sits there |
|---|---|---|
| Product and material master | ERP | Everyone reads it. Nobody else creates or edits it. A part number that exists in two places with two descriptions is a recall conversation waiting to happen. |
| Business partner | ERP | Carriers, suppliers and sites. The commercial relationship lives where the money does. |
| Organisational structure | ERP | Company codes, plants, sales organisations. Changing these anywhere else is how reporting quietly stops reconciling. |
| Storage location and bin | Warehouse system | Where a pallet physically is. The ERP does not need to know the rack and should not be told. |
| Delivery and shipment documents | LES | Transactional rather than master, and genuinely owned here — but they reference masters they must not redefine. |
| Observed events | Observation layer | That a chassis passed the gate at 06:12, with evidence. Owned here because nothing else was watching. |
| Running stock balance | ERP | The number the business plans and bills from. An observation layer that claims this creates a second truth rather than a better one. |
The last two rows are the ones worth defending. Observed events belong to whatever was actually watching, because nothing else has the evidence. The running stock balance belongs to the ERP, because that is where the business plans and bills from — and an observation layer that claims the balance has not produced a better number, it has produced a second one.
What an Event Contract Has to Carry
Five properties. A contract missing any of them will work in testing and fail in a way that is hard to attribute.
A useful contract says a chassis was observed leaving bay four at a time, with evidence. It does not say here is a row from my table. The first survives a schema change at either end; the second does not.
Not the time the message was built or sent. Captures that queue on site during an outage must arrive carrying the time they were actually taken, or every downstream calculation shifts by the length of the outage.
An event should carry the identifier of a part, not its description, weight and classification. Restating a master in an event is how a copy quietly becomes an editable second version.
Every event should have exactly one producer. Two systems emitting the same logical event is the message-layer version of two editors on a master.
Each exchange should state plainly whether it runs on its own or still has a person in it, so nothing on the diagram claims an automation it does not have.
The third is the one that quietly undoes ownership. An event that carries a part identifier is referencing a master. An event that carries the part identifier plus its description, weight and classification has restated the master, and the receiving system now has somewhere to edit it. That is how a clean boundary becomes a duplicate without anyone deciding to create one.
The Three-Question Test
Run this against every master object in the stack. It takes an afternoon and it is the highest-value afternoon in the project.
If more than one system can bring this object into existence, you will get duplicates with different identifiers for the same physical thing.
The one that genuinely matters. Two editors is not an integration pattern, it is a scheduled disagreement.
If the answer is that somebody looks at both and decides, the boundary is not drawn — it has been deferred to whoever is on shift.
If any object fails the third question, it is not an integration issue to be resolved later — it is an unresolved design decision currently being made by whoever happens to notice the difference first. Writing down the answer is the fix, and it costs nothing at design time and a great deal afterwards.
Why Vehicle Plants Feel This Sooner
The same architecture is more forgiving in a general warehouse than it is on an assembly line, for reasons worth being explicit about.
A truck is built from specific parts against a specific configuration. A part master that has diverged between two systems does not cause a quantity error; it causes the wrong component to be presented against a chassis that required a different one. That is a quality event with traceability consequences rather than a stock discrepancy, and it is discovered at a station rather than at a count.
The volume of master objects is also higher and they change more often — engineering changes, supersessions, variant explosions. A boundary that holds under a stable master set comes under genuine pressure when the set itself is moving weekly, which is the normal condition in vehicle manufacturing rather than an exception. The discipline that keeps a maintenance record coherent across a fleet is the same one: one identifier, one owner, everything else references it.
Then there is sequence. A warehouse can usually tolerate a pallet arriving in a different order than expected, because the order is a convenience. A line cannot, because the order is the requirement — an axle assembly delivered in the wrong position against a moving sequence is not late, it is wrong, and the cost of discovering that at the station rather than at the dock is measured in line minutes. Any boundary drawn across a sequenced flow has to answer who owns the sequence itself, and the answer is almost never the system that physically moves the parts.
The last factor is traceability. A finished vehicle carries a record of which components went into it, and that record outlives the systems that produced it. A duplicated master in that context means two defensible answers to what a given part was, years later, with no way to tell which the build actually used.
How FleetRabbit Handles This
Oneflow was built around a position rather than a feature set: it watches, records and files. It does not hold the plan, it does not hold the money, and — the part that matters for a scope conversation — it does not hold master data. Four consequences follow, and the first is the one to raise in the first meeting.
Oneflow does not create or edit products, partners or organisational structures. It reads them and references them, which is what keeps it out of the arbitration problem entirely.
An observation carries the identifier of the part and the unit, not a copy of their attributes, so a master change at the owner propagates instead of conflicting.
Observations taken during a connectivity outage queue on site and arrive batched, each carrying the moment it was actually taken rather than the moment it was delivered.
The sandbox builds the identical message and stops before the network, so an architecture review can inspect exactly what would cross the boundary before anything does.
Two further behaviours exist for the same reason. A reading the system is not confident about is presented as held, with the reason attached, and cannot be selected until a person resolves it — because a guess entered into a system of record is worse than an acknowledged gap, and far harder to find later. And nothing is applied anywhere until somebody presses a button; a form that fills itself silently is one nobody trusts twice, which is a poor foundation for a boundary everyone has to rely on.
Questions Architecture Teams Ask
Where should the scope boundary actually be drawn?
Around ownership rather than around features. For each master object, decide which single system may create and change it; everything else reads. A feature-based boundary looks tidy on a diagram and tells you nothing about what happens when two systems disagree. Scope the Boundary.
Is copying master data between systems wrong?
No, and it is usually unavoidable. Integration patterns routinely transfer products, business partners and organisational structures into the execution layer. What matters is whether the receiving system treats that as a reference it reads or a record it may edit. Draw Your Ownership Map.
How do we find existing duplicates?
Ask three questions per object: who may create it, who may change it, and what happens when the two copies differ. Anything where the third answer is that somebody looks and decides is already duplicated, whatever the diagram says. Find the Duplicated Masters.
Does LE overlap with transportation management?
Yes. Transportation exists both inside logistics execution and as a separate, more capable application that supersedes it. A site running both has made a scope decision already, and it is worth that decision being explicit rather than emergent. Review the overlap.
What should an event carry?
The thing that happened, the time it actually happened, and identifiers that reference masters rather than restating them. An event that repeats a master's attributes has given the receiver somewhere to edit it. Define the Event Contract.
What about events captured during an outage?
They should queue locally and arrive batched when the link returns, each carrying the time it was actually taken rather than the time it was delivered. Otherwise every downstream calculation shifts by the length of the outage. Check your queueing.
Does adding an observation layer add another master owner?
It should not, and in this case it does not. The observation layer reads masters and references them, and owns only the record of what was observed. That is what keeps it out of the arbitration problem rather than adding to it. See the split.
How do we start without committing the whole architecture?
Take one flow end to end with write-back disabled, inspect the messages it would have sent, and confirm no master is being restated anywhere in them. That tells you more than a design review and costs considerably less. Start With One Flow.
Add a Layer Without Adding an Owner
Oneflow reads masters and never edits them, references identifiers rather than restating attributes, carries the time an observation was actually taken, and keeps write-back off until somebody has read the exact message that would cross the boundary.
