EDI protocol and history
Purpose
This page describes the historical traceability of the EDI interface. The focus is on the EDI log as the technical evidence trail and on the history view for inbound delivery-note EDI in EDL/consignment and purchasing scenarios.
EDI protocol as the technical evidence trail
The EDI protocol stores all interface actions in a traceable way. It is therefore the first place to look when a message is expected but it is unclear whether it was imported, processed, sent, or ended with an error.
Key fields in the protocol
| Field | Meaning |
|---|---|
| Direction | inbound or outbound |
| Created date | date of the protocol entry |
| Created time | time of the protocol entry |
| Description | file name or error description |
| Process code | technical classification of the process step |
| Process description | concrete interface action that was executed |
| Status code | technical result status |
| Status description | plain-text explanation of the result |
This combination helps separate technical and business questions. The protocol does not tell you whether the business process was correct, but it shows exactly what the interface actually did.
Review inbound delivery-note EDI historically
When EDI messages were received for EDL/consignment processes or for purchasing receipt scenarios, the inbound delivery-note EDI can be reviewed in a dedicated history view.
This view is especially important when you need to confirm:
- whether an expected delivery-note message arrived at all,
- whether it belongs to the correct process area,
- whether the technical inbound was already turned into business processing,
- whether a later receipt or consignment case goes back to exactly this message.
Recommended troubleshooting routine
- Start with the EDI protocol.
- Filter by direction, period, file name, or process description.
- Identify the last successful or failing processing step.
- Move from there into the message list or affected business document.
- Also review the inbound delivery-note EDI history if the issue belongs to shipping or receipt handling.
Typical error patterns
| Situation | Possible cause | Check |
|---|---|---|
| Message seems to be missing | it never arrived or the wrong channel was checked | search the protocol by file name and period |
| Message arrived technically, but is not visible functionally | processing stopped after import | review status description and follow-up steps in the protocol |
| Purchasing delivery-note relation is unclear | inbound delivery-note EDI was not included in the review | compare the delivery-note EDI history with the purchasing flow |
| Consignment or EDL case cannot be explained | technical inbound and business flow were reviewed separately | check protocol, EDI history, and document flow together |
Result
- You can use the EDI protocol as a reliable technical evidence trail.
- You know when the history of inbound delivery-note EDI is decisive for purchasing or EDL/consignment scenarios.
- You separate technical transmission issues cleanly from business follow-up problems.
Links