Most supplier portal integrations are specified as a list of documents — schedules in, ship notices out, a few acknowledgements, some identity plumbing round the edges. What that specification leaves out is the only thing that reliably breaks: the two main message families have opposite update rules. A delivery schedule replaces the one before it. An advance ship notice never replaces anything. Build a portal that treats both the same way and you will either triple a demand figure or quietly lose two truckloads, and in both cases the message log will look perfectly healthy while it happens because nothing technically failed. The distinction is published, specific, and almost never written into the integration brief that engineers actually work from. Request an enterprise demo.
One Portal, Two Opposite Update Rules
Why schedules replace and ship notices accumulate, which fields actually form the key, what nesting an ASN carries, and the identity gap that leaves departed supplier staff holding live logins.
Replace Versus Append
A truck OEM’s own published delivery forecast guideline states the rule in a single sentence: a delivery schedule should be replaced by a new one once the combination of the key elements remains the same. Everything difficult about portal integration follows from that sentence and from the fact that ship notices obey the opposite rule.
The failure mode is asymmetric, which is what makes it hard to catch. Treating schedules as additive inflates demand — visible, alarming, and found within a day. Treating ship notices as replacing silently discards loads that were genuinely despatched, and that one surfaces at a goods receipt several days later with no obvious cause and a supplier insisting they shipped.
Note also what the rule hinges on: the combination of key elements, not a document number. Two messages with different reference numbers but the same key are the same schedule. Two messages with the same reference number but different keys are not.
What Actually Forms the Key
From the same guideline, the elements that together identify a schedule. Get the set wrong and replacement either misfires or stops happening. Swipe the table sideways on mobile.
| Element | Segment | Why it belongs in the key |
|---|---|---|
| Part number | LIN | The item being scheduled. Obvious, and the one everybody gets right. |
| Order number | RFF+ON | The commercial reference the schedule answers to. |
| Place of discharge | LOC+11 | The physical unloading point. Two docks on one site are two keys. |
| Seller | NAD+SE | The supplier party as the OEM identifies them, not as they identify themselves. |
| Ship-to | NAD+ST | The receiving site. |
| Delivery party | NAD+DP | Who actually takes delivery — frequently not the same as ship-to. |
The last three are where implementations go wrong, because they look redundant. Seller, ship-to and delivery party are frequently three different parties, and a portal that collapses them into one supplier identifier has reduced the key and will now replace schedules that were never the same schedule.
Thirty minutes, one question
Does your portal replace on the key, or on the document number?
If nobody can answer immediately, it is worth finding out before a peak week does it for you. We will walk your inbound schedule handling and your ASN handling and confirm each one obeys the rule it is supposed to.
Firm and Forecast Are Codes, Not a Horizon
A persistent assumption worth dismantling, because it is usually wrong and always invisible.
Integrators routinely encode a rule along the lines of the first four weeks are firm and everything past that is forecast. The published guideline does not say that. It carries the distinction as a code on each scheduling line — firm order, forecast demand, and separately a commitment for material, each with its own quantity and shipment date. There is no stated day-range boundary at all.
That matters in both directions. A line marked firm inside what you assumed was the forecast window is a genuine commitment you will miss. A line marked forecast inside what you assumed was the firm window is capacity you have reserved for nothing. Reading the code is the only correct behaviour, and it is less work than the rule people invent instead.
There is a second ambiguity in the same message. Its type identifier can carry either delivery forecast or delivery schedule — the same structure serving two meanings. A portal that ignores that field and treats everything as one or the other will be wrong roughly half the time without ever logging an error.
The ASN Is Nested, and the Nesting Is the Point
Ship notices are built as hierarchical levels, each inheriting from the one outside it.
Flatten this into a list of part numbers and quantities and the message still validates, still reconciles against the schedule, and has lost the thing it was for — which part sat in which carton on which load. That is the information a receiving bay needs when a pallet arrives short, and it cannot be reconstructed afterwards.
It is also, by common account, the single hardest document for suppliers to implement, precisely because the levels each OEM requires differ. A supplier shipping to four manufacturers may be building four materially different notices from the same physical pallet.
The Identity Gap Nobody Owns
Portal access is the part of the architecture where the control boundary genuinely leaves your organisation, and it is worth being precise about what each protocol does.
Confirms the person at the login box is who the supplier's own directory says they are. SAML exchanges signed XML assertions; OIDC returns a signed ID token on top of OAuth 2.0. Either one gets a verified person through the door.
An account appears the first time somebody logs in. Convenient, and documented plainly as create-only — it cannot deprovision, which leaves offboarded accounts lingering.
The REST and JSON standard for automated user and group provisioning. It syncs accounts continuously and revokes access on removal, usually as a soft delete that flips the account inactive rather than deleting it outright.
The gap is the middle row, and it is wider for a supplier portal than for internal software. You do not run the supplier’s HR process and you are not told when their staff change. Without directory synchronisation, a logistics clerk who left a tier-two supplier months ago may still hold a working login to your delivery schedules — and the stated default without it is manual offboarding and stale accounts after people leave.
Onboarding Effort Is the Real Constraint
Four things that reduce it, roughly in the order they pay back.
Schedules are inbound to the supplier and need no new data from them. ASNs are outbound and require them to capture pack and item detail they may not hold yet. Sequencing it the other way stalls onboarding at the smallest suppliers.
A supplier cannot test replacement behaviour without knowing which fields form the key. Publishing it is a one-page document that removes an entire category of support ticket.
A supplier who can re-send yesterday’s message against a sandbox and see what the portal did with it debugs their own problem. A scheduled test window means they debug it through you.
Published automotive message guidelines get superseded — one joint JIT delivery instruction guideline from September 2022 is already marked as no longer valid. Suppliers need to know which release they are building against and that it will move.
The underlying asymmetry is worth naming. A large tier-one supplier has an EDI team and will absorb whatever you specify. A tier-two machining a bracket has one person who also does invoicing, and that supplier is on the critical path for a vehicle just the same. Portal designs are usually tested against the first and deployed against the second.
Why Vehicle Programmes Feel the Cost Sooner
The same integration is more forgiving in general distribution than it is against an assembly line, for a specific reason.
A lost ship notice in distribution becomes a stock discrepancy, found at a count and corrected. Against a chassis in a sequenced build, the same lost notice means a bracket or an axle assembly is not expected, not staged, and not there when the unit reaches the station. The shortage is discovered at the point of consumption rather than at the dock, and the cost is line minutes rather than an adjustment. The discipline is the same one that keeps a maintenance record trustworthy: one identity, one update rule, nothing silently overwritten.
Traceability compounds it. A finished vehicle carries a record of which components went into it, and that record is assembled partly from ship notices. Levels discarded at integration time cannot be recovered years later when somebody needs to know which carton a suspect part arrived in.
How FleetRabbit Handles This
Oneflow does not replace the portal and does not become a second source of schedules. It sits next to the exchange and records what was observed, which is a deliberately narrow job.
An ASN is what the supplier said was coming. Oneflow records what actually arrived at the gate, with evidence and the time it was observed. Those are two different facts and the second one is the one disputes turn on.
Observations are events. Nothing in the observation layer replaces anything, which removes the whole class of bug where a late message quietly overwrites an earlier truth.
A reading the system is not confident about — an unreadable label, a partial scan — is shown as held with the reason attached and cannot be selected until a person resolves it. A guess in a system of record is worse than an acknowledged gap.
The sandbox assembles the exact message that would go back to the portal and stops before the network, so the integration can be reviewed before it is live rather than after.
Questions Integration Teams Ask
Why do schedules replace instead of accumulate?
Because a schedule is a statement of current requirement, not an order being added to a pile. The published guideline is explicit: a new schedule replaces the previous one where the combination of key elements is unchanged. The latest message is the demand. See the Replace Logic.
Which fields make up the key?
Part number, order reference, place of discharge, seller, ship-to and delivery party. The last three are distinct parties more often than people expect, and collapsing them is the common cause of replacement misfiring. Check Your Key Combination.
Can we assume the first few weeks of a schedule are firm?
No, and this is worth correcting early. Firm, forecast and material commitment arrive as codes on individual scheduling lines, each with its own quantity and date. No day-range horizon is specified, so the code is the only reliable signal. Map Your Message Semantics.
What happens if an ASN arrives after the goods?
Published material describes the notice as sent in advance of arrival but does not state a rule for the late case, so the portal has to define one. The safe design treats a late notice as still valid and reconciles it against what was observed arriving, rather than rejecting it and losing the record entirely.
Do we need every hierarchical level in the ASN?
That depends on the receiving OEM, and the variation between them is exactly why this message is the hardest one for suppliers. Decide which levels you genuinely consume, publish that, and do not require detail you will discard. Review Onboarding Load.
Is single sign-on enough for supplier access?
It is enough to authenticate and not enough to control access over time. Login federation confirms who somebody is; just-in-time provisioning is documented as create-only and cannot remove an account. Continuous directory synchronisation is what revokes access when a person leaves. Audit Supplier Access.
How do we reduce onboarding effort for small suppliers?
Begin with inbound schedules, which need nothing new from them, before outbound notices, which do. Publish the key combination up front, and give them a replay sandbox rather than a booked test window. Review Onboarding Load.
Which message version should we build against?
Whichever the receiving OEM currently publishes, and with the expectation that it moves. One joint automotive JIT delivery instruction guideline published in September 2022 is already marked as superseded, so version handling belongs in the design rather than in a later migration project. Request an Enterprise Demo.
Observation, not another opinion
Record What Arrived, Separately From What Was Promised
Oneflow is append-only by construction, holds uncertain readings rather than guessing them, keeps write-back disabled until somebody has read the exact message, and never becomes a second source of demand.
