Migrate from Edicom EDI to Dolibarr ERP

Edicom EDI ANSI X12 850 Purchase Orders map to Dolibarr's ask_quotation or commande_fournisseur object depending on the direction of trade. We extract the PO header (N1, REF segments) as Third-Party references and line items (PO1, PID segments) as product rows. The Dolibarr EDI module must be activated and the document standard configured for X12 parsing. If the company sends 850s as a buyer to suppliers, the mapping direction reverses accordingly.

Edicom EDI 810 invoices map to Dolibarr facture records. The 810's REF segment carries the invoice number mapped to facnumber, the IT1 segment lines map to product or service lines, and the ITD segment handles payment terms mapped to cond_reglement. If Edicom EDI includes tax calculation (TXI segment), we preserve tax codes as extra fields on the Dolibarr invoice rather than attempting to replicate jurisdiction-specific tax logic.

Edicom EDI 856 Advance Ship Notices map to Dolibarr expedition records linked to the corresponding order or invoice. The ASN's SN1 segment carries shipped quantity, TD1 carries carrier and weight details, and REF carries thebol_number. We link each shipment to the original Dolibarr order by order reference resolution during import.

Edicom EDI 855 Order Acknowledgments map to Dolibarr commande records representing the seller's acceptance of a customer purchase order. The 855's ACK segment carries acceptance status (IA, AK, CR, RD) mapped to Dolibarr's status field, and REF carries the originating PO reference for cross-referencing.

Edicom EDI trading partner configurations map to Dolibarr societe (company/organization) and contact records. Each partner's N1 segment in Edicom EDI provides the partner name; address segments (N3, N4) populate the Dolibarr address fields. We preserve the Edicom partner ID as a custom field edicom_partner_id__c on the societe record for reference during future EDI exchanges. Partner-specific validation rules in Edicom cannot migrate and are listed in the custom mapping inventory for manual rebuild in Dolibarr's EDI module.

Edicom EDI connection credentials (AS2 endpoints, SFTP host/port/key, VAN mailbox addresses) do not transfer to Dolibarr because they are destination-platform-specific infrastructure. We extract the protocol type and endpoint details from Edicom as a reference document. The customer's admin re-enters the appropriate credentials in Dolibarr's EDI module or a third-party AS2/VAN provider (such as Courier Online, SEEBURGER, or IBM Sterling) chosen by the customer. OFTP2 certificates for automotive partners require re-registration with the destination VAN or direct partner endpoint.

Edicom EDI operates as a Value-Added Network with mailbox addresses per organization and per trading partner. Dolibarr has no native VAN functionality. We document the existing VAN mailbox topology from Edicom and recommend a third-party VAN provider (GXS/Tron, SPS Commerce, TrueCommerce, or OpenText) or direct AS2/SFTP configuration in Dolibarr's EDI module as the replacement. Interchange acknowledgments (997/Contrl) that Edicom generated automatically must be configured manually in the chosen replacement VAN.

If Edicom EDI carries a product catalog synchronized from an ERP integration (item codes, descriptions, UPC/EAN, standard unit of measure), we map these to Dolibarr produit records. The Edicom EDI product reference maps to ref in Dolibarr; the description maps to label; barcodes map to barcode fields. Price information from EDIFACT or X12 segment pricing (CTP, LIN) can populate the cost_price or price_ttc fields depending on the trade direction.

Edicom EDI supports ANSI X12, UN/EDIFACT, UBL 2.x, and ODETTE document standards per trading partner. Dolibarr's EDI module supports X12 and EDIFACT as native parsers. We inventory every active document standard in use from Edicom and configure Dolibarr's EDI module accordingly. UBL and ODETTE standards that do not have native Dolibarr support are flagged for either custom PHP development or a third-party middleware layer as part of the post-migration scope.

Edicom EDI's automotive module uses OFTP2 (Odette File Transfer Protocol) and VDA standards for manufacturer-supplier exchanges. Dolibarr does not include OFTP2 or VDA support. We extract the OFTP2 virtual filepaths, certificate references, and partner endpoints from Edicom as a configuration reference. The customer's admin must either subscribe to an OFTP2-capable VAN (such as OpenText or SupplyOn) or engage a Dolibarr development partner to extend the EDI module with OFTP2 capability. OFTP2 certificate re-registration with the destination automotive network is a mandatory step that cannot be automated.

Edicom EDI supports IFTDPC, COPISNL, and similar maritime transport messages for customs, port authority, and shipping company communications. Dolibarr has no maritime document module. We document the active maritime document types and their trading partner requirements as a standalone reference for the customer's operations team. Replacement typically involves a specialized maritime EDI provider or customs compliance platform rather than Dolibarr.

Edicom EDI encodes country-specific e-invoicing validation rules, digital signature requirements, and government portal submission flows (e.g., Brazil NF-e, Italy SDI, France Chorus Pro, Saudi ZATCA Phase 2). These rules cannot be exported and loaded into Dolibarr. We catalog every active country mandate during discovery and produce a jurisdiction-by-jurisdiction compliance inventory that itemizes re-implementation effort separately. Each destination jurisdiction requires its own compliance module (such as FatturaPA for Italy, Chorus Pro API for France, or a third-party e-invoicing SaaS) as a post-migration engagement.

Edicom EDI connects to ERP systems (SAP, Oracle, Microsoft Dynamics, NetSuite) via pre-built or custom connectors that define field selection, transformation rules, and triggering conditions. Dolibarr exposes REST and SOAP WebServices for ERP integration. We inventory the ERP connection configuration from Edicom as a reference document, map the field selections to Dolibarr object attributes, and flag any custom transformation logic that requires re-engineering in Dolibarr's ERP connector or a middleware layer such as Dolibarr's native iKal or a third-party iPaaS.

Custom field-level mappings on Edicom EDI that transform internal ERP data fields into EDI segment positions and partner-specific validation rules represent accumulated business logic with no external reference. We perform a manual inventory of all non-standard mappings during scoping and flag each one that lacks a clear equivalent in Dolibarr's EDI module as requiring re-engineering before cutover. The custom mapping inventory is delivered as a written document for the customer's technical team or a Dolibarr development partner to rebuild in PHP or via a middleware layer.