# Flxpoint EDI Help Center, complete documentation > The public EDI specifications for Flxpoint: 15 documents covering the X12 > 004010VICS transactions Flxpoint exchanges with suppliers and retailers. Flxpoint is a > retail operations platform for multi-channel ecommerce, dropship automation and order > management. - Human documentation: https://www.edihelpcenter.flxpoint.com/docs - Free EDI file validator: https://www.edihelpcenter.flxpoint.com/flxpector - Generated from the same documents the site renders, so it matches the pages exactly. --- # Common EDI Errors Source: https://www.edihelpcenter.flxpoint.com/docs/errors Last updated: 2026-09-02 # Common EDI Errors & Troubleshooting ## Top Failure Reasons ### 1. Missing Shipping Provider (856) **Error**: TD5 segment missing or incomplete **Fix**: Always include TD502=`2`, TD503=SCAC code (e.g. `UPSN`), TD512=service level **Impact**: Fails validation and FLX processing ### 2. Mismatched Product Codes **Error**: SKU/UPC/EAN in 856 or 810 doesn't match what was sent in the 850 **Fix**: Return the EXACT same product identifiers from the original 850 **Impact**: FLX cannot update order status or process invoice **Real case (810, recurring):** a marketplace channel rejected a batch of a vendor invoices because the SKU in the 810 `IT1` line (`IT106=SK` / `IT107`) didn't match the SKU on the original PO line — e.g. `IT1*1*1*EA*18.00**SK*SS-NBAF-NYK-Ci5*VN*…*UP*840501364061~`. The trading partner refuses the invoice (and may apply chargebacks) until it's corrected. Root cause is almost always a **missing or wrong entry in the outbound invoice/accounting mapping set**: an unmapped SKU comes through unchanged and no longer matches the PO. Fix the mapping so the correct `IT107` value is emitted, then re-sync the affected invoices. Map all of a partner's required SKUs before go-live to avoid a backlog of rejections. ### 3. Wrong PO Number **Error**: 856 or 810 references a PO number not matching any 850 **Fix**: Use PRF01 (856) or BIG04 (810) with exact PO number from BEG03 of 850 **Impact**: Transaction cannot be linked to order ### 4. Invoice Date Out of Range (810) **Error**: BIG01 date is in the future or more than 17 months old **Fix**: Use current or recent date in CCYYMMDD format **Impact**: Strict validators reject; FLX may also reject ### 5. Control Number Mismatch **Error**: SE02 ≠ ST02, GE02 ≠ GS06, or IEA02 ≠ ISA13 **Fix**: Ensure all trailer control numbers match their header counterparts **Impact**: Structural validation failure in both systems ### 6. TDS Implied Decimal Confusion (810) **Error**: Sending `12.00` instead of `1200` for $12.00 **Fix**: TDS uses implied 2 decimal places: multiply dollar amount by 100 **Impact**: Incorrect invoice total processed ### 7. IT1 Unit Price Format (810) **Error**: Using implied decimal for unit price (sending `1595` for $15.95) **Fix**: IT1 unit price does NOT use implied decimal: send `15.95` **Impact**: Incorrect line item pricing ### 8. Segment Count Wrong (SE01) **Error**: SE01 doesn't match actual segment count (including ST and SE) **Fix**: Count every segment from ST through SE inclusive **Impact**: Structural validation failure ### 9. ISA Field Padding **Error**: ISA06/ISA08 not padded to exactly 15 characters **Fix**: Right-pad with spaces to exactly 15 chars **Impact**: Strict validators may reject; FLX may still accept ### 10. Sending Both REF*CN and MAN*CP in 856 **Error**: Including tracking number at both Shipment (REF) and Pack (MAN) levels **Fix**: Choose ONE method — they are mutually exclusive **Impact**: Ambiguous tracking data ### 11. UPC/EAN Wrong Digit Count **Error**: UPC is not 12 digits or EAN is not 13 digits **Evidence**: 616 product-code support emails in 6 months. Leading zeros stripped from UPC is the #1 issue. **Fix**: UPC must be exactly 12 numeric digits (pad with leading zeros if needed). EAN must be exactly 13 digits. Check for spreadsheet/data-import stripping leading zeros. **Impact**: Product matching fails — shipment or invoice cannot link to order items ### 12. DTM Date Invalid **Error**: DTM02 is not valid CCYYMMDD format, or has impossible date (e.g., Feb 30) **Evidence**: 91 date-format emails, 43 body-pattern matches in 6 months **Fix**: Use CCYYMMDD format (e.g., 20260413). Validate month is 01-12, day is valid for that month. Feb has 28/29 days. **Impact**: Date parsing fails on the receiving side ### 13. N1/N102 Ship-To Name Too Long **Error**: N102 field exceeds 60-character maximum **Evidence**: PO# 111-4788281-4221863 rejected — "invalid N102 field. The ship-to name exceeds the maximum allowed length of 60 characters." (469 related support emails in 6 months) **Fix**: Truncate ship-to name to 60 characters. Also validate: N401 (city) <= 30 chars, N402 (state) = exactly 2 chars, N403 (zip) <= 15 chars. Flxpector auto-repair can truncate automatically. **Impact**: Hard rejection on 850, 856, 810 — file will not process (typical error: `TextParsingException: Length of parsed input`) ### 14. Invalid Segment Terminator (corrupted encoding, often on a Flxpoint 997) **Error**: Partner's translator says "segment separator qualifier is invalid"; every segment ends in `�`, `�` or `?` instead of `~`. Flxpector: `TOK-003 Invalid segment terminator` **Evidence**: Deflecto (Amazon 856 vendor) rejected Flxpoint's 997, #int-operator AID #70131, 2026-08-25. Before this rule Flxpector showed 11 unrelated errors on the file, and passed the single-character variant as Valid **Fix**: Use `~`. Flxpector's "Apply fix" rewrites every terminator in the file. If the file is a Flxpoint-generated 997, the partner cannot fix the cause: send it to support@flxpoint.com to be re-issued, and have the partner end their own segments with `~`, because the 997 inherits the terminator of the file it acknowledges. A raw control byte such as `0x85` is reported as a warning with the byte in hex **Impact**: The receiving system rejects the file outright. Flxpoint itself reads the inbound file (it maps the byte to `U+FFFD`), which is exactly what comes back in the 997 --- ## Transaction-Specific Gotchas ### 846 Inventory | Issue | Details | |-------|---------| | QTY=0 effect | Does NOT cancel existing pending orders | | LIN03 uniqueness | Must be unique across ALL items in the file | | Missing REF*IA | Must include FLX-assigned vendor number | | LIN without QTY | Every `LIN` must be followed by a `QTY`. Otherwise: `No QTY segment found to match LIN with SK*` — the inventory job aborts (FLX-846-006) | | Unmapped segments | `CTT`, custom `LS`/`I PMG` loops, etc. reject the **whole file** with `Unmapped segments found in transaction: S: ` and import zero items, wherever the segment sits. Remove them (adjusting `SE01`) or have the integration extend the mapping | ### 850 Purchase Order | Issue | Details | |-------|---------| | N9 customer order # | MUST be printed on packing slip | | TD5 service level | Supplier MUST use this shipping method | | DTM cancel-after | Default is 7 days after order date | | PID 80 char limit | Text over 80 characters is trimmed and excluded | | Postal code format | No hyphens or blanks in N403 | | N102 name max length | **60 characters max** — exceeding causes hard rejection (FLX-ALL-007) | ### 856 Ship Notice | Issue | Details | |-------|---------| | BSN05 hierarchy | Must be `0001` (S,O,P,I) or `0004` (S,O,I) | | N1*SF required | Ship-From with code 92 and FLX supplier number | | Item codes | LIN03 MUST match the 850 item codes exactly | | DTM time | Both date AND time required for shipped date | | N1 name length | N102 max 60 chars; N401 max 30; N402 = 2 chars; N403 max 15 (FLX-ALL-007) | ### 810 Invoice | Issue | Details | |-------|---------| | Ship first | Invoice only accepted for shipped items (856 before 810) | | REF*DP | Always `0000` — fixed value, mandatory | | SAC codes | Only `G821` (Shipping) supported by FLX | | ITD conditionals | Complex pairing rules for discount fields | | BIG04 | PO Number is REQUIRED (listed as M in FLX PDF) | | N1 name length | N102 max 60 chars; city max 30; state exactly 2; zip max 15 (FLX-ALL-007) | | a pharma distributor vs ABC party loops | a pharma distributor uses `N101=BY`/`N101=SE`; a pharma distributor uses `N101=RE`/`N101=ST`. a pharma distributor adds `TXI*TX` tax | ### 832 Catalog (GIP) | Issue | Details | |-------|---------| | Blank CTP03 price | Item is **kept**, quantity updates, price not saved (no longer skipped/archived as of mid-2026) | | Invalid CTP03 price | `Invalid CTP03 value: CTP03 (price) must be numeric` — item **is skipped**. Send a numeric price or omit the CTP | | LIN identifier priority | Matched as `VN`→`UP`→`ND`→`MG`→`SK`→`VC`→`EA`→`UN` | ### Outbound 850 (Send Fulfillment Request) | Issue | Details | |-------|---------| | REF2 vendor number length | Max **30 chars** (raised from 10 in May 2026). Older error `REF2 element value is greater then 10` no longer fires for IDs ≤ 30 | | Unit of measure (PO103) | Defaults to `EA`; map `CA`/`CT` in the Send-FR template when the vendor requires it | --- ## Supported EDI Versions For the full version-handling spec, see [Flxpoint Parser Rules](./09-flxpoint-parser-rules.md). | GS08 value | Flxpoint behavior | Flxpector finding | |-----------|-------------------|-------------------| | `004010VICS` | Preferred — matches VICS-specific segments cleanly | Clean | | `004010` (no VICS suffix) | Accepted — processes normally | Warning (not error). Auto-fix to `004010VICS` is offered, not required. | | `005010` | Accepted — processes normally | Warning. Auto-fix to `004010VICS` is offered if you want to standardize. | | Anything else | Processing depends on whether segment structure still parses | Warning with no safe auto-fix | | Wrong GS01 code | Must match transaction type | IB=846, PO=850, AD=855, SH=856, IN=810, FA=997, PI=832 | | Wrong ST01 code | Must match: 846, 850, 855, 856, 810, 832, or 997 | — | | ISA06/ISA08 not 15 chars | **Hard reject** — parser fails to find segment terminator | Error (format) | | Segment terminator is `U+FFFD` / `�` / a raw control byte | Inbound: accepted (byte becomes `U+FFFD` internally). Outbound 997: **inherits it**, so the partner rejects the 997 | Error TOK-003 (warning for a raw byte). "Apply fix" rewrites to `~` | | ISA13 duplicate in 24h window from same sender | **Hard reject** | Error (structural) | | GS06 ≠ GE02, or ST02 ≠ SE02 | **Hard reject** | Error (structural) | > **Note:** Some integrations may enforce stricter version requirements than the global parser (e.g., requiring `004010VICS` specifically). If your file fails with a version error, confirm with your Flxpoint integration contact whether a strict version is configured for your account. --- ## Flxpector vs FLX Processing Quick Reference | Scenario | Flxpector | FLX Processing | |----------|-----------|----------------| | Non-unique ISA control numbers | Warns | Accepts | | Extra segments (CTP, N2) | Passes | Ignores (no error) | | Non-G821 SAC codes | Warns | May not process | | Missing TD5 SCAC | Fails | Fails | | QTY as simple element | Passes | Accepts | | Loose field lengths | Fails | May accept | | N102 name > 60 chars | Fails (FLX-ALL-007) | Fails (hard rejection) | --- # EDI 810 — Invoice Source: https://www.edihelpcenter.flxpoint.com/docs/810 Last updated: 2026-09-02 # EDI 810 — Invoice ## Purpose Inform the Retailer of the cost the retailer must pay the supplier for a given order. Originates with the **Supplier**, sent to FLX, then Retailer gets it. ## How It Works The 810 is the bill. Once the supplier has shipped an order (confirmed via 856), they send an invoice telling the retailer how much is owed for which items. Flxpoint uses the 810 to reconcile the cost side of the order — matching it against the 850 line prices and the 856 shipment — and then passes it to the retailer's finance or accounting system. Because the 810 drives payment, every element has to be precise: the invoice total must equal the sum of line items plus freight minus allowances, the decimals must follow Flxpoint's implied-decimal convention (TDS and SAC amounts are cents), and the REF*DP department code is mandatory. An 810 that fails validation blocks the payment cycle for that order until the supplier fixes and resends it — which is why the FLX team tracks 810 rejections closely. ## Frequency Within 24 hours of shipment. Hourly recommended, daily minimum. ## Business Rules - Invoice data **only accepted for items that have been shipped** (856 must come first) - Must include PO number and UPC/EAN/SKU matching the original 850 - Retailer determines if invoices are for cost of goods only or include shipping/handling - If supplier ships on retailer's shipping account → no shipping/handling charges in invoice - Payment terms are between Retailer and Supplier — FLX does not set them - Invoice date should be current or within 17 months (spec guidance; the parser does not reject on date range) - TDS uses **implied decimals**: $12.00 → `1200` - IT1 unit price does NOT use implied decimals: $15.95 → `15.95` - **Invoice number goes in BIG02 OR in `REF*IV*`** — a blank BIG02 is fine when REF*IV carries it; neither present rejects the file (`No Invoice Number found in BIG segment or REF segment with REF01 = IV`) - **IT102 quantity must be a whole number** — a decimal like `2.0` rejects the file (`Quantity is expected in IT102 value`) - **SAC charges** — the complete production set: `G821` Shipping, `D240` Freight, `AFEE` Generic Fee, `G740` Service Charge, `H750` Sales Tax, `D500` Handling (all `SAC01=C`), and `C310` Discount (an **allowance**: `SAC01=A`, the amount subtracts). **Any other code — including `F050` — rejects the file** (`SAC01 code F050 not supported`; older spec versions wrongly listed F050 as valid). A wrong SAC01 for the code hits the same reject. SAC05 (amount) is required and always implied 2-decimal - **The 810 does not map party (N1) loops**, `FOB`, or `CUR` — they surface as `Unmapped loops/segments found in transaction`. Summary segments (`TXI`/`CAD`/`SAC`/`ISS`/`CTT`) must come **after** TDS - `REF*DP*0000` is in the FLX spec but the parser does not hard-enforce it (Flxpector shows a warning); CTT01 is never read on the 810 > **Tip — validate against your 850**: the inspector's "Cross-check with your 850" panel verifies the invoice's PO number (BIG04), item identifiers, and invoiced quantities against the original order before you send it. --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "IN") ST Transaction Set Header (ST01 = "810") BIG Beginning Segment for Invoice REF Reference Number - Department (DP, fixed "0000") REF Reference Number - Internal Vendor (IA) — Optional REF Reference Number - Invoice Number (IV) — Optional ITD Terms of Sale DTM Date/Time Reference (011 = Shipped) ┌─ IT1 Loop (repeats per line item) │ IT1 Baseline Item Data │ CTP Pricing Information (optional) │ SAC Service/Charge per item (optional) └─ TDS Total Monetary Value Summary CAD Carrier Detail (optional) ┌─ SAC Loop (summary level) │ SAC Service, Promotion, Allowance, or Charge └─ ┌─ ISS Loop (optional) │ ISS Invoice Shipment Summary └─ CTT Transaction Set Totals SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Overview | Segment | Name | FLX Status | Notes | |---------|------|------------|-------| | ST | Transaction Set Header | **Required** | ST01 = `810` | | BIG | Beginning Segment for Invoice | **Required** | Invoice date, invoice #, PO # | | REF (DP) | Department Number | **Required** | Fixed value `0000` | | REF (IA) | Internal Vendor # | Situational | FLX-assigned vendor number | | REF (IV) | Invoice Number | Situational | Vendor's invoice reference | | ITD | Terms of Sale | Situational | Payment terms | | DTM | Date/Time Reference | Situational | `011` = Ship date | | IT1 | Line Item Loop | **Required** | Repeats per invoiced item | | CTP | Pricing Information (per item) | **Not Used** | Generic X12 allows; FLX ignores per-item CTP | | SAC (detail) | Charge per Line Item | **Not Used** | Generic X12 allows; FLX ignores detail-level SAC | | TDS | Total Monetary Value | **Required** | Implied decimals: $12.00 → `1200` | | CAD | Carrier Detail | Situational | Service level + SCAC + tracking | | SAC (summary) | Charges/Allowances | Situational | Valid SAC02 codes: `G821` Shipping, `D240` Freight, `AFEE` Fee, `G740` Service, `H750` Tax, `D500` Handling (all `SAC01=C`) + `C310` Discount (`SAC01=A`). Anything else — including `F050` — is rejected. Source: [parser rules](../reference/09-flxpoint-parser-rules.md) | | ISS | Invoice Shipment Summary | Situational | Unit count + weight | | CTT | Transaction Totals | **Required** | Count of IT1 segments | | SE | Transaction Set Trailer | **Required** | | --- ## Pharma Vendor Variations Pharma distributors on customized integrations map the party loops differently from each other and from the standard. When onboarding a pharma 810 source, confirm with support which qualifiers the specific vendor uses: | Field | Distributor pattern A | Distributor pattern B | |-------|-----------------------|-----------------------| | Buyer party (N1) | `N101 = RE` (Remit-To) | `N101 = BY` (Buyer) | | Seller party (N1) | `N101 = ST` (Ship-To) | `N101 = SE` (Seller) | | Tax | — | `TXI*TX` segment carries tax amount (TXI02) | | Charges | `SAC*C*D240` (charges) | `SAC*C*D240` (`SAC15 = CHARGES`) | | Allowances | — | `SAC*A*A400` (`SAC15 = ALLOWANCES`) | Line-item identifiers in pattern A's IT1 loop: `IT106=UP` (UPC) / `IT108=ND` (NDC) / `IT110=VC` (Vendor Catalog). `IT103` unit of measure is `EA` / `CA` / `CT`. These are vendor-specific configurations — for your integration's exact layout, open a support ticket. --- ## Segment Specifications ### ST - Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `810` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, incremented by 1 | ### BIG - Beginning Segment for Invoice | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BIG01 | Invoice Date | 8 DT | M | CCYYMMDD. **No future dates. No dates >17 months old** | | BIG02 | Invoice Number | 10 AN | M | Assigned by sender | | BIG03 | PO Date | 8 DT | O | PO Date | | BIG04 | PO Number | 22 AN | M | **REQUIRED** — PO Number from 850 | ### REF - Department Number | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference Number Qualifier | 2 ID | M | `DP` (Department Number) | | REF02 | Reference Number | 10 AN | M | `0000` (fixed value) | ### REF - Internal Vendor Number (Optional) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference Number Qualifier | 2 ID | O | `IA` (Internal Vendor Number) | | REF02 | Reference Number | 10 AN | O | FLX Assigned Vendor/Supplier # | ### REF - Invoice Number (Optional) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference Number Qualifier | 2 ID | O | `IV` (Seller's Invoice Number) | | REF02 | Reference Number | 10 AN | O | Invoice number | ### ITD - Terms of Sale/Deferred Terms of Sale | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ITD01 | Terms Type Code | 2 ID | M | `01`=Basic, `02`=EOM, `05`=Discount N/A, `08`=Basic Discount Offered, `12`=10 Days After EOM | | ITD02 | Terms Basis Date Code | 1 ID | M | `3` (Invoice Date) | | ITD03 | Terms Discount Percent | 6 R | O | % discount if paid early | | ITD04 | Terms Discount Due Date | 8 DT | C | Date to qualify for discount. Conditional: required if ITD03 or ITD08 present | | ITD05 | Terms Discount Days Due | 3 N | C | Days from invoice for discounted payment | | ITD06 | Terms Net Due Date | 8 DT | M | Date invoice payment is due in full | | ITD07 | Terms Net Days | 3 N | M | Number of days until full amount due | | ITD08 | Terms Discount Amount | 8 R | C | Dollar amount of discount | | ITD13 | Day of Month | 3 N | C | For EOM codes (02, 12): days after EOM invoice is due | **Conditional Logic:** - If ITD03 (discount %) present → ITD04, ITD05, or ITD13 required - If ITD08 (discount $) present → ITD04, ITD05, or ITD13 required ### DTM - Date/Time Reference | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | DTM01 | Date/Time Qualifier | 3 ID | M | `011` (Shipped Date) | | DTM02 | Date | 8 DT | M | CCYYMMDD | ### IT1 - Baseline Item Data (Repeating Loop) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | IT101 | Assigned Identifier | 6 AN | O | Invoice line number | | IT102 | Quantity Invoiced | 6 R | M | Units shipped per line item | | IT103 | Unit of Measurement Code | 2 ID | M | `EA` (Each) | | IT104 | Unit Price | 8 R | M | Price per unit. **NO implied decimal**: $15.95 → `15.95`, $29.00 → `29` | | IT105 | Basis of Unit Price | 2 ID | M | `QT` (Quoted/Default), `LE` (Catalog Price per Each), `WE` (Wholesale per Each) | | IT106 | Prod/Serv ID Qualifier | 2 ID | M | `UP` (UPC), `EN` (EAN), `SK` (SKU), or `BP` (Buyer's Part Number) | | IT107 | Prod/Serv ID | 30 AN | M | **MUST match the SKU/UPC/EAN from the 850** | > **Not Used by FLX in IT1 Loop:** > - **CTP (Pricing Information)** — Generic X12 supports a `CTP` segment inside the IT1 loop for per-item price breakdowns. FLX does not process this segment — do not include it. > - **SAC (per line item)** — Generic X12 supports allowances and charges at the line-item level. FLX only reads the summary-level SAC segment (outside the IT1 loop) and only for code `G821` (outbound freight). ### TDS - Total Monetary Value Summary | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | TDS01 | Total Invoice Amount | 10 R | M | Total of invoice + charges - allowances. **Implied decimal**: $12.00 → `1200` | | TDS02 | Amount Subject to Terms Discount | 10 R | O | Amount eligible for discount. **Implied decimal** | ### CAD - Carrier Detail (Optional) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CAD01 | Transportation Method Type Code | 2 ID | O | See 850 TD512 codes (D3, ND, SC, SI, SP) | | CAD04 | Standard Carrier Alpha Code | 4 AN | M | If CAD sent, SCAC is required. If not available, don't send CAD | | CAD07 | Reference Number Qualifier | 2 ID | O | `BM` (Bill of Lading) or `CN` (Carrier's Reference/PRO) | | CAD08 | Reference Number | 7-22 AN | C | Required if CAD07 present | ### SAC - Service, Promotion, Allowance, or Charge (Shipping) — FLX PDF | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SAC01 | Allowance or Charge Indicator | 1 ID | O | Must be `C` (Charge) | | SAC02 | SAC Code | 4 ID | C | Must be `G821` (Shipping). **Other codes not supported in FLX PDF** | | SAC05 | Amount | 15 N | C | Total shipping charge. **Implied decimal**: $5.00 → `500` | ### SAC — Other Codes in X12 004010 (Not Used by FLX) | SAC02 Code | Description | |------------|-------------| | `AFEE` | Fee | | `C310` | Discount | | `D240` | Freight | | `G740` | Service Charge | | `G821` | Shipping | | `H750` | Tax - Sales Tax | **Note**: FLX only supports `G821` for shipping charges. Other SAC codes exist in the X12 standard but FLX does not process them. > **FLX only accepts SAC code `G821` (Outbound Freight) at summary level.** Detail-level SAC (inside the IT1 loop) is ignored. Other X12 examples show codes like `D240` (discount) — FLX does not process those. ### ISS - Invoice Shipment Summary (Optional) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ISS01 | Number of Units Shipped | 6 N | O | Total units shipped | | ISS02 | Unit of Measurement Code | 2 ID | C | `EA` (Each). Required if ISS01 present | | ISS03 | Weight | 8 R | O | Total weight of shipment | | ISS04 | Unit of Measurement Code | 2 ID | C | `LB` (Pound), `OZ` (Ounce), `50` (Kilograms). Required if ISS03 present | ### CTT - Transaction Set Totals | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CTT01 | Number of Line Items | 6 N | M | Count of IT1 segments | ### SE - Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Validation Notes ### FLX-Specific Requirements vs Generic X12 | Field | FLX Spec | Generic 004010 | Impact | |-------|----------|----------------|--------| | REF*DP | M (always "0000") | Optional | **FLX stricter — department number required** | | SAC codes | Whitelist: `G821`/`C310`/`D240`/`F050` | Broader X12 list (AFEE, G740, H750, etc.) | FLX processes only codes in the whitelist. `G821` remains the primary shipping code. | | IT1 extra qualifier pairs | Single pair only | Supports multiple qualifier/ID pairs | Generic X12 more permissive | | CTP segment | **Not Used** — FLX ignores | Optional (detail level pricing) | Do not include; generic X12 allows but FLX skips | | SAC at detail level | **Not Used** — FLX ignores | Optional (per-item charges) | Only summary-level SAC (G821) is processed | | ISS weight units | LB, OZ, 50 (Kg) | LB, OZ, 50 (Actual Kilograms) | Match | | IT104 format | NO implied decimal (15.95) | Type R (real number) | Match | | TDS format | IMPLIED decimal ($12→1200) | Type N2 (2 implied decimals) | Match | ### Common Validation Failures 1. **BIG01 date in future** — Rejected 2. **BIG01 date >17 months old** — Rejected 3. **ITD conditional logic violated** — Discount fields without proper pairing 4. **SAC with unsupported code** — May pass generic validation but FLX won't process it 5. **TDS without implied decimal** — Sending 12.00 instead of 1200 --- ## Example File ``` ISA*00* *00* *ZZ*XXXXXX*ZZ*FLXPOINT*120116*0218*U*00401*310000617*0*P*>~ GS*IN*XXXXXX*FLXPOINT*20180116*0218*617*X*004010VICS~ ST*810*53737~ BIG*20180116*123456**75070461~ REF*IA*123456~ REF*DP*0000~ ITD*01*3****20180126*45~ DTM*011*20180116~ IT1*1*1*EA*14.4*QT*UP*123456789159~ TDS*1940~ SAC*C*G821***500~ ISS*1*CA*4*LB~ CTT*1~ SE*12*53737~ ST*810*53738~ BIG*20011109*4857775**75070462~ REF*IA*123456~ REF*DP*0000~ ITD*01*3****20180126*45~ DTM*011*20180116~ IT1*1*1*EA*27.5*QT*UP*123456789951~ IT1*2*1*EA*27.5*QT*UP*123456777777~ TDS*6500~ SAC*C*G821***500~ ISS*1*CA*3*LB~ CTT*2~ SE*13*53738~ GE*2*617~ IEA*1*310000617~ ``` **Notes:** - Two invoices for the two POs in the 850 example - Each has $5.00 shipping charge (SAC*C*G821***500) - First invoice: 1 item @ $14.40, total $19.40 (TDS*1940) - Second invoice: 2 items @ $27.50 each = $55 + $5 shipping + $5 unrepresented = $65 (TDS*6500) - The extra $5 cannot currently be represented in an 810 segment --- # EDI 832 — Price/Sales Catalog Source: https://www.edihelpcenter.flxpoint.com/docs/832 Last updated: 2026-09-02 # EDI 832 — Price/Sales Catalog ## Purpose Send your full product catalog — items, prices, and availability — to Flxpoint. Originates with the **Supplier**, sent to Flxpoint. Used for initial catalog setup and ongoing price or product updates. ## How It Works The 832 is your product list. Where the 846 answers "how many of each item do you have right now?", the 832 answers "what do you sell, how do you describe it, and what does it cost?". Flxpoint ingests the 832 to set up the master catalog — SKUs, descriptions, wholesale prices, category codes, pack sizes — so that when orders come in the system already knows what each item is. Partners typically send one big 832 during onboarding (a full catalog load) and then send smaller delta 832s whenever prices change or new SKUs launch. A wrong 832 creates downstream pain: incorrect pricing on PO 850s, mismatched UPCs on invoices, or catalog items that never appear in the retailer's channel because Flxpoint could not match them. Flxpoint now **supports the 832** as a catalog-import document (internally called **GIP** — Get Inventory & Price), rolling out on Standard EDI V2 and live first for pharma sources such as **a pharma distributor** and **a pharma distributor**. > **Note:** The 832 is a catalog document, not an inventory update. For live inventory quantity changes use the **846**. The 832 is for pricing, product details, and availability status. > **How Flxpoint actually parses the 832 (important):** there is **no generic 832 parser** — 832/GIP is handled only by **vendor parsers (a pharma distributor, a pharma distributor)**, both built on the 846 base. Both **hard-require `BCT01=PC`** and **key items on NDC**. Their LIN-qualifier and CTP price-type sets diverge, so Flxpector validates the 832 **leniently**: envelope + `BCT` present + `BCT01=PC` + LIN pair structure, with **no whitelist** on BCT02 / CTP02 / LIN qualifiers. The generic `SC`/`UP`/`CA` + `WS`/`NET` details below are X12 reference; the **"Pharma / GIP Catalog Variant" section at the bottom is the operative spec** for what Flxpoint actually reads. ## Frequency - **Initial setup**: Send a full catalog when onboarding - **Updates**: Send price changes or new SKUs (delta) as needed - **Full refresh**: Resend the complete catalog periodically to sync any gaps ## Business Rules - One 832 per catalog or catalog segment — do not mix multiple suppliers in one file - **Multiple CTP segments per item are normal and expected** (one per price type — e.g. MSR, WHL, CON); a CTP needs both the code (CTP02) and a plain-numeric value (CTP03). A blank CTP03 keeps the item without saving that price; a non-numeric CTP03 drops that price - **Multiple PID segments per item are normal** (different description types) - **Items are keyed on NDC identifiers** (`ND` family qualifiers) in any LIN pair slot — a LIN without an NDC pair is skipped by the catalog import. Other identifiers (VN/UP/MG…) are stored but do not key the item - Only `BCT`/`REF`/`DTM`/`N1`–`N4`/`LIN`/`G53`/`PID`/`PO4`/`TD4`/`CTP`/`G39`/`CTT` are consumed — anything else rejects the file as unmapped - ⚠️ **832 catalogs are processed only by integrations configured for them.** The Standard EDI V2 integration rejects the file outright (`Unmapped doc type 832`) — coordinate with Flxpoint support before sending 832s --- ## Transaction Purpose Codes ### BCT02 — Transaction Set Purpose Code | Code | Meaning | When to Use | |------|---------|-------------| | `SC` | Specific Catalog | Full catalog transmission | | `UP` | Update | Partial update — new items or price changes only | | `DL` | Delete | Remove items from catalog | | `CA` | Catalog | General catalog (initial or full refresh) | --- ## Availability Status ### PO401 (in PO4 loop) or CTP product availability Use the **PID** segment description or **CTP** availability codes to communicate stock status: | Status | Meaning | |--------|---------| | Available | Item is in stock and available to order | | Discontinued | Item is no longer carried — include in `DL` update | | Back Order | Item temporarily unavailable | --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "SP") ST Transaction Set Header (ST01 = "832") BCT Beginning Segment for Price/Sales Catalog ┌─ LIN Loop (repeats per item) │ LIN Item Identification │ CTP Pricing Information │ PID Product/Item Description (recommended) │ QTY Quantity Available (optional) └─ CTT Transaction Totals (optional) SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Specifications ### ST — Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `832` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, must match SE02 | ### BCT — Beginning Segment for Price/Sales Catalog | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BCT01 | Catalog Purpose Code | 2 ID | M | **`PC`** — Flxpoint's GIP parser (a pharma distributor, a pharma distributor) **hard-requires `PC`** here and rejects anything else (`Invalid BCT01 Catalog Purpose Code — expected 'PC'`). This is what Flxpector validates. | | BCT02 | Catalog Number | 30 AN | O | Catalog identifier or version. (Generic X12 also carries purpose codes `SC`/`UP`/`CA` on the BCT segment, but Flxpoint keys on **BCT01=`PC`**, not those.) | | BCT03 | Description | 80 AN | O | Catalog description | | BCT07 | Date | 8 DT | M | Catalog date (CCYYMMDD) | ### LIN — Item Identification | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | LIN01 | Assigned Identification | 20 AN | M | Line item number (sequential) | | LIN02 | Product/Service ID Qualifier | 2 ID | M | Generic: `SK`/`UP`/`EN`. **Pharma GIP (ABC/a pharma distributor) keys on NDC** — qualifier `ND` (one pharma integration also falls back `N1`→`N4`). Flxpoint does **not** whitelist 832 LIN qualifiers (vendor sets diverge). | | LIN03 | Product/Service ID | 48 AN | M | Your item identifier | | LIN04 | Product/Service ID Qualifier | 2 ID | O | Secondary identifier qualifier | | LIN05 | Product/Service ID | 48 AN | O | Secondary identifier value | ### CTP — Pricing Information | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CTP01 | Class of Trade Code | 2 ID | O | Leave blank if not applicable | | CTP02 | Price Identifier Code | 3 ID | M | Generic: `WS`/`NET`/`RTL`. **Flxpoint does not whitelist CTP02** — pharma sets diverge (ABC: `AWP`/`CON`/`LPR`/`MSR`/`RTL`/`WHL`/`SPE`; a pharma distributor: `INV`/`MSR`). A **non-numeric CTP03 skips the item**; a blank CTP03 keeps it (price unset). | | CTP03 | Unit Price | 17 R | M | Unit price — supports up to 4 decimal places | | CTP04 | Quantity | 15 N | O | Quantity associated with this price | | CTP05 | Unit of Measure | 2 ID | M | `EA` (Each) | ### PID — Product/Item Description | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PID01 | Item Description Type | 1 ID | M | `F` (Free-form) or `S` (Structured) | | PID02 | Product Characteristic Code | 2 ID | O | Leave blank for free-form | | PID05 | Description | 80 AN | M | Product name or description | ### QTY — Quantity Available | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | QTY01 | Quantity Qualifier | 2 ID | M | `OH` (On Hand), `OA` (On Order), `AV` (Available) | | QTY02 | Quantity | 15 N | M | Available quantity | | QTY03 | Unit of Measure | 2 ID | O | `EA` (Each) | ### CTT — Transaction Totals | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CTT01 | Number of Line Items | 6 N | M | Total count of LIN segments | ### SE — Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Count of all segments including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Example File ``` ISA*00* *00* *ZZ*SUPPLIER *ZZ*FLXPOINT *240115*1200*U*00401*000000020*0*P*>~ GS*PI*SUPPLIER*FLXPOINT*20240115*1200*20*X*004010VICS~ ST*832*0001~ BCT*PC*CAT-2024-001***20240115~ LIN*1*SK*SKU-ABC123~ CTP**WS*29.99*1*EA~ PID*F****Blue Widget 12oz - Case of 1~ QTY*OH*150*EA~ LIN*2*SK*SKU-DEF456*UP*UPC-012345678901~ CTP**WS*49.99*1*EA~ PID*F****Pro Tool Kit - Standard Edition~ QTY*OH*42*EA~ LIN*3*SK*SKU-GHI789~ CTP**WS*15.00*1*EA~ PID*F****Cotton T-Shirt - White XL~ QTY*OH*0*EA~ CTT*3~ SE*16*0001~ GE*1*20~ IEA*1*000000020~ ``` **What this file does**: Sends 3 items with wholesale pricing and on-hand quantities: - SKU-ABC123: $29.99 — 150 units on hand - SKU-DEF456: $49.99 — 42 units (also has a UPC cross-reference) - SKU-GHI789: $15.00 — 0 units on hand (still listed in catalog) --- ## Common Mistakes > ⚠️ **The 832 is a catalog document, not inventory.** Use the 846 to send daily inventory quantity updates. The 832 is for product setup, pricing, and catalog management. > ⚠️ **BCT07 (date) is required.** Missing the date field is a common structural error that causes a 997 rejection. > ⚠️ **LIN identifiers must match your other transactions.** If you use `SK` + a SKU value in your 846/856, use the same qualifier and value in the 832. Mismatched identifiers break product matching in Flxpoint. > ⚠️ **CTP03 unit price must be a positive decimal.** Do not include currency symbols or commas. Use `29.99` not `$29.99` or `29,99`. --- ## Pharma / GIP Catalog Variant Pharma distributors (a pharma distributor, a pharma distributor) send a richer 832 with pricing and packaging detail. If your catalog follows this flavor: - **Header:** `BCT01 = PC` (Price Catalog). REF qualifiers seen here: `ACC`, `FL`, `2K`, `X9`. - **Parties:** `N1*VN` (Vendor) and `N1*BY` (Buyer). - **Item identifiers (LIN):** Flxpoint matches in this qualifier priority — `VN` → `UP` → `ND` → `MG` → `SK` → `VC` → `EA` → `UN`. Send the identifier your channel keys on first. - **Validity dates:** `DTM*092` (price start) and `DTM*093` (price end). - **Packaging:** `PO4` (e.g. 1 case / 100 each). - **Pricing (CTP02 price-type qualifiers):** `AWP` (Average Wholesale Price), `CON` (Contract), `LPR` (List), `WHL` (Wholesale), `RTL` (Retail), `MSR` (MSRP). ### CTP03 (price) handling | CTP03 value | Result | |-------------|--------| | Valid number | Price saved normally | | **Blank / empty** | Item is **kept** and its quantity updates; the price is simply **not saved** (item is *not* skipped or archived). | | **Invalid / non-numeric** | Error `Invalid CTP03 value: CTP03 (price) must be numeric` — the item **is skipped**. | > ⚠️ A blank CTP03 used to skip and archive the item. As of mid-2026 a blank price keeps the item; only an *invalid* (non-numeric) price skips it. Reprocess the catalog file to apply the current logic. --- ## Known Issues & Status > **Full structural validation is incremental.** The 832 is supported for catalog import (GIP); Flxpector currently applies envelope + generic X12 validation and is adding deeper GIP-832 field checks as the standard finalizes. The documentation above reflects the X12 004010 standard and the current Flxpoint GIP implementation. ### Known limitations under review - Extraction of secondary product identifiers (e.g. UPC) from `LIN` segments when multiple qualifier/value pairs are present: Flxpoint reads pairs in the qualifier-priority order above. - Deeper GIP-832 structural validation (pricing/packaging segments) is being added to Flxpector incrementally. --- # EDI 846 — Inventory Advice Source: https://www.edihelpcenter.flxpoint.com/docs/846 Last updated: 2026-09-03 # EDI 846 — Inventory Inquiry/Advice ## Purpose Inform the Retailer of inventory availability with accurate inventory levels. Originates with the **Supplier**, sent to FLX, then Retailer's ecommerce platform is updated. ## How It Works The 846 is how a supplier tells a retailer "here is what I have in stock right now." Flxpoint receives the file, updates each SKU's quantity, and then pushes the new numbers out to every connected channel (Shopify, Amazon, Walmart, etc.). If the 846 is wrong — missing SKUs, stale quantities, or an unexpected structure — the downstream channels will either oversell items that are not available or hide items that are actually in stock. That is why the 846 is the most frequently sent EDI transaction in a dropship operation: it is the heartbeat of inventory sync. ## Frequency Hourly recommended, daily minimum. ## Business Rules - QTY > 0 = in-stock, can be purchased - QTY = 0 = out-of-stock OR below safety stock (supplier's discretion) - Sending QTY=0 does NOT affect existing pending orders - Suppliers can implement "safety net" algorithms (send 0 when stock is critically low) - Unique UPC codes at variant level required for accurate tracking - **Each item (LIN03) must appear once** — a duplicate SKU/UPC makes the later quantity silently overwrite the earlier one (Flxpector warns: FLX-846-009) - **Strict line-item structure `LIN → [PID] → [CTP] → QTY`**: a foreign segment inside the loop, a CTP before the PID, or a **second QTY under one LIN** (per-warehouse pattern — not supported) aborts the import like a missing QTY (`No QTY segment found to match LIN with ...`) - **LIN02 accepts `UP`/`EA`/`SK`/`EN`** — `EA` (EAN) is valid; `BP` is not. LIN04–07 identifier pairs are not validated (unknown qualifiers are silently ignored). An invalid LIN02 or an empty LIN03 skips that line item (file still processes): when there is no UPC, send the SKU first (`LIN**SK*`) instead of `LIN**UP**SK*`, or the item never imports - **Only `BIA`/`REF`/`LIN`/`PID`/`CTP`/`QTY` are mapped.** Any other segment leaves the file rejected with `Unmapped segments found in transaction: S: ` and **zero items processed** (Flxpector: FLX-846-008). This holds wherever the segment sits: before the first LIN, inside the detail area, or trailing at the end. **`CTT` is the most common case** (FLX-846-005) and it is fatal too: the 846 parser does not consume CTT the way the 810 and 855 do, so a trailing `CTT*n` rejects an otherwise perfect file. Send the 846 without CTT and lower `SE01` by one - **PID01 must be `F`** — anything else skips that line item (file still processes; FLX-846-007) - **QTY02 must be a whole number and QTY03 must be `EA`**: a missing or invalid value skips that line item, the file still processes (Flxpector warns) --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "IB") ST Transaction Set Header (ST01 = "846") BIA Beginning Segment for Inventory REF Reference Identification ┌─ LIN Loop (repeats per product) │ LIN Item Identification │ PID Product/Item Description (optional) │ QTY Quantity └─ SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Overview | Segment | Name | FLX Status | Notes | |---------|------|------------|-------| | ST | Transaction Set Header | **Required** | ST01 = `846` | | BIA | Beginning Segment | **Required** | Purpose `00`, type `MM` | | REF | Reference Identification | **Required** | `IA` = Internal Vendor # | | LIN | Item Identification | **Required** | Repeats per product. SKU as primary ID | | PID | Product Description | Situational | Product title, freeform | | QTY | Quantity | **Required** | `33` = stock available for sale | | CTP | Pricing Information | **Not Used** | Generic X12 accepts unit price (`UCP`/`WHL`); FLX ignores this segment entirely | | SE | Transaction Set Trailer | **Required** | | --- ## Segment Specifications ### ST - Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `846` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, incremented by 1 | ### BIA - Beginning Segment for Inventory Inquiry | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BIA01 | Transaction Set Purpose Code | 2 ID | M | `00` (Original) | | BIA02 | Report Type Code | 2 ID | M | `MM` (Manufacturers Inventory Report) | | BIA03 | Reference Identification | 9 N | M | Sequential reference number | | BIA04 | Date | 8 DT | M | CCYYMMDD format | ### REF - Reference Identification | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference ID Qualifier | 2 ID | M | `IA` (Internal Vendor Number) | | REF02 | Reference Identification | 30 AN | M | FLX-assigned vendor number. **Max length: 30** — raised from 10 in May 2026 so longer partner-supplied vendor IDs are accepted | **Locating the Source ID (REF02)** The `REF02` element requires the Flxpoint **Source ID**. This is a unique numeric identifier assigned to the specific inventory source you are updating. You can locate this value in two ways: - **Platform URL**: Open the Source in the Flxpoint UI. The ID is the number at the end of the URL (e.g., `.../sources/12345`). - **Source Settings**: The ID is displayed in the header of the Source Settings page. Note: If your account manages multiple sources (e.g., different physical warehouses or separate vendor accounts), each requires a unique 846 file with the corresponding Source ID in `REF02` to ensure inventory is allocated to the correct record. ### LIN - Item Identification (Repeating Loop) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | LIN02 | Prod/Serv ID Qualifier | 2 ID | M | `UP` (UPC), `EN` (EAN), or `SK` (SKU) | | LIN03 | Prod/Serv ID | 48 AN | M | **Primary identifier in FLX**. Send SKU here if you want SKU in 850s. Exact size: UPC=12, EAN=13, SKU=30 max. **Must be unique across all items** | | LIN04 | Prod/Serv ID Qualifier | 2 ID | O | Same codes as LIN02. Required if LIN05 present | | LIN05 | Prod/Serv ID | 48 AN | O | Additional product identifier. Required if LIN04 present | | LIN06 | Prod/Serv ID Qualifier | 2 ID | O | Same codes as LIN02. Required if LIN07 present | | LIN07 | Prod/Serv ID | 48 AN | O | Additional product identifier. Required if LIN06 present | **Key**: LIN03 will serve as the primary identifier in Flxpoint. Send a SKU here if you wish to receive the SKU in 850s. ### PID - Product/Item Description (title) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PID01 | Item Description Type | 1 ID | O | `F` (Free-form Description) | | PID02 | Product Characteristic Code | 2 ID | O | `08` (Product) | | PID05 | Description | 80 AN | O | Freeform product title | ### QTY - Quantity | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | QTY01 | Quantity Qualifier | 2 ID | M | `33` (Stock quantity available for sale) | | QTY02 | Quantity | 15 N | M | Numeric value of available inventory. Missing or non-numeric: that line item is skipped, the file processes | | QTY03 | Composite Unit of Measure | 2 ID | M | `EA` (Each). Anything else: that line item is skipped, the file processes | ### SE - Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Count including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Validation Notes ### Segments Not Used by FLX > **One quantity per item — no per-warehouse breakdown.** Flxpoint's 846 parser reads a **single available quantity per SKU** from the `QTY` segment (`QTY01=33`, one QTY per `LIN`). It does **not** support a per-warehouse / per-location quantity breakdown — there is **no `SDQ` support** and it does not read multiple location-level `QTY` segments. If a supplier's file splits stock across warehouses, Flxpoint produces one **total** available quantity per item, not a per-location breakdown. (Confirmed against the production the production parser + engineering, 2026-07.) > **CTP — Pricing Information**: Generic X12 allows a `CTP` segment inside the LIN loop. Flxpoint's parser **does read it** when present — `CTP02` must be `WHL` or `UCP` and `CTP03` must be numeric, otherwise **that item is skipped**. It is not a reliable price channel (a malformed CTP silently drops the item), so keep pricing in the dedicated price/catalog feed and send only `LIN` + `PID` + `QTY` on the 846. ### Known Compatibility Notes | Field | FLX Behavior | Notes | |-------|-------------|-------| | QTY03 | Accepts simple `EA` | Standard X12 expects composite element C001 with sub-components. FLX accepts both formats. | | QTY02 / QTY03 invalid | **Line item skipped, file processes** | Same behavior as a malformed CTP or PID01 not `F`. Flxpector warns (it was a blocking error before 2026-09-01). | | Warehouse/location qty | **One total quantity per SKU** (`QTY01=33`) | **No per-warehouse breakdown / no `SDQ`** — not supported by the parser. | | CTP segment | Parsed if present (`CTP02`=`WHL`/`UCP`, numeric `CTP03`) — a malformed CTP drops the item | Keep pricing in the price feed; send `LIN` + `PID` + `QTY`. | | PID max use | Not specified | Practical limit; FLX uses first PID as title. | | LIN qualifier set | `UP` / `EA` / `SK` / `EN` (all LIN qualifier positions) | Validity set in the parser; `EA` (EAN) is valid in every position. | --- ## Example File ``` ISA*00* *00* *ZZ*XXXXXX*ZZ*FLXPOINT*120116*0640*U*00401*000000001*0*P*>~ GS*IB*XXXXXX*FLXPOINT*20180116*0640*1*X*004010VICS~ ST*846*1~ BIA*00*MM*1*20180116~ REF*IA*99999~ LIN**SK*SKU123*EA*1222222222222*UP*222222222222~ PID*F*08***Your product title~ QTY*33*145*EA~ LIN**SK*SKU456*EA*2333333333333*UP*333333333333~ PID*F*08***Another product title. Skipping optional title below~ QTY*33*0*EA~ LIN**SK*SKU789~ QTY*33*0*EA~ SE*12*1~ GE*1*1~ IEA*1*000000001~ ``` **Scenario**: 3 products, all using SKU as primary ID. - Product 1 (SKU123): 145 in stock, has UPC and EAN - Product 2 (SKU456): 0 = out-of-stock/backorder, has UPC and EAN - Product 3 (SKU789): 0 = discontinued, SKU only --- # EDI 850 — Purchase Order Source: https://www.edihelpcenter.flxpoint.com/docs/850 Last updated: 2026-09-03 # EDI 850 — Purchase Order ## Purpose Transmit new orders from Retailer (via FLX) to Supplier. Originates with the **Retailer**, sent to FLX, then FLX sends to Supplier. ## How It Works The 850 is the order itself — the retailer's commitment to buy, including what, how many, where to ship it, and how fast. Flxpoint generates the 850 from the underlying channel order (Shopify, Amazon, etc.) and drops it in the supplier's inbound SFTP directory. Everything downstream — the 855 acknowledgement, the 856 ship notice, the 810 invoice — is tied back to the PO number assigned on this 850. That is why the PO number, customer order number, and item identifiers on the 850 must be echoed exactly on every follow-up transaction. A single mismatch and the supplier's shipment won't match back to an order on the retailer's side. ## Frequency Hourly recommended, daily minimum. Can arrive at any time of day. ## Business Rules - Customer order number (N9 segment) **MUST be printed on the packing slip** - Supplier **MUST adhere to the shipping service level** in TD5 segment - Cancel After date (`DTM*001`) defaults to **7 days after order date**; it — and other date qualifiers — can be overridden by mapping a date field in the Send Fulfillment Requests template - Unit of Measure (`PO103`) defaults to **`EA`** but can be mapped to other codes (e.g. `CA` = Case) in the Send Fulfillment Requests template - PO number and UPC/EAN/SKU must be returned on 856 and 810 - Billing address only included if enabled within Flxpoint - **Order types**: Standard B2B/B2C account types are supported in Send FR mapping. Promotion order types are not yet supported as an account type option. Custom order type handling requires Integrations team configuration. --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "PO") ST Transaction Set Header (ST01 = "850") BEG Beginning Segment for Purchase Order CUR Currency REF Reference Identification (Internal Vendor #) PER Administrative Communications Contact (Seller's Phone) DTM Date/Time Reference (Cancel After + optional mapped date qualifiers) TD5 Carrier/Shipment Details N9 Reference Identification (Customer Order #) ┌─ N1 Loop - Ship-To (Mandatory) │ N1 Name (ST = Ship To) │ N3 Address Information │ N4 Geographic Location │ PER Communications Contact └─ ┌─ N1 Loop - Bill-To (Optional) │ N1 Name (BT = Bill To) │ N3 Address Information │ N4 Geographic Location │ PER Communications Contact └─ ┌─ PO1 Loop (repeats per line item) │ PO1 Baseline Item Data │ PID Product/Item Description (title) │ PID Product/Item Description (customizations - optional, multiple) └─ CTT Transaction Set Totals SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Overview | Segment | Name | FLX Status | Notes | |---------|------|------------|-------| | ST | Transaction Set Header | **Required** | ST01 = `850` | | BEG | Beginning Segment | **Required** | Purpose `00`, type `SA` | | CUR | Currency | **Required** | Always `BY` / `USD` | | REF | Reference Identification | **Required** | `IA` = Internal Vendor # | | PER | Communications Contact | Situational | Seller phone at heading level | | DTM | Date/Time Reference | Situational | `001` Cancel After always sent; `002`/`010`/`037`/`038`/`063` sent when mapped | | TD5 | Carrier Details | **Required** | TD512 service level code is mandatory | | N9 | Extended Reference | **Required** | Customer order # — must go on packing slip | | N1 / N3 / N4 / PER | Ship-To Loop | **Required** | Ship-to address and contact | | N2 | Additional Name | **Not Used** | Generic X12 accepts; FLX ignores this segment entirely | | N1 / N3 / N4 / PER | Bill-To Loop | Situational | Only included if billing address enabled in FLX | | PO1 / PID | Line Item Loop | **Required** | Repeats once per line item | | CTT | Transaction Totals | **Required** | Count of PO1 segments | | SE | Transaction Set Trailer | **Required** | | --- ## Segment Specifications ### ST - Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `850` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, incremented by 1 | ### BEG - Beginning Segment for Purchase Order | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BEG01 | Transaction Set Purpose Code | 2 ID | M | `00` (Original) | | BEG02 | Purchase Order Type Code | 2 ID | M | `SA` (Stand-Alone Order) by default. Some partners drive other types — e.g. **one vendor** supports `DS` (Dropship) and `SA`, and uses the order type to choose the Ship-To `N104` value (see note below) | | BEG03 | Purchase Order Number | 22 AN | M | Unique PO identifier | | BEG05 | Date | 8 DT | M | CCYYMMDD format | > **Vendor note — partner-specific PO types & Ship-To codes (e.g. one vendor):** A partner may restrict which `BEG02` PO types are allowed and map the **`N104` (Ship-To, `N101=ST`) value per PO type**, set per customer. one vendor supports only `DS` (Dropship) / `SA` (Stand-Alone); the `N104` code for each is configured in the mapping template (`N104(ST)-DS` / `N104(ST)-SA`) and provided per partner during onboarding (e.g. a vendor → DS=`02`, SA=`01`). If a DS/SA order has no `N104` code mapped, the Send-FR step returns a validation error rather than emitting a blank `N104`. ### CUR - Currency | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CUR01 | Entity Identifier Code | 3 ID | M | `BY` (Buying Party) | | CUR02 | Currency Code | 3 ID | M | `USD` | ### REF - Reference Identification | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference ID Qualifier | 2 ID | M | `IA` (Internal Vendor Number) | | REF02 | Reference Identification | 30 AN | M | FLX-assigned vendor number. **Max length: 30** — raised from 10 in May 2026 so longer partner-supplied vendor IDs (e.g. `ZZ/5082658025T`) are accepted | ### PER - Administrative Communications Contact (Seller's Phone) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PER01 | Contact Function Code | 2 ID | O | `EA` (EDI Coordinator) | | PER03 | Communication Number Qualifier | 2 ID | O | `TE` (Telephone Number) | | PER04 | Communication Number | 80 AN | O | Freeform telephone number | ### DTM - Date/Time Reference The 850 header can carry **one or more** DTM segments. `DTM*001` (Cancel After) is **always generated**; the remaining qualifiers are added **only when their field is mapped** in the Send Fulfillment Requests template. | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | DTM01 | Date/Time Qualifier | 3 ID | M | Qualifier code — see table below | | DTM02 | Date | 8 DT | M | CCYYMMDD format | **Supported DTM Qualifiers** (mappable in the Send Fulfillment Requests template): | Code | Description | Behavior | |------|-------------|----------| | `001` | Cancel After | **Always sent.** Defaults to **order date + 7 days** when left as *Don't Map*; map a date field to override the default. | | `002` | Delivery Requested | Sent only when mapped | | `010` | Requested Ship | Sent only when mapped | | `037` | Ship Not Before | Sent only when mapped | | `038` | Ship No Later | Sent only when mapped | | `063` | Do Not Deliver After | Sent only when mapped | > **Backward compatibility:** If no DTM field is mapped, output is identical to the previous behavior — a single `DTM*001` at order date + 7 days. Each qualifier you map adds one DTM segment to the header. *(Mappable DTM qualifiers went live in production May 2026.)* ### TD5 - Carrier/Shipment Details | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | TD505 | Routing | 35 AN | O | Free-form name of requested carrier. Conform to trading partner's supported options | | TD512 | Service Level Code | 2 ID | M | Shipping method the Retailer is requesting | **TD512 Service Level Codes:** | Code | Description | |------|-------------| | `D3` | 3 Day Select | | `ND` | Next Day Air Saver | | `SC` | Second Day Air | | `SI` | Standard Ground | | `SP` | SurePost | *These values may vary based on trading partner.* > **Mapping template (Aug 2026):** the TD5 fields are exposed in the Send Fulfillment Requests mapping template, so you can control what Flxpoint writes into each element. Map the human-readable carrier / service description (e.g. `Royal Mail Tracked 24`) to **TD5.5** and the 2-character Service Level Code to **TD5.12**. If a trading partner reports the description arriving in TD5.12 (it fails their validation - max 2 characters), fix the template mapping and re-run the job. The 856 you send back should mirror the 850's TD5 values. ### N9 - Reference Identification (Customer Order Number) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N901 | Reference ID Qualifier | 3 ID | M | `CO` (Customer Order Number) | | N902 | Reference Identification | 30 AN | M | **Customer order number - MUST be put on packing slip** | ### N1 - Ship-To Name (Mandatory) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N101 | Entity Identifier Code | 3 ID | M | `ST` (Ship To) | | N102 | Name | 60 AN | M | Customer name. Display on packing slip. **Max 60 chars — exceeding causes hard rejection** (FLX-ALL-007) | ### N2 - Additional Name | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N201 | Name | 60 AN | M | Additional name or company name | | N202 | Name | 60 AN | O | Second additional name line | > **Amazon Orders & Company Names:** For Amazon Get Orders, Flxpoint can ingest the company name or second name line (e.g., a hospital or charity name) and map it to the N2 segment. This must be configured in the **Send Fulfillment Requests** mapping template before orders are pulled. > > **Important:** This mapping is not retroactive. If an N2 segment appears blank on an existing order, check if the mapping was saved after the order was already ingested. Orders pulled before the mapping was configured will not be backfilled with the company name. ### N3 - Ship-To Address | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N301 | Address Information | 55 AN | M | First address line. Display on package label | | N302 | Address Information | 55 AN | O | Second address line | ### N4 - Ship-To Geographic Location | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N401 | City Name | 30 AN | M | Ship-To city | | N402 | State Code | 2 AN | M | Ship-To state | | N403 | Postal Code | 15 N | M | Zip code, **no hyphens or blanks** | ### PER - Ship-To Communications Contact | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PER01 | Contact Function Code | 2 ID | O | `NT` (Notification Contact) | | PER03 | Communication Number Qualifier | 2 ID | O | `TE` (Telephone) | | PER04 | Communication Number | 80 AN | O | Phone number | | PER05 | Communication Number Qualifier | 2 ID | O | `EM` (Email) | | PER06 | Communication Number | 80 AN | O | Email address | ### N1 - Bill-To Name (Optional) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N101 | Entity Identifier Code | 3 ID | O | `BT` (Bill To). Only included if enabled in Flxpoint | | N102 | Name | 60 AN | O | Customer name | *Bill-To loop includes same N3, N4, PER segments as Ship-To.* ### PO1 - Baseline Item Data (Repeating Loop) PO1 supports multiple product identifier pairs starting at position 6. Flxpoint reads the **first pair (PO106/PO107)** as the primary identifier. Additional pairs (PO108–PO117) can carry secondary identifiers like manufacturer codes, alternate UPCs, or buyer part numbers. | Element | Name | Length | Status | Value/Notes | |---------|------|--------|--------|-------------| | PO101 | Assigned Identification | 20 N | Required | Line item number. **Starts at 1, incrementing** | | PO102 | Quantity Ordered | 15 N | Required | Will be 1 or more | | PO103 | Unit of Measure | 2 ID | Required | Defaults to `EA` (Each). Mappable to other unit codes (e.g. `CA` = Case) via the Send Fulfillment Requests template; falls back to `EA` when unmapped | | PO104 | Unit Price | 17 N | Required | Expected cost. Format: `99.99` (e.g., `1.5`, `150`, `0.95`) | | PO106 | Prod/Serv ID Qualifier | 2 ID | Required | Primary ID type: `UP` (UPC), `EN` (EAN), or `SK` (SKU) | | PO107 | Prod/Serv ID | 48 AN | Required | Primary identifier. Exact size: UPC=12, EAN=13, SKU≤30 | | PO108 | Prod/Serv ID Qualifier | 2 ID | Situational | Additional type: `MG` (Manufacturer), `BP` (Buyer Part #), `VN` (Vendor #), `UP`, `EN`, `SK` | | PO109 | Prod/Serv ID | 48 AN | Situational | Value for PO108 qualifier | | PO110 | Prod/Serv ID Qualifier | 2 ID | Situational | Additional type (third pair) | | PO111 | Prod/Serv ID | 48 AN | Situational | Value for PO110 qualifier | | PO112 | Prod/Serv ID Qualifier | 2 ID | Situational | Additional type (fourth pair) | | PO113 | Prod/Serv ID | 48 AN | Situational | Value for PO112 qualifier | | PO114–PO117 | Additional ID Pairs | — | Situational | Up to two more pairs (positions 14–17) | > **FLX reads up to 6 identifier pairs per line item.** Always include at least one of `SK`, `UP`, or `EN` in the first pair. Additional pairs improve matching accuracy but are not required. > **Unit of Measure (PO103):** Defaults to `EA`. To send a different unit — for example `CA` (Case) — map the **Unit of Measure** field in the Send Fulfillment Requests template. The mapped value is written verbatim to PO103; vendors already sending `EA` are unaffected, and setting the field to *Don't Map* keeps the `EA` fallback. *(Selectable UOM went live in production May 2026.)* ### PID - Product/Item Description (title) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PID01 | Item Description Type | 1 ID | O | `F` (Free-form) | | PID02 | Product Characteristic Code | 2 ID | O | `08` (Product) | | PID05 | Description | 80 AN | O | First PID = product title. **Text over 80 chars trimmed** | ### PID - Item Customizations (Optional, Multiple) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PID01 | Item Description Type | 1 ID | O | `F` | | PID02 | Product Characteristic Code | 2 ID | O | `08` | | PID05 | Description | 80 AN | O | Key-value format: `[key] : [value]`. Only for suppliers who need them. **80 char limit, trimmed** | ### CTT - Transaction Set Totals | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | CTT01 | Number of Line Items | 6 N | M | Count of PO1 segments | ### SE - Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Validation Notes ### FLX-Specific Requirements vs Generic X12 | Field | FLX Spec | Generic 004010 | Impact | |-------|----------|----------------|--------| | PO1 qualifiers | UP, EN, SK | SK primary + BP, MG, VP, UP, EN secondary | Generic X12 allows more qualifier pairs | | PO1 extra ID pairs | Not used | Up to PO1-17 (6 pairs) | Generic X12 more permissive | | N1-03/N1-04 | Not in FLX spec | Optional (ZZ qualifier, ID code) | Additional facility/location code | | N2 segment | **Not Used** | Optional additional name | FLX ignores N2 entirely — don't include it | | PER in heading | Only seller phone | EA + NT contact codes | Generic X12 has both EDI coordinator and notification | ### What Strict Validators May Flag - Missing N1-03/N1-04 identification code qualifier pair (optional in both) - PO1 with only one product identifier pair (generic X12 supports many) - Missing PER segment (optional) --- ## Example File ``` ISA*00* *00* *ZZ*FLXPOINT *ZZ*123456 *120111*2309*U*00401*000007607*0*P*>~ GS*PO*FLXPOINT*001017078*20180111*2309*7607*X*004010VICS~ ST*850*0001~ BEG*00*SA*75070461**20180111~ CUR*BY*USD~ REF*IA*123456~ PER*EA**TE*8011234567~ DTM*001*20180116~ TD5*****UPS******SI~ N9*CO*10007241899999~ N1*ST*John Smith~ N3*1234 E Main Street~ N4*City*UT*84003~ PER*NT**TE*8011234567*EM*[email redacted]~ N1*BT*John Smith~ N3*1234 E Main Street~ N4*City*UT*84003~ PER*NT**TE*8011234567*EM*[email redacted]~ PO1*0001*1*EA*14.4**UP*123456789159~ PID*F*08***Item Title Here~ PID*F*08***Customization Text : Happy Birthday, Gift Recipient!~ PID*F*08***Custom Image Link : tinyurl.com/80CharacterLimit.................cutoff~ CTT*1~ SE*22*0001~ ST*850*0002~ BEG*00*SA*75070462**20180111~ CUR*BY*USD~ REF*IA*123456~ PER*EA**TE*9999999999~ DTM*001*20180112~ TD5*****any******ND~ N9*CO*10007247199999~ N1*ST*Fake Name~ N3*456 N 200 S~ N4*Nowhereville*UT*84003~ PER*NT**TE*(801)123-4567*EM*[email redacted]~ PO1*0001*1*EA*27.5**UP*123456789951~ PID*F*08***Item Title Here~ PO1*0002*1*EA*27.5**UP*456789111213~ PID*F*08***Item Title Here~ CTT*2~ SE*18*0002~ GE*2*7607~ IEA*1*000007607~ ``` **Notes:** - First transaction includes optional billing address + item customizations (PID key:value) - Second transaction has no billing address, 2 line items, Next Day Air shipping --- # EDI 855 — Purchase Order Acknowledgement Source: https://www.edihelpcenter.flxpoint.com/docs/855 Last updated: 2026-09-02 # EDI 855 — Purchase Order Acknowledgement ## Purpose Confirm receipt of a Purchase Order (850) and communicate your intent to fulfill it — line by line. Originates with the **Supplier**, sent to Flxpoint. ## How It Works The 855 is the supplier's commitment back to the retailer: "I got your PO and here is exactly what I plan to ship." Unlike the 997 — which only confirms the file envelope arrived — the 855 confirms business intent, line by line. For each item on the original 850 the supplier responds with an acknowledgement code: accept as-is, accept with a changed quantity, backorder, or reject. Flxpoint uses the 855 to update the order status in the channel before the shipment actually moves, so the end customer sees accurate expectations. A missing or partial 855 is a common source of support tickets because the retailer cannot tell what will ship until the ASN arrives hours or days later. ## Frequency Send within 24 hours of receiving the 850. Required for every PO received. ## Business Rules - The 855 must reference the original 850 PO number (BAK03 must match exactly, or the acknowledgement is silently ignored) - You must respond to every line item from the 850 - Accepted quantity must be ≤ the original PO quantity - Send one 855 per 850 — do not combine multiple POs in one 855 - **Every PO1 loop needs exactly one ACK segment** on the Standard EDI V2 integration — a line with no ACK fails the whole file; a second ACK in one loop is rejected (`Multiple segments found when only one is allowed: ACK, ACK`) - **Product identifiers are strict positional** on the Standard parser: `SK`@PO106, `BP`@PO108, `EN`@PO110, `MG`@PO112, `UP`@PO114, `VP`@PO116 (value in the following element). A different qualifier at those positions rejects the file (e.g. `Unknown Buyers Qualifier PO108 value VN`). Customized integrations may use other positions - **The header maps only BAK + the N1 party loop.** Header segments like `PER`, `REF`, `DTM`, `ITD` are rejected as unmapped by the Standard parser - BAK01/BAK02 values are not validated (any non-blank BAK02 is accepted); ACK03 unit of measure and PO101–PO105 are never read; CTT01 is never read (a wrong count is harmless) --- ## Status Codes ### BAK02 — Transaction Purpose | Code | Meaning | |------|---------| | `AD` | Accepted — PO is accepted as-is | | `AC` | Accepted with Changes — some lines modified | | `RD` | Rejected | ### ACK01 — Line Item Status Flxpoint resolves each line to **acknowledged** or **canceled** from the ACK01 code. The Standard EDI parser does **not** reject a file for an unrecognized ACK01 — a code in neither list is simply a no-op (the line ends up neither acknowledged nor canceled), so use a code from one of these lists. **Accepted (line acknowledged):** | Code | Meaning | |------|---------| | `IA` | Accepted, no change | | `IQ` | Accepted, quantity changed | | `IP` | Accepted, price changed | | `DR` | Accepted, date rescheduled | | `IC` | Accepted, changes made | | `AC` | Accepted and shipped | | `AR` | Accepted and released for shipment | | `AA` | Accepted — order forwarded to alternate supplier | **Rejected (line canceled):** | Code | Meaning | |------|---------| | `IR` | Rejected | | `R1` | Rejected — not a contract item | | `R2` | Rejected — invalid item / product number | | `R4` | Rejected — contract item not available | > **Pharma vendor variants:** the pharma distributors run **custom parsers** and add `IS` = *Accepted with Substitution* (the substitute item's identifiers follow on the ACK segment); a pharma distributor also treats `IW` (On Hold) as accepted. `IB` (Backordered) is **not** supported by the generic parser or by a pharma distributor. Use these only if your integration's spec calls for them. > **Where a cancellation reason shows up.** For suppliers whose parser carries it, the > code arrives as a line-item custom field named **Cancellation Reason**, visible on the > order details page under the line item's custom fields. The codes surfaced today are > `IA`, `IQ`, `IR`, `IB` and `IP`. Nothing new appears in the interface: no extra tab or > button, just the field on the line. Note the scope is cancellation reasons only for now, > so an acknowledgement code that is not one of those five will not appear there even > though the line still acknowledges normally. > **A canceled line can zero your inventory.** When a line comes back canceled (`IR`/`R1`/`R2`/`R4`) or is acknowledged for less than the quantity ordered, Flxpoint can treat the shortfall as the supplier having no stock and set that SKU's quantity to **0**, which then propagates to every connected channel. This is controlled by the source's out-of-stock flag, off by default: turn it on when the supplier's acknowledgement is a reliable stock signal, and leave it off when cancellations are routine for reasons other than stock. Pair it with an out-of-stock email notification so the zeroing is visible rather than something you discover from a channel listing that disappeared. > **Vendors send more codes than the base parser maps — and that's fine.** The base acknowledgement process maps **only** the four cancel codes (`IR`/`R1`/`R2`/`R4`); any other code is left unmapped, never rejected. Real vendors send a much wider set: one high-volume vendor sends ~25 codes including `ROS`, `IB`, `CC`, `R3`, `R7`. Because Flxpoint never rejects on ACK01, **Flxpector does not flag an unrecognized ACK01 as invalid** — if the inspector ever flagged a real vendor code like `ROS` it would be a false positive. If you need the cancellation reason surfaced (e.g. one high-volume vendor), the vendor parser can write `"{CODE} - {description}"` to a fulfillment-request item custom field rather than expanding the accept/cancel lists. > **Supported 855 senders:** firearms/outdoor partners route their 855 through **SPS Commerce**. **one high-volume vendor** sends its 855 this way today; **a distributor 855 support is rolling out** the same way. Note that **860 (PO Change Request)** is a *different* transaction; Flxpoint does **not** currently support inbound 860, even where a partner's SPS connection offers it. > **Tip — validate against your 850**: the inspector's "Cross-check with your 850" panel confirms BAK03 matches the PO, every 850 line has an acknowledgement, and acknowledged quantities don't exceed ordered. --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "PR") ST Transaction Set Header (ST01 = "855") BAK Beginning Acknowledgement for PO ┌─ PO1 Loop (repeats per line item) │ PO1 Line Item Detail │ ACK Line Item Acknowledgement └─ CTT Transaction Totals (optional) SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Overview | Segment | Name | FLX Status | Notes | |---------|------|------------|-------| | ST | Transaction Set Header | **Required** | ST01 = `855` | | BAK | Beginning Acknowledgement | **Required** | Purpose `00`, ack type, PO#, date | | N1 / N3 / N4 | Ship-To Loop | Situational | Ship-to address — mirror from 850 | | PO1 | Line Item Loop | **Required** | One per line item from original 850 | | ACK | Line Item Acknowledgement | **Required** | Status code per PO1 | | CTT | Transaction Totals | Situational | Count of PO1 segments | | SE | Transaction Set Trailer | **Required** | | --- ## Segment Specifications ### ST — Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `855` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, must match SE02 | ### BAK — Beginning Acknowledgement | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BAK01 | Transaction Set Purpose Code | 2 ID | M | `00` (Original) | | BAK02 | Acknowledgement Type | 2 ID | M | `AD` (Accepted), `AC` (Accepted with Changes), `RD` (Rejected) | | BAK03 | Purchase Order Number | 22 AN | M | Must match BEG03 from the original 850 | | BAK04 | Date | 8 DT | M | Date of acknowledgement (CCYYMMDD) | ### N1 Loop — Ship-To Address (Situational) When included, the N1 loop mirrors the Ship-To address from the original 850. | Element | Name | Length | Status | Value/Notes | |---------|------|--------|--------|-------------| | N101 | Entity Identifier Code | 3 ID | Required | `ST` (Ship To) | | N102 | Name | 60 AN | Required | Customer name | | N103 | Identification Code Qualifier | 2 ID | Situational | `ZZ` (Mutually Defined) | | N104 | Identification Code | 80 AN | Situational | Facility or location identifier | N3 and N4 follow (address line, city/state/zip) — same structure as 850. ### PO1 — Line Item Detail PO1 in the 855 echoes back the line items from the original 850. Include the same product identifiers that were in the 850 PO1. Multiple ID pairs (positions 6–17) are supported. | Element | Name | Length | Status | Value/Notes | |---------|------|--------|--------|-------------| | PO101 | Assigned Identification | 20 AN | Required | Line item number from the 850 | | PO102 | Quantity Ordered | 15 N | Required | Original quantity from the 850 | | PO103 | Unit of Measure | 2 ID | Required | `EA` (Each) | | PO104 | Unit Price | 17 R | Situational | Unit price from the 850 | | PO106 | Prod/Serv ID Qualifier | 2 ID | Required | Generic parser expects **`SK`** here. It reads a strict positional layout: `SK`@PO106, `BP`@PO108, `EN`@PO110, `MG`@PO112, `UP`@PO114, `VP`@PO116 (value in the following element). Pharma vendors (a pharma distributor, a pharma distributor) use `VN` at PO106 via custom parsers | | PO107 | Prod/Serv ID | 48 AN | Required | Primary identifier — must match the 850 | | PO108 | Prod/Serv ID Qualifier | 2 ID | Situational | Additional type (e.g., `BP` Buyer Part #, `EN` EAN, `MG` Manufacturer) | | PO109 | Prod/Serv ID | 48 AN | Situational | Value for PO108 qualifier | | PO110–PO117 | Additional ID Pairs | — | Situational | Up to 4 more pairs matching the 850 | > **Tip**: Include all product ID pairs that were in the original 850 PO1. This ensures Flxpoint can match the acknowledgement to the correct line item even if the primary ID is ambiguous. #### Choosing which identifier the job matches on Which element above Flxpoint matches against is a Flxpoint-side setting, not something the file controls. In the **Get PO/FR Acknowledgments** job's mapping template, the SKU field can be mapped to **Buyer's Item Number** (`BP`, read at PO108) instead of the default supplier SKU (`SK` at PO106). Use it when your PO lines carry your own part number rather than the supplier's: the acknowledgement then resolves against the identifier your catalog actually holds. Before this was supported the job could not resolve those lines and the acknowledgement failed to save. ### ACK — Line Item Acknowledgement | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ACK01 | Line Item Status Code | 2 ID | M | An accept code (`IA`/`IQ`/`IP`/`DR`/`IC`/`AC`/`AR`/`AA`) or a reject code (`IR`/`R1`/`R2`/`R4`) — see Status Codes above | | ACK02 | Quantity | 15 N | M | Acknowledged quantity. Must be ≤ PO102 | | ACK03 | Unit of Measure | 2 ID | Situational | `EA` (Each) — read by some vendor parsers | The generic Standard EDI parser reads only **ACK01** (status) and **ACK02** (quantity) from the ACK segment. Product identifiers come from the **PO1** segment, not the ACK. #### Pharma vendor variant — ACK identifiers & substitution This applies **only to the pharma catalog integrations** (custom parsers), not to the generic 855. When `ACK01 = IS` (Accepted with Substitution), the substitute item's identifiers ride in later ACK positions — a pharma distributor scans `ACK07/08` through `ACK13/14` for qualifiers `ND`/`N4` (NDC), `VC`/`VN` (vendor catalog), `UP` (UPC). For those integrations, include the identifier the PO line carries so Flxpoint can match the line; otherwise the SKU resolves null and the ack fails to save (root cause of the pharma distributor cross-dock 855 issue, mid-2026). #### Cross-Dock PO acknowledgements For a Cross-Dock PO, saving the 855 is **idempotent** — once the acknowledged quantity is recorded it cannot be re-applied. Re-sending the same 855 returns `Acknowledged quantity can't be greater than total quantity for sku …`, which is expected. The Cross-Dock PO stays in **Processed** status (there is no separate "Acknowledged" status badge for cross-dock). ### SE — Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Count of all segments including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Example File ``` ISA*00* *00* *ZZ*SUPPLIER *ZZ*FLXPOINT *240115*1200*U*00401*000000010*0*P*>~ GS*PR*SUPPLIER*FLXPOINT*20240115*1200*10*X*004010VICS~ ST*855*0010~ BAK*00*AD*PO-12345678*20240115~ PO1*1*2*EA*29.99**SK*SKU-ABC123~ ACK*IA*2*EA~ PO1*2*1*EA*49.99**SK*SKU-DEF456~ ACK*IA*1*EA~ PO1*3*4*EA*15.00**SK*SKU-GHI789~ ACK*IQ*2*EA~ SE*9*0010~ GE*1*10~ IEA*1*000000010~ ``` **Scenario**: 3-line PO response - Line 1 (SKU-ABC123): 2 units — Fully accepted (`IA`) - Line 2 (SKU-DEF456): 1 unit — Fully accepted (`IA`) - Line 3 (SKU-GHI789): Only 2 of 4 units available — Partial acceptance (`IQ`, qty=2) --- ## Common Mistakes > ⚠️ **ACK02 must always be ≤ PO102.** You cannot accept more than was ordered. Sending a higher quantity will cause a validation error. > ⚠️ **BAK03 must exactly match the PO number from BEG03 of the 850.** A mismatch means Flxpoint cannot link the acknowledgement to the original order. > ⚠️ **One 855 per 850.** Never combine acknowledgements for multiple POs in a single transaction set. --- # EDI 856 — Advance Ship Notice Source: https://www.edihelpcenter.flxpoint.com/docs/856 Last updated: 2026-09-29 # EDI 856 — Advance Ship Notice (ASN) ## Purpose Inform the customer of the tracking number to track the progress of their shipped order. Also called "Ship Confirm". Originates with the **Supplier**, sent to FLX, then Retailer gets it. ## How It Works The 856 closes the loop for the end customer: it tells Flxpoint (and the retailer's channel) that the order has shipped, the carrier is X, and the tracking number is Y. Flxpoint uses the 856 to mark the order fulfilled in the original channel and to push the tracking email to the shopper. This is also the hardest transaction to get right because it has a nested hierarchy — each shipment contains packs, each pack contains items — and every element must line up with the original 850. If the TD5 carrier segment is missing, or the HL hierarchy is broken, the entire ASN fails and the retailer's order stays stuck in "awaiting shipment" until support intervenes. The number one cause of failed 856s across Flxpoint's partner base is a missing TD5 shipping provider. ## Frequency Hourly recommended, daily minimum. ## Business Rules - Information MUST be based on the 850: PO number, line item number, customer order number, vendor UPC/EAN/SKU - Orders ship based on the **service level in TD5** from the 850/PO - Ship from first business day the PO is available - Correct UPC/EAN/SKU and PO number required to update FLX system - **Tracking number**: Can be sent in REF segment (shipment level) OR MAN segment (pack level) — these are **mutually exclusive** - **Partial shipments**: Each shipment must be a separate 856 with its own unique BSN02 (Shipment Identification). Do NOT combine multiple shipments for the same PO into a single 856 — Flxpoint processes one 856 per fulfillment. If splitting an order across multiple shipments, each gets its own ASN file. - **SSCC-18 format**: If using MAN*CP with SSCC-18 carton codes, the value must be exactly 18 numeric digits. Flxpector validates this (FLX-856-013) - **HL hierarchy linking**: Every HL below the Shipment level must populate HL02 with its parent's HL01 (Order → Shipment, Pack → Order, Item → Pack or Order). Only the first HL (Shipment, the root) leaves HL02 empty. A blank HL02 on a child HL is a **hard reject**: `Invalid HL segment - HL01 and HL02 must both be present`. Flxpector validates this (FLX-856-015 / FLX-856-016) - **Address block**: N3 (street) is optional, but **an N1 loop that carries N3 must also carry N4** (city/state/zip) — N3 without N4 rejects the file with `N4 segment is missing` (FLX-856-017) - **One DTM per shipment**: a repeated DTM at the shipment level is rejected (`The DTM segment is repeated; we only allow one`) - Two hierarchy structure options: `0001` (S, O, P, I) or `0004` (S, O, I) > **Tip — validate against your 850**: in the inspector, open "Cross-check with your 850" and paste the original PO. It verifies the PO number, every item identifier, quantities vs. ordered, and the service level — the mismatches that otherwise only surface after Flxpoint rejects the file. --- ### Mapping Template & Rules The Get Shipments EDI 856 mapping template exposes specific fields that can be used to trigger automated workflows or modify data during the integration process. Beyond the standard SKU/Item identifiers, the template now includes: - **Carrier**: The carrier value identified in the TD5 segment. - **Tracking Number**: The tracking identifier found in either the REF*CN or MAN*CP segments. These fields allow for the configuration of custom rules within Flxpoint. For example, a user can create a rule to automatically modify or re-assign a Carrier value based on specific patterns or suffixes detected within the Tracking Number field. ## Segment Hierarchy ### Option 1: BSN05 = 0001 (Shipment, Order, Pack, Item) — RECOMMENDED ``` ISA Interchange Header GS Group Header (GS01 = "SH") ST Transaction Set Header (ST01 = "856") BSN Beginning Segment for Ship Notice ┌─ HL Loop - Shipment (HL03 = "S") │ HL Hierarchical Level │ TD5 Carrier Details (SCAC + Service Level) │ REF Reference ID (CN = Carrier Tracking #) — OR use MAN at Pack level │ DTM Date/Time (011 = Shipped) │ ┌─ N1 Loop │ │ N1 Name (SF = Ship From, code 92) │ └─ │ ┌─ HL Loop - Order (HL03 = "O") │ │ HL Hierarchical Level │ │ PRF Purchase Order Reference │ │ REF Reference ID (CO = Customer Order #) — Optional │ │ REF Reference ID (VN = Vendor Order #) — Optional │ │ ┌─ HL Loop - Pack (HL03 = "P") │ │ │ HL Hierarchical Level │ │ │ MAN Marks and Numbers (CP = Carrier Package ID / Tracking #) │ │ │ ┌─ HL Loop - Item (HL03 = "I") │ │ │ │ HL Hierarchical Level │ │ │ │ LIN Item Identification │ │ │ │ SN1 Item Detail (units shipped) │ │ │ └─ │ │ └─ │ └─ └─ SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` ### Option 2: BSN05 = 0004 (Shipment, Order, Item) — No Pack level ``` Same as above but without the Pack (P) HL level. Items are direct children of Orders. ``` --- ### Hierarchy & Tracking Placement When selecting a hierarchy structure, note that the placement of tracking information is dependent on the chosen option. These two approaches are mutually exclusive: - **Option 1 (Shipment, Order, Pack, Item)**: This is the recommended structure. In this format, package-level tracking must be placed in the **MAN*CP** segment at the Pack level. - **Option 2 (Shipment, Order, Item)**: In this structure without a Pack level, shipment-level tracking must be placed in the **REF*CN** segment at the Shipment or Order level. Suppliers should ensure only one of these tracking segments is used per ASN to avoid validation failures. ## Segment Overview | Segment | Name | FLX Status | Notes | |---------|------|------------|-------| | ST | Transaction Set Header | **Required** | ST01 = `856` | | BSN | Beginning Segment | **Required** | BSN05 = `0001` (SOPI) or `0004` (SOI) | | HL (S) | Shipment Level | **Required** | Top of hierarchy | | TD5 | Carrier Details | **Required** | SCAC + service level code. Mandatory per FLX | | REF (CN) | Carrier Tracking # | Situational | At shipment level. **Mutually exclusive with MAN** | | DTM | Ship Date/Time | Situational | `011` = Actual ship date | | N1 (SF) | Ship From | Situational | Code `92` = supplier number | | HL (O) | Order Level | **Required** | One per PO | | PRF | Purchase Order Reference | **Required** | PO number from original 850 | | REF (CO) | Customer Order # | Situational | Echo from 850 N9 | | REF (VN) | Vendor Order # | Situational | Vendor's internal reference | | HL (P) | Pack Level | Situational | Required if BSN05=0001 | | MAN (CP) | Tracking # at Pack Level | Situational | **Mutually exclusive with REF (CN) at shipment level** | | HL (I) | Item Level | **Required** | One per line item | | LIN | Item Identification | **Required** | UPC, EAN, or SKU | | SN1 | Item Detail / Units Shipped | **Required** | Quantity and unit of measure | | SE | Transaction Set Trailer | **Required** | | > **Tracking number placement**: Use REF*CN at shipment level (0004 hierarchy) OR MAN*CP at pack level (0001 hierarchy). Never both. --- ## Segment Specifications ### ST - Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `856` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, incremented by 1 | ### BSN - Beginning Segment for Ship Notice | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BSN01 | Transaction Set Purpose Code | 2 ID | M | `00` (Original) | | BSN02 | Shipment Identification | 30 AN | M | Unique control number assigned by supplier | | BSN03 | Date | 8 DT | M | CCYYMMDD | | BSN04 | Time | 4 TM | M | HHMM | | BSN05 | Hierarchical Structure Code | 4 ID | M | `0001` (S,O,P,I) or `0004` (S,O,I) | ### HL - Shipment Level | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | HL01 | Hierarchical ID Number | 12 AN | M | `1` (starts, increments with multiple orders) | | HL02 | Hierarchical Parent ID Number | 12 AN | — | **Leave EMPTY at this level only** — the Shipment HL is the hierarchy root and has no parent. Written `HL*1**S` (blank element separator still present) | | HL03 | Hierarchical Level Code | 2 ID | M | `S` (Shipment) | > **IMPORTANT**: Only the Shipment-level HL has an empty HL02. Every HL below it (Order, Pack, Item) **must** carry HL02 = its parent's HL01 — e.g. `HL*2*1*O` (Order under Shipment 1), `HL*3*2*I` (Item under Order 2). A blank HL02 on a child level **FAILS** the file: `Invalid HL segment - HL01 and HL02 must both be present`. ### TD5 - Carrier Details | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | TD502 | Identification Code Qualifier | 2 ID | M | `2` (Standard Carrier Alpha Code / SCAC) | | TD503 | Identification Code | 80 AN | M | Carrier SCAC code. Max size 4 (e.g. `UPSN` for UPS) | | TD505 | Routing (Carrier Description) | 35 AN | O | Free-form carrier / service description (e.g. `Royal Mail Tracked 24`) — mirror the 850's TD5.5 | | TD512 | Service Level Code | 2 ID | M | `D3`, `ND`, `SC`, `SI`, `SP` — match 850 TD5 | **IMPORTANT**: If TD5 shipping provider is **missing**, the transaction **FAILS** validation. > **Description vs code:** the human-readable service name belongs in **TD5.5**, never in TD5.12. A file with `TD512 "Royal Mail Tracked 24" is too long (21 chars, max 2)` has the two elements swapped — put the 2-character code in TD5.12 and the description in TD5.5. On the Flxpoint side these TD5 fields are exposed in the mapping template (Aug 2026), so the placement is controlled by the template mapping. > **International carriers without a US SCAC** (Royal Mail, DPD, …): TD503 is format-checked only — use any consistent 2–4 character code per carrier and coordinate the mapping with support. TD512 is stored as-is; hardcoding/translating the service level in your ASN export is normal. The carrier never goes in CAD segments on the 856 — always TD5. ### REF - Carrier Tracking Number (Shipment Level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference ID Qualifier | 3 ID | M | `CN` (Carrier's Reference Number) | | REF02 | Reference Identification | 30 AN | M | Carrier's tracking number. **NOTE: This segment OR MAN segment — mutually exclusive** | ### DTM - Date/Time | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | DTM01 | Date/Time Qualifier | 3 ID | M | `011` (Shipped) | | DTM02 | Date | 8 DT | M | Date shipped (CCYYMMDD) | | DTM03 | Time | 4 TM | O | Time shipped (HHMM) — optional: the parser stores it when present but never requires it (corrected 2026-07-08; the old spec wrongly marked it mandatory) | ### N1 - Ship From Name > **N1*SF is required** — without it the file is rejected (`Expecting N101 Element with value 'SF'`). N104 carries the code configured for your source in Flxpoint (typically the Flxpoint-assigned supplier number; some accounts use a GLN). **N1*ST (Ship To) is optional** — the destination is already known from the 850. | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | N101 | Entity Identifier Code | 3 ID | M | `SF` (Ship From) | | N103 | Identification Code Qualifier | 2 ID | M | `92` (Assigned by Buyer or Buyer's Agent) | | N104 | Identification Code | 80 AN | M | FLX-assigned supplier number. **Max size 10** | ### HL - Order Level | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | HL01 | Hierarchical ID Number | 12 AN | M | `2` (increments) | | HL02 | Hierarchical Parent ID Number | 12 AN | M | `1` (parent = shipment) | | HL03 | Hierarchical Level Code | 2 ID | M | `O` (Order) | ### PRF - Purchase Order Reference | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PRF01 | Purchase Order Number | 22 AN | M | PO number from the BEG segment of the 850 | ### REF - Customer Order Number (Order Level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference ID Qualifier | 3 ID | O | `CO` (Customer Order Number) | | REF02 | Reference Identification | 30 AN | O | Customer Order Number from N9 of the 850 | ### REF - Vendor Order Number (Order Level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Reference ID Qualifier | 3 ID | O | `VN` (Vendor Order Number) | | REF02 | Reference Identification | 30 AN | O | Vendor's order number | ### HL - Pack Level (Only for BSN05=0001) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | HL01 | Hierarchical ID Number | 12 AN | M | `3` (increments) | | HL02 | Hierarchical Parent ID Number | 12 AN | M | Parent = order hierarchy | | HL03 | Hierarchical Level Code | 2 ID | M | `P` (Pack) | ### MAN - Marks and Numbers (Pack Level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | MAN01 | Marks and Numbers Qualifier | 2 ID | M | `CP` (Carrier-Assigned Package ID) | | MAN02 | Marks and Numbers | 48 AN | M | Carrier's tracking number. **NOTE: Mutually exclusive with Shipment-level REF*CN** | ### HL - Item Level | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | HL01 | Hierarchical ID Number | 12 AN | M | Increments | | HL02 | Hierarchical Parent ID Number | 12 AN | M | Parent = order (0004) or pack (0001) | | HL03 | Hierarchical Level Code | 2 ID | M | `I` (Item) | ### LIN - Item Identification | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | LIN01 | Line Number | 4 N | O | Starts at 1, incrementing | | LIN02 | Prod/Serv ID Qualifier | 2 ID | M | `UP` (UPC), `EN` (EAN), `SK` (SKU), or `BP` (Buyer's Part Number) | | LIN03 | Prod/Serv ID | 30 AN | M | **MUST match the SKU/UPC/EAN sent in the 850** | ### SN1 - Item Detail (Shipment) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SN101 | Assigned Identification | 20 AN | O | Not Used | | SN102 | Number of Units Shipped | 10 N | M | Number of units shipped | | SN103 | Unit of Measure | 2 ID | M | `EA` (Each) | ### SE - Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Validation Notes ### FLX-Specific Requirements vs Generic X12 | Field | FLX Spec | Generic 004010 | Impact | |-------|----------|----------------|--------| | TD5 | TD502, TD503, TD512 all M | TD502 M, TD503 M, TD512 O | **FLX requires TD512 service level; some validators mark it optional** | | REF tracking | `CN` at shipment level OR MAN at pack | Same, mutually exclusive | Enforced strictly | | N1 Ship-From | N101=SF, N103=92, N104=supplier# | N101=SF, N103=92, N104=ID | FLX uses supplier-specific N104 | | BSN05 | `0001` or `0004` | `0001` or `0004` | Match | ### Common Validation Failures 1. **Missing TD5 shipping provider** — FAILS validation (SCAC code required) 2. **Missing TD512 service level** — May fail depending on validator config; FLX requires it 3. **Sending both REF*CN and MAN*CP** — Should be mutually exclusive 4. **LIN03 not matching 850 item codes** — Logical error, not structural --- ## Example Files ### Option #1: RECOMMENDED — One ASN with ST/SE per shipment, tracking at Pack level ``` ISA*00* *00* *ZZ*XXXXXX *ZZ*FLXPOINT *120116*0705*U*00401*000000004*0*P*>~ GS*SH*XXXXXX*FLXPOINT*20180116*0705*253*X*004010VICS~ ST*856*3936~ BSN*00*1111111*20020718*0855*0001~ HL*1**S~ TD5**2*UPSN*********SI~ DTM*011*20180116*0855~ N1*SF**92*22222~ HL*2*1*O~ PRF*11123456~ REF*CO*22123456780103~ REF*VN*33333333333333333333~ HL*3*2*P~ MAN*CP*1ZE44444444444444~ HL*4*3*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ SE*16*3936~ ST*856*3937~ BSN*00*11111111*20020718*1234*0001~ HL*1**S~ TD5**2*UPSN*********ND~ DTM*011*20180116*1234~ N1*SF**92*222222~ HL*2*1*O~ PRF*11123457~ REF*CO*22123456780102~ REF*VN*333333333333334444444~ HL*3*2*P~ MAN*CP*1ZE44444444888888~ HL*4*3*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ HL*5*3*I~ LIN*0002*BP*055555111111~ SN1**1*EA~ SE*19*3937~ GE*2*253~ IEA*1*000000004~ ``` ### Option #3: Tracking number at Shipment Level (REF*CN) ``` ISA*00* *00* *ZZ*XXXXXX *ZZ*FLXPOINT *120116*0705*U*00401*000000022*0*P*>~ GS*SH*XXXXXX*FLXPOINT*20180116*0705*253*X*004010VICS~ ST*856*3936~ BSN*00*11111111*20180116*2040*0004~ HL*1**S~ TD5**2*UPSN*********SC~ REF*CN*1ZE55555222241598~ DTM*011*20180116*2040~ N1*SF**92*22222~ HL*2*1*O~ PRF*11123456~ REF*CO*22123456780103~ REF*VN*33333333333333333333~ HL*3*2*I~ LIN*0001*BP*055555555111~ SN1**1*EA~ HL*4**S~ TD5**2*UPSN*********D3~ REF*CN*1ZE55555222244444~ DTM*011*20180116*2100~ N1*SF**92*22222~ HL*5*4*O~ PRF*11123457~ REF*CO*22123456780102~ REF*VN*1111111145~ HL*6*5*I~ LIN*0001*BP*044444444444~ SN1**2*EA~ HL*7*5*I~ LIN*0002*BP*044444422222~ SN1**2*EA~ SE*30*3936~ GE*1*253~ IEA*1*000000022~ ``` --- # EDI 870 — Order Status Report Source: https://www.edihelpcenter.flxpoint.com/docs/870 Last updated: 2026-09-02 # EDI 870 — Order Status Report ## Purpose Report the status of items on a purchase order. Originates with the **Supplier**, sent to Flxpoint. ⚠️ **Flxpoint uses the 870 for item cancellations ONLY.** Every status in the file must be `ISR01 = IC` (Item Cancelled). Any other status code rejects the file — statuses like "shipped" belong on the 856, and acknowledgements on the 855. ## How It Works When a supplier cannot fulfill one or more items on a PO, the 870 tells Flxpoint which items are cancelled. Flxpoint matches the file to the order using three references together — the PO number (PRF01), the customer order number (REF*CO), and the vendor order number (REF*VN) — and then cancels the listed items. A missing or blank reference means the order cannot be identified and the file is rejected. ## Business Rules - **Cancellations only**: every PO1 loop must carry an `ISR` segment with `ISR01 = IC`. Any other code rejects the file (`Illegal ISR segment, ISR01 `) - **BSR + REF*IA open the file**: `BSR*2*PP**~` must be immediately followed by `REF*IA*~` - **Two hierarchy levels only**: `HL03 = O` (Order) and `HL03 = I` (Item). Any other level code (S, P, …) rejects the file - **Each order HL needs**: exactly one `PRF` (PO number) plus `REF*CO` and `REF*VN` — **both with values** — right after the loop - **Each item HL** points at its order via HL02 and carries `PO1` + `ISR` pairs - **PO106 accepts only `UP` (UPC) or `EA` (EAN)** — other qualifiers are not supported on the 870 - **PO102 (quantity) must be a whole number** - Only the segments above are mapped — anything else rejects the file as unmapped ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "RS") ST Transaction Set Header (ST01 = "870") BSR Beginning Segment for Order Status Report (BSR01=2, BSR02=PP) REF Reference — Internal Vendor Number (IA) — must follow BSR ┌─ HL Loop — Order level (HL03 = O) │ HL Hierarchical Level │ PRF Purchase Order Reference (PO number) │ REF Customer Order Number (CO) │ REF Vendor Order Number (VN) └─ ┌─ HL Loop — Item level (HL03 = I, HL02 = parent order HL01) │ HL Hierarchical Level │ PO1 Baseline Item Data (quantity + UP/EA identifier) │ ISR Item Status Report (IC = Item Cancelled) └─ SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` ## Segment Specifications ### BSR - Beginning Segment for Order Status Report | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | BSR01 | Status Report Code | 1-2 ID | M | `2` (fixed) | | BSR02 | Order/Item Code | 2 ID | M | `PP` (fixed) | | BSR03 | Reference Identification | 30 AN | O | Vendor's reference for this report | | BSR04 | Date | 8 DT | O | CCYYMMDD | ### REF - Internal Vendor Number (immediately after BSR) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Qualifier | 2 ID | M | `IA` | | REF02 | Reference | 30 AN | M | Flxpoint-assigned vendor number | ### HL - Hierarchical Level | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | HL01 | Hierarchical ID Number | 12 AN | M | Increments | | HL02 | Hierarchical Parent ID | 12 AN | — | Empty on Order level; on Item level = the parent order's HL01 | | HL03 | Hierarchical Level Code | 2 ID | M | `O` (Order) or `I` (Item) — **no other levels** | ### PRF - Purchase Order Reference (Order level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PRF01 | Purchase Order Number | 22 AN | M | PO number from the original 850 | ### REF - Order References (Order level, after PRF) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | REF01 | Qualifier | 2 ID | M | `CO` (Customer Order #) and `VN` (Vendor Order #) — **both required, both with values** | | REF02 | Reference | 30 AN | M | The order number | ### PO1 - Baseline Item Data (Item level) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | PO101 | Assigned Identification | 20 AN | O | PO line number | | PO102 | Quantity | 10 N | M | Cancelled quantity — **whole number** | | PO103 | Unit of Measure | 2 ID | O | e.g. `EA` | | PO106 | Product/Service ID Qualifier | 2 ID | M | `UP` (UPC) or `EA` (EAN) **only** | | PO107 | Product/Service ID | 48 AN | M | The item identifier | ### ISR - Item Status Report (one per PO1) | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ISR01 | Status Code | 2 ID | M | `IC` (Item Cancelled) — **the only accepted value** | | ISR02 | Date | 8 DT | O | Cancellation date (CCYYMMDD) | ## Example ``` ISA*00* *00* *ZZ*VENDORID *ZZ*FLXPOINT *260708*0900*U*00401*000000001*0*P*>~ GS*RS*VENDORID*FLXPOINT*20260708*0900*1*X*004010~ ST*870*0001~ BSR*2*PP*STATUS001*20260708~ REF*IA*12345~ HL*1**O~ PRF*PO-98765~ REF*CO*CUST-11111~ REF*VN*VORD-22222~ HL*2*1*I~ PO1*1*2*EA***UP*012345678905~ ISR*IC*20260708~ SE*11*0001~ GE*1*1~ IEA*1*000000001~ ``` This cancels 2 units of UPC 012345678905 on PO-98765. > **Note on the version identifier:** the example uses `004010`, but Flxpoint does **not** validate the interchange/group version number (e.g. `004010` vs `005010`) — it is ignored during parsing. What matters is the segment structure and the required values (`BSR01=2`, `BSR02=PP`, `REF01=IA`, `ISR01=IC`). ## Processing Pipeline An inbound 870 moves through the standard EDI intake stages: 1. The **file downloader** pulls 870 files from the supplier's FTP/SFTP location. 2. The **parser** reads the file and breaks it into orders and items. 3. The **writer** matches the parsed data to your purchase orders and records the cancellations. 4. The processed file is **marked complete** so it is never processed twice. ## What Happens After Parsing Once the file parses cleanly: 1. Flxpoint matches `PRF01` (the PO number) to an existing purchase order. 2. For each item, the corresponding PO line is **acknowledged as cancelled**. 3. The **acknowledgement date is taken from the file's ISA envelope date**. `ISR02`, when present, is an optional per-item cancellation date. 4. The file is marked processed so it will not be re-read. ## Common Errors & What They Mean If an 870 fails or has no effect, pull the raw EDI file and compare it against the segment specs above. | Message | Meaning | What to do | |---|---|---| | `BSR01 must be '2'` | BSR has an unexpected status code | Ask the supplier to verify BSR01 in their 870 | | `BSR02 must be 'PP'` | BSR has the wrong status type | The file isn't using the expected Product Transfer format | | `REF01 following the BSR segment must be 'IA'` | The REF right after BSR isn't qualifier `IA` | Supplier is sending the wrong reference qualifier | | `Missing ISR loop` / `Missing ISR Segment` | An item loop has no ISR status | File is incomplete — every item must carry a status | | `Missing ISR01, Order Status Code` | ISR exists but has no status code | Supplier sent an empty ISR segment | | `Illegal ISR segment, ISR01 ` | ISR01 is something other than `IC` | Unsupported status code — the 870 is for cancellations only | | `Missing items for order ` | An order has no items under it | Order header with no line items | | `Unmapped segments in ItemDetail PO Loop` | Extra segments inside a PO1 loop | Supplier is sending segments Flxpoint doesn't parse | | `Unmapped segments in ItemDetail Loop` | Extra segments in the item loop | Unexpected data from the supplier | | `Unmapped segments found in transaction` | Leftover segments after parsing | The file contains segments Flxpoint doesn't recognize. The whole file is rejected, nothing from it is applied | | **No acknowledgement created (no error)** | `PRF01` didn't match any PO | Not an error, but nothing was cancelled — verify the PO number exists and that the supplier is sending it in the correct format | ## Vendor Variations Most suppliers follow the standard structure above, where every listed item is treated as a cancellation. A few suppliers (for example, Jessica Simpson) send a slightly different 870 layout, but the outcome is the same — the listed items are cancelled. ## Key Takeaways 1. **870 = cancellations.** Every item in an 870 is treated as cancelled. 2. **The PO number is key.** Matching is on `PRF01`; a wrong or misformatted PO number matches nothing (and produces no acknowledgement, with no error). 3. **Segment validation is strict.** `BSR01 = 2`, `BSR02 = PP`, `REF01 = IA`, `ISR01 = IC` — any deviation rejects the file. (The envelope version number is not checked.) 4. **Files are processed once.** After a successful parse the file is marked processed and won't be picked up again. 5. **Check the raw file.** For a failed 870, pull the raw EDI and compare it against the segment specs above. --- # EDI 997 — Functional Acknowledgement Source: https://www.edihelpcenter.flxpoint.com/docs/997 Last updated: 2026-09-29 # EDI 997 — Functional Acknowledgement ## Purpose Confirm receipt of an EDI transaction. Flxpoint sends a 997 to **you** every time it receives a file from you. It confirms the file arrived and was structurally valid — it does **not** confirm business logic. ## How It Works The 997 is the receipt. Every time you send Flxpoint a file — an 850, an 856, an 810 — Flxpoint writes a tiny 997 back to your outbound folder that says "got it, the envelope was readable." It is not a business confirmation: it does not promise the inventory was updated, the shipment was accepted, or the order was processed. That is what the 855 (PO acknowledgement) and 810 matching are for. Think of the 997 like a delivery receipt for a certified letter — it proves the letter arrived, not that the recipient agreed with what was inside. Most "overdue 997" support tickets turn out to be SFTP round-trip issues (the partner never picked up the file from `/out`), not actual processing failures. > **Note:** A 997 only means "we received your file and it was readable." It does NOT mean the inventory was updated, the shipment was accepted, or the order was processed. ## Frequency Sent by Flxpoint automatically in response to every inbound transaction. Find 997s in your **`/out`** (outbound from Flxpoint) directory. ## Business Rules - You must generate a 997 for every transaction Flxpoint sends you (850, etc.) - A 997 with AK501=`A` means the transaction was accepted - A 997 with AK501=`E` means accepted with errors — review the AK5 detail - A 997 with AK501=`R` means rejected — the file had structural issues --- ## Acknowledgement Status Codes ### AK501 — Transaction Set Acknowledgement Code | Code | Meaning | What to Do | |------|---------|-----------| | `A` | Accepted | No action needed | | `E` | Accepted, But Errors Were Noted | Review errors — file was processed but had issues | | `R` | Rejected | File was NOT processed — fix and resend | ### AK901 — Group Acknowledgement Code | Code | Meaning | |------|---------| | `A` | Accepted | | `E` | Accepted with Errors | | `R` | Rejected | | `P` | Partially Accepted | --- ## Segment Hierarchy ``` ISA Interchange Header GS Group Header (GS01 = "FA") ST Transaction Set Header (ST01 = "997") AK1 Functional Group Response Header ┌─ AK2 Loop (one per transaction set) │ AK2 Transaction Set Response Header │ AK5 Transaction Set Response Trailer └─ AK9 Functional Group Response Trailer SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer ``` --- ## Segment Specifications ### ST — Transaction Set Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ST01 | Transaction Set ID Code | 3 ID | M | `997` | | ST02 | Transaction Set Control Number | 9 N | M | Unique, must match SE02 | ### AK1 — Functional Group Response Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | AK101 | Functional ID Code | 2 ID | M | Matches GS01 of the acknowledged group (e.g. `SH` for 856) | | AK102 | Group Control Number | 9 N | M | Matches GS06 of the acknowledged group | ### AK2 — Transaction Set Response Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | AK201 | Transaction Set ID Code | 3 ID | M | Transaction type being acknowledged (e.g. `856`) | | AK202 | Transaction Set Control Number | 9 N | M | Matches ST02 of the acknowledged transaction | ### AK5 — Transaction Set Response Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | AK501 | Transaction Set Acknowledgement Code | 1 ID | M | `A` (Accepted), `E` (Accepted with Errors), `R` (Rejected) | | AK502 | Error Code | 3 N | O | Present if AK501 ≠ `A`. See X12 error codes | ### AK9 — Functional Group Response Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | AK901 | Functional Group Acknowledgement Code | 1 ID | M | `A`, `E`, `R`, or `P` | | AK902 | Number of Transaction Sets Included | 6 N | M | Count of transaction sets in the group | | AK903 | Number of Received Transaction Sets | 6 N | M | Count of sets received | | AK904 | Number of Accepted Transaction Sets | 6 N | M | Count of accepted sets | ### SE — Transaction Set Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | SE01 | Number of Included Segments | 6 N | M | Count of all segments including ST and SE | | SE02 | Transaction Set Control Number | 9 N | M | Must match ST02 | --- ## Example — Accepted 997 ``` ISA*00* *00* *ZZ*FLXPOINT *ZZ*SUPPLIER *240115*1200*U*00401*000000015*0*P*>~ GS*FA*FLXPOINT*SUPPLIER*20240115*1200*15*X*004010VICS~ ST*997*0001~ AK1*SH*253~ AK2*856*3936~ AK5*A~ AK9*A*1*1*1~ SE*5*0001~ GE*1*15~ IEA*1*000000015~ ``` **What this means**: Flxpoint received your 856 (Ship Notice, GS control number 253, ST control number 3936) and it was accepted (`AK5*A`). --- ## Reading 997 Errors If you receive a 997 with `AK501=E` or `AK501=R`, the AK5 segment will include error codes: | Common Error Code | Meaning | |-------------------|---------| | `001` | Transaction Set Not Supported | | `002` | Transaction Set Trailer Missing | | `003` | Transaction Set Control Number Mismatch | | `004` | Groups Not Properly Bounded | | `005` | Transactions Not Properly Bounded | | `006` | Transaction Set Control Number Not Unique | | `022` | Segment Not in Defined Transaction Set | | `023` | Segment Not in Proper Sequence | | `024` | Segment Not Defined in Transaction Set | > ⚠️ **A rejected 997 means your file was NOT processed.** You must fix the structural issue and resend the original transaction. Do not send a corrected version without understanding what caused the rejection. --- ## How Flxpoint Handles 997s Because the 997 is an envelope-level acknowledgement (not a business validation), Flxpoint treats it differently from transactions like the 846 or 856: - **Generation is automatic.** Every inbound 850 / 855 / 810 / 846 / 856 that Flxpoint receives triggers a 997 response. You do not request it — it is written to your outbound SFTP directory as soon as the file is read. - **Validation is structural only.** Flxpoint does not open the business content to produce the 997. The 997 confirms that the interchange, group, and transaction-set envelopes are well-formed — that is all. - **Envelope and delimiters only inside Flxpector.** The Flxpector inspector does not run schema checks on 997 content because there is no business payload to validate. It does check the envelope (ISA/GS/ST/SE/GE/IEA counts and control numbers) and the delimiters: a 997 whose segment terminator is corrupted (**TOK-003**) is reported as invalid, because that is a real reason a partner cannot read it. A well-formed 997 parses with no findings. - **Flxpector focuses on the transactions that carry business data** (846, 850, 855, 856, 810). If you need to confirm a 997 round-trip, check your SFTP `/out` folder and your partner's pickup logs. This is the same approach most X12 processors take: the 997 is infrastructure, not content. --- ## Troubleshooting — "We didn't receive your 997" This is one of the most common support requests. Partners occasionally send an "Overdue Ack Report" email listing ASNs or invoices they say were not acknowledged within the expected window. **Before assuming the 997 is missing, verify the round trip:** 1. **Was the original file received?** Check Flxpoint's inbound logs for the ASN / invoice control number (ISA13 / GS06 / ST02) listed in the overdue report. If it is not in the logs, the partner never delivered it — the issue is upstream of Flxpoint. 2. **Did Flxpoint generate the 997?** Ninety-nine percent of the time the 997 was generated and written to the outbound folder within seconds of receipt. Confirm the file exists in your outbound SFTP directory with the matching control numbers. 3. **Did the partner pick it up?** If the 997 is on the outbound server and the partner says they did not receive it, the issue is on the partner side or in the SFTP connection configuration. Options: - Verify the partner is polling the correct outbound path. - Confirm their whitelist includes the Flxpoint SFTP host and static IP. - If the partner hosts the SFTP, confirm Flxpoint has write credentials to the expected drop path. **Who handles it?** This is operational (SFTP / logs), not parsing. It is worked by the integrations team through backend logs — it is not a Flxpector validation case. When the chatbot is asked about "overdue 997s," it should point the user to this troubleshooting flow and avoid suggesting parser fixes. > **Typical resolution pattern:** "I checked the logs and can confirm the 856 was received and a 997 was uploaded to the FTP. Please verify your outbound pickup path or share an alternative SFTP connection if needed." --- ## Troubleshooting — "Your 997 has an invalid segment separator" The partner opens Flxpoint's 997 and every segment ends in a strange character (`�`, `�`, or a `?`) instead of `~`. Their translator rejects the file with a message like "segment separator qualifier is invalid" and asks for `~`. **What happened.** Flxpoint's 997 reuses the delimiters of the file it acknowledges, terminator included. If the partner's inbound file (usually an 856 or 810) ended its segments with a byte that is not valid UTF-8 (a common one is `0x85`, the NEL control character), Flxpoint read that byte as the Unicode replacement character `U+FFFD` and wrote it back as the 997's terminator. Flxpoint processed the inbound file fine; only the acknowledgement is unreadable. **How to confirm.** Paste the 997 into Flxpector: it reports a single finding, `TOK-003 Invalid segment terminator`, naming the character. The Breakdown tab shows the terminator in red at the end of every row. **Resolution.** 1. The partner cannot fix the root cause on their side because Flxpoint wrote the file. Ask them to send the 997 to support@flxpoint.com (or open the ticket for them) so it can be re-issued. Flxpector's "Apply fix" gives them a readable copy with `~` in the meantime. 2. Ask the partner to end segments in their outbound files with `~` (or another printable ASCII character). That is what stops the next 997 from inheriting the byte. Recommend `~` over `?`: `~` is the X12 convention and `?` is a release character in EDIFACT. 3. Internal: engineering can pin the 997 syntax to `~` in the generator regardless of the inbound file (`dmx-core`, `setAcknowledgment(writer, SyntaxDescriptor)`); until that ships, this section applies. Do not tell the partner "the 997 is only a receipt, nothing to fix": in this case the file itself is malformed and their translator is right to reject it. ### Recommended Separator Values To ensure that the 997s generated by Flxpoint are always parseable by your system, we recommend using standard ASCII characters in the EDI 856 files you send to us. Because the 997 inherits the delimiters from your inbound file, using non-standard characters can cause the acknowledgement to fail. **Best Practices:** - **Segment Terminator:** Use the tilde (`~`). - **Component Separator:** Use the pipe (`|`). - **Consistency:** A reliable way to ensure compatibility is to use the exact same separators that are present in the EDI 850 (Purchase Order) files Flxpoint sends to you. If your system can parse our 850s, using those same characters in your 856 will ensure your system can parse the resulting 997. --- # EDI Envelope — ISA, GS, GE, IEA Source: https://www.edihelpcenter.flxpoint.com/docs/envelope Last updated: 2026-09-02 # EDI Envelope Segments — ISA, GS, GE, IEA ## Overview Every EDI transaction is wrapped in envelope segments. These are consistent across all transaction types (846, 850, 856, 810). ``` ISA ─── Interchange Header (outermost envelope) GS ─── Functional Group Header ST ─── Transaction Set Header ... transaction content ... SE ─── Transaction Set Trailer GE ─── Functional Group Trailer IEA ─── Interchange Control Trailer ``` --- ## ISA - Interchange Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | ISA01 | Authorization Info Qualifier | 2 ID | M | `00` (No authorization info present) | | ISA02 | Authorization Information | 10 AN | M | Not Used (space-filled) | | ISA03 | Security Info Qualifier | 2 ID | M | `00` (No security info present) | | ISA04 | Security Information | 10 AN | M | Not Used (space-filled) | | ISA05 | Interchange ID Qualifier | 2 ID | M | `ZZ` (Mutually Defined) or `01` (DUNS) | | ISA06 | Interchange Sender ID | 15 AN | M | If sender is FLX → `FLXPOINT`. If sender is Vendor → vendor's ISA ID number. **Right-padded with spaces to 15 chars** | | ISA07 | Interchange ID Qualifier | 2 ID | M | `ZZ` (Mutually Defined) | | ISA08 | Interchange Receiver ID | 15 AN | M | If receiver is FLX → `FLXPOINT`. **Right-padded to 15 chars** | | ISA09 | Date | 6 DT | M | YYMMDD format | | ISA10 | Time | 4 TM | M | HHMM format | | ISA11 | Interchange Control Standards ID | 1 ID | M | `U` (US EDI Community of X12, TDCC, UCS) | | ISA12 | Interchange Control Version | 5 AN | M | `00401` | | ISA13 | Interchange Control Number | 9 N | M | Sequential number starting with 1, incremented by 1 per transmission | | ISA14 | Acknowledgment Requested | 1 ID | M | `0` (No Interchange Acknowledgment TA1 requested) | | ISA15 | Test Indicator | 1 ID | M | `P` (Production) or `T` (Test) | | ISA16 | Sub-element Separator | 1 AN | M | `>` (standard) or `:` — must be consistent throughout the file. 992 support emails in 6 months mention delimiter/separator issues. | ### Delimiter Troubleshooting - **Standard delimiters**: segment terminator `~`, element separator `*`, sub-element separator `>` (ISA16). This is what Flxpoint's outbound documents (850, 855, 856, 810) use. **Exception: the 997** reuses the delimiters of the file it acknowledges, terminator and trailing whitespace included. - **Invalid terminator** (Flxpector **TOK-003**): if the character after ISA16 is the replacement character `U+FFFD` (shown as `�` in some editors) or a raw control byte such as `0x85`, the file went through an encoding conversion that corrupted it. Every segment ends with it and most receivers reject the file. Flxpector's "Apply fix" rewrites the terminator to `~`. If the file is a Flxpoint-generated 997, contact support@flxpoint.com with the file attached so it can be re-issued, and switch your own outbound terminator to `~` so the next 997 does not inherit the problem. - **Common issue**: files have line breaks (CR/LF) before `~` — Flxpoint's parser handles this, but be aware - **Unusual delimiters**: if a vendor uses `|` instead of `*`, the ISA header must declare it correctly at the fixed position - **Data containing delimiters**: if product names or descriptions contain `*`, `~`, or `>`, this will break the parser. These characters must be escaped or removed from data fields. ### ISA ID Qualifier Codes (ISA05/ISA07) | Code | Description | |------|-------------| | `01` | DUNS (Dun & Bradstreet) | | `14` | DUNS Plus Suffix | | `30` | U.S. Federal Tax ID | | `32` | U.S. Federal Employer ID (FEIN) | | `ZZ` | Mutually Defined (default) | *X12 defines 30+ qualifier codes but FLX typically uses ZZ.* --- ## GS - Functional Group Header | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | GS01 | Functional Identifier Code | 2 ID | M | See table below | | GS02 | Application Sender's Code | 15 AN | M | Sender's ID | | GS03 | Application Receiver's Code | 15 AN | M | Receiver's ID | | GS04 | Date | 8 DT | M | CCYYMMDD format | | GS05 | Time | 4 TM | M | HHMM format | | GS06 | Group Control Number | 9 N | M | Control number, starting with 1, incremented by 1 | | GS07 | Responsible Agency Code | 2 ID | M | `X` (Accredited Standards Committee X12) | | GS08 | Version | 12 AN | M | `004010VICS` | ### GS01 Functional Identifier Codes > Authoritative code table per the Flxpoint Integrations team. See [Flxpoint Parser Rules](./09-flxpoint-parser-rules.md) for envelope-layer behavior. | Code | Transaction | Notes | |------|-------------|-------| | `IB` | 846 Inventory Inquiry/Advice | | | `PO` | 850 Purchase Order | | | `AD` | 855 PO Acknowledgement | **Canonical** Flxpoint code | | `PR` | 855 PO Acknowledgement | Legacy alias — still accepted by the parser | | `SH` | 856 Ship Notice/Manifest | | | `IN` | 810 Invoice | | | `PI` | 832 Price/Sales Catalog | | | `FA` | 997 Functional Acknowledgment | | ### Accepted Versions (GS08) Flxpoint accepts three variants: - `004010VICS` — **preferred** (matches VICS-specific segments) - `004010` — accepted with a warning (not hard-rejected even if VICS-specific segments are present) - `005010` — accepted ### ISA15 Usage Indicator — Test Mode - `P` = Production - `T` = Test — both are processed by Flxpoint, but the UI (and Flxpector) badges test files with a "Test Mode" pill so they are not mistaken for live orders. --- ## GE - Functional Group Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | GE01 | Number of Included Transaction Sets | 6 N | M | Count of ST segments within the group | | GE02 | Group Control Number | 9 AN | M | **Must match GS06** | --- ## IEA - Interchange Control Trailer | Element | Name | Length | M/O | Value/Notes | |---------|------|--------|-----|-------------| | IEA01 | Number of Included Functional Groups | 5 N | M | Count of GS segments within the interchange | | IEA02 | Interchange Control Number | 9 N | M | **Must match ISA13** | --- ## Control Number Matching Rules | Trailer Field | Must Match | Description | |---------------|-----------|-------------| | SE02 | ST02 | Transaction Set Control Number | | GE02 | GS06 | Group Control Number | | IEA02 | ISA13 | Interchange Control Number | --- ## FLX Envelope Requirements vs Generic X12 | Aspect | FLX Spec | Generic X12 004010 | |--------|----------|-------------------| | ISA05 | ZZ or 01 | 30+ qualifier codes supported | | ISA13 uniqueness | Not required by FLX (best practice) | Some validators enforce | | ISA date format | YYMMDD | YYMMDD (match) | | GS date format | CCYYMMDD | CCYYMMDD (match) | | GS time formats | HHMM | HHMM, HHMMSS, HHMMSSD, HHMMSSDD | --- ## Test vs. Production traffic Two levers distinguish test from production interchanges: | Lever | Test | Production | |-------|------|------------| | **ISA15** (usage indicator) | `T` — processed but badged "Test Mode"; nothing ships for real | `P` — live processing | | **Trading-partner IDs** (ISA06/08, GS02/03) | Often a suffixed test ID (e.g. the production ID + trailing `T`, commonly under qualifier `ZZ`) | The production ID/qualifier agreed with Flxpoint | **Go-live checklist:** flip ISA15 `T`→`P`; switch to the production IDs on BOTH sides at the same time (a one-sided switch means files stop being recognized); keep ISA13 incrementing — never reuse control numbers across the cutover; send one small production file and confirm it processes before full volume. A "missing trading partner profile" notice from a VAN after the switch means the production IDs aren't provisioned on the receiving side yet. --- # EDI Example Files Source: https://www.edihelpcenter.flxpoint.com/docs/examples Last updated: 2026-09-02 # EDI Example Files (from FLX PDF Spec) All examples use 004010VICS format. --- ## 846 Inventory Advice Example **Scenario**: Supplier sending inventory for 3 products. All use SKU as primary identifier. - Product 1 (SKU123): 145 in stock, has UPC and EAN - Product 2 (SKU456): 0 = out-of-stock/backorder, has UPC and EAN - Product 3 (SKU789): 0 = discontinued, SKU only ```edi ISA*00* *00* *ZZ*XXXXXX*ZZ*FLXPOINT*120116*0640*U*00401*000000001*0*P*>~ GS*IB*XXXXXX*FLXPOINT*20180116*0640*1*X*004010VICS~ ST*846*1~ BIA*00*MM*1*20180116~ REF*IA*99999~ LIN**SK*SKU123*EA*1222222222222*UP*222222222222~ PID*F*08***Your product title~ QTY*33*145*EA~ LIN**SK*SKU456*EA*2333333333333*UP*333333333333~ PID*F*08***Another product title. Skipping optional title below~ QTY*33*0*EA~ LIN**SK*SKU789~ QTY*33*0*EA~ SE*12*1~ GE*1*1~ IEA*1*000000001~ ``` --- ## 850 Purchase Order Example **Scenario**: Two POs in one interchange. First includes billing address and item customizations. Second has 2 line items, no billing, Next Day Air. ```edi ISA*00* *00* *ZZ*FLXPOINT *ZZ*123456 *120111*2309*U*00401*000007607*0*P*>~ GS*PO*FLXPOINT*001017078*20180111*2309*7607*X*004010VICS~ ST*850*0001~ BEG*00*SA*75070461**20180111~ CUR*BY*USD~ REF*IA*123456~ PER*EA**TE*8011234567~ DTM*001*20180116~ TD5*****UPS******SI~ N9*CO*10007241899999~ N1*ST*John Smith~ N3*1234 E Main Street~ N4*City*UT*84003~ PER*NT**TE*8011234567*EM*[email redacted]~ N1*BT*John Smith~ N3*1234 E Main Street~ N4*City*UT*84003~ PER*NT**TE*8011234567*EM*[email redacted]~ PO1*0001*1*EA*14.4**UP*123456789159~ PID*F*08***Item Title Here~ PID*F*08***Customization Text : Happy Birthday, Gift Recipient!~ PID*F*08***Custom Image Link : tinyurl.com/80CharacterLimit.................cutoff~ CTT*1~ SE*22*0001~ ST*850*0002~ BEG*00*SA*75070462**20180111~ CUR*BY*USD~ REF*IA*123456~ PER*EA**TE*9999999999~ DTM*001*20180112~ TD5*****any******ND~ N9*CO*10007247199999~ N1*ST*Fake Name~ N3*456 N 200 S~ N4*Nowhereville*UT*84003~ PER*NT**TE*(801)123-4567*EM*[email redacted]~ PO1*0001*1*EA*27.5**UP*123456789951~ PID*F*08***Item Title Here~ PO1*0002*1*EA*27.5**UP*456789111213~ PID*F*08***Item Title Here~ CTT*2~ SE*18*0002~ GE*2*7607~ IEA*1*000007607~ ``` --- ## 856 Ship Notice Examples ### Option #1 (RECOMMENDED): One ASN per shipment, tracking at Pack level (BSN05=0001) ```edi ISA*00* *00* *ZZ*XXXXXX *ZZ*FLXPOINT *120116*0705*U*00401*000000004*0*P*>~ GS*SH*XXXXXX*FLXPOINT*20180116*0705*253*X*004010VICS~ ST*856*3936~ BSN*00*1111111*20020718*0855*0001~ HL*1**S~ TD5**2*UPSN*********SI~ DTM*011*20180116*0855~ N1*SF**92*22222~ HL*2*1*O~ PRF*11123456~ REF*CO*22123456780103~ REF*VN*33333333333333333333~ HL*3*2*P~ MAN*CP*1ZE44444444444444~ HL*4*3*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ SE*16*3936~ ST*856*3937~ BSN*00*11111111*20020718*1234*0001~ HL*1**S~ TD5**2*UPSN*********ND~ DTM*011*20180116*1234~ N1*SF**92*222222~ HL*2*1*O~ PRF*11123457~ REF*CO*22123456780102~ REF*VN*333333333333334444444~ HL*3*2*P~ MAN*CP*1ZE44444444888888~ HL*4*3*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ HL*5*3*I~ LIN*0002*BP*055555111111~ SN1**1*EA~ SE*19*3937~ GE*2*253~ IEA*1*000000004~ ``` ### Option #2: One HL shipment per shipment, single ST/SE, tracking at Pack level ```edi ISA*00* *00* *ZZ*XXXXXX *ZZ*FLXPOINT *120116*0705*U*00401*000000002*0*P*>~ GS*SH*XXXXXX*FLXPOINT*20180116*0705*253*X*004010VICS~ ST*856*3936~ BSN*00*11111111*20180116*1930*0001~ HL*1**S~ TD5**2*UPSN*********SC~ DTM*011*20180116*1930~ N1*SF**92*22222~ HL*2*1*O~ PRF*11123456~ REF*CO*22123456780103~ REF*VN*33333333333333333333~ HL*3*2*P~ MAN*CP*1ZE44444444444444~ HL*4*3*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ HL*5**S~ TD5**2*UPSN*********SC~ DTM*011*20180116*1930~ N1*SF**92*22222~ HL*6*5*O~ PRF*11123457~ REF*CO*22123456780102~ REF*VN*333333333333338888888~ HL*7*6*P~ MAN*CP*1ZE44444444488888~ HL*8*7*I~ LIN*0001*BP*055555555555~ SN1**1*EA~ HL*9*7*I~ LIN*0001*BP*055555511111~ SN1**2*EA~ SE*32*3936~ GE*1*253~ IEA*1*000000002~ ``` ### Option #3: Tracking number at Shipment level (REF*CN), BSN05=0004 (no Pack) ```edi ISA*00* *00* *ZZ*XXXXXX *ZZ*FLXPOINT *120116*0705*U*00401*000000022*0*P*>~ GS*SH*XXXXXX*FLXPOINT*20180116*0705*253*X*004010VICS~ ST*856*3936~ BSN*00*11111111*20180116*2040*0004~ HL*1**S~ TD5**2*UPSN*********SC~ REF*CN*1ZE55555222241598~ DTM*011*20180116*2040~ N1*SF**92*22222~ HL*2*1*O~ PRF*11123456~ REF*CO*22123456780103~ REF*VN*33333333333333333333~ HL*3*2*I~ LIN*0001*BP*055555555111~ SN1**1*EA~ HL*4**S~ TD5**2*UPSN*********D3~ REF*CN*1ZE55555222244444~ DTM*011*20180116*2100~ N1*SF**92*22222~ HL*5*4*O~ PRF*11123457~ REF*CO*22123456780102~ REF*VN*1111111145~ HL*6*5*I~ LIN*0001*BP*044444444444~ SN1**2*EA~ HL*7*5*I~ LIN*0002*BP*044444422222~ SN1**2*EA~ SE*30*3936~ GE*1*253~ IEA*1*000000022~ ``` --- ## 810 Invoice Example **Scenario**: Invoicing for the two POs above. Each has $5.00 shipping charge. Second invoice total ($65) is $5 higher than itemized total ($55 items + $5 shipping) — the extra $5 cannot currently be represented in an 810 segment. ```edi ISA*00* *00* *ZZ*XXXXXX*ZZ*FLXPOINT*120116*0218*U*00401*310000617*0*P*>~ GS*IN*XXXXXX*FLXPOINT*20180116*0218*617*X*004010VICS~ ST*810*53737~ BIG*20180116*123456**75070461~ REF*IA*123456~ REF*DP*0000~ ITD*01*3****20180126*45~ DTM*011*20180116~ IT1*1*1*EA*14.4*QT*UP*123456789159~ TDS*1940~ SAC*C*G821***500~ ISS*1*CA*4*LB~ CTT*1~ SE*12*53737~ ST*810*53738~ BIG*20011109*4857775**75070462~ REF*IA*123456~ REF*DP*0000~ ITD*01*3****20180126*45~ DTM*011*20180116~ IT1*1*1*EA*27.5*QT*UP*123456789951~ IT1*2*1*EA*27.5*QT*UP*123456777777~ TDS*6500~ SAC*C*G821***500~ ISS*1*CA*3*LB~ CTT*2~ SE*13*53738~ GE*2*617~ IEA*1*310000617~ ``` --- # EDI Help Center Overview Source: https://www.edihelpcenter.flxpoint.com/docs/overview Last updated: 2026-09-02 # Flxpoint EDI Overview & General Guidelines ## What is Flxpoint EDI? Flxpoint ("FLX") solves one-to-many integration relationships for retailers and suppliers in **drop shipping** operations. The platform handles Inventory management, Order management, consolidation, and automation. This EDI specification is for **suppliers** connecting via EDI to Flxpoint for their Retail Partners. --- ## Standard Version **004010VICS** is the preferred version for inbound files. Flxpoint's parser also **accepts** `004010` (no VICS) and `005010`: - Files without the `VICS` suffix are processed with a warning, not a hard rejection. - The authoritative source for parser acceptance is [Flxpoint Parser Rules](reference/09-flxpoint-parser-rules.md). - Partners should still standardize on `004010VICS` — it is the cleanest match for the VICS-specific segments Flxpoint expects. --- ## Supported Transactions | Code | Name | Direction | GS-01 Code | Purpose | |------|------|-----------|------------|---------| | 846 | Inventory Advice | Supplier → FLX | IB | Inform retailer of inventory availability | | 850 | Purchase Order | FLX → Supplier | PO | Transmit new orders to supplier | | 855 | PO Acknowledgement | Supplier → FLX | AD | Acknowledge receipt and accept/reject each line | | 856 | Advance Ship Notice (ASN) | Supplier → FLX | SH | Tracking info for shipped orders | | 810 | Invoice | Supplier → FLX | IN | Cost info for retailer to pay supplier | | 832 | Price/Sales Catalog (GIP) | Supplier → FLX | PI | Vendor price and catalog import — supported via GIP (Get Inventory & Price), live first for pharma sources (a pharma distributor, a pharma distributor) | | 997 | Functional Acknowledgement | Both directions | FA | Confirm transaction receipt | ### Transaction Flow ``` Retailer → FLX → [850 Purchase Order] → Supplier Supplier → [846 Inventory] → FLX → Retailer Supplier → [856 ASN/Ship Confirm] → FLX → Retailer Supplier → [810 Invoice] → FLX → Retailer Each direction: 997 acknowledgement returned ``` --- ## Data Communications - **Protocol**: SFTP only. **AS2 is NOT supported.** - Every FLX account includes a dedicated FTP/SFTP account. ### SFTP Directory Structure | Directory | Purpose | |-----------|---------| | `/in` | Supplier places files TO Flxpoint here | | `/out` | Flxpoint places files FOR supplier here | | `/out/archive` | Recommended: supplier moves processed `/out` files here | ### SFTP Rules - Supplier → FLX files go in `/in` directory - FLX processes inbound file, places 997 on `/out` - FLX outbound files (850s, 997s) deposited in `/out` - Supplier should place 997 acknowledgements in `/in` - **Do NOT delete files from `/out`** — archive them instead ### File actions on the Flxpoint side Standard EDI V2 can act on the files itself: **Read**, **Move**, **Append** and **Delete** are available as configured actions on the source integration, rather than every step being something you or your supplier does by hand on the server. This softens the rule above rather than replacing it. Archiving is still the safe default, and deleting a file you have not confirmed as processed is still how a missing order becomes unrecoverable. The difference is that moving a processed file into `/out/archive` can now be part of the integration instead of a manual convention both sides have to remember. Configure the actions on the source integration; if you are not sure which ones your setup already performs, check there before changing anything on the server, because a file moved twice is a file the other side cannot find. - FLX does NOT archive or modify files in `/out` --- ## Interchange ID - Default Qualifier: **"ZZ"** (Mutually Defined) - Default Receiver ID: **"FLXPOINT"** (if no specific ID agreed at setup) - Can use customer's name instead of FLXPOINT --- ## Delimiters (Default) | Delimiter | Character | Decimal | Hex | |-----------|-----------|---------|-----| | Segment Terminator | `~` | 126 | 7E | | Element Separator | `*` | 42 | 2A | | Sub-element Separator | `>` | 62 | 3E | Configurable per job, but these are the defaults. --- ## ISA Control Numbers - **Inbound**: FLX does NOT require unique ISA Control Numbers (but best practice to use them) - **Outbound**: FLX provides sequential ISA Control Numbers --- ## 997 Acknowledgements - FLX **requires** a 997 for each transaction sent to the supplier - FLX **generates** a 997 for each transaction received - 997s are deposited in `/out` directory - FLX does NOT support routing 997s to external destinations - A 997 confirms the transaction was **received**, NOT that the content is correct --- ## Timing / Frequency | Transaction | Recommended | Minimum | Notes | |-------------|-------------|---------|-------| | 846 Inventory | Hourly | Daily | Critical for accurate stock levels | | 850 Purchase Order | Hourly | Daily | Can arrive at any time of day | | 856 Ship Notice | Hourly | Daily | At least daily | | 810 Invoice | Within 24hrs of shipment | Daily | Only for shipped items | --- ## Data Integrity Rules 1. **PO Number and UPC** sent on the 850 MUST be returned on 856 and 810 2. Invoice data accepted **only for shipped items** 3. **UPC/EAN/SKU codes at variant level** must be unique for accurate inventory/order tracking 4. Product catalog info (descriptions, images) must come via flat file (CSV/TAB/Excel), NOT EDI 5. Images provided via HTTPS link in catalog or in shared folder named by SKU/UPC --- ## Contact **EDI Support**: connect@flxpoint.com --- # Flxpector Validation Reference Source: https://www.edihelpcenter.flxpoint.com/docs/flxpector-reference Last updated: 2026-09-02 # Flxpector — EDI Validation Reference This document describes Flxpector's validation logic for Flxpoint EDI files using the X12 004010VICS standard. --- ## File Size Limit Flxpector accepts EDI files up to **5 MB** (about 250,000 segments). Larger files are rejected with "File too large: the limit is 5 MB"; split them into smaller interchanges and inspect each one. Files are read as text, so the limit applies to the text pasted or uploaded, not to a zipped archive. Files over 1 MB are treated as **large files**: - Validation runs exactly the same way, and the verdict (valid / invalid), the counts and every finding are complete. - The Breakdown, Structured and Raw views show segments in blocks of 1,500 with a "Show more" control, and the Issues tab pages findings 300 at a time, so the browser stays responsive on files with 100,000+ segments. - Automatic re-checking while typing is off; click **Inspect File** again after editing. - Ask Tim receives the first 40,000 characters of the file and the first 150 findings as context, so ask about a specific segment or line if it is not in that window. Before 2026-09-01 the limit was 1 MB. --- ## How Validation Works Flxpector validates against **Flxpoint-specific rules**, not just the generic X12 004010 standard. This means: 1. The rules define which segments are **Required (R)**, **Optional (O)**, or **Not Used (N)** 2. The rules define which **element codes are allowed** (e.g., only specific SAC codes) 3. The rules define **element lengths, types, and conditional relationships** 4. Flxpector checks every segment/element against these rules ### Validation Hierarchy ``` Level 1: Structural Validation - Is the envelope valid? (ISA/GS/ST/SE/GE/IEA) - Are control numbers matching? (SE02=ST02, GE02=GS06, IEA02=ISA13) - Are segment counts correct? (SE01, GE01, IEA01) Level 2: Segment Validation - Are all Required (M) segments present? - Are segments in the correct order? - Are segments within allowed loop repetitions? Level 3: Element Validation - Are all Required (M) elements present within each segment? - Do element values match allowed code lists? - Do element lengths meet min/max requirements? - Are data types correct? (ID, AN, N, N0, N2, R, DT, TM) Level 4: Conditional/Relational Validation - C (Condition): If element A present -> elements B,C must be present - E (Exclusive): Only one of elements A,B,C can be present - L (List): If element A present -> at least one of B,C must be present - P (Paired): If any of A,B,C present -> all must be present - R (Required): At least one of A,B,C must be present ``` --- ## Error Types Flxpector Catches ### 1. Missing Required Segments **What**: A segment marked Required/Mandatory is not present in the EDI file. **Example**: Missing `TD5` in 856 (carrier details), missing `BIG` in 810, missing `BIA` in 846. **Severity**: Fatal — transaction will not validate. ### 2. Missing Required Elements **What**: An element within a segment that is marked Mandatory is missing or empty. **Example**: `TD503` (SCAC code) missing from TD5 segment in 856. This is the **#1 failure for 856 files**. **Severity**: Fatal. ### 3. Invalid/Unknown Code Values **What**: An element value doesn't match the allowed code list. **Example**: Using SAC02=`D240` (Freight) when FLX only allows `G821` (Shipping). Using an unrecognized service level code in TD512. **Severity**: Fatal — the code is not in the accepted values. **Deliberate exception — 855 ACK01**: ACK01 (855 line-item status) is **not** whitelisted. Flxpoint's acknowledgement parser never rejects on ACK01 — it maps only `IR`/`R1`/`R2`/`R4` to "canceled" and the accept set to "acknowledged," leaving every other code unmapped (a no-op). Vendors send far more (one high-volume vendor alone sends ~25, e.g. `ROS`/`IB`/`CC`/`R3`/`R7`), so Flxpector only checks that ACK01 is a 2-char value and does **not** flag unrecognized codes — that would be a false positive. ### 4. Incorrect Data Format **What**: Element value doesn't match expected data type or format. **Example**: Date not in CCYYMMDD format, ISA date not in YYMMDD format, numeric field containing letters. **Severity**: Fatal. ### 5. Element Length Violations **What**: Element value is shorter than minimum or longer than maximum length. **Example**: ISA06 not exactly 15 characters (must be right-padded with spaces), ISA13 not exactly 9 digits. **Severity**: Fatal. ### 6. Segments Out of Order **What**: Segments appear in wrong sequence relative to the defined order. **Example**: DTM appearing before BEG in an 850, IT1 appearing in the heading section. **Severity**: Fatal. ### 7. Conditional Rule Violations **What**: Relational conditions between elements are not met. **Example 810 ITD**: If ITD03 (discount %) is present, then ITD04, ITD05, or ITD13 must also be present. **Example 856 N1**: If N1-03 is present, N1-04 is required (Paired condition). **Example 810 CAD**: If CAD07 is present, CAD08 is required. **Example 810 ISS**: If ISS03 (weight) is present, ISS04 (unit) is required. **Severity**: Fatal. ### 8. Control Number Mismatches **What**: Trailer control numbers don't match their header counterparts. **Example**: SE02 != ST02, GE02 != GS06, IEA02 != ISA13. **Severity**: Fatal. ### 9. Incorrect Segment/Group Counts **What**: SE01 doesn't match actual segment count, GE01 doesn't match transaction set count, IEA01 doesn't match functional group count. **Severity**: Fatal. ### 10. Loop Repetition Exceeded **What**: A loop repeats more times than allowed. **Example**: More N1 loops than the max use allows. **Severity**: Warning or Fatal depending on configuration. --- ## FLX-Specific Validation Rules ### 846 Inventory Advice | Check | What Flxpector Validates | Common Failure | |-------|-------------------------|----------------| | BIA01 | Must be `00` (Original) | Wrong purpose code | | BIA02 | Must be `MM` | Wrong report type | | REF01 | Must be `IA` | Wrong qualifier | | LIN02 | Must be `SK`, `UP`, or `EN` | Unsupported qualifier | | LIN03 | Max 48 chars, must be unique | Duplicate SKU across items | | QTY01 | Must be `33` | Wrong quantity qualifier | | QTY03 | `EA` (Each) | FLX accepts simple element format | ### 850 Purchase Order | Check | What Flxpector Validates | Common Failure | |-------|-------------------------|----------------| | BEG01 | Must be `00` | Wrong purpose code | | BEG02 | Must be `SA` | Wrong order type | | CUR02 | Must be `USD` | Wrong currency | | REF01 | Must be `IA` | Wrong qualifier | | TD512 | Must be D3/ND/SC/SI/SP | Unsupported service level | | N901 | Must be `CO` | Wrong qualifier for customer order | | N101 | Must be `ST` (ship-to) or `BT` (bill-to) | Wrong entity code | | PO103 | Must be `EA` | Wrong unit of measure | | PO106 | Must be `SK`, `UP`, or `EN` | Unsupported qualifier | ### 856 Ship Notice | Check | What Flxpector Validates | Common Failure | |-------|-------------------------|----------------| | BSN01 | Must be `00` | Wrong purpose code | | BSN05 | Must be `0001` or `0004` | Wrong hierarchy structure | | **TD502** | **Must be `2` (SCAC)** | **Missing = #1 FAILURE** | | **TD503** | **Must have valid SCAC code** | **Missing carrier = FAIL** | | TD512 | Service level code (required by FLX) | Missing service level | | HL03 | Must be S/O/P/I in correct hierarchy | Wrong level codes | | REF01 at shipment | `CN` for tracking | Wrong qualifier | | MAN01 at pack | `CP` for package tracking | Wrong qualifier | | REF*CN + MAN*CP | **Mutually exclusive** | Both present = error | | N101 | Must be `SF` (Ship From) | Wrong entity | | N103 | Must be `92` | Wrong code qualifier | | LIN02 | `UP`, `EN`, `SK`, or `BP` | Wrong product qualifier | | SN103 | Must be `EA` | Wrong unit | ### 810 Invoice | Check | What Flxpector Validates | Common Failure | |-------|-------------------------|----------------| | BIG01 | Date: current or within 17 months | Future date or too old | | BIG04 | PO Number required | Missing PO reference | | REF*DP | `DP` qualifier with value | Missing department number | | ITD01 | Must be 01/02/05/08/12 | Wrong terms code | | ITD conditionals | Discount fields pairing | Missing paired discount field | | IT103 | Must be `EA` | Wrong unit | | IT105 | Must be QT/LE/WE | Wrong price basis | | IT106 | Must be UP/EN/SK/BP | Wrong product qualifier | | TDS01 | N2 type (implied decimal) | Sending 12.00 instead of 1200 | | SAC02 | **Whitelist: `G821`/`C310`/`D240`/`F050`** | Codes outside the whitelist produce warnings, not errors | | CAD04 | SCAC required if CAD present | Missing carrier code | | CAD07->CAD08 | If CAD07 present, CAD08 required | Missing reference number | | ISS03->ISS04 | If weight present, unit required | Missing weight unit | --- ## Flxpector vs Flxpoint Processing — Decision Matrix Use this to determine what to do when Flxpector validation and Flxpoint processing disagree: | Scenario | Flxpector | FLX | Action | |----------|-----------|-----|--------| | Missing required segment | FAIL | FAIL | Fix it — both reject | | Missing SCAC in TD5 | FAIL | FAIL | Fix it — critical | | QTY03 as simple element | PASS | PASS | FLX accepts simple format | | Non-unique ISA13 | WARN | PASS | Best practice to fix, not required | | Extra CTP segment | PASS | IGNORE | Harmless — FLX ignores it | | SAC code outside G821/C310/D240/F050 | WARN | May skip | Use a whitelisted code; Flxpoint won't auto-rewrite SAC (that would mislabel charge types) | | Strict element lengths | FAIL | PASS (sometimes) | Fix if possible, FLX may forgive | | Control number mismatch | FAIL | FAIL | Always fix | | Conditional rule violation | FAIL | FAIL (usually) | Fix it | --- ## Key Takeaway **Flxpector validates against FLX-specific rules that are a superset of what Flxpoint processes.** Files that pass Flxpector will work in FLX. Flxpector also catches issues that Flxpoint's processing might silently ignore — catching these early prevents downstream problems. --- # Flxpoint Parser Rules — Authoritative Reference Source: https://www.edihelpcenter.flxpoint.com/docs/parser-rules Last updated: 2026-09-02 # 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. > This is **Flxpoint's implementation guidance** for exchanging documents with Flxpoint — not a reproduction of the X12 standard. X12 is a registered trademark of X12 Incorporated; the underlying EDI standards are copyrighted by X12 and available at [x12.org](https://x12.org). 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) | Version | Flxpoint behavior | |---------|-------------------| | `004010VICS` | **Preferred** — X12 Retail VICS. Accepted. | | `004010` (no VICS) | Accepted + **warning**. Not hard-rejected even when VICS-specific segments are present. Partners should ideally switch to `004010VICS`. | | `005010` | Accepted. | | Anything else | Warning. Processing depends on whether the segment structure still parses. | 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**. ### Segment terminator (the character after ISA16) - **Legal:** one printable ASCII character (`~` by convention; `^` and `|` are also seen) or a line break. Flxpector reads whatever follows ISA16 and reports it in the result's `delimiters`. - **Corrupted terminator** (the Unicode replacement character `U+FFFD`, its Latin-1 rendering `�`, or any multi-character run): Flxpector **error TOK-003**. The original byte was lost during an encoding conversion, so no receiver can be expected to parse the file. Auto-fix `replaceTerminator` rewrites every terminator to `~`. - **Raw non-ASCII or control byte** (e.g. `0x85` NEL): Flxpector **warning TOK-003**, naming the byte in hex. Flxpoint's parser accepts the file (the core library reads it as UTF-8 with replacement, so the byte becomes `U+FFFD` internally), but that `U+FFFD` is exactly what comes back to the partner in the 997 (see section 2). - Flxpector splits the file on the whole run, so the rest of the report stays accurate: no "Unexpected segment" cascade, no false "missing IEA". - Production facts (`dmx-core`, verified 2026-08-25): `EDIToXML` reads inbound files as UTF-8 with replacement; the 997 generator (`edireader` `AnsiFAGenerator`) uses the inbound file's terminator when no syntax descriptor is set; the 997 is written with the JVM default charset. Real case: Deflecto 997, `tests/real-cases/README-deflecto-997.md`. ### GS01 — Functional Identifier Code | Code | Transaction | |------|-------------| | `IB` | 846 Inventory | | `SH` | 856 Ship Notice | | `PO` | 850 Purchase Order | | `PR` | 855 PO Acknowledgement (standard X12 code; `AD` is tolerated as a legacy alias) | | `IN` | 810 Invoice | | `FA` | 997 Functional Acknowledgement | | `PI` | 832 Price/Sales Catalog | | `RS` | 870 Order Status Report | GS01 for the 855 is **`PR`** per every authoritative spec on file 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. **The delimiters of a Flxpoint 997 are inherited from the file it acknowledges** (element separator, sub-element separator, terminator, and the whitespace after the terminator). A vendor whose 856 ends segments with a non-UTF-8 byte therefore receives a 997 whose segments end in `U+FFFD`, which their translator rejects ("segment separator qualifier is invalid"). Flxpector flags that 997 as **TOK-003** and routes the vendor to support@flxpoint.com, because only Flxpoint can re-issue the file; the vendor's own fix is to end segments with `~`. Engineering fix pending: pin the 997 syntax to `~` in `dmx-core` (`setAcknowledgment(writer, SyntaxDescriptor)`), after which the inheritance sentence here, in the 997 doc and in `tokenizer.ts` (`TODO(dmx-core)`) comes out. --- ## 2b. 870 Order Status Report — cancellations only The 870 is supported for **item cancellations exclusively** (code-verified 2026-07-08 against the production standard parser): every PO1 loop must carry `ISR*IC`; any other ISR01 rejects the file (`Illegal ISR segment, ISR01 `). Structure enforced by production: `BSR*2*PP` immediately followed by `REF*IA*`; HL levels `O`/`I` only (any other level code rejects); each order HL = one `PRF` + `REF*CO` + `REF*VN` (both with values, or the order can't be identified and the file rejects as unmapped); each item HL = `PO1` + `ISR` pairs, with `PO106` restricted to `UP`/`EA` (other qualifiers crash the job) and integer `PO102`. Flxpector mirrors all of this (schema + FLX-870-001..004). ## 3. 832 Price / Sales Catalog (GIP) As of mid-2026 the 832 is a **supported catalog-import document** ("GIP" — Get Inventory & Price) **for integrations specifically configured for it** (currently the two pharma catalog integrations). ⚠️ **There is no generic 832 parser yet**: the Standard EDI V2 integration rejects any 832 with `Unmapped doc type 832` (code-verified 2026-07-08; the generic GIP-832 is approved and in the engineering pipeline as of Jul 2026 — this section flips when it ships). The structure below is therefore the **target spec** for the Standard rollout (the standard GIP spec draft) — the currently-enforced behavior is the pharma parsers': items keyed on NDC qualifiers, multiple CTPs/PIDs per LIN, unknown CTP02 codes silently ignored (no whitelist), and the "LIN identifier priority" chain is spec-only (not in code today). It decouples catalog data (SKUs, descriptions, pricing) from the live-quantity 846 feed. **Defined segment structure:** | Area | Segments | Notes | |------|----------|-------| | Header | `ST`, `BCT` (`BCT01 = PC` Price Catalog), `REF`, `DTM` | REF qualifiers: `ACC`, `FL`, `2K`, `X9` | | Parties | `N1*VN` (Vendor), `N1*BY` (Buyer) | | | Item ID (LIN loop) | `LIN` | Identifier qualifier priority: `VN` → `UP` → `ND` → `MG` → `SK` → `VC` → `EA` → `UN` | | Product | `PID` (descriptions), `PO4` (packaging, e.g. 1 case / 100 each) | | | Validity dates | `DTM*092` (start), `DTM*093` (end) | | | Pricing | `CTP` | Price-type qualifiers below | | Additional | `G53`, `TD4`, `G39`, `CTT` | | **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 the standard GIP spec draft, 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**. > Generic envelope + X12 validation still applies; full GIP-832 schema validation in Flxpector is incremental as the standard finalizes. --- ## 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):** | Qualifier | Meaning | |-----------|---------| | `011` | Shipped | | `017` | Estimated Delivery | | `002` | Delivery Requested | **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 + 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: | Result | ACK01 codes | |--------|-------------| | **Accepted** (line acknowledged) | `AA`, `AC`, `AR`, `IA`, `IQ`, `DR`, `IP`, `IC` | | **Canceled** (line rejected) | `IR`, `R1`, `R2`, `R4` | 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 (the production parser) 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 — one high-volume vendor sends ~25 codes including `ROS`, `IB`, `CC`, `R3`, `R7`. **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 one high-volume vendor via an internal ticket). **Vendor variants (custom parsers, not generic):** the pharma catalog integrations add `IS` = Accepted with Substitution (substitute identifiers ride in later ACK positions, `ACK07/08`–`ACK13/14`, qualifiers `ND`/`N4`/`VC`/`VN`/`UP`); a pharma distributor treats `IW` (On Hold) as accepted. `IB` (Backordered) is **not** supported by the generic parser or a pharma distributor. 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 (a pharma distributor, a pharma distributor) use `VN` at PO106 via custom parsers; other vendors vary (a medical-supplies vendor/a pharma distributor `VC`/`VN`/`VP`, one high-volume vendor positional). ### SAC02 — 810 Service / Allowance / Charge Codes The complete production set (verified directly in the parse-time enum, 2026-07-08 — descriptions are production's own): | Code | Production meaning | SAC01 indicator | |------|--------------------|-----------------| | `G821` | Shipping Charge (primary code) | `C` (charge) | | `D240` | Freight Charge | `C` | | `AFEE` | Generic Fee | `C` | | `G740` | Service Charge | `C` | | `H750` | Sales Tax | `C` | | `D500` | Handling Charge | `C` | | `C310` | Discount | `A` (**allowance** — the amount subtracts) | **Any other code — including `F050` — rejects the file** with `SAC01 code not supported`. ⚠️ The April spec listed F050 as valid; that was stale — the production whitelist has never included it (corrected 2026-07-08, code- verified). A wrong SAC01 for a known code (e.g. `SAC*C*C310`) hits the same reject, because production matches the code+indicator **pair**. SAC05 (amount) is required and is **always implied 2-decimal** (even with a `.`). --- ## 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. | Segment / Rule | Rule | Source | |----------------|------|--------| | **BIA01** (846) | Must be exactly `00` | **FLX-Custom** — X12 allows `05` (Replace) | | **BIA02** (846) | Must be exactly `MM` | **FLX-Custom** — X12 allows `DD` (Distributor), `DR` (Delivery) | | **REF*IA** (846) | Mandatory; qualifier must be `IA` | **FLX-Custom** — X12 marks REF as optional | | **REF02** (846/850) | Vendor number, **max 30 chars** (raised from 10 in May 2026) | Length cap is FLX; the underlying X12 max is 30. Files with vendor IDs of 11–30 chars are now accepted. | | **LIN ↔ QTY** (846) | Every `LIN` must be followed by a `QTY` segment | X12-Standard — a `LIN` with no quantity aborts the Flxpoint inventory job (`No QTY segment found to match LIN with *`). Flagged by Flxpector as **FLX-846-006**. | | **846 quantity** | **One available quantity per SKU** (`QTY01=33`, one `QTY` per `LIN`) | X12-Standard — the parser does **NOT** support per-warehouse / per-location quantity breakdown (no `SDQ`, no multi-QTY per location); it stores a single total per item even when the file carries warehouse detail. Confirmed vs the production parser + engineering (2026-07-02). | | **846 QTY02 / QTY03** | `QTY02` must be a whole number and `QTY03` must be `EA`; a missing or invalid value **skips that line item** (the file processes and the other items import) | X12 marks both mandatory. The FLX consequence comes from the parser (`itemIsValid` logs a warning and drops the item), the same as a malformed CTP or PID01 not `F`. Flxpector warns; it was a blocking error until 2026-09-01. | | **846 LIN qualifiers** | Validity set `UP` / `EA` / `SK` / `EN` (every LIN qualifier position) | X12-Standard — verified vs the parser; `EA` (EAN) is valid in all positions. | | **846 CTP** | If present: `CTP02` ∈ {`WHL`,`UCP`} + numeric `CTP03`, else the item is **skipped** | Corrected 2026-07 (was documented "ignored"): the parser reads CTP03. Not a reliable price channel — keep pricing in the price feed. | | **LIN02** | 846: must be `UP`/`EA`/`SK`/`EN` (**EA is valid** — EAN); an invalid LIN02 or an empty LIN03 **skips that line item** (file processes; Flxpector warns since 2026-09-01). 856: `SK`/`UP`/`EN`/`BP`. LIN04–07 in the 846 are **not validated** (unknown qualifiers / half pairs silently ignored, item imports) | X12-Standard — corrected 2026-07-08 vs the parser (`EA` was falsely warned on, `BP` falsely accepted for 846) | | **846 loop grammar** | Strict `LIN → [PID] → [CTP] → QTY`: a foreign segment inside the loop, a CTP before the PID, or a **second QTY under one LIN** (per-warehouse pattern) aborts the job the same as a missing QTY | X12-Standard — flagged as FLX-846-006 / FLX-ALL-006 | | **846 PID01** | Must be `F` — anything else skips the line item (file processes) | FLX-Custom — warning FLX-846-007 | | **855 PO1 positional qualifiers** | Standard parser is strict positional beyond PO106: `BP`@PO108, `EN`@PO110, `MG`@PO112, `UP`@PO114, `VP`@PO116 — mismatch rejects the file (`Unknown Buyers Qualifier PO108 value X`). Vendor-specific parsers differ | FLX-Custom — warning FLX-855-002 (vendor-variance) | | **855 ACK per line** | Standard parser fails the whole file if any PO1 loop lacks an ACK; a second ACK in one loop is also a reject | FLX-Custom — FLX-855-001 (warning) + FLX-ALL-006 ACK entry | | **810 invoice number** | `BIG02` **or** `REF*IV*` — blank BIG02 alone is fine when REF*IV exists (`No Invoice Number found in BIG segment or REF segment with REF01 = IV`) | FLX-Custom — FLX-810-009. Corrected 2026-07-08: BIG02 alone was wrongly hard-required | | **810 IT102** | Must be a plain integer — decimals (`2.0`) reject the file (`Quantity is expected in IT102 value`) | FLX-Custom — FLX-810-010 | | **810 SAC01↔SAC02** | `C310` = allowance (`SAC01=A`, amount subtracts); other mapped codes = charge (`SAC01=C`). Mismatch rejects. SAC05 required (implied 2-decimal, always) | FLX-Custom — FLX-810-012 | | **SN102** (856) | Must be a positive integer > 0 | X12-Standard (ASN business logic) | | **CTT** (846) | **Not ignored: it rejects the whole file.** The 846 parser never consumes CTT, so it is left over and the transaction fails as unmapped, importing zero items. Remove it and lower `SE01` by one | FLX-Custom — FLX-846-005 | | **REF*DP** (810) | The FLX PDF spec marks it mandatory with value `0000` — but the production parser removes all REF segments **unread** and a file without REF*DP provably processes (2026-07-08 code audit). Flxpector flags it as a **warning** (spec hygiene), not an error | **FLX-Custom (spec-only)** | | **TD5** (856) | Required; TD502=`2`, TD503 SCAC required, TD512 service level required. TD512's VALUE is stored **verbatim** by production (a real file with TD512=`31` processed) — the standard codes `D3`/`ND`/`SC`/`SI`/`SP` are recommended (Flxpector warns on others, FLX-856-018) but not enforced | **FLX-Custom** | | **Item Tracking Reachability** (856) | Every item HL must have reachable tracking (REF*0L/CN/TN at shipment, or MAN*CP/GM at pack/item) | **FLX-Custom** (runtime mapper requirement) | | **HL parent linkage** (856) | Every HL below the Shipment level must carry HL02 = its parent's HL01 (Order→Shipment, Pack→Order, Item→Pack or Order), and HL02 must reference an existing HL01. Only the root (Shipment) HL leaves HL02 empty — written `HL*1**S` with the blank separator present. | X12-Standard — a blank HL02 on an item HL is a **hard reject** (`Invalid HL segment - HL01 and HL02 must both be present`); a blank or dangling HL02 on order/pack HLs breaks linking and fails as `Missing orders for shipment` / `Missing packs for order`. Flagged by Flxpector as **FLX-856-015** (blank) / **FLX-856-016** (broken reference). | Flxpector tags every validation finding with this provenance so the UI can badge FLX-Custom rules distinctly. --- ## 5b. Cross-check against the 850 (Flxpector feature) The inspector can validate an 855/856/810 **against the original 850** (paste the PO into the "Cross-check with your 850" panel). Findings are advisory (warnings/info — partial shipments and invoices are legitimate): | Rule | Checks | |------|--------| | FLX-XCHK-001 | PO number (856 PRF01 / 810 BIG04 / 855 BAK03) matches the 850 BEG03 | | FLX-XCHK-002 | Every item identifier exists on the 850 PO1 lines (exact value, leading zeros matter) | | FLX-XCHK-003 | Shipped / invoiced / acknowledged quantity per item ≤ ordered quantity | | FLX-XCHK-004 | 856 TD5 service level echoes the 850's requested service level | | FLX-XCHK-005 | Order lines not covered by the document (warning on the 855 — it must answer every line; info elsewhere) | ## 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: ` — e.g. `S: CTT`, `S: I PMG`, `S: LS`, `S: PID` - `Unmapped loops found in transaction: L: ` — e.g. an unmapped `N1` loop in an 810 **An unmapped-segment message always means the file was rejected.** It is not a cosmetic notice. Every parser that ends with `requireEmptyTransaction` (846, 850, 810, 855, 856, 870) throws `EdiUnmappedArgumentException` on whatever is left over, and `EdiFileDownloader` catches it per file, marks the file with the parsing error and skips it. Line items already parsed into memory are discarded with the throw, so **zero rows import from that file**. Other files in the same run are unaffected. Position inside the transaction does not change this. A foreign segment before the first detail loop, in the middle, or trailing at the end all reach the same throw. Position only changes which segments the message lists. Known cases: | Case | Behavior | |------|----------| | `CTT` in **846** | **Rejects the whole file. Zero items import** (error, **FLX-846-005**). The 846 parser never consumes CTT, unlike the 810 and 855, so it is left over and throws. Partners must send the 846 without CTT and lower `SE01` by one. Source-verified in `dmx-core` 2026-08-13 (PartXpress / Stens case); this supersedes the earlier "items still import, it is only a UI message" guidance, which was wrong. | | Any other segment in **846** outside `BIA/REF/LIN/PID/CTP/QTY` | Generalized sweep **FLX-846-008**. Error wherever it sits: before the first LIN, inside the detail area, or trailing. All import ZERO items. | | Custom loops in **846** (e.g. `LS` / `LE` wrappers, `I PMG`) | Reject the file as unmapped; the integration mapping must be extended or the partner must drop them (one vendor, mid-2026). | | **855** header segments beyond `BAK` + `N1` loop (incl. `PER`, `REF`, `DTM`, `ITD`) | The standard 855 consumes only BAK + N1 loops + PO1 loops + CTT — the rest rejects the file as unmapped. Flagged as warning **FLX-855-003**, not error, only because Flxpector cannot tell which integration the file is bound for and vendor-specific 855 parsers do consume more. On the Standard EDI V2 integration, treat it as a rejection. | | Unmapped `N1` loop / `FOB` / `CUR` / summary segments before `TDS` in **810** | Rejects the file, surfacing as `Unmapped loops found in transaction: L: N1` / `S: `. Flagged as warning **FLX-810-013** for the same vendor-variance reason as the 855 row. | | Anything in an **832** outside `BCT/REF/DTM/N1–N4/LIN/G53/PID/PO4/TD4/CTP/G39/CTT` | Rejects as unmapped in both 832 integrations — warning **FLX-832-002**. | ### CTT count validation (when CTT is mapped) | Transaction | CTT behavior | |-------------|--------------| | **850** | CTT01 must equal the number of PO1 segments. Mismatch is an error (FLX-generated outbound). | | **855 / 810** | Production removes CTT **without reading CTT01** (fixture-proven, 2026-07-08) — a wrong or blank count processes fine. Flxpector flags a mismatch as a **warning** only. | | **856 / 997** | CTT is not used. | | **846** | CTT is **not** mapped at all, so there is no count to validate. Its mere presence rejects the file (FLX-846-005). | --- --- _Last reviewed by the Flxpoint Integrations team._ --- # Validation Notes & Known Differences Source: https://www.edihelpcenter.flxpoint.com/docs/validation-notes Last updated: 2026-09-02 # Validation Notes & Known Differences ## Overview Flxpoint's EDI guides define specific validation rules. Generic X12 validators and other inspector tools sometimes apply stricter — or simply different — rules than what Flxpoint actually accepts. This document maps every known difference so you can build files that pass cleanly in Flxpoint. The key insight: **a file that passes a generic X12 inspector may still be rejected by Flxpoint if it does not match the FLX spec, and vice versa.** Always build to the FLX PDF spec. --- ## Version Standard Authoritative rule per the Flxpoint Integrations team. See [Flxpoint Parser Rules](../reference/09-flxpoint-parser-rules.md) for the full envelope spec. | Aspect | Flxpoint | |--------|----------| | **Preferred version** | `004010VICS` — matches Flxpoint's VICS-specific segments | | **`004010` (no VICS)** | Accepted; Flxpector emits a warning, parser does not reject | | **`005010`** | Accepted; Flxpector emits a warning if you want to standardize | | **Hard rejects** | Structural parse failures only (ISA06/ISA08 padding, GS06↔GE02 / ST02↔SE02 mismatches, duplicate ISA13) | Some integrations enforce stricter version requirements than the global parser. If your file fails with a version error, confirm with your Flxpoint integration contact whether a strict version is configured for your account. --- ## Cross-Transaction Summary ### Things That PASS in Flxpoint but May FAIL in Stricter X12 Validators | # | Transaction | Issue | Why It May Fail Elsewhere | |---|-------------|-------|---------------------------| | 1 | 846 | QTY03 sent as simple `EA` element | Strict X12 validators expect composite C001 structure | | 2 | 856 | Missing TD512 service level code | Some validators treat it as required in certain configs | | 3 | 810 | SAC with only `G821` code | Other validators check against a broader code list | | 4 | All | ISA Control Numbers not unique | FLX does not require uniqueness; some validators do | | 5 | All | Loose element length enforcement | Some validators strictly check min/max lengths. **Update (Apr 2026):** Flxpector now validates N102 (name) ≤ 60 chars, N401 (city) ≤ 30 chars, N402 (state) = 2 chars, N403 (zip) ≤ 15 chars via FLX-ALL-007 | ### Things Generic X12 Allows but Flxpoint May NOT Process | # | Transaction | Issue | Why FLX May Reject/Ignore | |---|-------------|-------|--------------------------| | 1 | 810 | SAC codes outside the whitelist (AFEE, G740, H750, etc.) | SAC02 whitelist: `G821`/`C310`/`D240`/`F050`. Codes outside this list are warned on, not auto-rewritten. | | 1b | 846 | CTT segment | **Flxpoint rejects the entire file and imports zero items**, surfacing `Unmapped segments found in transaction: S: CTT`. Stedi is right to flag it. Flxpector reports it as an error (FLX-846-005): send the 846 without CTT and lower `SE01` by one. (Corrected 2026-08-13 against the `dmx-core` parser. Supersedes both the original "Flxpoint ignores CTT entirely" note and the mid-2026 "items import, it is only a UI message" revision. Both were wrong.) | | 1c | 846 | LIN with no QTY | Every `LIN` must be followed by a `QTY`; otherwise the inventory job aborts with `No QTY segment found to match LIN with SK*` (FLX-846-006). | | 1d | all | Any unmapped segment/loop | Surfaces as `Unmapped segments/loops found in transaction: S/L: ` (e.g. custom `LS`/`I PMG` loops, unmapped `N1` loop in 810). Remove them or have the integration extend its mapping. | | 2 | 846 | CTP pricing segment (UCP/WHL) | Not in FLX PDF; ignored | | 3 | 810 | CTP pricing at detail level | Not in FLX PDF; ignored | | 4 | 810 | SAC at detail level (per-item charges) | Not in FLX PDF; only summary-level SAC | | 5 | 850 | Multiple PO1 product ID qualifier pairs (up to 6) | FLX PDF shows single pair | | 6 | 850 | N2 (additional name) segment | Not in FLX PDF | | 7 | 856 | Extra ISA qualifier codes beyond ZZ | FLX typically uses ZZ | --- ## Per-Transaction Detailed Notes ### 846 Inventory Advice | Segment/Element | Flxpoint | Generic X12 | Note | |-----------------|----------|-------------|------| | QTY03 structure | Simple element `EA` | Composite C001 with sub-components | Strict validators may reject simple format | | CTP segment | Not present | Optional (UCP/WHL pricing) | FLX ignores | | PID max use | Unspecified | 200 | Limit difference | | LIN conditional pairs | LIN04-07 optional | Same with strict conditional enforcement | Strict validators check pairing | ### 850 Purchase Order | Segment/Element | Flxpoint | Generic X12 | Note | |-----------------|----------|-------------|------| | PO1 ID pairs | Single pair (PO106/PO107) | Up to 6 pairs (PO108-PO117) | FLX uses one pair only | | PO1-08 qualifiers | Not in PDF | BP, MG, VP, UP, EN | Not used by FLX | | N1-03/N1-04 | Not in PDF | Optional ZZ qualifier + ID code | Not used by FLX | | N2 segment | Not in PDF | Optional additional name info | Ignored by FLX | | PER heading | Only seller phone (EA) | EA + NT contact types | FLX uses EA only | | TD5 elements | TD505 + TD512 only | Full TD5 spec | FLX uses simplified subset | ### 856 Ship Notice | Segment/Element | Flxpoint | Generic X12 | Note | |-----------------|----------|-------------|------| | TD5 shipping provider | Required (SCAC) | Required (SCAC) | Missing provider = FAIL everywhere | | TD512 service level | Mandatory in FLX | Often optional | **FLX stricter** | | REF/MAN exclusivity | Mutually exclusive | Enforced | Match | | LIN02 qualifiers | UP, EN, SK, BP | Typically SK, UP | FLX accepts more options | | BSN05 structure codes | 0001, 0004 | 0001, 0004 | Match | ### 810 Invoice | Segment/Element | Flxpoint | Generic X12 | Note | |-----------------|----------|-------------|------| | REF*DP | Mandatory (fixed `0000`) | Optional variant | **FLX stricter** | | SAC codes | Only `G821` (Shipping) | AFEE, C310, D240, G740, G821, H750 | **FLX limited** | | SAC at detail level | Not supported | Allowed | Ignored by FLX | | CTP at detail level | Not supported | Allowed | Ignored by FLX | | IT1 extra ID pairs | Single pair | Multiple pairs possible | FLX uses one pair | | IT104 format | Real number (15.95) | Type R | Match | | TDS format | Implied decimal N2 | Implied decimal N2 | Match | | BIG01 date validation | Current or within 17 months | Same | Match | --- ## Critical Failure Points These are the most common reasons EDI files get rejected: ### 1. Missing Shipping Provider (856 TD5) **If the SCAC code is missing, the 856 fails.** - TD502 must be `2` (SCAC qualifier) - TD503 must have a valid SCAC code (e.g., `UPSN`, `FEDX`) ### 2. Strict Conditional Element Enforcement - If PER-03 present → PER-04 required (and vice versa) - If ISS-03 present → ISS-04 required - If CAD-07 present → CAD-08 required - ITD discount field dependencies ### 3. Control Number Mismatch - SE02 must match ST02 - GE02 must match GS06 - IEA02 must match ISA13 ### 4. Element Length Violations - ISA06/ISA08: exactly 15 chars (right-padded with spaces) - ISA13: exactly 9 digits (left-padded with zeros) - Various ID fields with specific length requirements --- ## Recommendations for Suppliers 1. **Build to the FLX PDF spec** as the primary reference 2. **Validate against Flxpector** for structural correctness 3. **Always include**: SCAC code in TD5, service level code, matching PO numbers and item codes 4. **Prefer `004010VICS`** — plain `004010` and `005010` are also accepted (with warnings), but `004010VICS` is the cleanest match for Flxpoint's VICS-specific segments