EDI Integration
Does an invoice raised in Cin7 Core price against the purchase order a partner sent, or against the item master sitting behind the SKU? Cin7 Core holds both figures, and when the invoice run pulls from the item master instead of the PO, the gap doesn't show up until the remittance advice lands with a deduction nobody flagged at dispatch. The fix sits in what triggers the invoice line inside Cin7 Core, not in how the report reads afterwards.
Cin7 Core can carry a partner's negotiated price on the sales order and still raise the invoice at the item master rate if the line isn't locked to the PO. Multiple API Applications on one account make this worse when one key files invoices and a different key confirms receipt of the order, because nobody owns the check between them. The six categories below are where that gap gets priced back against the account.
Cin7 Core's API is a subset of what the UI can do, so the first job is checking which fields the account's trading partner actually needs sit inside that subset. The account ID and API Application key pairing has to be set up for the right application before anything goes live.
Each one is a JSON payload Cin7 Core raises or receives through its REST API, authenticated against the account's API Application.
The question that matters is whether the line still carries the price the PO set or has reverted to the item master rate. A reversion shows up as a deduction on the remittance, not as an error on the invoice itself.
It arrives against whichever API Application the partner's connection is authenticated through. If that application key isn't the one the invoice run later uses, the two sides of the trade stop checking against each other.
This closes the receipt loop before picking starts. A missed acknowledgement here is usually the first sign the API Application pairing has drifted.
This is where an item master price quietly substituted for a PO price actually surfaces, weeks after the goods shipped.
If a partial ship or a date change isn't written back here before the 810 goes out, the invoice and the acknowledgement tell the partner two different stories.
Offset pagination and per-application rate limits mean a high-volume document run needs its own monitoring, separate from the webhook feed that triggers each document.
Cin7 Core fires event notifications through webhooks, and that's the mechanism that should be triggering the invoice and the acknowledgement, not a scheduled pull. Authentication runs on two HTTP headers, api-auth-accountid and api-auth-applicationkey, so every webhook and every call downstream is tied to a specific API Application. The platform accepts JSON only, versions its API by URI path with v1 still available alongside v2, and paginates list results by offset, which matters once a partner's order volume pushes an account against its own rate limit.
Confirmed against your instance during onboarding.
Cin7 Core's documentation is published per endpoint, which helps a developer but doesn't tell finance which price actually hit the invoice. One person needs to own the API Application key mapping. A second needs to own what the invoice line was priced against before it went out.
With more than one API Application possible on an account, somebody has to know which key files which partner, and update that mapping the moment a connection changes.
Somebody checks that the sales order line still carries the PO price before the invoice run touches it, not after the remittance comes back short.
Related
Cin7 Core versions its API by URI path, and v1 sitting alongside v2 means nothing breaks until the older path is actually withdrawn. Moving a live feed means remapping to whatever fields v2 adds or renames, and retesting the invoice and acknowledgement payloads before the old path goes away, not after.
Cin7 Core holds the inventory figure as its own stock engine, and a partner reading availability through this platform is reading whatever store or channel mapping last pushed it. Where Cin7 Core runs a two-way sync against a storefront and that sync misses a cycle, the partner ends up reading a number Cin7 Core has already moved past, and the mismatch gets found on the next order, not before.
If the push and pull sync between Cin7 Core and the shipping system fails, the order gets pushed out but the tracking callback never comes back, and the ASN has no shipment data to build from. That's the point where someone has to reconcile manually before anything reaches the partner, and it's usually caught late.
Cin7 Core supports multiple API Applications on one account, so a spec change has to be applied against the specific application key filing that partner. Someone needs to own which key maps to which partner relationship, otherwise the update gets made against the wrong connection and the old spec keeps going out.
That depends on whether the invoice is triggered by the shipment event through a webhook or waits on someone to run it manually. Wired to the event, the timing holds against the partner's clock. Left to a manual step, the clock the partner is counting against starts running before Cin7 Core has actually raised anything.
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.
