Flxpoint Parser Rules — Authoritative Reference

This page documents the Flxpoint parser's actual behavior. It is the authoritative source for what Flxpoint accepts, rejects, or quietly ignores.

Use this page to answer the two most common partner questions:

1. "Will Flxpoint accept my file?"
2. "Is this rule a generic X12 requirement or a Flxpoint-specific one?"

---

1. Envelope Layer (ISA / GS / ST)

Envelope validation is delegated to the core EDI library. Flxpoint's Accept vs. Reject behavior on envelope fields is as follows:

Supported Versions (GS08 / ISA12)

Hard rejection on version strings only happens when the segment structure itself fails to parse — not the version literal.

ISA06 / ISA08 — Sender / Receiver IDs

• Must be exactly 15 characters, right-padded with spaces when the ID is shorter.
• Missing padding → the internal parser fails to find the segment terminator → hard reject.

GS01 — Functional Identifier Code

GS01 for the 855 is PR per every authoritative spec (CHSPEC_855_4010, Palmetto, AmerisourceBergen, and the Confluence EDI V2 page). The production parser does not actually validate GS01 for the 855, so it never rejects on it; Flxpector treats GS01 as informational for the 855 and accepts PR or AD. A GS01/ST01 mismatch for the other transaction types is a hard reject.

Control Numbers

• ISA13 must be unique within a 24-hour window from the same Sender ID. Duplicate ISA13 from the same sender is rejected.
• GS06 ↔ GE02 must match; mismatch is rejected.
• ST02 ↔ SE02 must match; mismatch is rejected.

ISA15 — Usage Indicator

• T (Test) and P (Production) are both processed.
• Test files are badged in the Flxpoint UI as "Test Mode" to prevent accidental real-world fulfillment.

---

2. 997 Functional Acknowledgement

Flxpoint treats 997 as an acknowledgement only. The payload is not run through content validation. Flxpector mirrors this — it parses the envelope but does not enforce a content schema on 997.

---

3. 832 Price / Sales Catalog (GIP)

As of mid-2026 the 832 is a supported catalog-import document ("GIP" — Get Inventory & Price). It is built first for pharma sources (AmerisourceBergen, Kinray) and is rolling out on Standard EDI V2. It decouples catalog data (SKUs, descriptions, pricing) from the live-quantity 846 feed.

Defined segment structure:

CTP price-type qualifiers (CTP02): AWP (Average Wholesale Price), CON (Contract), LPR (List), WHL (Wholesale), RTL (Retail), MSR (MSRP). These are industry/pharma-specific.

CTP03 price handling (per Concept One GIS, mid-2026):

• Blank CTP03 → the item is kept and its quantity is updated; the price is simply not saved (it does not skip/archive the item).
• Invalid (non-numeric) CTP03 → Invalid CTP03 value: CTP03 (price) must be numeric → the item errors and is skipped.

---

4. Enum Whitelists

These are the exact values the parser checks against. When the inspector says "invalid ___", partners can use this table to pick a valid value.

SCAC Codes (TD503)

• Flxpoint does not maintain an exhaustive list. New carriers are added constantly.
• Validation is format-only: 2 to 4 alphanumeric characters (e.g. UPSN, FDXE, USPS).
• Flxpector warns when a SCAC is not in the common-carrier list, but the file still processes.

DTM Qualifiers (DTM01)

856 (inbound ASN dates):

850 (outbound PO dates — Send Fulfillment Requests, live May 2026): mappable per-template. 001 (Cancel After) is always sent (defaults to order date + 7 days when unmapped); 002 (Delivery Requested), 010 (Requested Ship), 037 (Ship Not Before), 038 (Ship No Later), 063 (Do Not Deliver After) are sent only when their field is mapped.

Unit of Measure — 850 PO103 (outbound)

Defaults to EA (Each). Configurable per Send-FR template to other unit codes (e.g. CA Case, CT Carton); falls back to EA when unmapped. Existing EA mappings are unaffected.

ACK01 — 855 Line Item Status Codes

Verified against the production parser (dmx-core EdiGetPOAcknowledgements) + the Confluence "Flxpoint Standard EDI V2" status-determination logic (May 2026). The parser does not hard-reject on ACK01 — meaning is resolved at the process layer by two lists:

Any code in neither list is a silent no-op (line neither acknowledged nor canceled). Note R2/R4 are valid (cancel) — they are not errors.

There is no ACK01 whitelist. The base class (EdiGetPOAcknowledgements) maps only the 4 cancel codes above (IR/R1/R2/R4); everything else is left unmapped, not rejected. Vendors routinely send a much broader set — RSR EDI alone sends ~25 codes including ROS, IB, CC, R3, R7 (INT-56691, Fernando's dmx-core eval, Jun 2026). Flxpector therefore does not validate ACK01 against an allowed-values list — doing so would false-positive on those legitimate vendor codes (same class as the N103=ZZ false positive). Only structural checks apply (2-char ID, present). When a partner needs a human-readable cancel reason, the vendor-specific parser can map its full code set and write it to an FR-item custom field (CancellationReason = "{CODE} - {description}", shipped for RSR via INT-56691).

Vendor variants (custom parsers, not generic): Kinray & AmerisourceBergen add IS = Accepted with Substitution (substitute identifiers ride in later ACK positions, ACK07/08–ACK13/14, qualifiers ND/N4/VC/VN/UP); AmerisourceBergen treats IW (On Hold) as accepted. IB (Backordered) is not supported by the generic parser or Kinray. The generic parser reads only ACK01 + ACK02 from the ACK segment; product identifiers come from PO1. A cross-dock PO's 855 ack is idempotent — once saved it can't be re-saved (Acknowledged quantity can't be greater than total quantity), and the PO stays in "Processed" status.

PO1 product qualifiers (855)

The generic Standard parser is strict positional and throws on a mismatch: SK@PO106, BP@PO108, EN@PO110, MG@PO112, UP@PO114, VP@PO116 (value in the following element). Pharma vendors (Kinray, AmerisourceBergen) use VN at PO106 via custom parsers; other vendors vary (Medline/McKesson VC/VN/VP, RSR positional).

SAC02 — 810 Service / Allowance / Charge Codes

Any other SAC code (e.g. AFEE, G740, H750) will be flagged by Flxpector as "may not be processed".

---

5. X12-Standard vs. FLX-Custom Rules

When a partner argues "my file is X12 compliant", these are the rows where Flxpoint diverges from the industry standard. Everything else in the inspector is generic X12 syntax.

Flxpector tags every validation finding with this provenance so the UI can badge FLX-Custom rules distinctly.

---

6. Unmapped Segments & Loops

The Flxpoint parser maps a specific set of segments per transaction type. Any segment or loop it does not map is surfaced in the UI Parsing Error column as:

• Unmapped segments found in transaction: S: <SEG> — e.g. S: CTT, S: I PMG, S: LS, S: PID
• Unmapped loops found in transaction: L: <LOOP> — e.g. an unmapped N1 loop in an 810

Support agents reject files on these messages even when the row otherwise processed, so Flxpector mirrors the UI, not the parser internals. Known cases:

CTT count validation (when CTT is mapped)

---

---

Last reviewed by the Flxpoint Integrations team.