techone --guide=edi
EDI for Manufacturers: From Specification to Operations
EDI delivery starts with the partner specification. It defines messages, identifiers, communication, ERP mapping, tests, monitoring and responsibility for operational errors.
TL;DR
- Required Inputs
- We need the partner implementation guide, sample messages, code lists, contacts, required deadline, and acceptance process.
- Business Flow
- Every message must connect to a specific event, business document, and status in both companies.
- Integration Route
- A platform, direct connection, or partner portal assigns mapping, communication, monitoring, and change responsibilities differently.
- Acceptance
- Before go-live, we test standard variants, duplicates, invalid values, acknowledgements, and recovery after a transfer failure.
- Preparation Output
- The output covers message scope, integration design, mapping documentation, test plan, operating model, and estimation inputs.
What the Partner EDI Specification Must Define
UN/EDIFACT defines standardized business messages, while GS1 EANCOM is a widely used subset. A standard name is not enough for delivery. The trading partner profile, business process, required data, communication method, and acceptance conditions control the implementation.
Business Flow and Messages
We first identify the event that creates a message, its sender, the receiving document, and the next step. ORDERS, DESADV, and INVOIC are common examples, but the partner defines their direction and sequence.
Format, Version, and Profile
A label such as EDIFACT or XML does not state the required fields or code lists. Delivery needs the version, subset, partner profile, examples, and rules for segments that may be optional in the general standard.
Identifiers and Master Data
Mapping connects partners, sites, items, units, packaging, and tax data. GLN or GTIN applies where required by the partner; other scenarios use customer and supplier identifiers agreed between the two companies.
Communication and Security
The specification sets AS2, SFTP, OFTP2, a VAN, or a platform interface, including addresses, accounts, certificates, and acknowledgements. DELFOR, DELJIT, and OFTP2 occur frequently in automotive, but they are not fixed requirements for the whole sector.
Testing, Acceptance, and Operation
The scope includes test cases, contacts, response times, approval conditions, and the transition date. Operations also need the meaning of each acknowledgement, an error procedure, and an owner for corrective action on both sides.
How We Prepare an EDI Connection
An EDI project connects the business process, data, ERP, communication, and support. Some activities can overlap, but development should not start before the message flow, source data, and acceptance method are confirmed.
Collect the Specification and Sample Messages
We review the implementation guide, messages, code lists, communication requirements, test contacts, and deadlines. Missing or conflicting information becomes a clear question list for the partner.
Map the Business Flow and Data Sources
For every message, we define the triggering event, value sources, target document, processing status, and response. Changes, cancellations, partial fulfillment, and other common variants are included.
Select the Integration and Communication Route
We compare an EDI platform, direct system integration, and a partner portal. The design assigns the protocol, identifiers, certificates, transformation, availability, archiving, and monitoring responsibilities.
Design Mapping and Error Behavior
Every field receives a source, target element, transformation rule, and example. We add validation, unit conversions, code lists, duplicate protection, acknowledgements, and safe correction and retry procedures.
Implement and Complete Acceptance
Internal processing is validated before running the partner test plan. Tests cover valid messages, invalid values, document sequence, duplicates, unavailability, and repeated delivery.
Go Live and Establish Monitoring
Before cutover, we verify production addresses, identifiers, certificates, queues, and contacts. Monitoring then covers transport, acknowledgements, and business processing, with certificate renewal and escalation ownership.
Platform, Direct Connection, or Portal
All three options can meet a partner requirement. They differ in who owns communication, transformations, certificates, monitoring, and changes. Partner count or message volume alone cannot determine the choice.
EDI Platform
A platform can provide communication channels, some transformations, archiving, and monitoring. The company still needs a reliable ERP interface, its own data rules, and a clear procedure for errors that require action by its team.
Direct System Connection
The company manages communication, mapping, and operation in its own architecture. This provides control but requires capacity for certificates, specification changes, availability, monitoring, and support.
Trading Partner Portal
A portal can meet the requirement without system integration, but people enter or download messages manually. It is worth assessing for a simple, infrequent flow; growing volume can justify a new comparison later.
We compare the options against the same business scenario, availability target, expected changes, and full operating responsibility. This makes the tradeoffs visible.
How an EDI Message Connects to ERP
EDI does not end when a file arrives. The message must be validated, linked to the correct partner and document, and allowed to change ERP status safely. A supported route may use APIs, files, a database interface, or integration middleware. Dynamics 365 Business Central provides standard and custom APIs; the version, entities, authentication, and extensions must still be verified.
Receive and Correlate
An incoming message receives a technical identifier and sender reference. The integration retains the original content and the data needed to trace transport, acknowledgements, and any retry.
Technical and Business Validation
Syntax, version, and mandatory elements are checked before business rules. An unknown item, unit, or site must not silently create a valid ERP document.
Master Data Mapping
Partner codes are translated to internal partners, items, units, warehouses, and other objects. Each mapping needs an owner, validity period, and a procedure for values that do not yet exist in ERP.
Controlled Read and Write
The integration uses a supported ERP interface and respects business logic. It verifies the target document and status before writing and does not create the same business event twice after repeated delivery.
Acknowledgements and Processing Status
Technical delivery does not prove that ERP accepted the business content. The design separates transport, syntax validation, document creation, rejection, and any response sent to the partner.
Monitoring and Reconciliation
The operating view connects the message, partner, business document, and latest status. Teams can find pending or rejected messages and confirm that neither side is missing part of the exchange.
What the Integration Must Prove before Go-Live
One correct sample message is insufficient. Acceptance must cover the standard flow, its variants, and states that could create an incorrect document or stop downstream processing. The partner scenario and test procedure define the exact set.
Correct Document and Status
A valid message creates or updates the right business document, uses the expected master data, and reaches the intended status without manual correction.
Missing or Unknown Value
A missing mandatory field, unknown code, or invalid combination stops before the business write. The error has a clear description, owner, and correction procedure.
Duplicate Message
Repeated delivery does not create another document or movement. The integration identifies the duplicate and retains a traceable result.
Change, Cancellation, and Partial Fulfillment
The message links to the correct original document and respects its current status. An invalid change is rejected or routed for a decision under the agreed procedure.
Acknowledgement or Rejection
A missing, negative, or late acknowledgement triggers a defined response. The team knows when to wait, when to retry, and when to contact the partner.
Failure and Safe Recovery
Processing can resume after communication or ERP unavailability without losing the message or writing it twice. Queues and retries have limits and monitoring.
End-to-End Traceability
A partner, message, or business document identifier can retrieve receipt, validation, write, acknowledgement, error, and later correction.
TechOne Experience with EDI Projects
Our projects cover production EDI connections and the analysis required before development. This experience connects partner requirements with ERP data, acceptance, and operating responsibility.
Tecam PCV
We provide ongoing ERP development for a wholesale company and delivered automatic receipt of supplier orders and invoices through EDI. The work also includes operational reporting and user support.
Lagardère Travel Retail
During EDI communication preparation, we mapped the order-to-invoice flow, ORDERS, DESADV, and INVOIC fields, validation rules, and a supplier onboarding procedure.
Holík International
As part of a manufacturing and warehouse analysis, we designed supplier EDI communication within a phased digitization plan. The proposal connected ERP, warehouse records, and production work.
The next project scope follows the specific partner guide, current ERP, and the responsibility TechOne should assume during delivery and operation.
Frequently Asked Questions
Which inputs do you need to design and estimate an EDI connection?
We need the trading partner implementation guide, sample messages, code lists, communication method, test procedure, required deadline, and contacts. On the company side, we verify the ERP and version, data sources, process owners, current documents, and operating requirements.
When should we assess an EDI platform, direct connection, or partner portal?
Assess a platform when it should provide multiple communication channels, transformations, and part of the operation. A direct connection can fit a company prepared to manage its integration route. A portal may be enough for a simple, infrequent flow. Service levels, security, change handling, monitoring, and error ownership also matter.
Can EDI connect to an ERP without a built-in EDI module?
Yes, when the ERP provides a supported API, file, or database interface, or when integration middleware can be used. We first verify the version, authentication, available data, business logic, and vendor support. Direct database writes without an agreed interface may bypass ERP rules and complicate upgrades.
What determines delivery scope, schedule, and cost?
The factors include message flows, differences between partner and ERP data, master data quality, communication channel, certificates, development, the partner test procedure and response time, cutover, and required monitoring. An estimate follows these inputs and confirmed open questions.
What can be reused when connecting another trading partner?
Communication infrastructure, parts of the ERP connector, monitoring, archiving, and some mapping components may be reused. A new partner can still require a different version, profile, code lists, tests, and operating rules. Every connection needs its own gap review and acceptance.
Related Topics
ERP Integration (service)
Supported interfaces, data ownership, and operational monitoring between ERP and connected systems.
Logistics and ERP
How EDI messages connect to receiving, inventory, dispatch, and the physical material flow.
ERP in Manufacturing
How supplier and customer messages connect to manufacturing planning and execution.
Review Your EDI Integration Specification.
In the initial meeting, we review the trading partner guide, sample messages, current ERP, required deadline, and testing process. This identifies open questions and the inputs needed for design, estimation, and delivery.