850 Translation Failures from Embedded Delimiters and Multiple ST Transactions
A supplier receives EDI 850 purchase orders from a retailer in X12 004010. A single interchange often contains three GS groups and up to 40 ST transactions; each ST has up to 200 PO1 line items. The inbound business process uses the envelope service to deenvelope, the translation service to map to an internal XML schema, and then generates a 997. Recently, two problems appeared. First, a PO line description contains a tilde (~), an asterisk (*), and a caret (^); the translated XML has a truncated description and an extra bogus segment, and the 997 reports a segment error. Second, only the first ST in each GS is being written to the order database; the other STs are silently dropped. The partner insists its data is valid and will not change its delimiters. The team can change envelope settings, map handling, and acknowledgement logic.
1. What is causing the truncated description and bogus segment, and what are your options? Which option is correct?
Read the worked answer
The description contains characters that are also X12 delimiters: ~ is commonly the segment terminator and * the element separator. If those characters appear in data unescaped, the parser will end the segment early and interpret the remainder as new elements or segments. The caret is commonly used as the X12 release character; if the sender wrote ^~ or ^*, the intent is that the delimiter is data, not syntax. If the envelope or translation layer is not configured to honor the release character, it will split anyway.
The options are: enable release-character handling in the envelope/translation configuration; pre-process the payload to escape delimiters before parsing; or reject the interchange and ask the partner to correct it. The correct first choice is to honor the release character if it is present, because the partner is using valid X12 escaping. I would verify in the raw payload whether the caret actually precedes each delimiter. If the caret is absent and the delimiter appears raw inside the description, the data is not reliably parseable and should be rejected with a 997 rather than guessed at. A pre-processor that blindly escapes every ~ would corrupt the segment boundaries, so it is not safe.
I would also check the map's delimiter and release-character settings and confirm that the XML output escapes &, <, and > after translation. The bogus segment is a symptom of the parser seeing a premature terminator; fixing the release character should remove it.
2. Why are only the first ST transactions processed, and how would you change envelope and business process logic?
Read the worked answer
The envelope service is almost certainly configured to process a single transaction set per envelope, or the business process retrieves only the first transaction from the deenveloped result and then exits. The parser may still validate the whole GS, which is why the file is accepted, but the downstream loop never iterates over the remaining STs. That produces silent data loss, which is worse than a hard failure.
I would enable multi-transaction processing or transaction splitting in the envelope service so each ST is exposed as a separate unit, then change the business process to loop over all returned transactions. The loop must preserve the GS and ST control numbers so each transaction can be mapped and acknowledged independently. If the envelope service supports a maximum transaction count, raise it above 40 and add a guard that fails the process if the number of parsed STs does not match the number of ST segments counted in the raw interchange. That guard catches future silent truncation.
I would also confirm that the order database write is inside the loop and that a failure on one ST does not abort the remaining STs unless the partner agreement requires all-or-nothing processing. For 40 STs, partial success is usually preferable, but each failed ST must be reported in the 997. Testing should use a synthetic interchange with three GS groups and 40 STs, including one invalid ST, to prove both the loop and the error path.
3. How should 997 generation be aligned with the partner's expectations and failure handling?
Read the worked answer
The 997 must reflect what was actually validated, not what downstream business processing later does. If the partner expects one 997 per ST, generate AK1/AK2/AK5 for each ST; if it expects one per GS, aggregate the ST results under the correct AK1. The partner agreement should decide this, because a single GS-level 997 that reports only the first ST will hide errors in the other 39.
The 997 should be generated after envelope and translation validation, with AK5 indicating accepted or rejected and the error codes for the failing segment. It should not wait for the order to be created in the database, because a 997 is a syntax acknowledgment, not a business acceptance. Conversely, do not send a positive 997 for an ST that was dropped by the business process; the loop guard above should turn that into a rejection or an operator alert.
Control numbers matter: the 997's AK1 must reference the received GS06, and each AK2 must reference the received ST02. The outbound 997 envelope must use the correct ISA/GS sender and receiver qualifiers and the partner's expected delimiter set. I would also retain the raw inbound payload and the generated 997 keyed by interchange control number so a dispute can be reconstructed. If the partner sends a new 997 request or a TA1, confirm whether interchange-level acknowledgment is also required; do not assume 997 alone covers a rejected ISA.