From Errors to EDI 810: The TDS, Decimal and Mapping Mistakes That Cost Me Hours—and How I Fixed Them

A Map Editor is a tool used to transform data from one format to another—commonly from structured formats like XML, CSV, Excel, or flat files into standard EDI documents such as ANSI X12 and EDIFACT, and vice versa (EDI to XML or flat file). In real-world integrations, input data can come in various forms, including JSON, cXML, EDI, or even PDFs. This data is typically converted into structured XML—the most commonly used intermediate format—and defined using an XSD (XML Schema Definition) to establish the input structure.

Once the schema is in place, the mapping process begins, where each element from the input is transformed into the required EDI output format. In this article, I walk through a practical scenario where I converted an XML invoice into an EDI 810 document and the real issues I encountered along the way.

A Practical Implementation: XML Invoice to EDI 810

My input was an XML file structured according to the following schema. Simple XML—but converting it into a proper EDI 810 output involved significant troubleshooting. Here is every problem I hit and how I fixed it.

Problem 1: Mandatory Block Missing—The TDS Segment

When I ran my first test translation, the map compiled fine but the translation report showed a mandatory block missing error for TDS.

TDS is the Total Dollar Summary segment in EDI 810. The standard map has it set as mandatory by default. My input XML had no total field—only individual amounts per service. Sterling first checks structure: it verifies whether a mandatory segment like TDS has a proper mapping to generate output. Since I did not map it initially, the system threw the error even before running accumulator logic.

I tried to make TDS optional by changing a field inside it. That did nothing—the segment itself was still mandatory. The fix requires changing the segment, not the field: right-click the TDS segment in the output tree, open Properties, go to the Looping tab, and change Minimum from 1 to 0.

That was only an initial workaround to bypass the error and proceed with testing. In a real-world scenario, TDS is mandatory for a reason. Instead of skipping it, the correct solution is to provide the required value: calculate the total by summing all service-level amounts from the input, then map that calculated value to the TDS segment. With this approach, the error was resolved properly and the output aligned with the EDI standard.

Problem 2: Line Number Counter Using Accumulator

My output needed IT1-01 to be a line number—1, 2, 3—for each service. My XML had no line number field. I needed to generate it automatically using Sterling’s built-in accumulator.

• Click IT1-01 field → Properties → Standard Rule tab.
• Select Use Accumulator.
• Click New to create an accumulator entry: Primary Accumulator 0, Name LineCounter, first operation Increment primary.
• Click New again for a second entry: Primary Accumulator 0, first operation Use primary accumulator.
• You need both entries: Increment adds 1 to the counter; Use outputs the current value. Without both, nothing appears.

IT1-01 was outputting 1.0, 2.0, 3.0 instead of 1, 2, 3 because the field format was set to Real (decimal). Fix: IT1-01 → Properties → Validation tab → change format from R to N0.

Problem 3: Handling Tax and Discount—TXI and SAC Segments

I had both Tax and Discount in my XML. My first instinct was to put both in TXI segments. There is an important difference:

• TXI segment = Tax Information. Use for tax amounts (e.g., TXI-02 with TXI-01 hardcoded as GS).
• SAC segment = Service, Promotion, Allowance, or Charge. Use for discounts (e.g., SAC-05 with SAC-01 hardcoded as A and SAC-02 as D240).
• My XML had no discount code field—only the discount amount. I hardcoded SAC-01 and SAC-02 as constants and mapped only the amount from XML.

Problem 4: The Decimal N2 vs N0

My output showed incorrect inflated amounts—for example:

              SAC*A*D240***500~
            

Instead of the expected:

              SAC*A*D240***5~
            

The cause: SAC-05 field format was set to N2, which means two implied decimal places. Sterling interprets 5 as 0.05 and outputs 500 in EDI format. The fix: SAC-05 → Properties → Validation tab → change format from N2 to N0. N0 means no implied decimals—value 5 outputs as 5. Always check this when amounts look wrong. The same issue can happen on IT1-04 for unit price.

Testing the Map: Moving from Design to Execution

When you save work in the IBM Sterling Map Editor, you manage two file types. The .mxl file is your source—it contains loops, extended rules, constants, and structures. It is human-readable but not executable. Compiling turns .mxl into a .txo file—the machine-readable version the Sterling B2B Integrator engine uses.

Before uploading to the server, run a local test in the Map Editor. The editor generates a Translation Report. Warnings often indicate data mismatches; errors stop translation entirely—mandatory fields empty or loop keys that do not match. In my case, the map compiled successfully but output initially showed missing mandatory segments. By analyzing the report and output together, I fixed structure and mapping and re-ran the test until output matched expected EDI format.

Final Thoughts

Mapping in IBM Sterling is not just about connecting dots. It is about understanding structure underneath—mandatory segments, accumulators, segment purpose, and validation formats. Whether fixing a date format or building a nested loop, the goal is the same: clean, repeatable, and accurate data.