Acumatica and TrueCommerce integration

What moves between them

Documents move in both directions. Inbound, ml-connector picks up 850 purchase orders that TrueCommerce drops for your retail trading partners and creates the matching sales orders in Acumatica, with each line resolved to a real Acumatica stock item. Outbound, as Acumatica ships and bills those orders, ml-connector reads the shipment and AR invoice records and sends them back to TrueCommerce as 856 advance ship notices and 810 invoices for translation and delivery to the retailer. Inventory levels can flow out as 846 advice, and TrueCommerce returns 855 acknowledgments and 997 functional acknowledgments that ml-connector tracks against the originating order. TrueCommerce never holds financial truth, so the ledger stays in Acumatica.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it requests and refreshes an OAuth 2.0 bearer token, pins the endpoint version to the customer ERP release so a version mismatch never silently 404s, and wraps every field value in the value object Acumatica requires. On the TrueCommerce side it connects to the SFTP host with the username and password TrueCommerce provisions, or the managed Exchange API where that path is configured, and reads and writes against the exact import and export directories confirmed during onboarding, since those paths are not standardized across customers. Because neither side offers a reliable push, ml-connector polls: it pulls new 850 files from the TrueCommerce drop on a schedule and reads Acumatica shipments and invoices by filtering on LastModifiedDateTime, keeping a high-water mark per run. Item numbers are mapped to each retailer's SKUs first, so every inbound order line and every outbound invoice line resolves correctly, and trading-partner ISA sender and receiver IDs are held per relationship. Acumatica has no idempotency key, so ml-connector dedupes on the EDI document control number and a BullMQ jobId before creating a sales order, which stops a re-read 850 from booking twice. Outbound 810 and 856 files are named to the per-customer convention TrueCommerce expects, and the 997 acknowledgment is reconciled back so a rejected document surfaces instead of being lost. Acumatica throttles when the per-minute request count crosses half the licensed limit and returns HTTP 429, so ml-connector backs off with jitter. Every document carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods supplier with roughly 200 employees runs Acumatica for orders, inventory, and finance, and sells into several large grocery and big-box retailers that mandate EDI through TrueCommerce. Before the integration, a coordinator printed each retailer purchase order out of TrueCommerce and keyed it into Acumatica by hand, then manually built the ship notice and invoice files after each order shipped, which meant orders sat for hours, SKUs were sometimes mismatched to the retailer's catalog, and late or malformed ASNs drew chargebacks. With Acumatica and TrueCommerce connected, each inbound 850 becomes an Acumatica sales order within the polling window, and the 856 and 810 go back out automatically as the order ships and bills, mapped to the correct retailer SKUs. The orders flow faster, the keying errors disappear, and the compliance chargebacks for late documents stop.

What you can do

• •Turn inbound EDI 850 purchase orders from TrueCommerce into Acumatica sales orders, with each line mapped to a real stock item.
• •Send Acumatica shipments and AR invoices back to TrueCommerce as 856 advance ship notices and 810 invoices for delivery to the retailer.
• •Map Acumatica item numbers to each trading partner's SKUs and hold ISA sender and receiver IDs per relationship.
• •Bridge Acumatica OAuth 2.0 with the SFTP or Exchange API credentials TrueCommerce provisions, pinned to the correct endpoint version.
• •Poll both sides on a schedule with document-control and jobId dedup, 997 reconciliation, retries, and a full audit trail on every document.

Questions

Which direction does data move between Acumatica and TrueCommerce?

Both directions. Inbound 850 purchase orders move from TrueCommerce into Acumatica as sales orders, and outbound 856 ship notices and 810 invoices move from Acumatica back to TrueCommerce for delivery to the retailer. TrueCommerce is a translator and VAN with no ledger of its own, so financial records stay in Acumatica and are never overwritten by the connector.

Does TrueCommerce push documents, or does ml-connector poll for them?

It polls. TrueCommerce has no reliable self-serve webhook, so ml-connector reads new inbound files from the SFTP drop directories on a schedule, typically hourly, and reads Acumatica shipments and invoices by filtering on LastModifiedDateTime. The import and export paths are confirmed per customer during onboarding because they are not standardized across TrueCommerce accounts.

How does the integration keep a re-read EDI order from creating a duplicate sales order in Acumatica?

Acumatica has no native idempotency key, so ml-connector deduplicates before it writes. It keys each inbound document on the EDI interchange and transaction control number plus a BullMQ jobId, so re-reading the same 850 file does not create a second Acumatica sales order. Outbound documents are reconciled against the 997 functional acknowledgment so a rejected file is surfaced rather than silently dropped.