Migrate from Edicom EDI to Epicor Prophet 21

Edicom EDI Transaction Sets (X12 850 purchase orders, 810 invoices, 856 ASN, 855 order acknowledgments, 997 functional acknowledgments; EDIFACT ORDERS, INVOIC, DESADV) map to Epicor EDI document records within the Epicor EDI module. We extract transaction history as structured export (XML/CSV) from Edicom, then load into Epicor Kinetic or Prophet 21 order, invoice, and ASN tables using Epicor's data import tools or REST API, preserving document numbers, dates, line items, and amounts. VAN interchange control numbers and functional acknowledgment status (997/Contrl) are stored as reference fields in Epicor EDI.

Each Trading Partner record in Edicom EDI defines document types exchanged, communication protocol, and partner-specific validation rules. We export partner records as structured configuration files, then map each to Epicor EDI's Trading Partner module by partner ID, document types, and protocol. Connection credentials (AS2 URL, SFTP keys, VAN mailbox) are re-established in Epicor EDI or AtlasExchange; partner-specific validation rules are cataloged for rebuild in Epicor's mapping tool. Automotive partners using OFTP2 are configured in Epicor's automotive EDI module with virtual filepaths and certificate exchange completed under Epicor's automotive protocol requirements.

Edicom EDI supports AS2, SFTP/FTPS, VAN mailbox, OFTP for automotive, and HTTPS web services. We extract protocol endpoint definitions, credential configurations, and certificate details from Edicom, then re-establish each in Epicor EDI or AtlasExchange by protocol type. AS2 and SFTP credentials (user, password, certificate, URL) transfer as configuration values and are entered manually into Epicor EDI connection settings. VAN mailbox routing tables from Edicom's network are replaced by Epicor EDI's VAN or re-routed via AtlasExchange managed VAN. OFTP2 for automotive requires virtual filepath and certificate setup in Epicor automotive module, which is rebuilt from Edicom's OFTP2 configuration during the mapping phase.

Custom field-level EDI maps in Edicom EDI define how ERP data fields translate into EDI segment positions (e.g., ERP customer part number to X12 N1 segment). Edicom stores maps in a proprietary format; Epicor Kinetic uses its own mapping tool or AtlasExchange map management. We perform a manual field-level inventory of every custom in-house mapping during scoping, output a written map inventory document, and the customer's EDI team rebuilds each map in Epicor Kinetic's mapping interface or AtlasExchange based on our field inventory. Non-standard maps without a clear Epicor equivalent are flagged as requiring re-engineering before cutover.

Edicom EDI connects to ERP systems (SAP, Oracle, Microsoft Dynamics, NetSuite) via pre-built or custom connectors with field selection, transformation rules, and triggering conditions. We extract ERP integration logic from Edicom configuration exports, then re-implement equivalent integration in Epicor Kinetic using REST API endpoints or in Prophet 21 using its API integration framework. Inbound EDI-to-ERP flows (EDI 850 to Epicor Kinetic Sales Order) and outbound ERP-to-EDI flows (Epicor Kinetic Invoice to EDI 810) are rebuilt as Epicor integration configurations. Epicor's iParts and REST adapter framework replaces the connector logic that was previously managed in Edicom EDI.

Edicom EDI operates as a Value-Added Network with mailbox addresses per organization and per Trading Partner. VAN routing tables, interchange acknowledgments (997/Contrl), and transmission logs are exported as structured data. We re-establish VAN connectivity in Epicor EDI via AtlasExchange (Epicor's managed VAN) or by configuring direct AS2/SFTP connections for each Trading Partner. Mailbox address assignments and routing configurations are mapped to Epicor's VAN management or AtlasExchange partner routing tables.

Edicom EDI natively handles X12 (US retail), UN/EDIFACT (Europe, global logistics), UBL (cross-industry XML), and ODETTE (automotive). Epicor EDI via AtlasExchange supports all four standards families. We export document type configurations from Edicom by standard and version, then re-create the equivalent configuration in Epicor EDI for each Trading Partner's required standard. Test credentials, acknowledgment requirements, and partner-specific protocol settings are re-established per partner in Epicor EDI.

Edicom EDI encodes country-specific e-invoicing validation rules and government portal submission flows for jurisdictions including Brazil NF-e, France Chorus Pro, Italy SDI, and Saudi ZATCA Phase 2. These rules cannot be exported and loaded into Epicor; each destination jurisdiction requires re-implementation in Epicor Compliance Management or country-specific integration. We catalog every active country mandate during discovery, document the current Edicom configuration (validation rules, digital signature requirements, portal endpoints), and itemize re-implementation effort separately so customers do not assume regulatory compliance transfers automatically with the data.

When Edicom EDI handles mandatory e-invoicing (rather than pure EDI), the platform enforces country-specific schema, digital signatures, and government portal submissions that are jurisdiction-bound. We flag every active e-invoicing mandate in the discovery phase, document the Edicom configuration (submission endpoint, authentication, schema version, digital certificate), and deliver a written re-implementation plan for Epicor's compliance module. The customer's fiscal or IT team coordinates with each tax authority's portal for re-registration, as digital certificates and portal credentials cannot be transferred between EDI platforms.

Edicom EDI's automotive module uses OFTP2 (Odette File Transfer Protocol) and VDA standards for manufacturer-supplier exchanges. OFTP2 connection setup—certificates, endpoints, virtual filepaths—is required in Epicor's automotive EDI module. We extract OFTP2 configuration from Edicom (partner endpoints, virtual mailbox, certificate thumbprints, conversation IDs), then rebuild the equivalent configuration in Epicor Automotive EDI. VDA message type support (VDA 4906, VDA 4913) is configured per Trading Partner in Epicor's automotive module. Customer-supplier OFTP2 test exchanges with each automotive partner are coordinated as part of the trading partner re-onboarding phase.

Edicom EDI exposes some document exchange via REST or SOAP web services for ERP systems that cannot use traditional EDI protocols. Endpoint definitions, payload schemas, and authentication configuration from Edicom are exported as configuration data. We re-implement the equivalent integration in Epicor Kinetic using the Epicor REST API (Ice.Core.Session login, Erp.BO.SalesOrder, Erp.BO.Invoice) or Epicor iParts adapter framework. API authentication (API key, OAuth, basic auth) is re-configured in Epicor; endpoint URLs and payload field mappings are documented in the integration inventory for the customer's Epicor administrator.

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 catalog every active maritime message type during discovery, then assess whether Epicor EDI's AtlasExchange VAN handles the relevant port community system integration or whether a middleware layer is required to maintain maritime document exchange. If Epicor EDI does not natively support a specific maritime standard, we document the gap and recommend a middleware approach (iPaaS or direct API integration with the port community system) as a separate implementation workstream.

In-house-developed custom transformations, partner-specific validations, and ERP integration hooks built on Edicom EDI often encode years of accumulated business logic with no external reference. We perform a manual field-level inventory of all custom transformations during scoping, document each map's input fields, output positions, validation rules, and business logic, then deliver a written map inventory for the customer's EDI team to rebuild in Epicor Kinetic's mapping tool or AtlasExchange. Maps without a clear Epicor equivalent are flagged as requiring re-engineering before cutover, and the re-engineering effort is itemized as a separate workstream in the migration scope.

Edicom EDI stores compliance testing status, test document exchange logs, and partner acknowledgment records per Trading Partner. This history does not transfer to Epicor EDI; each Trading Partner's compliance test status resets at cutover. We export the current compliance testing history as a reference document, then coordinate re-testing with each partner after Epicor EDI is configured. Top-volume partners run parallel testing before full cutover; lower-volume partners are migrated in a second wave with extended parallel-run windows.