EDI interface

Purpose

This page describes the EDI interface in Automotive from basic configuration through partner and message-type setup to the operational processing of inbound and outbound messages. It serves as the central orientation point for scenarios in which call-offs, invoices, delivery-note data, or transport information are exchanged automatically with partners.

Business value

• You choose a suitable transmission mode for partner communication.
• You set up partners, message types, and number series so that messages are created, recognized, and archived reliably.
• You understand the difference between inbound and outbound message processing.
• You use protocol and history for error analysis, evidence, and restart scenarios.

Core EDI processing logic

The EDI interface connects Business Central with converters, web services, or file locations. The process always follows the same core logic:

1. A message is received or generated.
2. Partner, message type, and direction are identified.
3. The message is processed, validated, and where required converted into a document.
4. Status, protocol, and archiving protect traceability.

graph LR;

%% Nodes
A[Partner or system]
B[Receive or generate message]
C[Identify partner and message type]
D[Process message]
E[Document or status update]
F[Protocol and history]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
D ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

How EDI fits into the BC document flow

For end users, one point is especially important: in Automotive, EDI is not a parallel world outside Business Central. EDI reads data into Business Central or writes data out from existing BC documents. The message list itself is therefore only rarely the real end of the process.

graph LR;

%% Nodes
A[Partner]
B[EDI Inbound Messages]
C[Check and process]
D[Automotive order or purchase document]
E[Warehouse or goods receipt]
F[Posted document]
G[EDI Outbound Messages]
H[Partner]
I[Protocol and archive]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F
F ==> G
G ==> H
C ==> I
G ==> I

%% Classes
class A btProcessTitle
class B,C,D,E,F,G,H,I btProcessActive

For daily work, this reading rule helps:

1. Check in the EDI list whether the message has technically arrived or been sent.
2. Then move into the created or affected business document.
3. Only there decide whether the process is functionally complete.

EDL information flow as a reference model

The service description extends the EDI view with a clear exchange model for EDL scenarios between supplier, EDL, and customer.

Click to enlarge

For operational mapping in Automotive, this sequence is especially important:

1. Delivery call-off or detailed call-off is triggered as VDA call data.
2. Delivery-note transport data is provided as VDA 4913.
3. EDL confirms receipts and returns inventory information.
4. Warehouse calls and delivery-note data between EDL and customer also run via VDA 4913.
5. Invoice data is exchanged via VDA 4906 and credit processes via VDA 4908.

This clarifies that EDI in this scenario covers not only call-off and invoicing, but also ongoing inventory and shipment communication along the physical flow.

Choose transmission modes deliberately

The legacy documentation describes three base models for transmission:

In the current cloud code, the selectable default transmission type is restricted to Web Interface and Azure File Share. The file-based logic still exists in code, but in the current product state it mainly matters as a legacy or special-case pattern.

The global transmission mode can also be overridden per partner. Decide early whether all partners should use the same mode or whether mixed scenarios are required.

EDI setup and number series

The central EDI setup defines activation, archiving, paths, and number series. Number series are not a side topic, but a prerequisite for stable processing.

In code, the EDI Setup page provides dedicated groups for General, Nos. Series, Import, Export, Web Service, and Azure File Share. It also provides direct actions for:

• Create EDI Standard Data
• Create EDI Standard Data with Paths
• opening the EDI Partner List
• opening EDI Message Types

Number series are especially important for:

• EDI partners
• inbound sales documents
• inbound purchase invoices
• inbound delivery-note data
• outbound sales and purchase messages
• credit memos and additional follow-up documents

If these number series are missing, generation or assignment often fails not as a visible business issue, but inside technical processing.

On the setup page, review these fields consciously as well:

• Interface is Active
• Mandatory Information
• Archive Messages, Archive Type, and Archive Grouping
• Inbound Message Error Handling and Max. No. of Attempts to Proc
• Web Service Provider, Web Service URL, Web Service Timeout, and provider-specific service paths
• Azure File Share Account Name, access key, and inbound, outbound, and archive URLs

Set up partners and partner lines

Every EDI partner connects Business Central master data with message logic. This includes:

• Partner Type, in the current cloud build typically Customer or Vendor
• Partner No. and, where relevant, Ship-to Address
• Partner ID as the identifier for inbound messages
• Sender ID as your own identifier for outbound messages
• Transmission Type per partner
• Mandatory Information including GLN-related mandatory logic
• parameters such as sender and receiver IDs, Odette IDs, and further partner details

Partner lines control:

• whether the line is Active
• which Direction and Message Type Code apply
• whether Create Document, Automatic Processing, or Send Message are enabled
• which Message Filename and Message Extension are used
• whether a separate Message Location is used
• which delivery, incoming, invoice, or shipping guidelines apply

Important for maintenance: the code blocks changes to Partner Type and Partner No. once partner lines already exist. These master-data values should therefore be stable before you start detailed message configuration.

For outbound partner lines, the file name is not just convenient, but effectively mandatory. Without it, output often fails only later in the send process.

Understand message types

Message types define how a message is recognized and processed. This includes format, direction, record type or XML node, and whether a document may be generated from it.

The EDI Message Types page shows in code, among others, these fields:

• Code
• Direction
• Description
• Type
• Test Mode
• Create Message
• Automatic Processing
• Send Message
• Message Format
• Root Element
• Record Type
• Method Delivery EDI and Method Invoice EDI

In addition, the page provides the Create Default Message Types action. This is the intended standard path so that you do not build the basic set of message types manually from scratch.

The source refers in particular to VDA and extended VDA scenarios such as:

• delivery call-offs
• fine-schedule call-offs
• delivery-note or transport data
• invoice data
• credit memos

The important point is this: message type, partner line, and guide must fit together. Otherwise a message may be received technically, but still not be processed correctly from a business perspective.

The code also shows that guideline logic is not a simple label choice. Specific variants for BMW, Porsche, Daimler, PSA, Nissan, VW, Jaguar, Motherson, and other OEM or partner cases actually affect later generation and processing.

Process inbound messages

For inbound messages, the process usually runs in three steps:

1. read messages
2. process messages
3. review the result and, where required, accept, reject, or reprocess

The EDI Inbound Messages list maps this flow directly. Important actions in code are:

• Import Messages
• Import Message File
• Check Message
• Process Message
• Reprocess Message
• Toggle Test Mode
• Delete Message

Typical inbound objects are:

• call-offs for sales or purchasing
• invoices or credit memos
• delivery-note data
• further partner-related documents in the message context

For operational review, these list fields are especially important:

• Status
• Test Mode
• EDI Partner No., Partner No., and Partner Name
• Filename with drilldown into the message content
• Last Error Message
• No. of Attempts to Process

Especially for inbound sales documents, automatic processing should not replace business review. Use status, error message, and content drilldown before finally releasing documents.

In BC terms, this means something very practical: a successfully processed message only creates real business value once the related order, call-off, receipt, or follow-up document is also plausible in content.

Process outbound messages

Outbound messages are generated from Business Central documents or status changes. They can be sent automatically or manually. Typical examples are:

• outbound delivery call-offs
• outbound invoice data
• transport or shipment data
• credit-note or follow-up documents

The EDI Outbound Messages page provides, among others, these actions in code:

• Send Message
• Update Delivery Status
• Manually Set Status to Processed
• Toggle Test Mode
• Delete Message

Before sending, check:

• is the correct message type active?
• is the partner assigned correctly?
• are file name, guide, and path logic complete?
• is the message in test mode or live mode?

In web-service scenarios, the outbound list also adds Converter Status, Converter Status Text, and Converter Send Time. These fields matter when technical transmission does not fail during sending itself, but only later at the converter or web service.

The same principle applies here: a technical send status is not automatically a business release. In clarification cases, always review the originating document as well, for example the call-off, transport record, posted shipment, or invoice.

Archiving, protocol, and history

Archiving and protocol are the central evidence layer of EDI processing. They help not only with debugging, but also with partner inquiries, audits, and restart scenarios.

Use in particular:

• protocol with direction, time, file, status, and error message
• inbound and outbound archives
• error archives for files that could not be processed successfully
• history for received delivery-note data and other follow-up objects

Without clean archives, a technical retry may still be possible, but business traceability is not.

Web-service and platform integration

For web-service scenarios, the legacy documentation refers in particular to integrations with Ecosio and Eddyson. Important parameters include:

• service URL
• send, receive, and callback paths
• user identifier or API key
• company or partner ID
• timeouts and test environment

These parameters should only be maintained in an aligned test and production setup. Errors in URL or authentication immediately affect inbound or outbound message processing.

In addition, the code already checks the web-service connection in the background when the URL changes. Use that check early, not only during the first business test transmission.

Operational control steps

Typical failure patterns

Migration checklist from legacy help

For a stable migration from older EDI documentation, maintain at least the following evidence per partner group:

This checklist mainly addresses operational monitoring and error-handling gaps that were often described in greater detail in legacy documentation.

Result

• You understand the basic architecture of the EDI interface in Automotive including the actual work pages in code.
• You can classify transmission modes, partners, partner lines, and message types correctly from a business perspective.
• You use inbound and outbound lists, converter status, protocol, and history as the operational control and evidence layer for message exchange.