Microsoft Dynamics 365 Business Central and Orderful integration

What moves between them

Documents move in both directions. Inbound, Orderful delivers 850 purchase orders that ml-connector creates as Business Central sales orders. Outbound, when those orders are acknowledged, shipped, and posted as sales invoices in Business Central, ml-connector sends 855 acknowledgments, 856 ship notices, and 810 invoices back to the partner through Orderful. Records are tied together by purchase order number and by the sender and receiver ISA IDs. Inbound EDI arrives on Orderful push or polling, while outbound EDI is triggered by Business Central sales order and sales invoice changes, caught by webhook where supported and by scheduled polling for entities that have none.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges two unlike auth models: it requests a Microsoft Entra OAuth2 token for Business Central, refreshing it when a call returns 401, and attaches the static orderful-api-key header to every Orderful request. On the Business Central side it stores the tenant ID, environment name, and company so it can build the company-scoped base URL per customer. Inbound 850 documents arrive by Orderful HTTP push or polling bucket and are mapped into Business Central sales order lines by item number, quantity, unit price, and ship-to address. Outbound, sales order changes raise a Business Central subscription notification, which only signals a change, so ml-connector fetches the record before building the 855, 856, or 810 transaction with matching ISA IDs. Because purchase orders are not webhook-enabled and subscriptions expire after three days, ml-connector polls purchase orders with a lastModifiedDateTime filter and renews live subscriptions on a cron before expiry. Orderful transactions are kept on the test stream until partner testing is done, then switched to live. Business Central throttling returns HTTP 429 and Orderful returns 429 with a Retry-After header, so ml-connector backs off and retries, every record carries a full audit trail, and a failed downstream call can be replayed.

A real-world example

A mid-sized consumer goods supplier with roughly two hundred staff runs Microsoft Dynamics 365 Business Central for sales, inventory, and finance and trades EDI with several large retail customers through Orderful. Before the integration, a coordinator printed each inbound EDI purchase order and hand-keyed it into Business Central as a sales order, then manually built ship notices and invoices to send back, which caused chargebacks when an order was entered late or an ASN did not match the shipment. With Business Central and Orderful connected, each 850 becomes a sales order automatically, and the 855, 856, and 810 go back out from the posted Business Central documents, so orders are acknowledged on time and the EDI traffic stays in step with the ledger.

What you can do

• •Turn inbound Orderful 850 purchase orders into Microsoft Dynamics 365 Business Central sales orders without re-keying.
• •Send 855 acknowledgments, 856 ship notices, and 810 invoices back to trading partners from posted Business Central documents.
• •Match EDI traffic to Business Central records by purchase order number and by sender and receiver ISA IDs.
• •Bridge Business Central Microsoft Entra OAuth2 with Orderful's static API key, refreshing the OAuth token as needed.
• •Poll purchase orders by lastModifiedDateTime and renew three-day Business Central subscriptions before they expire.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Orderful?

It moves both ways. Inbound, Orderful 850 purchase orders become Business Central sales orders, and outbound, 855 acknowledgments, 856 ship notices, and 810 invoices are built from posted Business Central documents and sent back through Orderful. Records on each side are matched by purchase order number and by the sender and receiver ISA IDs.

How does the integration handle authentication across the two systems?

Business Central uses Microsoft Entra OAuth2 client credentials, so ml-connector requests a token for the configured tenant and environment and refreshes it when a call returns 401. Orderful uses a single static orderful-api-key header with no token refresh. ml-connector stores both credential sets encrypted and applies the correct one to each request.

How does the integration deal with Business Central webhooks and purchase orders?

Business Central notifications only signal that a record changed, so ml-connector fetches the record before acting on it, and it renews subscriptions before the three-day expiry. Sales orders support webhooks, but purchase orders do not, so those are read by polling with a lastModifiedDateTime filter. Inbound EDI from Orderful arrives by HTTP push or by polling a polling bucket.