Etlworks ships a generic EDI format that covers the EDI dialects without a dedicated connector. This article is the reference for those dialects: EDIFACT, NCPDP, and VDA. For X12 use the dedicated Working with X12; for HL7 use Working with HL7.
Status: the generic EDI format currently supports reading EDI messages (parse to JSON / XML / CSV, load into a database). Writing — generating EDIFACT / NCPDP / VDA messages from a source dataset — is on the roadmap and not yet available.
Which EDI format should I use?
Etlworks exposes four EDI format types in the format gallery. Pick by dialect:
| Format type | Dialects it covers | Read | Write | Article |
|---|---|---|---|---|
| X12 | X12 | Yes | Yes | Working with X12 |
| HL7 2.x | HL7 2.x | Yes | Yes | Working with HL7 |
| HL7 FHIR | HL7 FHIR | Yes | Yes | Working with HL7 |
| EDI (generic) | EDIFACT, NCPDP, VDA (and X12 / HL7 for backward compatibility) | Yes | Not yet | This article |
The generic EDI format technically also supports X12 and HL7 dialects, but the dedicated X12 and HL7 formats are the preferred choice for those — they're tuned for the dialect and include writing support. Use the generic EDI format when the dialect is EDIFACT, NCPDP, or VDA.
Note: The generic EDI format is a premium format.
The dialects covered by this article
EDIFACT
UN/EDIFACT is the international EDI standard maintained by the United Nations — the European-and-rest-of-world counterpart to X12. It's heavily used in trade, transport, customs, finance, and healthcare outside North America. Common message types: ORDERS (purchase order), INVOIC (invoice), DESADV (despatch advice), ORDRSP (order response), IFTMIN (transport instruction), CUSDEC (customs declaration).
EDIFACT messages are framed by UNB / UNZ (Interchange) and UNH / UNT (Message) envelopes — the EDIFACT equivalents of X12's ISA/IEA and ST/SE. Functional groups (UNG/UNE) are optional and less common than in X12.
NCPDP
NCPDP (National Council for Prescription Drug Programs) is the US standard for retail pharmacy and prescription drug electronic transactions. The Telecom Standard handles real-time pharmacy claims, eligibility checks, prior authorizations, and reversals. NCPDP SCRIPT covers electronic prescribing. NCPDP messages are tightly delimited and use their own segment/element model distinct from both X12 and EDIFACT.
VDA
VDA (Verband der Automobilindustrie) is the German automotive industry's EDI standard. VDA recommendations cover delivery instructions (VDA 4905), advance shipment notifications (VDA 4913), invoices (VDA 4906), and many other transaction types used by VW, BMW, Mercedes, Audi, and their tier-1 / tier-2 suppliers. VDA pre-dates EDIFACT (which is why it exists as a separate standard) and remains in active use across the German auto supply chain.
The generic EDI format
Create a format in Connections → Formats and pick EDI. The configuration mirrors the X12 format but the first required field is the dialect.
| Setting | What it does |
|---|---|
| EDI dialect (required) | x12, edifact, hl7, ncpdp, or vda. Picks the parser and the schema namespace. |
| Version | Dialect release — e.g., EDIFACT D.96A, D.01B, D.18A; NCPDP D.0, vD; VDA 4905 / 4913 / etc. |
| Message type | For inbound parsing, the expected message (ORDERS, INVOIC, DESADV, …). Optional — the parser reads the message header itself. |
| Schema path | Override the default schema location. Use only when running offline or pinning to a specific schema patch. |
| Output format | How the parsed EDI is exposed: XML (best for nested mapping), JSON, or CSV (flat, segment-per-row). |
| Strict validation | Reject messages that don't conform to the schema. |
| Use long names | Use human-readable segment / element names in the parsed output. |
| Delimiters | Override the segment / element / sub-element separators. EDIFACT declares these in the UNA segment; override only when a partner uses non-standard delimiters that aren't declared correctly. |
| Acknowledgment File Name | Enables automatic acknowledgment generation on inbound (997 for X12 dialect, CONTRL for EDIFACT). See Acknowledgments. |
Read EDI messages
For loading parsed EDI into a database, use a regular ETL flow with the EDI format on the source side and the nested mapping editor for the structure. The mechanics are the same as X12 — see Read X12 with visual mapping for the step-by-step. The only difference is the format type and the dialect selector.
Three sub-patterns are available, same as X12:
- Nested mapping — preserves the EDI hierarchy. Use when the destination handles nested data (JSON, Parquet, Avro, MongoDB) or when you want to load multiple segments into linked tables in one pass.
- Flat mapping — targets one segment type at a time. Use a source query like SELECT * FROM NAD (EDIFACT name-and-address segment) to extract just that segment across a batch.
- Staging tables — full normalization into one table per segment / subsegment. Use Automatically create staging tables from any data source.
Transform with JavaScript or Python
For transformations that don't fit mapping — conditional segment handling, multi-message routing, custom code-list lookups — transform the parsed EDI dataset in a JavaScript / Python flow and let a downstream step write the result. The parser exposes the EDI message as a nested dataset; the same scripting hooks used for X12 work here.
Acknowledgments
The generic EDI format generates an acknowledgment automatically when reading an inbound message. The acknowledgment type follows the dialect:
- EDIFACT → CONTRL (control message).
- X12 dialect (when used via the generic format) → 997 functional acknowledgment.
- NCPDP and VDA use their own acknowledgment models; check your trading partner agreement.
Enable by setting Acknowledgment File Name on the format:
- The acknowledgment file is written to the connection attached to the flow.
- Use the {app.data} token to point at the server-storage home folder, e.g., {app.data}/ack/contrl_{filename}.edi.
- The name can be dynamic via global variables.
- The generic EDI format exposes additional per-acknowledgment parameters; see the format reference.
Transport: AS2, SFTP, HTTP, email
Transport is decoupled from format. EDIFACT, NCPDP, and VDA messages move over the same set of transports as X12:
- AS2 — secure point-to-point with MDN. Common for EDIFACT with European partners. See Working with X12 → AS2 send and receive for full setup — the AS2 connector is dialect-agnostic; only the format on the flow changes.
- SFTP / FTPS / FTP — classic VAN-style file drops. Still common for VDA in the German automotive supply chain.
- HTTP / HTTPS — direct POST to a partner endpoint. Common for NCPDP real-time pharmacy claims.
- Inbound / outbound email — EDI as a body or attachment.
Handling processed files
Inbound file disposition (delete / skip / move) is identical to X12. See Working with X12 → Handling processed files.
Notes and limitations
- Generating EDIFACT / NCPDP / VDA from a source is not yet supported. Writing support is on the roadmap. For now, this article covers the read direction only.
- The generic EDI format technically supports the x12 and hl7 dialects too, but for those use the dedicated X12 / HL7 formats — they're tuned and include writing.
- The generic EDI format is best suited for files up to ~100 KB. For large X12 documents prefer the dedicated X12 format (handles up to ~100 MB).
- Validation strictness on EDIFACT depends on the schema patch (D.96A vs D.18A); pin the version explicitly on the format to avoid surprises.
- VDA versions evolve more slowly than EDIFACT; specify the VDA transaction number (4905, 4913, …) precisely on the format.
Related articles
- Get started with EDI documents — the dialect-agnostic umbrella.
- Working with X12 — the dedicated X12 article (shared mechanics for transport and file handling).
- Working with HL7 — HL7 2.x and FHIR.
- Nested mapping — the mapping mechanism EDI work uses end-to-end.