Migrate from Edicom to Dolibarr ERP

Edicom partner profiles contain connection settings, supported document types, certification status, and contact information. We export these as structured records and map contact data to Dolibarr's Third Party module. EDI-specific fields (AS2 ID, VAN address, connection protocol) have no Dolibarr equivalent — we preserve them in a custom extrafields block on the Third Party record for reference. The customer's EDI middleware or a Dolibarr EDI add-on consumes these fields during reconfiguration.

Edicom's long-term archive (EDICOMLta) stores EDI transaction evidence with timestamping and signatures. We export archive records as structured data and map INVOIC documents to Dolibarr Customer Invoice records, ORDERS to Dolibarr Customer Order records, and DESADV to Dolibarr Shipment records where the module is enabled. Line items map from EDI segments (LIN, PIA, QTY, MOA) to Dolibarr invoice lines with product references resolved. The evidentiary metadata (timestamp, signature hash) is preserved as document attachments rather than native Dolibarr fields.

Edicom message flows define which EDI transaction types are active per trading partner. Dolibarr has no EDI flow concept. We export all active flow configurations as structured JSON and deliver a written inventory specifying for each partner: the transaction type, direction (inbound/outbound), EDI standard (X12, EDIFACT), version, and the corresponding Dolibarr module action. A Dolibarr implementation partner or EDI consultant uses this inventory to configure the replacement middleware.

Edicom translation maps translate between partner EDI formats and ERP data structures with field-level transformation rules. These are not transferable as executable logic. We export each map definition as a structured specification (source segment, destination field, transformation type) and deliver it as a reference document for the customer's team to implement in their chosen EDI middleware (such as a Dolibarr-compatible community add-on or a standalone EDI platform). Maps with undocumented intermediate data table dependencies are flagged separately.

Many Edicom customers have intermediate data tables and equivalence lists referenced by map logic but not stored as first-class Edicom objects. These are often maintained by a single developer and undocumented. We discover and export every referenced table during the mapping phase, replicate their contents as Dolibarr dictionary entries or CSV lookup tables, and document the update frequency so the customer's team can maintain synchronization after cutover.

Edicom connects to ERP systems via middleware, intermediate data tables, or direct API/WebService calls. We document the specific integration layer — API endpoint, authentication method, data format, and polling or push cadence — for each connected ERP. In Dolibarr, we configure equivalent REST API credentials or webhook endpoints if the same ERP systems are retained. If the ERP is being replaced alongside Edicom, we flag the integration for redesign during the cutover window.

Edicom logs capture timestamp, status, and content hash for each processed document. We export historical logs for the retention period the customer specifies and re-index them in Dolibarr as document records with a custom audit metadata block. Logs are searchable in Dolibarr through standard document search rather than a dedicated audit trail interface.

TLS certificates, AS2/AS4 identifiers, and signing keys are tied to the Edicom platform account and cannot be exported and uploaded elsewhere. We flag every certificate-bound connection during scoping with its certificate type, expiration date, and certificate authority. The customer coordinates re-issuance through their CA, and we integrate the re-issuance timeline into the cutover schedule to avoid gaps in connectivity. This is documented rather than migrated.

Edicom Managed Services cover 24x7 monitoring and administration of EDI flows. We document which connections are under managed services coverage, the escalation contacts, and the monitoring thresholds so that the customer can establish equivalent coverage with a Dolibarr support provider (DoliCloud, a third-party partner, or in-house) before Edicom Managed Services is decommissioned.

Edicom supports multiple EDI standards (X12, EDIFACT, VDA, ODETTE) and version variants per trading partner. We capture the standard and version for each active connection and map it to a custom extrafields block on the Dolibarr Third Party record. This metadata informs the EDI middleware configuration during the post-migration rebuild.

Edicom EDI transactions include product data within INVOIC and ORDERS segments (LIN, PIA for item identification, QTY for quantities, MOA for monetary amounts). We extract product identifiers, descriptions, and unit-of-measure codes from archived EDI documents and map them to Dolibarr Product records. Where the customer has a separate product master in their ERP, we align Dolibarr product codes with the ERP product codes exported through the Edicom integration.

Archived INVOIC documents contain payment terms, amounts, tax codes, and monetary totals in MOA segments. We extract these and map to Dolibarr Payment records linked to the corresponding Customer Invoice. Tax codes map to Dolibarr's VAT configuration where jurisdiction-specific tax rules are set up.