EDI Integration Suite

Large retail, grocery, automotive and industrial customers do not ask whether you support EDI. They send a routing guide, a partner specification and a compliance schedule, and they expect an 855 back inside a defined window, an 856 that matches the pallet you actually shipped, and an 810 whose totals tie to the purchase order they sent. Miss the advance ship notice, get the SSCC hierarchy wrong, or send a carton whose label does not scan at the receiving door, and a deduction appears on the next remittance.

Dynamics 365 Finance and Supply Chain Management does not ship an EDI subsystem. Electronic reporting can build a file format, but it does not manage trading partner profiles, envelope control numbers, functional acknowledgements, AS2 or VAN transport, retailer-specific validation rules, or the mapping between a partner item number and your released product. That gap is why EDI is the largest third-party add-on category for F&O, and it is the work ECOSIRE does for you as a build-to-order project.

This is not a product you download. We read your partner specifications, agree a fixed-price scope covering exactly which documents and which partners are in the first wave, build the maps and the code, and install it into your sandbox for partner certification before anything reaches production.

What ECOSIRE builds

Sales-side documents

Inbound 850 and EDIFACT ORDERS become sales orders (SalesTable and SalesLine). Partner item numbers, UPC and GTIN values resolve to released products through the customer and vendor external item cross-reference, and a line that will not resolve stops as an exception rather than posting a wrong item. Inbound 860 and ORDCHG change orders are applied to open orders, with changes rejected or escalated where the line has already been released to warehouse work.

Outbound 855 and ORDRSP are generated from order confirmation with line-level accept, reject, quantity-change and date-change codes. Outbound 856 and DESADV are built from the actual WHS shipment and load, carrying the full SSCC-18 licence plate hierarchy at pallet, carton and item level, so the ASN describes what left the dock rather than what was planned. Outbound 810 and INVOIC are generated from posted customer invoices (CustInvoiceJour) with allowances, misc. charges and payment terms translated to the codes each partner demands.

Purchase-side documents

Where you are the buyer, the same engine runs in reverse: outbound 850 from purchase orders (PurchTable), inbound 855 acknowledgements applied to the confirmed order, inbound 856 driving item arrival and receipt, and inbound 810 staged for vendor invoice matching against the purchase order and product receipt.

Warehouse, 3PL and logistics documents

For third-party logistics operations, 940 and 945 warehouse shipping order and advice, and 943 and 944 stock transfer documents, are aligned with transfer orders and WHS work so a 3PL and your own warehouses appear consistent in the sub-ledger. Inbound 214 carrier status messages can update shipment tracking. Outbound 846 inventory advice publishes on-hand from InventSum by site, warehouse and inventory status. Inbound 852 product activity data is staged into custom entities for demand review.

Money documents

Inbound 820 and REMADV remittance advice is parsed and staged into a customer payment journal, matched to open invoices and settled where the references are clean, with unmatched deductions listed for the credit team instead of being silently absorbed.

Envelopes, control numbers and acknowledgements

ISA, GS and ST envelopes for X12, and UNB, UNG and UNH for EDIFACT, are generated per partner with the correct qualifiers, test and production indicators, and independently sequenced control numbers. Outbound 997 and CONTRL acknowledgements are returned automatically, inbound ones are matched against what you sent, and anything unacknowledged past its window raises an alert rather than being discovered during a chargeback dispute.

Transport

AS2 with certificate management and MDN handling, SFTP polling and push, and VAN mailbox pickup, all driven from batch framework jobs with retry, dead-letter handling and a full audit of what was sent and received.

Architecture and technical approach

The suite is X++ extension code in your own model: extension classes, Chain of Command, event handlers, and table and form extensions. No overlayering, so platform updates stay routine. Maps and code lists are configuration, held in a trading partner workbench and, where it fits, in Electronic reporting format and model mapping configurations, so a new partner code value does not require a code deployment.

Every inbound and outbound message is persisted in raw form with its parsed result, correlation id, partner, document type and status. Anything can be reprocessed, and anything can be released manually after a fix. Processing runs as SysOperation batch jobs so it is scheduled and monitored like the rest of your F&O estate, with alerts and business events for failures, missing acknowledgements and ageing exceptions. Custom data entities are exposed over OData and the Data Management Framework for staging and bulk correction. Security ships as duties and privileges rolled into roles, so an EDI coordinator does not need broad sales or ledger access.

Who this is for

Suppliers to grocery, mass-market, home improvement, pharmacy and automotive customers who have received a trading partner specification and a compliance deadline. It suits organisations running advanced warehouse management on WHS, shipping to retailer routing guides, and carrying deduction exposure they can measure. It also suits companies moving off an older Dynamics AX EDI arrangement that never made the transition to the current architecture.

It is not for a business exchanging a handful of orders a month by email, where a simpler import will do the job for less money.

How delivery works

1. Scoping call. We read the partner specifications and routing guides, list the documents in wave one, and confirm your version, LCS environments, warehouse configuration and labelling requirements. 2. Fixed quote. A written scope naming every document, partner, transport method and exclusion, with a fixed price. Additional partners are quoted as their own increments so you can phase them. 3. Build. Maps, code lists, validation rules and the X++ code are developed against your release, in a model you own. 4. Install in test. The deployable package goes into your Tier 2 or higher sandbox from LCS. We run partner test cycles and certification from that environment, using real documents, until each partner signs off. 5. Production. Cutover partner by partner through your LCS pipeline, with production control numbers reset and the test indicator flipped in a controlled sequence. 6. Support. A defect-fix window after go-live, and an ongoing arrangement for new partners and specification changes if you want one.

Scope boundaries

We do not resell VAN capacity or act as your VAN; if you use one, we connect to it. We do not guarantee a retailer will certify on a fixed date, because that timetable belongs to them. And we will say at scoping when a partner requirement, such as a bespoke portal-only process, is not an EDI problem at all.