Migrate from Edicom EDI to Odoo ERP

Edicom EDI 850 Purchase Order transaction sets map to Odoo Purchase Order records. The EDI document's PO1 segment lines (line number, quantity ordered, unit price, product identifier) map to Odoo Purchase Order Line records linked to the corresponding Product2 by SKU. Buyer Part Number and Vendor Part Number from the EDI REF segment are preserved in custom purchase order line fields. We create the vendor as an Odoo Contact with supplier rank enabled before importing any purchase orders.

Edicom EDI 810 Invoice transaction sets map to Odoo Vendor Bill (account.move with move_type=in_invoice). The EDI header fields (invoice number, date, amount) map to Odoo Invoice Number, Invoice Date, and Amount Total. Tax identification from the EDI REF segment maps to Odoo's tax configuration lookup. If the source Edicom invoice references a Purchase Order number, we link the Vendor Bill to the corresponding Odoo Purchase Order for two-way invoice reconciliation.

Edicom EDI 856 Advanced Ship Notice maps to Odoo's Stock Picking record (incoming route). The ASN's SN1 segment (shipment quantity) maps to move_line quantity_done. Carrier and tracking information from the EDI REF segment becomes the Odoo picking note and carrier reference field. We link the picking to the corresponding Purchase Order using the PO number embedded in the EDI transaction.

Edicom EDI 855 Order Acknowledgment documents received from suppliers map to Odoo Sale Order records for outbound processing. The acknowledgment's line acceptances and changes (O01 segment) are logged as sale order line notes in Odoo. If the original 850 Purchase Order was sent from a customer's Odoo instance, we link the acknowledgment to the originating Sale Order using the customer order number from the EDI.

Edicom EDI Trading Partner records with role=Supplier map to Odoo Contact records with the supplier flag enabled. The partner's EDI communication protocol (AS2, SFTP, VAN) and endpoint details are preserved in a custom contact field (edi_protocol__c, edi_endpoint__c) for the customer's EDI developer to reference when building the Odoo EDI integration. Partner-specific validation rules from Edicom are itemized separately as they require manual re-implementation.

Edicom EDI Trading Partner records with role=Customer map to Odoo Contact records with the customer flag enabled. Each contact inherits the address data (name, street, city, postal code, country) from the Edicom EDI partner record. The customer's EDI document types (which document standards they accept) are logged in a custom contact field edi_document_types__c to support EDI integration configuration in Odoo.

Edicom EDI connection credentials (AS2 endpoint URL, AS2 certificate, SFTP host/port/key, VAN mailbox ID, OFTP virtual filepath) do not have a direct Odoo equivalent because Odoo does not have a native EDI protocol layer. We export the connection configuration as a structured JSON document and deliver it to the customer's Odoo developer for configuration in Odoo's ir.config_parameter (system parameters) or a custom EDI Configuration model. AS2 and SFTP credentials must be re-entered in the customer's chosen EDI middleware or Python connector.

Edicom EDI custom field-level mappings encode transformation logic between the company's ERP fields and EDI segment positions. These mappings cannot migrate as code. We perform a manual inventory of every non-standard mapping during scoping, document the source field, EDI segment/element, transformation logic, and any conditional rules, then deliver a written mapping specification that the customer's Python developer or EDI implementation partner uses to build equivalent logic in Odoo. Any map without a clear Odoo equivalent is flagged as requiring re-engineering.

Edicom EDI VAN mailbox addresses and routing tables map to Odoo as custom EDI routing configuration on the Contact record. The VAN interchange ID and acknowledgment settings (997/Contrl) are preserved in custom fields for the EDI implementation partner. VAN routing rules (which documents route to which mailbox) are itemized in a routing table document that accompanies the migration.

Edicom EDI supports X12 (US retail), EDIFACT (Europe/global logistics), UBL (cross-industry XML), and ODETTE (automotive OFTP2). Odoo has no native document standard handler, so we document the standard applied per trading partner in a migration deliverable titled EDI Standard Matrix. This matrix tells the customer's EDI implementation partner which standard to configure in their chosen Odoo EDI connector (OSI EDI, community modules, or custom Python) for each partner.

Edicom EDI automotive module OFTP2 connection setups (certificates, endpoints, virtual filepaths) and VDA document standards map to a documented configuration export. OFTP2 is not natively supported by Odoo and requires a dedicated automotive EDI connector or custom implementation. We flag OFTP2 partners as requiring specialized EDI middleware alongside Odoo and include the original Edicom OFTP2 configuration parameters in the handoff documentation.

Edicom EDI ERP integration configurations (field selection, transformation rules, triggering conditions) for the company's existing ERP (SAP, Oracle, Microsoft Dynamics) are not applicable in Odoo because Odoo is the destination ERP. We document the original integration logic as a reference for Odoo implementation: which ERP fields fed into which EDI segments, and what triggers initiated outbound document generation. This reference helps the Odoo developer configure equivalent import/export logic in Odoo using Python or the Odoo Studio interface.