EDI setup and partner maintenance

Purpose

This page deepens the EDI interface around the concrete setup of transmission type, number series, partners, partner lines, message types, and field mapping. It complements the EDI overview page with the fields and project decisions that were described in detail in the legacy wiki.

Build EDI Setup in a clear order

The base setup is structured into several tabs. Do not maintain them in parallel. Work through them in a fixed sequence.

1. Define the General tab first.
2. Complete all relevant number series.
3. Choose the transmission type and maintain only the matching technical tab.
4. Only afterwards create partners, partner lines, and message types.

General tab

Numbering tab

Number series are not a formality. If they are missing, the failure often happens in technical assignment or traceability rather than in the business document itself.

At least these number ranges should be validated before the first end-to-end test:

• partner numbers
• inbound sales orders
• inbound sales and purchase invoices
• inbound purchase receipts
• outbound sales orders, invoices, and credit memos
• outbound purchase orders

Technical tabs by transmission type

File-based

The file-based route is mainly relevant for older or on-premises-style scenarios. Here you must maintain inbound and outbound folders, archives, error handling, and the maximum number of processing attempts.

Web interface

For web-service scenarios, maintain provider, base URL, timeout, send path, receive path, callback path, and authentication data. The legacy documentation mentions ecosio and Eddyson as typical providers.

For web-based integrations, also verify:

• test and live URLs are not mixed up
• timeout is realistic
• user ID, password, app key, and company ID are aligned with the partner
• sandbox environments have the required app permission for outbound communication

Azure File Share

For Azure File Share, you need the account name, access key, and separate URLs for input, output, and both archive locations. Create the full folder structure before the first test instead of adding it only after an error appears.

Create EDI partners cleanly

An EDI partner links the Business Central master data to the actual message logic. The especially important fields are:

The parameter area adds sender and receiver numbers, sub-supplier numbers, mailboxes, Odette IDs, or code additions. These fields are not mandatory in every scenario, but they become business-critical depending on message type or OEM guide.

Partner lines as the real process steering

Each partner can have multiple partner lines. In practice, one line usually represents one combination of message type and direction.

Especially relevant fields are:

• Active
• Direction
• Message type code
• Create document
• Automatic processing or sending
• Send message
• Message filename
• File extension
• Message location or archive location
• Guides for delivery-note, invoice, or inbound EDI

Key rule: the partner card describes the communication partner. The partner line decides what technically and functionally happens with one specific message type.

Message types and guides

Message types define direction, format, VDA record type, and processing logic. Standard message types should preferably be generated through the intended function instead of being rebuilt manually.

The classic VDA mapping from the legacy documentation is:

Addition from COMEDI training: operational message-processing flow

The training material adds a precise operating flow for day-to-day processing. The key point is to follow a strict sequence per direction.

graph LR;

%% Nodes
A[Read message]
B[Validate message]
C[Process message]
D[Open document view]
E[Check status and log]

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

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

Inbound messages

1. Read messages from the configured inbound folder.
2. If required, run Check message and review errors in Last Error Message or in the protocol.
3. Process messages and validate generated EDI documents.
4. In Inbound Sales Documents, decide functionally: Accept, Reject, or Postpone.

Outbound messages

1. Ensure partner line and message type are active.
2. If automation is not enabled, trigger Send message manually.
3. Then use Update converter status and review feedback.
4. Use Show message and Protocol to trace file output and process history.

Additional checks from training

• Use UNC paths for file-based scenarios (for example \\SERVER\EDI\INPUT).
• On partner lines, Message file name and optionally a dedicated folder are mandatory for outbound flow.
• If partner-line paths are empty, the global folders from EDI setup are applied automatically.
• Use field mapping deliberately for value transformation, for example unit PCE to internal BC code ST.

Selected OEM guides also influence the actual behavior in processing. Guides such as BMW, Porsche, VW, Daimler, or Jaguar must therefore not be treated as descriptive labels only.

Guides directly affect the business process

The legacy documentation shows this clearly: the selected guide does not only define the message format, it also changes fields, print content, and downstream process steps. Maintain this choice together with the business process design instead of treating it as an isolated technical setting.

Other guides such as BMW JIS, Nissan, Bosch, or Lamborghini also contain project-specific rules. Document these differences not only in partner setup, but also in your test cases and go-live checklists.

Use field mapping consciously

Field mapping lets you translate values from inbound messages into the values expected by the system. A typical example is converting an externally transmitted unit such as PCE into the internal BC code ST.

Use this function especially when:

• partner data arrives technically correct, but does not match your internal codes
• one message type should run stably without constant manual correction of master data
• project-specific translation rules must remain documented and traceable

Typical error patterns