EDI Integration
A SparkLayer order lands in the same place a retail order does: the merchant's existing Shopify order list. The question worth asking before go live is what tells the warehouse and the invoice run that this one carries a negotiated price and net terms, not the storefront's listed rate. If nothing does, the order ships and bills like any other web sale.
Because the order sits in the same storefront admin as retail traffic, nothing in the platform itself enforces the buyer's routing guide, carton labelling or fill rate commitment. Those checks have to run against the order before it ships, using the terms the buyer agreed, not what the order record shows by default.
SparkLayer puts B2B pricing and terms in front of the buyer at checkout, but someone still has to confirm what happens to that order once it's placed and where each document goes after that.
Each one crosses the boundary between the storefront order SparkLayer creates and the partner's own system. The note below each is where that handoff tends to go wrong.
The order lands in the merchant's existing Shopify order list, same as any retail sale. If the buyer's net terms and tier pricing don't persist onto that order record, it prices like a web checkout.
Built from the storefront's fulfilment record once the order is picked. It only matches the PO if nothing in the order was changed after acknowledgement without updating both sides.
The order already exists in Shopify admin by this point. A change from the buyer has to reach that same record before picking, not a copy of it.
Covers the exchange itself, not whether the order was priced or terms were applied correctly.
Where product visibility is split by customer group, the figure sent has to reflect what that buyer's account can actually order, not the storefront's general stock.
This is where the retail-price risk actually lands. If the net terms set in SparkLayer never reach the invoice run, the buyer gets billed at the listed rate and the dispute follows.
Gives the buyer a chance to catch a wrong price or quantity before the 810 goes out, if the acknowledgement actually carries the applied terms.
Most of what goes wrong here traces back to one thing: the order record in Shopify carrying the buyer's terms, or not.
SparkLayer applies the buyer's pricing, payment terms and quantity rules at checkout, on the merchant's own site. Once that order is placed, it's a Shopify order like any other, and whatever prices the invoice downstream has to be told what terms applied. If that handoff is missing, the order invoices at list price and the buyer disputes it.
A SparkLayer order carrying the wrong terms rarely announces itself. It looks like a normal Shopify order until the invoice goes out or the buyer queries their balance.
Every order is checked against the buyer's agreed price tier and net terms before it's allowed to proceed to pick, so the invoice that follows prices correctly the first time.
A credit note raised against a buyer's account is checked for whether it reached the storefront balance, since a sync gap here is the kind of thing a buyer notices before anyone on the brand's side does.
Dispatch confirmations are checked against the partner's carton labelling rule and cutoff before they're filed, so a chargeback doesn't land on an order that actually shipped on time.
Related
No. SparkLayer orders land in the same Shopify order list as retail orders, so an existing EDI relationship for that store doesn't need to be unwound. What changes is the shape of some of those orders, carrying different terms and payment methods, and whatever handles EDI for the account needs to account for that difference rather than treat every order the same way.
The price tier and net terms set against that buyer's account in SparkLayer, and confirmation of where your finance system expects to read them from. Without that mapping, the invoice run defaults to whatever the storefront's item price shows, which is the gap that leads to disputed invoices and manual credit notes.
That call sits with whoever owns the integration layer between the storefront order and the partner feed. On accounts where Patchworks runs that flow, the labelling or routing check gets updated there, against the order as it sits in Shopify, rather than against a separate wholesale system.
It depends on when the order is actually confirmed in the storefront, since the ASN is built from that record once fulfilment is marked. If pick and pack finish well before the carrier's cutoff, the ASN can be filed from that same order data without a separate wholesale step slowing it down.
No. That's reconciliation and mapping work, checking that a credit raised in one system reaches the storefront balance and that terms set in SparkLayer persist onto the order. It doesn't require a hire, it requires someone watching the handoff and fixing it when it breaks.
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.
We use essential cookies to keep this site secure and working. We do not run advertising or analytics tracking. You can accept optional cookies or keep only the essentials. See our Cookie Policy.
