none
EDI 271 , 5010 Version , Unique Transaction Numbers( TRN02) from a file which contains Multiple ST SE segments RRS feed

  • Question

  • Hello,

    We are receiving EDI 271 files from multiple sources for the EDI 270 we send to clients. 

    In each 270 file we are sending single ST SE segment with Multiple HL segments in it. But we are getting responses back from the client , we are getting a single 271 file with individual response in one ST SE segment. which is multiple ST SE segments in one file.

    Now when this file is being received through the received port the file is getting split.

    Problem is suppose we have about 1000 ST SE in the 271 file we have the one file split into 1000 files with 1000 instances of orchestration parsing the files, and each orchestration making a call to WCF Service to update values. In certain cases the number of instances are touching 30,000 to 40,0000.

    can some one help/suggest If there is a way I get unique TRN values in the 271 file before the file is being split into individual files.

    Can someone help


    Krishna

    Wednesday, April 24, 2013 6:20 PM

Answers

  • Just to be clear, you are sending a unique TRN02 per 2000C/D Loop, correct?

    Are you saying the Information Source is returning only your first TRN02 in all TRN02 elements in the response Interchange?  If so, that is a problem on their end.

    Because, regardless of whether or not each 'request' is return in an individual ST, the TRN02 per Subscriber or Dependent should be what you transmitted.

    -Or-

    Are you transmitting multiple 2000D Loops under one 2000C and only sending the TRN02 at 2000C?  If so, what you're seeing is the correct behavior, technically, when BizTalk debatches the Interchange.

    The solution then is to transmit another unique identifier in 2000D/TRN02.

    -Or-

    You are transmitting multiple 2110C/D Loops under one 2000C/D and the Information Source is splitting at that level, thus duplicating the TRN02 in multiple ST's.

    If that the case, you would have to try sending one 2000 Loop per 2110, each with a unique TRN02.  That's perfectly legitimate unless the IS specifically requires otherwise.

    • Marked as answer by Pengzhen Song Wednesday, May 1, 2013 8:29 AM
    Thursday, April 25, 2013 5:57 PM

All replies

  • Hi Krishna,

    So, all the scenarios you've described are perfectly legitimate, provided a trading partner agreement doesn't explicitly prohibit them.

    As for the TRN, the Information Source is supposed to echo back whatever value the Information Receiver places in the 270 so if you're sending the TRN in 2000C/D, you're supposed to get the exact same values back in the same place.  The TRN references the 2000x Loop, not the ST.

    If you're not transmitting TRN's, the easiest solution would be to add them in a Map on the Port.  It sounds like you just need them for internal tracking, no?

    Wednesday, April 24, 2013 6:58 PM
  • Hello,

    Thank you very much for the reply.

    "So, all the scenarios you've described are perfectly legitimate, provided a trading partner agreement doesn't explicitly prohibit them."

    Yes, I have a party with option "Split Interchange as Transaction Setss" on  Local Host settings. Problem is if I set this option to "Preserver Interchange", xml is generated upon receiving an edi 271 with ISA values also on XML and this doesn't confirm to the "X12_00501_271.xsd" schema. So is there a way I can parse this document with ISA values, Is there a schema provided by Microsoft

    "If you're not transmitting TRN's, the easiest solution would be to add them in a Map on the Port.  It sounds like you just need them for internal tracking, no?"

    You are right, we need these TRN values for our internal tracking purpose, but as the file is being split into multiple files, we are unable to find which HL segments have a valid response to update in the database. You mentioned "the easiest solution would be to add them in a Map on the Port" can you throw some light on how to achieve this.

    Thanks a lot for your help.

    Thanks,




    Krishna



    • Edited by Krishna Kal Wednesday, April 24, 2013 7:31 PM
    Wednesday, April 24, 2013 7:29 PM
  • Oh, so you're using the HL position to match to the database?  Well....

    That's exactly what the TRN segment is for.  You would be much better off sending a TRN in the 270 and using that to match the 271 to your internal source.  Keep in mind, the Information Source is not obligated to return the 271 in the same order, or even with the same subscribers, or even at all.

    Wednesday, April 24, 2013 9:53 PM
  • I think I have given wrong impression. Sorry about that.

    We are using TRN02 for internal purpose. Sending on 270 and using that to match for our internal purpose.

    For example look at the below segment 

    HL*4*2*22*0~
    TRN*2*12345-67890*XXXXXXXXXXX~
    EB*X**XX~
    DTP*XXX*XXX*XXXXXXXX-XXXXXXXX~

    Real Problem: With some clients when we send a 270 we send a single ST SE and multiple HL segments in that file. But when the client returns the file they return each response in a Individual ST SE segment, so its like for example when we sent a 270 we have 10 patients in 10 HL segments in 270 and we get back a file with 10 ST ST segments where each ST SE has a single HL segment in them.

    Now, In the response file we have the same TRN02 value in all 10 segments and some HL loop may have a valid Eligbility and some may not have , so i am searching for a solution so that I can get list of all TRN02 in the file before the 271 file is being split into individual files.

    Thanks for your help



    Krishna

    Thursday, April 25, 2013 12:39 PM
  • Just to be clear, you are sending a unique TRN02 per 2000C/D Loop, correct?

    Are you saying the Information Source is returning only your first TRN02 in all TRN02 elements in the response Interchange?  If so, that is a problem on their end.

    Because, regardless of whether or not each 'request' is return in an individual ST, the TRN02 per Subscriber or Dependent should be what you transmitted.

    -Or-

    Are you transmitting multiple 2000D Loops under one 2000C and only sending the TRN02 at 2000C?  If so, what you're seeing is the correct behavior, technically, when BizTalk debatches the Interchange.

    The solution then is to transmit another unique identifier in 2000D/TRN02.

    -Or-

    You are transmitting multiple 2110C/D Loops under one 2000C/D and the Information Source is splitting at that level, thus duplicating the TRN02 in multiple ST's.

    If that the case, you would have to try sending one 2000 Loop per 2110, each with a unique TRN02.  That's perfectly legitimate unless the IS specifically requires otherwise.

    • Marked as answer by Pengzhen Song Wednesday, May 1, 2013 8:29 AM
    Thursday, April 25, 2013 5:57 PM