Advance ship notice
Built from the pick and pack confirmation inside Linnworks, not from the original order lines. If the carton count changes on the floor, the 856 has to change with it or it fails compliance checks on arrival.
AI Powered
EDI with expert operators
Linnworks
EDI Integration
Who actually builds the advance ship notice, the order system that took the order, or the warehouse that just closed the cartons? Linnworks runs warehouse operations over REST, and that protocol is what carries pick confirmation, carton detail and dispatch timing out to a partner feed, not the order as it was first placed. Get that handoff wrong and the ASN describes an order instead of the shipment that actually left the dock.
A fill rate chargeback lands on an order Linnworks never picked that way.
Most of these trace back to the gap between what the order system expected and what the warehouse actually did. A late ASN usually means the 856 waited on a pick confirmation that was slow to post. ASN non-compliance usually means the carton structure in the 856 didn't match what the floor recorded. Labelling disputes come from carton detail generated after the fact instead of read off the pack station.
- Late acknowledgement
- Late ASN
- ASN non-compliance
- Routing guide
- Labelling
- Fill rate
Three things have to be settled before the first ASN goes out.
Onboarding on Linnworks starts with the pick and pack workflow, not the order feed, because that's where the ASN's carton detail actually originates. Settle how reserved stock gets reported to the partner before it's picked, and settle who signs off the carton label format on the floor before live volume starts.
- Confirm which warehouse processes in Linnworks generate the carton and weight detail for the ASN
- Agree how reserved stock is reported to the partner before it's picked
- Set who signs off the carton label format against the partner's routing guide
The carton list isn't the order list, and the partner wants the carton list.
Each document below depends on Linnworks reporting what happened at pick and pack, not what the order originally asked for.
Warehouse shipping order
Linnworks receives this as the trigger to allocate stock and start picking. Whatever quantity actually gets released to pick is what everything downstream, the ASN included, has to match.
Invoice
Priced lines depend on whether the invoice is built from the confirmed ship quantity or pulled back from the original order. Those two numbers only match when nothing changed between release and pick.
Functional acknowledgement
Runs against whatever document Linnworks just sent out over REST. A missed or late 997 on an inbound order is usually the first sign something stalled before picking even started.
Warehouse shipping advice
Linnworks' own account of what happened on the floor, cartons, weights, carrier. This is the record a partner's receiving system checks the 856 against, so a disagreement between the two points straight back here.
Inventory advice
Bulk operations let this update in batches as picking consumes stock, which is what keeps the figure from lagging behind what the warehouse has already committed to an order.
Every document on this list depends on Linnworks reporting the pick after it happens, not the order before it.
REST is the lead fact, so everything downstream depends on what Linnworks exposes through it.
Linnworks exposes warehouse data over REST, and that's the channel the ASN, the shipping advice and the inventory advice all travel through. Bulk operations are supported, which matters when a single wave of picking closes dozens of orders at once and each one needs its own carton detail reported, not a single average figure. Nothing here depends on rate limit or version claims Linnworks hasn't published; the protocol and the bulk path are what the EDI build is anchored to.
- X12
- EDIFACT
- AS2
- SFTP
- Cloud storage
protocols
REST
bulk operations
yes
Confirmed against your instance during onboarding.
Six documents run through one warehouse system, and someone has to own the handoff.
Managed EDI on Linnworks means someone is watching the gap between pick confirmation and document transmission every day, not just when a chargeback lands. Cogent² AI reads the REST feed for mismatches between what was released to pick and what the floor actually reported, before the ASN goes out. That catches carton discrepancies before the partner's receiving dock does.
Pick to document
Every pick confirmation in Linnworks is checked against the shipping order before the ASN is built, so a short pick shows up as a flagged exception, not a false carton count.
Exception routing
When carton detail from the floor doesn't match what was released to pick, the exception goes to whoever owns that warehouse process, not to a shared inbox nobody checks.
Document timing
The 997, 856 and 945 are tracked against each other, so a stalled acknowledgement on an inbound order gets flagged before it delays the outbound ASN.
Related
Questions worth asking before Linnworks takes on the ASN deadline.
When a partner's purchase order reaches Linnworks, what does it actually get checked against before picking starts?
It's matched against the shipping order Linnworks received, and against the stock Linnworks has allocated to that order, not against an item master sitting in a separate system. If those two don't agree before picking starts, the mismatch shows up in the 856 later, not at the point it could have been caught.
If Linnworks moves its REST endpoints to a new version, what actually breaks for an account already live?
The documents mapped against the current REST paths, the inbound 940 and the outbound 856 and 945, need re-pointing to whatever the new version exposes. Bulk calls that batch pick confirmations are the ones to check first, because a version change there tends to show up as a silent gap rather than an error.
With cartons being picked continuously through the day, how does a partner see an availability figure that isn't already stale?
Linnworks reports stock net of what's reserved on the floor, and bulk operations let that figure update in batches as picking consumes it, rather than waiting for a single end of day sync. The 846 carries that number out, so the gap between what's promised and what's actually left is a matter of batch timing, not guesswork.
Before a Linnworks account starts sending ASNs, what do we actually need from the brand's warehouse team?
We need to know which processes inside Linnworks generate the carton and weight detail the ASN depends on, and who on the floor can confirm that detail is accurate before it's sent. Without that, the first live ASN is built on an assumption rather than a pick confirmation.
If the partner changes how they want cartons labelled or structured in the ASN, who goes back into Linnworks to change it?
We do. The build sits on Linnworks' REST feed, so updating how carton detail is read off the pick and pack process is our job, and the brand shouldn't need to touch warehouse configuration to accommodate a partner's new rule.
Given the ASN is built after picking finishes, can it still reach the partner by the stated cutoff?
That depends on how long the gap is between a pick confirmation posting inside Linnworks and the document actually leaving. Bulk operations can shorten that gap by processing carton confirmations as a batch rather than one at a time, but it still needs measuring against the partner's cutoff, not assumed.
Need help with this?
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.