EDI

If you already exchange EDI messages with your customers, there is no reason to build a second channel for delivery notes into Czech healthcare. We take the message in the form you send it today and produce the output format the recipient expects.

Messages we work with

EDI is the umbrella term. The message syntax is defined by the UN/EDIFACT standard maintained by UN/CEFACT; trade and logistics most often use its GS1 subset EANCOM, or XML variants such as GS1 XML or a particular communicator's own profiles. The message names — ORDERS, DESADV, INVOIC — stay the same whichever form they arrive in, and so does what we need to read out of them.

DESADV – despatch advice
The UN/EDIFACT Despatch Advice, the closest EDI counterpart of a delivery note. In its generic form it carries logistics without prices or VAT, so on its own it is not enough for a PDK delivery note and has to be paired with the corresponding tax document. The Czech XML profiles (see ORION below) extend it with unit prices, VAT rate, batch and expiry — from such a message we can issue the delivery note directly.
INVOIC – invoice
The UN/EDIFACT EDI invoice. It carries prices and VAT at line level plus a recapitulation per rate, which covers everything a delivery-note header needs. It typically arrives over the same channel as DESADV and can be paired with it into a single delivery.
ORDERS – purchase order
An order sent by the customer to the supplier. We process it as an input — see Electronic orders.

ORION (GRIT)

A Czech EDI platform operated by GRIT, used by many medical-supply distributors to communicate with their customers. We work with its version 3 XML profiles (DESADV, INVOIC, ORDERS) — so not EDIFACT syntax, but XML carrying the same messages; the GRIT documentation refers back to the EDIFACT code lists. Unlike generic EDIFACT, these profiles carry the data a Czech PDK delivery note requires:

  • Batch and expiry — batch_number, expiry_date, optionally best_before_date.
  • Prices and VAT — unit price excluding and including VAT (price, price_inc_vat) and the rate (vat_rate); the invoice adds a recapitulation per tax group.
  • Retail price — price_retail, the field the Lekis DL interface requires and which the PDK input itself does not carry.
  • Product identification — GTIN, supplier code and buyer code.

Transport

We are not prescriptive about how the messages reach us. We can take the files from an EDI VAN or AS2 link, from shared storage, by e-mail, or through a direct call to the API gateway. What matters is the content of the message, not the route it travels.

How the integration runs

  • Send us a sample of a real message — one is usually enough.
  • We check which fields it carries and what, if anything, is missing; mapping to the gateway input is on us.
  • We deploy, test against the specific recipient and hand it over to operation.

The fields we need in order to issue a delivery note are listed under Accepted formats.

Sign up