Going Live with Flxpoint EDI

Purpose

The path from first contact to production for a trading partner exchanging EDI with Flxpoint: connection, identifiers, testing, document order, checks, and what to do when a file is rejected.

How It Works

Flxpoint exchanges X12 files with you through two folders on an SFTP server. Flxpoint writes purchase orders (850) and functional acknowledgements (997) into one folder and reads your documents (846, 855, 856, 810, 870, and your 997s) from the other. Nothing is pushed in real time: Flxpoint reads and writes files when a job on the Flxpoint source runs, on the schedule set for that job. Going live means agreeing on the connection and the interchange IDs, running test orders end to end, checking your files, and then switching to production values on both sides at the same time.

The Path to Production

Once these first steps are done, an EDI specialist is assigned to help you through testing.

Connectivity

Protocol

Flxpoint exchanges EDI files over SFTP. AS2 and VAN connections are not supported.

Server and folders

The SFTP server is either an account Flxpoint provides or a server you host. If you host it, send Flxpoint the host, port, username, password, and the two folder paths.

• Keep the two folders separate. Flxpoint reads every file it finds in the inbound folder.
• One inbound folder holds every document type. Flxpoint reads the transaction set (ST01) inside each file and routes it to the matching job, so you do not need a folder per document.
• Only the inbound folder itself is read, not its subfolders. An archive subfolder inside the inbound folder is safe.
• What happens to your files after Flxpoint reads them is a setting on the Flxpoint source: by default they are left where they are; Flxpoint can instead move them to a folder you name, delete them, or rename them with a suffix (.processed unless another suffix is set). Ask which one your connection uses before you build your own cleanup.
• Files that were rejected, and files that hold only 997s, are never moved, deleted or renamed, whatever that setting is: the setting only acts on files that carried a document Flxpoint applied. A file still in the inbound folder on a "move" or "delete" connection is worth a look.
• Flxpoint does not move or delete files in the outbound folder. Download them and move them to an archive folder (for example /out/archive) rather than deleting them, so both sides can look a file up later.

File names

• Flxpoint's 850s are named <PO number>-850-<9-digit control number>.edi, one purchase order per file.
• Flxpoint's 997s are named 997_ followed by the name of the file they acknowledge, so you can match each 997 to the file you sent.
• Your files can use any name, but every file needs a new name. Flxpoint skips a file whose name matches one it already downloaded from you since two days before the job's previous run (upper and lower case are treated as the same). A corrected file re-sent under the old name can be skipped.
• Keep the upload time as the file's modified time. Flxpoint only looks at files modified after one day before the job's previous run (seven days back on a job's very first run). A file uploaded with an older, preserved timestamp can fall outside that window and never be read.

Encoding and delimiters

• Send plain ASCII or UTF-8. Flxpoint reads every inbound file as UTF-8; a byte from another encoding is replaced, which can corrupt the segment terminator and with it the whole file.
• Flxpoint's 850s end segments with ~ and separate elements with *. The sub-element separator in ISA16 is set per connection, so read it from ISA16 instead of assuming one.
• Flxpoint's 997 reuses the delimiters of the file it acknowledges, segment terminator included.

When files move

Flxpoint picks up and drops files when the jobs on the Flxpoint source run, on the schedule configured for each job; there is no continuous polling. The Flxpoint EDI standard recommends exchanging every transaction hourly, and at least daily, and asks for invoices within 24 hours of shipment.

• A run of any inbound job downloads all new files in the inbound folder and writes the 997 for each file it can read, even when that file belongs to another job; the other job picks it up on its own run.
• The job that sends orders writes each 850 to the outbound folder and retries a failed upload. Each 850 is checked by parsing it back before it is uploaded.

Identifiers (ISA/GS)

Each Flxpoint source stores four values: Flxpoint's qualifier and ID, and your qualifier and ID. The Flxpoint EDI standard uses qualifier ZZ (Mutually Defined); the IDs are agreed at setup. Send yours by email in the form ZZ:12345678 and confirm the ID Flxpoint will use before testing starts.

What Flxpoint's 850 carries

If Flxpoint re-sends the same purchase order, the file keeps its original control number and file name, so a repeated ISA13 on an 850 means a re-send of that order.

What your files should carry

• Mirror the 850: your qualifier and ID in ISA05/ISA06 and GS02, Flxpoint's in ISA07/ISA08 and GS03, exactly as they appear on the 850s you receive.
• ISA13: increment it for every interchange. Flxpoint does not reject a repeated ISA13, but unique numbers are what let both sides find a file when something needs research. Flxpector flags two interchanges in the same file that share an ISA13.
• ISA09/ISA10: send the real date and time. When several 846 files arrive between two runs, Flxpoint uses the one with the latest ISA date and time (unless your source is set to read inventory from multiple files).

ISA*00*          *00*          *ZZ*FLXPOINTID     *ZZ*SUPPLIERID     *261006*1200*U*00401*000000123*0*P*:~
GS*PO*FLXPOINTID*SUPPLIERID*20261006*1200*0123*X*004010VICS~

Envelope of an 850 from Flxpoint (placeholder IDs). Your 855, 856 and 810 swap the two IDs.

Test vs Production

The ISA15 usage indicator works differently in the two directions.

Flxpector shows a Test Mode badge on a file whose ISA15 is T, so you can see at a glance which value a file carries before you upload it.

Document Flow

The order of documents for a drop-ship order on a Flxpoint Standard EDI connection:

You       → [846 Inventory]            → Flxpoint   (on your own schedule, independent of orders)
Flxpoint  → [850 Purchase Order]       → You
You       → [997 for the 850]          → Flxpoint
You       → [855 PO Acknowledgement]   → Flxpoint
You       → [856 Ship Notice]          → Flxpoint
You       → [810 Invoice]              → Flxpoint
Flxpoint  → [997]                      → You        (for every file of yours Flxpoint can read)

Return the PO number and the item identifiers exactly as they appear on the 850: they are how Flxpoint connects your 855, 856 and 810 to the order.

Checking Files with Flxpector

Flxpector is the EDI inspector on this site. Run every test file through it before you upload, and keep using it after go-live whenever a file is rejected. It checks:

• Delimiters and terminator — the separators declared in ISA, and a segment terminator damaged by an encoding conversion.
• Envelope — ISA and GS formats (ISA06/ISA08 padded to 15 characters, YYMMDD/HHMM dates and times, GS01 matching ST01, GS07 = X, the GS08 version), and the ISA15 value.
• Control numbers and counts — SE02 = ST02, GE02 = GS06, IEA02 = ISA13, and the SE01, GE01 and IEA01 counts; a repeated ISA13 inside one file is flagged as a warning.
• Transaction rules — required segments and elements, allowed codes, lengths and formats for the 846, 850, 855, 856, 810, 870 and 997, following the rules of Flxpoint's parser. An unsupported transaction set (such as the 860) is reported as an unknown transaction type.
• Cross-check with your 850 — for an 855, 856 or 810, paste the original 850 and Flxpector compares the PO number, the item identifiers, the quantities, the shipping service level and which order lines are covered.

Flxpector checks the file, not the connection. It cannot tell whether the PO is still open in Flxpoint, whether your IDs match what was agreed, or whether the file reached the right folder. Those are covered by the checklist below.

See the Flxpector Validation Reference for every rule.

Go-Live Checklist

Connection

1. Both sides have tested the SFTP login, and Flxpoint can read the inbound folder and write the outbound folder.
2. Inbound and outbound are different folders.
3. You know what Flxpoint does with your files after reading them (leave, move, delete or rename), and your own cleanup does not fight it.
4. Your process gives every file a new name and keeps the upload time as the modified time.

Identifiers and envelope 5. Your ISA05/ISA06/GS02 and Flxpoint's ISA07/ISA08/GS03 match the 850s you received, character for character. 6. ISA13 increments for every interchange and IEA02 matches it. 7. Your production version is 004010VICS in GS08 and 00401 in ISA12.

Test orders 8. Every test 850 was answered with the documents you will send in production: 997, 855, 856 and 810. 9. Each of your test files produced a 997 from Flxpoint in the outbound folder. 10. Each test order shows the acknowledgement, the shipment with tracking, and the invoice in Flxpoint (the Flxpoint customer confirms this). 11. Every file passes Flxpector with no errors, and your 855, 856 and 810 pass the cross-check against their 850.

Cutover 12. Flxpoint switches its 850s to P, and you switch your own values to production at the same time. If you use different IDs for test and production, change them on both sides together. 13. No test file is waiting unread in the inbound folder at cutover: Flxpoint does not tell test files from production files. 14. Watch the first production order through 850 → 855 → 856 → 810 before relying on the flow.

When a File Is Rejected

How a rejection shows up

A 997 confirms that Flxpoint received and could read your file. It does not confirm the order was updated.

Flxpoint records the error message against the file and on the job's run, so the Flxpoint customer, or connect@flxpoint.com, can tell you exactly which segment failed. Include the file name when you ask.

Fixing and resending

1. Run the file through Flxpector and fix every error. For an 855, 856 or 810, use the cross-check against the original 850.
2. Upload the corrected file under a new file name. A file that failed is not retried, and a file with a name Flxpoint has already downloaded can be skipped.
3. Wait for the next job run and confirm the 997 for the new file appears in the outbound folder.
4. Confirm the order changed in Flxpoint. A 997 alone does not prove it.

Most rejections fail the whole file, not just one transaction: a structural error, an unsupported segment or an unsupported transaction set anywhere in the file stops all of it. On an 846, some item-level problems skip just that item and the rest of the file is applied. See Common EDI Errors for the most frequent causes and fixes.

Common Mistakes

EDI Support: connect@flxpoint.com