Migrate from Edicom EDI to Microsoft Dynamics 365 Business Central

EDI transaction sets in Edicom EDI are document-type records containing segment-level data (N1 party loop, PO1 line items, REF references). We decompose each document into one or more Dynamics 365 transactional entities: an X12 850 Purchase Order maps to a Dynamics 365 Purchase Order; an 810 Invoice maps to a Vendor Invoice; an 856 ASN maps to a Product Receipt with warehouse and shipping metadata. ISA control numbers, GS functional group identifiers, and ST transaction set counters migrate to custom fields on each record (edi_isa_control__c, edi_gs_control__c, edi_st_control__c) so the EDI audit trail is preserved without requiring a native EDI document object that does not exist in Dynamics 365.

Each trading partner in Edicom EDI carries document type assignments, communication protocol settings, and partner-specific validation rules. We map the partner identifier and qualifier (N1/GLN or N1/UNB) to Dynamics 365 Vendor or Customer records with the corresponding GLN or DUNS stored in the Address Validation Record or a custom field. The EDI protocol metadata (document types exchanged, acknowledgment requirements, envelope settings) migrates to a custom integration table in Dynamics 365 or to the middleware configuration record so that the Dynamics 365 EDI integration solution can reference it at runtime.

Edicom EDI connection credentials — AS2 endpoint URLs, SFTP host/key pairs, VAN mailbox addresses, OFTP virtual filepaths — do not have a direct Dynamics 365 equivalent. We reconstruct connection configurations in Azure Logic Apps workflows or API Management that serve as the EDI transport layer for the Dynamics 365 environment. AS2 certificate pairs, SFTP key pairs, and OFTP2 certificates require re-issuance or transfer from Edicom depending on the customer's certificate management policy. VAN routing tables from Edicom need to be recreated as Logic Apps conditional routing branches or API Management policies.

Custom field-level EDI mappings in Edicom EDI encode how internal ERP fields translate to EDI segment positions and vice versa. In-house custom maps often represent years of accumulated partner-specific business logic with no external reference. Dynamics 365 does not natively store EDI mappings; they live in the chosen EDI integration solution (STAEDEAN EDI Studio, OpenText, Cleo, SPS Commerce) or in Azure Logic Apps custom code. We perform a manual inventory of all non-standard mappings during scoping and flag any map without a clear equivalent in the target middleware as requiring re-engineering before cutover.

Edicom EDI connects to ERP backends (SAP, Oracle, Microsoft Dynamics, NetSuite) through pre-built or custom connectors with field-level transformation rules and triggering conditions. When migrating to Microsoft Dynamics 365, the connector logic must be rebuilt as Dynamics 365 OData/REST API calls, Power Platform dataflows, or Azure Logic Apps connectors that read from and write to Dynamics 365 entities. The field-to-field mapping from the Edicom connector migrates to the new connection configuration, and any custom ERP-side data transformation logic is documented for the customer's technical team to implement in the target integration layer.

Edicom EDI encodes country-specific e-invoicing validation rules, digital signature requirements, and government portal submission flows for jurisdictions including Brazil (NF-e), France (Chorus Pro), Italy (SDI), Greece (myDATA), and Saudi Arabia (ZATCA Phase 2). These rules are jurisdiction-bound and cannot be exported and loaded into a new platform. We catalog every active country mandate during discovery and itemize the re-implementation effort as a separate workstream. For mandatory e-invoicing countries, the customer must select and configure a certified compliance solution that integrates with Dynamics 365 before transaction processing resumes.

Edicom EDI operates as a Value-Added Network with per-organization and per-partner mailbox addresses, interchange acknowledgments (997/Contrl), and transmission logs. We map VAN mailbox routing tables to either Dynamics 365 custom integration table records or Azure Logic Apps workflow configurations that route documents by partner qualifier to the correct endpoint. Acknowledgment metadata (997 Functional Acknowledgment status, TA1 interchange acknowledgment) migrates as a custom field on the related Purchase Order or Vendor Invoice record so the customer retains a complete EDI transmission audit trail.

Edicom EDI natively handles X12 (US retail), UN/EDIFACT (Europe, global logistics), UBL (cross-industry XML), and ODETTE (automotive) with standard selection per trading partner. Dynamics 365 has no native EDI standard handler. We configure each active EDI standard in the chosen integration middleware: X12 850/810/855/856 maps to STAEDEAN EDI Studio, OpenText EDI Integration adapters, or Cleo integration rules; EDIFACT ORDERS/INVOIC maps through the same middleware with the applicable message implementation guide. We create a standard-by-standard configuration inventory during scoping so no active EDI standard is missed during migration.

Edicom EDI's automotive module uses OFTP2 (Odette File Transfer Protocol) and VDA standards for manufacturer-supplier exchanges. OFTP2 connection setup requires certificate exchange, remote entity ID configuration, virtual filepaths, and acknowledgment handling specific to the Odette network. We map OFTP2 configurations from Edicom to the equivalent settings in the target EDI integration middleware or to dedicated OFTP2 tooling (Cleo, Bosch Automotive, Traxess) that integrates with Dynamics 365. VDA document mappings (VDA 4905 purchase order, VDA 4913 invoice) need to be reconfigured against the Dynamics 365 entity model.

Edicom EDI exposes some document exchange via REST or SOAP web services for ERP systems that cannot use traditional EDI protocols. Endpoint definitions, payload schemas, and authentication configurations migrate to Azure Logic Apps HTTP connectors or API Management policies in the Dynamics 365 environment. We validate the source endpoint payload structure against Dynamics 365 OData field definitions and document any payload schema changes required for the target system.

Each trading partner's compliance profile in Edicom EDI defines which EDI transaction sets they accept, which acknowledgment types they require (997, 855, 864), and any partner-specific validation rules. We create a Dynamics 365 custom entity or middleware compliance record that stores these partner-specific requirements and links to the relevant Vendor or Customer record. The compliance profile drives routing logic and validation rules in the EDI integration middleware at runtime.

Edicom EDI maintains transmission logs with timestamps, interchange and group control numbers, acknowledgment status, and retry counts. This operational history migrates to a Dynamics 365 custom entity or an Azure Log Analytics workspace linked to the integration layer, so the customer retains a complete EDI transmission audit trail separate from the transactional ERP record.