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

EDIFACT DESADV (eASN / ASN): Global EDI standard Despatch Advice — the EDIFACT-formatted variant of an Advanced Shipping Notice (ASN) — maintained by UN/CEFACT (release D.96B – D21A and others). Delivery advice to the recipient with details about the shipment, items and packaging. Typically transferred over EDI VAN or AS2.
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. Some supplier ISDOC profiles also cover delivery notes.

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 invoicing / accounting system. For suppliers with lower volumes or specific workflows we handle CSV / XML exports.
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).

Delivery channels to the recipient

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