.png)
TL;DREDI stands for Electronic Data Interchange. It is the structured, machine to machine exchange of standardised business documents, such as orders, invoices and dispatch notes, directly between the computer systems of two trading partners, with minimal human intervention. Instead of a person typing an order into one system and someone else re-keying it into another, the systems exchange a defined message and book it automatically.
The word structured is the important one. In EDI each document follows an agreed format, so the receiving system knows exactly where to find the order number, the article, the quantity and the price. That is what separates EDI from sending a PDF invoice by email: a PDF still needs a human to read and re-enter it, while an EDI message is processed by software end to end.
The most widely used standard family in Europe is EDIFACT, in full UN/EDIFACT, the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. Its syntax rules were adopted as the international standard ISO 9735, and the standard is maintained and developed by UN/CEFACT, the United Nations Centre for Trade Facilitation and Electronic Business, under the UN Economic Commission for Europe. EDIFACT defines named message types for each document, for example ORDERS for a purchase order, DESADV for a dispatch or despatch advice, and INVOIC for an invoice.
In pharmaceutical distribution EDI matters because the same trading relationship generates many documents in a repeating cycle: a wholesaler or manufacturer receives orders, confirms them, ships goods and issues invoices, often thousands of times a day. Doing that by hand does not scale, and every manual re-entry is a chance to transpose a PZN or a quantity. This is also where the confusion tends to start. Teams often meet EDI first through their own accounting or ERP software, for example a Sage based EDI setup for invoicing, and then ask how it relates to the availability and ordering they know from MSV3. The short answer is that they solve different parts of the same supply chain, and a system can speak both.
This is the distinction that most often gets blurred in pharmaceutical wholesale, because all three connect systems, but they operate at different levels. EDI is a broad document exchange family, MSV3 is a narrow domain standard, and a REST API is a general technical style. The table makes the split concrete.
| Aspect | EDI (e.g. EDIFACT) | MSV3 | REST API |
|---|---|---|---|
| Scope | Broad family of business documents | Pharmacy to wholesaler availability and ordering | General technical integration style |
| Orientation | Document and message oriented | Domain specific web service | Resource oriented |
| Timing | Often batch or message based | Real time query and response | Real time request and response |
| Typical content | Orders, invoices, dispatch notes | Availability query, order, status | Whatever the API exposes |
| Standardised by | UN/CEFACT (EDIFACT), ISO 9735 | DAV, PHAGRO and ADAS | No single body, per provider |
In short, MSV3 is the specialised standard for one pharmaceutical process, the real time availability check and order between a pharmacy and a wholesaler, and the MSV3 entry covers its client and server roles in detail. EDI is the wider family that also carries the invoice, the dispatch note and the customs declaration that follow. A REST API says nothing about pharmaceutical ordering on its own; it is simply a modern way for systems to talk. The three are complementary rather than competing, and a single integration often uses more than one.
An order to invoice cycle over EDIFACT runs as a sequence of structured messages, each read automatically by the receiving system.
pharmazie.com does not present itself as an EDIFACT invoicing engine. What it provides are the integration options that let its pharmaceutical data flow into the systems where an EDI style workflow already runs.
One honest limitation: EDI and EDIFACT are general business document standards, not a native pharmazie.com module. The platform supplies pharmaceutical data through its API, web services and file feeds, which is what most integration projects actually need, but it does not itself act as your EDIFACT clearing centre for invoicing. That part stays with your ERP or your EDI provider.
