Accepted formats

Start with whatever your accounting or ERP system can export. As long as the data is present, we can generate a Czech PDK delivery note from it; mapping to the gateway input is on us during onboarding. Below are the formats we commonly encounter. For new integrations without an established export, our canonical pdk-conversion-delivery-note (JSON / XML) with a public schema and examples is available.

Commonly encountered formats

Most suppliers have some machine-readable output in their accounting, ERP or EDI middleware. Send us a sample during onboarding and we will handle the mapping to the gateway input. Below are typical groups of formats and systems.

International standards

SAP IDoc – DELVRY (DELVRY03 / DELVRY05 / DELVRY06): SAP-specific container for delivery advice. Header E1EDL20 (document number, shipping point, sales organization, weights, package count, Incoterms), items E1EDL24 (material, batch, delivered quantity), partners E1ADRM1. Available in fixed-length and XML variants.
ISDOC: Czech national standard for electronic documents maintained by the Czech Ministry of the Interior (current version 6.0.2). Defines an XML schema for tax and non-tax documents; files have a .isdoc extension, archives with attachments .isdocx, optionally PDF/A-3 with embedded XML. Because it carries prices and VAT at item level, it covers most of the fields a PDK delivery note requires; some supplier ISDOC profiles serve directly as a delivery note.
EDI messages — DESADV (eASN / ASN), INVOIC, ORDERS: Despatch advice, invoice and purchase order under the UN/EDIFACT standard, commonly in the GS1 EANCOM subset. We also process them in XML, including the profiles of the ORION (GRIT) communicator, which unlike generic EDIFACT carry prices, VAT, batch and expiry as well. Details and field coverage on the separate EDI page.

Accounting / ERP exports (XML, XLSX, CSV)

SAP (S/4 HANA, Business One): In addition to the native IDoc channel we also process plain XML / CSV exports from reports. Useful for suppliers without a full EDI link.
Helios (Inuvio, Nephrite – Asseco Solutions): Czech ERP with a long market history (Inuvio for mid-sized companies, Nephrite for large ones). Standard input is XML / CSV exports — fields are mapped per installation.
Money S3 / S5 (Solitea): Solitea accounting and ERP suite (formerly Cígler Software); S3 for smaller companies, S5 for mid and larger ones. Standard XML / CSV exports cover header and items.
Byznys ERP (Seyfor / J.K.R.): Czech ERP focused on production, warehousing, finance and project management (35+ years on the market, thousands of customers). Exports typically arrive as XML / CSV.
Premier System: Czech information and accounting system covering small and larger companies (4,800+ customers). Standardly handled via XML / CSV exports from the warehouse / invoicing module.
Pohoda (Stormware): Widely used Czech accounting application for smaller companies. Suppliers typically export documents as XML — the Pohoda XML schema is mapped to the gateway's canonical input.
Servant: Czech logistics and fulfillment provider (warehousing and distribution with its own warehouse system / WMS, on the market since 1990) — not an accounting system. For suppliers who store and ship through Servant, we process CSV exports from its warehouse system; they carry the item, quantity, batch, expiry and EAN.
Custom outputs and other systems: For customers without the systems listed above (or with a custom solution) we design the mapping individually. In edge cases we recommend deploying the canonical pdk-conversion-delivery-note format directly (see below).

Specification of data required for PDK export

The data we need in order to issue a PDK delivery note is described in the schema below. For new integrations whose customer system has no established export, the gateway can be driven directly by this canonical input — JSON or XML with a strict structure. The schema is identical in both variants; XML adds an XSD for toolchains that prefer it.

Downloads

JSON Schema (Draft 2020-12): pdk-conversion-delivery-note.schema.json
XSD (XML Schema 1.0): pdk-conversion-delivery-note.xsd
JSON example: pdk-conversion-delivery-note.example.json
XML example: pdk-conversion-delivery-note.example.xml

Payload structure

Section / field	Meaning	Requirement
Party identification
`supplier.code`	Supplier identifier (Company ID or an agreed identifier).	required
`recipient.internalId`	Stable internal ID of the recipient in the supplier's records.	required
`recipient.nationalCode`	Recipient's Company ID (8 digits).	required
`recipient.name`	Recipient name.	required
`recipient.email`	E-mail for delivery notifications.	required
Document header
`deliveryNoteNumber`	Delivery-note number in the supplier's namespace.	required
`orderNumber`	Recipient's order number.	optional
`dateOfIssue`	Date of issue.	required
`dateOfDelivery`	Date of delivery (if it differs from the issue date).	optional
`deliveryPlace`	Delivery place (department, pavilion).	optional
`totalPriceWithoutTax`	Total document price excluding VAT.	required
`totalPriceWithTax`	Total document price including VAT.	required
Items (`items[]`)
`pdkCode`	PDK code (official from PharmData or an agreed catalog code).	required
`name`	Product name.	optional
`quantity`	Quantity (pieces).	required
`unitPriceWithoutTax`	Unit price excluding VAT.	required
`unitPriceWithTax`	Unit price including VAT.	required
`vatRate`	VAT rate (e.g. 12, 21).	required
`batchCode`	Product batch.	conditional
`expirationDate`	Expiry date.	conditional
`barcode`	EAN / GTIN.	optional
`udiCode`	UDI (required for medical devices under EU MDR).	conditional

Exact regular expressions, ranges and additional descriptions are in the JSON Schema (primary source of truth; the XSD mirrors it 1:1 for XML).

Output formats

The input document is one side of the job; the other is the format the particular recipient expects. That is chosen per recipient rather than per supplier, so one input file may end up in different outputs depending on who receives it.

PDK delivery note: The PharmData standard and the principal format for electronic delivery notes in Czech healthcare. We cover versions 7 to 21, from the 2008 revision to the version effective 1 January 2026; the version is dictated by what the recipient's system accepts. Newer versions add, among other things, UDI (from version 19), special trade surcharges under § 77g of the Czech Medicines Act, and the EUDR reference number.
Lekis DL and Lekis XML: The delivery-note interfaces of Lekis, a pharmacy system widely used in the Czech Republic including hospital pharmacies. We support the fixed-length DL6 and DL7 formats and the current Lekis XML v4, which is the only one in this family that carries UDI. Delivered by e-mail.
ADC / NR SYS (Slovakia): The Slovak counterpart of PDK, using ŠÚKL SR codes. It is not compatible with the PDK standard and is handled as a separate output.

Delivery channels to the recipient

The issued file is delivered to the recipient automatically. In addition to standard channels — MEDIDATA e-kurýr (also written eKurýr), delivery API gates, shared storage and e-mail — we support recipient-specific solutions on demand.