Migrate from Edicom EDI to Infor CloudSuite Corporate

Edicom EDI transaction sets map to Infor CloudSuite Industrial's edi.* database tables (edi_orders, edi_transactions). We extract the X12/EDIFACT document payload from Edicom's export files, transform segment data into Infor's flat ASCII file format, and load via Infor's EDI Transaction Load Routine. The source document type (850, 810, 856, etc.) determines the target CloudSuite table. Closed and posted transactions must be completed in Edicom before extraction to ensure the CloudSuite migration database receives the most current state.

Edicom EDI trading partner records carry document type, communication protocol, and validation rules. We map these to Infor CloudSuite's EDI Customer Profiles (for inbound documents) and EDI Supplier Profiles (for outbound documents). The partner's ISA/UNB interchange identifier in Edicom becomes the Partner ID field in CloudSuite. We preserve the partner-specific validation rules as a configuration document for the customer's admin to re-enter in Infor's profile forms.

Edicom EDI connection credentials (AS2 endpoint URLs, SFTP host keys, VAN mailbox addresses, OFTP virtual filepaths) are exported as configuration data. These cannot be imported directly into Infor CloudSuite because Infor uses ION protocol configuration and external translator setup rather than storing credentials in database tables. We deliver a connection inventory document listing every partner protocol, endpoint, and credential, and the customer's IT team configures ION or their chosen EDI translator with this data before go-live.

Custom field-level EDI mappings in Edicom EDI encode how ERP data fields translate into EDI segment positions. These mappings are platform-specific and cannot be imported into Infor CloudSuite. We perform a manual inventory of every non-standard mapping during scoping, document the source-to-target field logic, and deliver a mapping matrix to the customer's Infor admin or EDI consultant for re-implementation in Infor's translation layer. Any mapping without a clear Infor equivalent is flagged as requiring re-engineering before cutover.

Edicom EDI's ERP integration logic (field selection, transformation rules, triggering conditions for SAP, Oracle, Dynamics, NetSuite) maps to Infor ION Workflows in CloudSuite. ION Workflows define data flow between CloudSuite and external systems. We document the Edicom EDI integration endpoints, payload structures, and triggering events as an integration inventory. We do not configure ION Workflows as part of the migration scope; the customer's Infor partner or admin rebuilds these based on the inventory.

Edicom EDI operates as a Value-Added Network with per-organization and per-partner mailbox addresses, interchange acknowledgments (997/Control), and transmission logs. We export the VAN routing tables and acknowledgment records as a reference document. Infor CloudSuite's EDI module does not maintain a VAN; instead, companies either use Infor ION with a third-party VAN or configure AS2/SFTP connections directly. We deliver the VAN routing table as part of the connection inventory for the customer's EDI team to re-establish post-migration.

Edicom EDI supports multiple standards families with the standard applied per trading partner. We catalog the standard used for each active document type. Infor CloudSuite Industrial receives data through a flat ASCII translator, and the translator must be configured for the correct standard. We deliver a standards-by-partner matrix documenting which partners use X12, EDIFACT, or UBL so that the customer's Infor implementation team or EDI consultant configures the translator accordingly.

Edicom EDI's automotive module uses OFTP2 (Odette File Transfer Protocol) and VDA standards for manufacturer-supplier exchanges. OFTP2 requires certificate exchange, endpoint definition, and virtual filepath configuration. We export the OFTP2 connection setup data (certificates, endpoints, virtual filepaths) from Edicom and deliver it as a configuration document. Infor CloudSuite supports OFTP2 through ION or a third-party translator; the automotive trading partner re-onboarding includes re-establishing OFTP2 credentials with each manufacturer.

Edicom EDI supports maritime transport messages including IFTDPC and COPISNL for customs, port authority, and shipping company communications. These are vertical-specific document types with limited Infor CloudSuite native support. We export the active maritime document configurations and port communication setup as a vertical integration inventory. The customer evaluates whether Infor ION, a third-party maritime EDI translator, or a dedicated maritime platform handles these document types post-migration.

Edicom EDI encodes country-specific e-invoicing validation rules, digital signatures, and government portal submissions (Brazil NF-e, Italy SDI, France Chorus Pro, Saudi ZATCA Phase 2, Greece myDATA). These rules are jurisdiction-bound and non-portable to Infor CloudSuite. We catalog every active country mandate during discovery and deliver a compliance inventory documenting the Edicom EDI rule per jurisdiction. The customer's tax, legal, and IT teams re-implement compliance in the appropriate jurisdiction's mandated platform or Infor-compliant third-party e-invoicing module.

Edicom EDI exposes some document exchange via REST or SOAP web services for ERP systems that cannot use traditional EDI protocols. We export the endpoint definitions, payload schemas, and authentication configurations as an API inventory. Infor CloudSuite uses ION API endpoints and Mongoose web services for similar integrations. The customer's Infor developer or integration partner rebuilds these web service connections in ION based on the inventory we deliver.