A catch 22 in generating 999 file

3
votes

Well, I have to say it is kind of funny when I meet this situation:

I am inbounding HIPPA 837 files and I am suppose to create 999 ACK files once received the 837 file. BizTalk will generate the 999 message if I setup the trading partner agreement to do so. And it works fine so far.

Today, I received a 837 file with some structure error: there are some leading space character in an element. Then the 999 was created, but when my send port subscribe this 999 message try to save it as a file, I got an validation error complains the 999 message itself is invalid cause its element have leading space characters.....

Error: 3 (Field level error)
SegmentID: IK4
Position in TS: 18
Data Element ID: IK44
Position in Segment: 4
Data Value:
6: Leading or trailing space found

It looks for me like a catch 22: your 999 files are suppose to report structure error of the inbound file,it will include the wrong element value as part of the report (in my case, it's in IK4 segment) , but the wrong element value itself make the 999 file invalid too.

I just want to know if anyone have meet the same situation? And what's your suggestion on this issue?

2
biztalkedi
Possible duplicate of BizTalk generated wrong 999 file? - Mathemats
@mahematd: You are wrong. Totally different problem - Zee
Both question asked by me. I am sure. - Zee
@Mathemats, If you are the one who downvote my question and mark it possible identify with another querstion(which is also my question). I'd like to see you correct your mistake. - Zee
They are completely different questions. - Johns-305

2 Answers

2
votes

I have not seen this, and really, I'm a bit surprised it hasn't come up before, if it's a real catch-22 :)

Try this, in the You->Them tab of the Agreement, set the Default row in the Validation section to have Leading and trailing spaces = Allowed.

You may have to explicitly set all other tx to Not Allowed since the 999 is not on the Transaction Type list.

1
votes

I would try @Johns-305's suggestion, but I know I've had issues with using the allow leading/trailing spaces before in the agreement (some fields just seem to blow up on this for me even with it on).

I would try capturing the 999 message before it gets to the EDI send and using normalize-space() (in XSLT) or .Trim() (in C#) on the node(s) in question. You can do this by creating a send port that filters on the 999 BTS.MessageType.

This may not fully satisfy your trading partner's expectations though, because the segment might be valid without a space (leading to confusion about why a perhaps otherwise valid segment was rejected).

You also might take this up with Microsoft, although it might be a limitation of using XML (where leading whitespace may be treated as insignificant) to represent EDI (where leading whitespace is bad news).