Migrate your Edicom EDI data

Standard EDI document types — purchase orders (850), invoices (810), ship notices (856), order acknowledgments (855), and tender/load documents. Edicom EDI stores and routes these in X12, EDIFACT, UBL, or ODETTE format. We migrate transaction history by exporting archive files in the original standard and re-parsing them into the target system.

Each trading partner in Edicom EDI carries a configuration record defining document types exchanged, communication protocol, and partner-specific validation rules. We export partner records as structured configuration data and replicate them in the target EDI platform, preserving the routing topology.

Edicom EDI supports AS2, SFTP/FTPS, HTTPS web services, VAN mailbox, and OFTP for automotive. Connection credentials and endpoint definitions are standard fields we carry forward during migration, re-establishing secure channels in the destination platform.

Custom field-level mappings define how internal ERP data fields translate into EDI segment positions and vice versa. In-house developed mappings on Edicom EDI often encode partner-specific logic that has no direct equivalent elsewhere. We inventory all custom maps, flag where they need re-engineering, and map them to destination format rules.

Edicom EDI connects directly to ERP systems (SAP, Oracle, Microsoft Dynamics, NetSuite) via pre-built or custom connectors. Integration logic — field selection, transformation rules, triggering conditions — lives in the integration layer. We extract this configuration and assess whether equivalent connectors exist in the target platform.

E-invoicing and fiscal reporting mandates differ by country (e.g., Brazil's NF-e, Italy's SDI, Greece's myDATA). Edicom EDI encodes validation rules and submission flows per jurisdiction. We catalog which compliance rules are active in the customer's account and carry forward the configuration intent, noting where country-specific legal requirements must be re-implemented.

When Edicom EDI is used for mandatory e-invoicing rather than pure EDI, the platform enforces country-specific schema, digital signatures, and government portal submissions. These mandates are jurisdiction-bound and cannot be globally mapped. We document the active countries and flag the re-implementation effort required in destination systems.

Edicom EDI operates as a Value-Added Network with mailbox addresses per organization and per partner. Mailbox routing tables, interchange acknowledgments (997/Contrl), and transmission logs are standard records we preserve to maintain audit trails and partner communication continuity.

Edicom EDI natively handles multiple standards families: ANSI X12 (US retail), UN/EDIFACT (Europe, global logistics), UBL (cross-industry XML), and ODETTE (automotive). The standard applied per trading partner is a first-class attribute we carry into the target platform to ensure documents land in the correct format.

EDICOM's automotive module uses OFTP2 (Odette File Transfer Protocol) and VDA standards for manufacturer-supplier exchanges. OFTP2 connection setup — certificates, endpoints, virtual filepaths — requires platform-specific configuration. We export OFTP profile data and flag the certificate reissuance required in the destination environment.

Edicom EDI supports IFTDPC, COPISNL, and similar maritime transport messages for customs, port authority, and shipping company communications. These are vertical-specific document types with limited target-platform support. We inventory active maritime flows and note where destination systems require custom parsing.

Edicom EDI exposes some document exchange via REST or SOAP web services for ERP systems that cannot use traditional EDI protocols. The endpoint definitions, payload schemas, and authentication config are part of the migration scope. We export the API contract definitions and assess compatibility with the target system's integration layer.