Articles in this section

EDI parser helper FAQs – parsing export files

What is the EDI parser helper in Celigo and why should I use it?
The EDI parser helper is a powerful tool available in the EDI listener/export form that helps you view parsing rules and troubleshoot errors in your EDI files. It uses your export configurations to show how EDI files are interpreted, helps visualize data parsing, and accelerates issue resolution.
Where can I access the EDI parser helper?
You can launch it directly from the Celigo EDI listener/export in your integrator.io flow.
What views are available in the EDI parser helper and when should I use them?

The following views are available in the File definition rules of the EDI parser helper:

  • JSON view: Best for coders familiar with EDI structures.
  • Tree view: Ideal for non-coders who want a hierarchical view of elements and segments.
What are the key sections of the EDI parser helper and what do they show?

The EDI parser helper consists of the following sections:

  • Sample EDI file: A preview of the raw or baseline EDI file used for evaluation.
  • File definition rules (FDRs): The set of rules used to parse the file displayed in both JSON and Tree views.
  • Parsed output: Shows the parsed data (as JSON) based on your rules.
How does the EDI parser helper highlight errors and where?
Errors are flagged in red with counts and exact error locations, helping you quickly locate and fix non-conformities with the parsing rules.
What should I check when an EDI file has parsing errors?
  1. Ensure the file conforms to the expected EDI standard (X12/EDIFACT).
  2. Compare your data and the parser rules in the helper.
  3. Make edits in the FDRs or source data and preview again.
Can I check if changes I've made have resolved errors before running my flow?
Yes — the EDI parser helper lets you preview and validate how your changes affect output before running the flow.
What’s the recommended workflow for using the EDI parser helper?
  1. During export configuration after providing the EDI file details — preview the parsed parsed output in the EDI parser helper.
  2. After making all configurations, preview parsed data in the export form — confirm parsed output is correct.
  3. After running the flow— troubleshoot errors using the EDI parser helper and check the preview, before running the flow again.
How do I interpret a specific error shown in the EDI parser helper?

Common error types and what they mean:

Error Type What It Means What To Check
Unexpected segment Segment not allowed in that loop/position Loop definition and segment sequence
Missing required segment Required segment was not found FDR required flag + source data
Element length violation Element exceeds allowed length Min/max length in EDI standard
Invalid code value Qualifier/code not allowed Trading partner specs
Max use exceeded Segment repeated too many times Loop repetition setting

Tip

Click the error list in yhr Tree view to see exactly where parsing failed and review the errors, or use the JSON view to browse through errors and fix them.

Why does my EDI file fail parsing even when the segment order looks correct?

Even if the segment order appears correct, parsing can fail due to:

  • Loop context issues – A segment may appear in the right order but in the wrong loop hierarchy.
  • Missing required segments – A required segment (for example, BEG in 850) might be absent.
  • Incorrect qualifiers – Many segments are validated based on qualifiers (for example, N1ST vs N1BT).
  • Max use violations – A segment exceeds the allowed repetition count.
  • Incorrect delimiters – ISA-defined separators don’t match the file structure.
  • Envelope mismatches – ISA/IEA or GS/GE control numbers don’t match.

Use the Tree view in the EDI parser helper to confirm loop placement, and check highlighted errors in red to identify rule violations.

How are loops determined in the EDI parser helper?

Loops are defined in the FDR (File Definition Rules) based on:

  • Trigger segments (e.g., PO1 starts a detail loop in 850) . 
  • Parent-child hierarchy rules
  • Maximum repeat counts
  • Segment grouping definitions

If a segment appears outside its expected loop, parsing fails even if order is technically correct

Tip

Think of loops as “containers” — segments must belong to the correct container to parse properly.

Why is a segment being ignored in the parsed output?

Possible reasons could be any of the following:

  • It is not defined in the FDR It exists in the wrong loop
  • Qualifier mismatch prevents rule activation
  • It exceeds max allowed repetitions
  • It’s a custom segment not configured

You could review the following items:

  • Segment exists in the FDR
  • Correct loop level
  • Qualifier condition matches file
How do I handle custom segments not covered by default rules?

You will need to:

  • Modify or extend the FDR definition. .
  • Define: segment name, Loop placement, Element structure, Repeat rules
  • Validate using EDI parser helper preview

    Important

    Ensure your trading partner’s implementation guide supports the custom segment before modifying standard definitions.

Why do I get errors when the trading partner says the file is valid?

Common reasons:

  • Partner uses implementation-specific variations
  • Custom qualifiers not in standard spec
  • Segment marked optional in standard but required in your FDR
  • Different version of X12/EDIFACT (for example, 4010 vs 5010)

Confirm: EDI version in ISA/GS, Trading partner implementation guide, FDR version alignment

How should I troubleshoot large EDI files?

Large files often fail due to a single malformed transaction. Considering that you have set the option to process EDI files only if all records are valid (default option), you could try the following steps:

  • Extract a small sample (1–2 transactions).
  • Test parsing in the helper.
  • Fix structural errors before validating large batches.
  • Confirm control numbers match in envelopes.
What’s the difference between EDI parser helper errors and flow run errors?
  • Parser helper errors → structural/format issues in the EDI file.
  • Flow errors → Downstream mapping, transformation, or destination errors.

If parsing fails, the data will not reach transformation/mapping; so fix parsing issues first if you're using the default option of processing files when all records are valid.

What are good practices to avoid EDI parsinng issues?

Consider these as good practices to follow for EDI files to be successfully parsed.

  • Validate ISA delimiters before processing.
  • Always confirm version (4010, 5010, etc.).
  • Align FDR strictly to trading partner specs.
  • Test new trading partners with sample files.
  • Use Tree view to validate loop nesting visually if you're relatively new to EDI and JSON code.
  • Avoid modifying standard definitions unless necessary.