Patchworks
EDI Integration
The partner has given a go live date, and by then the purchase order has to land as a proper wholesale order, not a retail checkout line, and the dispatch has to clear as an ASN the partner's system will accept without a query. Patchworks sits in the gap between the storefront and the back office, running the flows that turn one format into the other. Miss either deadline and the test cycle starts again from the top, not from wherever it broke.
Each of these chargebacks usually starts in a different place, not one shared cause. Late ASN and ASN non-compliance tend to come from the same flow: the dispatch confirmed before the carton count is final. Routing guide and labelling chargebacks come from the partner's rulebook changing without the mapping inside Patchworks changing with it. Fill rate, short ship and PO accuracy trace back further, to whatever quantity or price the order carried when it first wrote into the platform.
A Patchworks flow built against a guess at the partner's format fails quietly later, usually on the first real order. Confirm the format and the cutoff first, then build, then break it on purpose before the partner does.
Six documents cover one order's path through Patchworks, from the buyer's PO to the invoice that closes it. Each runs as its own flow, tested against the partner's own version of the format.
If the account's contract rate hasn't reached the flow, the order prices at the storefront's default. A duplicate order number sent downstream gets rejected by the receiving system, the same failure recorded against one Patchworks account trading into a warehouse platform.
A line item carrying a zero value in presentment currency gets rejected by the fulfilment partner on the far side, so the flow has to convert it to a real figure before the ASN goes out.
The object-level mapping that created the order is the same mapping that applies the change, line by line, or the invoice ends up priced against the original quantity.
An untested edge case in the transformation is what leaves an order sitting unacknowledged until someone goes looking for it.
This depends on whichever system last reported stock into the flow correctly; a reservation that never clears shows up as available stock that isn't.
If refunds or cancellations aren't filtered out before the invoice run, the figure on the remittance won't match the ASN, and finance ends up reconciling it by hand.
Each document runs as a separate flow inside Patchworks, built and tested against the partner's own version of the format, not a generic one.
Patchworks' own record for this account type isn't a fixed protocol or a paging limit; it's the transformation layer between systems, built as Flows and Functions and tested against whatever format the partner is currently running. A transformation built once and left alone is how an untested edge case turns into a rejected ASN months later. The pattern that holds up is versioned, testable transformations checked against the partner's changelog, not a one-off mapping built at go live and forgotten.
Go live doesn't close the file, it opens the watch list. These four get checked every week once the account is trading, not just during the test cycle.
Each purchase order has to arrive as a wholesale order at the partner's price, not the storefront's listed rate. That depends on the flow carrying the account's terms into the order object, every single time.
The advance ship notice gets built from whatever the warehouse or fulfilment partner confirms as shipped. If that confirmation comes back carrying a zero value line, the ASN has to show a real figure or the partner's system rejects it.
The 997 confirms receipt without errors. Left unwatched, a rejected PO or ASN sits quiet until the chargeback turns up on the remittance.
A duplicate order number, a failed transformation, a flow that stops running overnight: these get caught and resolved before they become a missed cutoff, not after.
Related
Building Patchworks flows and functions the first time is workflow engineering, and that skill matters at build stage. Running the account day to day, watching for a rejected PO or a transformation that's drifted out of date with the partner's spec, is the managed service, not a role you need to carry on the payroll.
Cogent² writes a translated, governed version of the file into its own location, and Patchworks reads from that, never from the raw drop. Nothing about an existing arrangement for a different account has to change; this account runs as its own flow.
The account's agreed price, the partner's account code and the customer ID mapping all have to be confirmed before the flow runs, not discovered when the first invoice goes out wrong. That field level mapping audit is where most go live delays actually start.
The transformation carries a freshness requirement against the partner's own changelog, so when their spec moves, the flow has to move with it. That update sits with whoever manages the account's flows day to day, not with the brand's team re-reading EDI documentation each time it changes.
The flow runs on the confirmation the moment it posts, not on a batch schedule, so the step itself isn't what decides the timing. What decides it is whether the warehouse confirms shipped early enough for the flow to build and send the ASN before the carrier collection.
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.