EDI Order Parser (X12 850 and EDIFACT ORDERS to JSON/CSV) avatar

EDI Order Parser (X12 850 and EDIFACT ORDERS to JSON/CSV)

Pricing

Pay per usage

Go to Apify Store
EDI Order Parser (X12 850 and EDIFACT ORDERS to JSON/CSV)

EDI Order Parser (X12 850 and EDIFACT ORDERS to JSON/CSV)

Parses X12 850 purchase orders and UN/EDIFACT ORDERS messages into plain JSON and CSV, with a per-message check of envelopes, control numbers, segment counts, required segments, dates and numbers. No EDI software needed.

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Jack Valmadre

Jack Valmadre

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

11 hours ago

Last modified

Share

Turn EDI purchase orders into data you can use without EDI software. Give the actor ANSI X12 850 purchase orders or UN/EDIFACT ORDERS messages (paste them, link them, or upload them to a key-value store) and get:

  • one dataset row per message with the order mapped to plain JSON: order number, dates, parties and addresses, references, currency, and every line item with IDs, description, quantity, unit and price;
  • orders.csv: one row per order line, ready for a spreadsheet or an import into your ERP or accounting system;
  • a structural check of every message (errors and warnings with segment, position and element), plus a Markdown report per file.

The standard is detected automatically. Delimiters are read from the ISA segment (X12) or the UNA segment (EDIFACT, with the default :+.? ' when UNA is absent); the EDIFACT release character is handled. One file can hold several interchanges, groups and messages.

What it checks

X12 envelopes (any transaction set)

  • ISA is 16 elements and 106 characters, each element at its fixed width; ISA09 date, ISA10 time, ISA12 version and ISA13 control number are well formed; ISA14 is 0 or 1; ISA15 is P or T (warning otherwise).
  • GS has 8 elements, a valid date (CCYYMMDD from version 004 on) and time, a 1-9 digit control number.
  • ST02 is 4-9 characters; SE01 equals the real segment count and SE02 matches ST02; GE01 equals the number of transaction sets and GE02 matches GS06; IEA01 equals the number of groups and IEA02 matches ISA13.
  • Missing trailers, stray segments outside a transaction set, and an 850 sent in a group other than PO.

X12 850 purchase orders

  • BEG present and first, with purpose code, order type, PO number and a valid date.
  • At least one PO1; quantity and unit price are numbers; a unit is given with a quantity; product ID qualifiers and values come in pairs.
  • CTT01 equals the number of PO1 lines; CTT02 hash total compared with the sum of quantities (warning).
  • For version 004010, a few element lengths published in public implementation guides (BEG03, PO101-PO104, N102, N104, REF02, CTT01, PID05) (warnings).

EDIFACT envelopes (any message type)

  • UNB syntax identifier and version, sender and recipient, date and time, control reference; UNG/UNE group reference.
  • UNH message reference and message identifier (type, version, release, agency); UNT segment count equals the real count and UNT reference matches UNH; UNE and UNZ counts and references match.
  • Characters outside the UNOA or UNOB character set declared in UNB (warning).

EDIFACT ORDERS

  • BGM present and directly after UNH; at least one header DTM; UNS+S present; LIN not after UNS.
  • DTM values match their format code (101, 102, 203, 204); QTY, PRI and MOA values are numbers; NAD has a party function.
  • CNT+2 line count equals the number of LIN segments; lines without a quantity (warning).
  • A few data element lengths from the UN/EDIFACT D.96A directory (warnings; later directories allow some longer values).

Each message gets a result: pass, pass-with-warnings or fail.

What it does not do

  • It does not check your trading partner's own implementation guide (their required segments, code values or business rules). It checks the envelope structure and the openly documented basics listed above. Code lists (qualifiers, units, party codes) are not validated.
  • Other document types (invoices, ship notices, etc.) are read and their envelopes checked, but only 850 and ORDERS are mapped; turn on Include raw segments to get every segment of any message as JSON.
  • It does not send or receive EDI (no AS2, VAN or SFTP) and does not create acknowledgements (997/CONTRL).

This actor does not certify that a message complies with any standard, guideline or trading-partner requirement. It runs a fixed list of automated checks and can miss problems. Check the mapped data before you ship goods or send invoices based on it.

Input

FieldWhat to put there
EDI files (pasted)A list of {"name": "...", "text": "..."} objects or plain strings
File URLsLinks to EDI files reachable without a login
Key-value storeA store in your account with uploaded EDI files (all records, or only the keys you list)
Include raw segmentsAdds every segment of each message to its dataset row
Maximum file size (MB)Applies to pasted text, URLs and key-value store records; larger files are reported as load failures (default 10, maximum 20)

Output

Dataset row (one per message), shortened:

{
"file": "po-1001.edi", "status": "parsed", "standard": "X12", "messageType": "850",
"messageControlNumber": "0001", "version": "004010", "sender": "BUYER", "receiver": "SUPPLIER",
"conformance": "fail", "errors": 1, "warnings": 0,
"issues": [{"severity": "error", "code": "se-count", "segment": "SE", "position": 9, "element": "SE01",
"message": "SE01 says 8 segments; the transaction set has 7 (ST to SE inclusive)."}],
"order": {"orderNumber": "PO-1001", "orderDate": "20260901",
"parties": [{"role": "ST", "name": "EXAMPLE STORE 12", "idQualifier": "92", "id": "0012"}],
"lines": [{"lineNumber": "1", "quantity": "24", "unit": "EA", "unitPrice": "3.50",
"productIds": [{"qualifier": "VN", "id": "SKU-100"}, {"qualifier": "UP", "id": "012345678905"}],
"description": "BLUE MUG"}]}
}

Key-value store: orders.csv (all order lines), OUTPUT (run summary per file, including the list of CSV keys) and NNN-<file>.report.md (issues per message). If the order lines exceed about 25 MB of CSV, they continue in orders-2.csv, orders-3.csv and so on, each with its own header row.

Limits and memory

Files are parsed one message at a time, so memory depends mostly on the largest single file, not on how many files you give (up to 1,000 per run).

  • About 10 MB of file per 256 MB of run memory. Measured on the Apify platform at the default 256 MB: a generated 10 MB X12 file of about 6,100 ordinary orders (20 line items each) peaked at 122 MB and stayed flat through the run. Parsing alone (measured outside the platform) peaked at about 40 MB (X12) and 65 MB (EDIFACT) for 10 MB files and about 60 MB and 105 MB for 20 MB files.
  • The default 256 MB handles files up to the default 10 MB limit. For files up to the 20 MB maximum, set the run memory to 512 MB.
  • A single message with more than 40,000 segments (about 20,000 X12 line items or 10,000 EDIFACT line items) is checked for envelope structure only and not mapped; its row carries a message-too-large warning. This keeps memory bounded for unusually large orders.
  • A dataset row is limited to 9 MB by the platform. If a row would be larger (usually only with Include raw segments), the raw segments are left out and then order lines are trimmed in that row (linesTruncated says how many); every line is still in orders.csv.

Values are kept as they appear in the file (text), so nothing is lost to number or date conversion.

Privacy

The actor reads only the files you give it and writes results to your own Apify storage. Purchase orders can contain names and addresses of businesses and contacts; they are not sent anywhere else.

Support

Open an issue on the actor's Issues tab. This actor is built and maintained with AI assistance by Madrasco; a human owner can be reached on request through the Issues tab.