EDI message processing

Purpose

This page describes operational message processing in Automotive. It complements the EDI setup with the daily work on inbound and outbound messages, the EDI documents generated from them, and the related sales and transport objects.

Core principle

Message processing is the central place for all inbound and outbound message types. This is where the live operation is managed. It is not the place where the EDI baseline is configured.

Inbound messages

Inbound messages are managed in a dedicated list. Import can happen manually or through the job queue. Depending on Automotive Setup, the release of certain call-offs can also be automated.

Key functions

Key fields in the inbound list

Key rule: an imported message is not yet a business-completed process. Only processing, document review, and if necessary acceptance lead into the real operational process.

Inbound sales documents

Processed EDI messages can be shown as inbound sales documents. There you review and control the business takeover.

Important actions are:

• Accept to generate an order,
• Reject for conscious refusal,
• Postpone for undecided cases,
• Reset status for renewed handling,
• Field processing to execute mapping rules,
• Update fields for renewed data takeover,
• Comments for traceability.

Outbound messages

Outbound messages also have their own overview. There you control whether messages were generated, sent, or still need manual release.

Key functions

Outbound sales documents and transport context

In the outbound sales-document view, you find the documents for which messages must be generated or were already generated. Especially important are:

• Create message when the file has not yet been created,
• Reset status when renewed technical handling is required,
• the jump into the linked sales document,
• comments for business context.

In addition, Sales Delivery Call-Offs and Posted Transport Data are important supporting views when messages must be reviewed not only technically, but along the real shipment process.

Apps required for CSC, HUM, and EDI processes

Before processing a message, check which apps belong to the planned process:

• Controlled Sales Core handles delivery call-offs, dispatch control, and transport data.
• Handling Unit Management is required when the process uses packaging structures, packaging materials, weights, or packaging assignments.
• BE-terna Connector HUM CSC connects packaging assignments with CSC sales and transport processes.
• BE-terna Connector CSC EDI provides the EDI integration for CSC. Packaging data can be projected to EDI targets such as VDA4987/DESADV.

The EDI app transfers packaging structures into the target message format. Fixed EDI levels, packaging type codes, and lot or serial numbers describe the message output; they do not change the neutral packaging structure in HUM.

Interpret delivery-call-off reset data correctly

A DELFOR context can contain a current cumulative quantity, a previous cumulative quantity, and a reset date. The previous cumulative quantity and reset date are input data from the EDI context. They are not automatically the target quantity confirmed by a CSC user in a controlled zero-setting process. Review candidates, links, and conflicts before execution.

Continue DELFOR processing in CSC

For an inbound DELFOR message, the connector checks partner and message setup and passes the mapped call-off data to CSC. After import, review:

• whether the delivery call-off was matched to the correct partner, blanket order, and item,
• whether call-off number, call-off date, date type, quantity type, and planning type are plausible,
• whether synchronization is shown as completed or failed, and
• whether the created or updated CSC call-off lines can continue into the next process step.

The EDI message remains the external source. Business processing and persistence of the call-off data take place in the CSC process.

Recommended daily routine

1. Import new inbound messages or check the automatic inbound queue.
2. Validate messages before the actual processing step.
3. Review EDI documents and inbound sales documents from a business perspective.
4. Accept, reject, or postpone the documents.
5. Check outbound messages and delivery status against sales or transport documents.

Typical error patterns

Migration deepening: restart and escalation path

To keep operational depth from older runbooks, use a strict restart path for message processing:

1. Validate the message technically and classify the latest error.
2. Identify business context: order, call-off, delivery note, or transport.
3. Reprocess only after the root cause is understood.
4. After rerun, immediately verify status and follow-up document.
5. If the error repeats, escalate to second-level support with protocol extract.

Screenshot backlog by section

Result

• You can steer inbound and outbound messages safely in daily operation.
• You know when a message is technically present, but still not finished from a business perspective.
• You connect EDI message, EDI document, sales document, and transport data into one traceable chain.