Acumatica and Orderful integration

What moves between them

Documents move in both directions. Inbound, ml-connector pulls 850 purchase orders from Orderful and creates them as Acumatica sales orders, matched to the right customer and stock items, and it can send back an 855 acknowledgment. Outbound, it reads released Acumatica sales invoices and posts them to Orderful as 810 invoices, and it turns Acumatica shipment confirmations into 856 ship notices for the partner. Because Orderful carries no GL accounts, customer master, or inventory of its own, the ledger and the customer and item records stay in Acumatica, and ml-connector never writes accounting data into Orderful. The outbound cadence follows Acumatica polling, and inbound runs on the Orderful poll or push.

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 and pins every call to the customer's instance URL and exact endpoint version, since a version mismatch returns a 404, and it wraps each field value in the value object Acumatica requires. On the Orderful side it sends the static orderful-api-key header, targets the correct US or EU base URL because the two regions are isolated, and stamps the configured sender and receiver ISA IDs on each transaction with the stream set to live in production. Acumatica is read by polling sales invoices and shipments on a LastModifiedDateTime high-water mark with top and skip paging, because its Push Notifications have no dead-letter queue and can be missed. Inbound 850 documents arrive by Orderful HTTP push or polling bucket; the endpoint returns 200 to mark a transaction delivered, or 202 when it needs time to finish creating the Acumatica sales order. Customers and stock items are mapped first, so every order line resolves to a real Acumatica item and a known partner ISA ID. Neither side offers an idempotency-key header, so ml-connector dedupes on the Acumatica reference number and the Orderful transaction ID, stored as a string since those IDs are 64-bit and overflow a normal number, and a BullMQ jobId guards against a re-read document being sent twice. Failed posts are retried with backoff on a 429 and carry a full audit trail for replay.

A real-world example

A mid-sized food and beverage distributor runs Acumatica Cloud ERP for order management, inventory, and finance, and supplies several grocery chains that require EDI. Before the integration, a coordinator printed each EDI purchase order from a portal and keyed it into Acumatica as a sales order, then typed each invoice and ship notice back into the EDI tool by hand, which delayed orders and produced chargebacks when a document was late or mistyped. With Acumatica and Orderful connected, inbound 850 purchase orders become Acumatica sales orders within the polling window, and released invoices and shipments go back out as compliant 810 and 856 documents automatically, matched to the right customer and items. Orders flow same day, the re-keying is gone, and the compliance chargebacks stop.

What you can do

• •Turn inbound Orderful 850 purchase orders into Acumatica sales orders matched to the right customer and stock items.
• •Send released Acumatica sales invoices to trading partners through Orderful as 810 invoices.
• •Convert Acumatica shipment confirmations into 856 ship notices and return 855 acknowledgments for received orders.
• •Bridge Acumatica OAuth 2.0 token auth and the static Orderful API key, with the correct endpoint version and region.
• •Dedupe on Acumatica reference numbers and Orderful transaction IDs, with retries and a full audit trail on every document.

Questions

Which direction do documents move between Acumatica and Orderful?

Both directions. Inbound EDI 850 purchase orders flow from Orderful into Acumatica as sales orders, and released Acumatica invoices and shipments flow back out as 810 invoices and 856 ship notices. Orderful is an EDI routing network with no general ledger or customer master, so the ledger and master records stay in Acumatica and ml-connector never writes accounting data into Orderful.

How does the integration get records out of Acumatica, by push or polling?

By polling. Acumatica can emit Push Notifications, but they have no dead-letter queue and can be missed, so ml-connector reads released invoices and shipment confirmations on a schedule using a LastModifiedDateTime filter and top and skip paging. It stores a high-water mark after each run so only new and changed records are picked up and sent to Orderful.

How are duplicate documents avoided when neither system has an idempotency key?

Neither Acumatica nor Orderful offers an idempotency-key header, so ml-connector handles it. It dedupes on the Acumatica document reference number and the Orderful transaction ID, which it stores as a string because those IDs are 64-bit and overflow a normal number, and a BullMQ jobId stops a re-read record from being sent twice. Failed posts are retried with backoff and can be replayed from the audit trail.