none
997 Receipt generates another 997 back to the trading partner RRS feed

  • General discussion

  • I have BizTalk 2009 and dont have tracking / reporting enabled for EDI documents and as such dont need to. When I send an Invoice or an ASN, I get back a 997 from the trading partners. BizTalk generates another 997 in response to this 997 and sends back to the trading partner

    Example: If sent an ASN from US to THEM with control# 1

    I get back a 997 for ASN from THEM to US with control #1

    BizTalk generates another 997 for ASN from US to THEM control #1. This 997 makes it look like they sent me an ASN with control #1 and they complain about it.

    How can I stop this behavior?

    Saturday, May 15, 2010 8:20 PM

All replies

  • This is my quick thought. May be you can disable 997 generation in the party THEM to US. Because you would have created US to THEM party to send. So deal this 997 in THEM to US party. will that help?

    Also check which party the 997 is resolving to.

    Thanks!

    Dev

     

    Sunday, May 16, 2010 4:24 AM
  • Apologies I did not word this right. The ASN went from Party "US" to Party "THEM". When the 997 came back from Party THEM, Party US responded with another 997. Now Party US needs to have 997 enabled because Party US receives PO also that needs acknowledgement. Party THEM respondes with 997 because I dont have any control over it.
    Sunday, May 16, 2010 12:54 PM
  • Hi,

        BizTalk generates 997 for every group in a Interchange. So please Check that how many GS are in ISA. If it contains two GS then it would be generating two 997s.

    Or there may be another problem that you may have two send ports subscribing the 997 messages. Then Message box makes copies of same 997 and gives to both send ports.

     

    If these two ways are not your problem please send your input file and settings.

     

     

    Thanks

    Gyan


    If this answers your question, please mark it as "Answered".
    Sunday, May 16, 2010 1:22 PM
  • so this is a simple app that has two parties. One representing THEM and another one representing a THEM ARCHIVE Party that I would use to archive messages from THEM. When I drop a PO in a receive folder the edi is subscribed by a port that sends the same PO out that is attached to the ARCHIVE PARTY. This way it still looks like a PO from them. The THEM party generated a 997 that is subscribed by a port with two filters. EDI.ST01 = 997 and EDI.ISA06 = THEM. This 997 looks perfect. Now I just edit the 997 and reverse the parties in the ISA and GS locations and drop back in the receive location. the 997 port for some reason gets a message from the message box and sends it back out. 

    I have included the Modified 997 (That invokes a response), the original PO I am testing with. If you notice both files look like please let me know what you see. 

    Cannot send the binding file... Makes the file too big. I can email the binding file if you need?

    ISA*00*     *00*     *ZZ*TESTGRAINGERLD2*12*7753594712   *100414*1347*U*00401*000001001*0*T*}~GS*PO*TESTGRAINGERLD2*7753594712*20100414*1347*1001*X*004010~ST*850*10010001~BEG*00*NE*4410000111**20071109~REF*IA*20002722~PER*BD*SARA KARLIN*TE*847-535-2321*FX*847-535-1121*EM*SARA.KARLIN@GRAINGER.COM~FOB*CC*DE***FOB~ITD************Net 30 days~N9*L1**REF TO MSG SEGMENT~MSG*This purchase order incorporates by reference, Purchase order terms found in applicable supplier acceptance letters and agreements.~N1*OB*GRAINGER~N1*VN*Haws~N1*ST*GRAINGER DC*92*001~N2*John Jane~N3*5959 W. HOWARD~N4*NILES*IL*60714*US~PO1*00001*10*EA*514**CB*1A999*VN*SP158A*****MN*SP158A*MG*SP158A~PID*F****Valve Freeze Protect Bleed~MSG*Ship Complete~SCH*10*EA***010*20100507~PO1*00002*50*EA*130**CB*1A992*VN*SP75*****MN*SP75*MG*SP75~PID*F****"Flange Floor Assy 9"""~MSG*Ship Complete~SCH*50*EA***010*20100507~PO1*00003*20*EA*60**CB*1A993*VN*6421*****MN*6421*MG*6421~PID*F****Strainer 60 Mesh In-Line~MSG*Ship Complete~SCH*20*EA***010*20100507~CTT*3~AMT*TT*12840~SE*29*10010001~GE*1*1001~IEA*1*000001001~
    ISA*00*     *00*     *ZZ*TESTGRAINGERLD2*12*7753594712   *100518*1420*U*00401*000000022*0*T*:~GS*FA*TESTGRAINGERLD2*7753594712*20100518*1420*22*X*004010~ST*997*0022~AK1*PO*1001~AK9*A*1*1*1~SE*4*0022~GE*1*22~IEA*1*000000022~

    Tuesday, May 18, 2010 7:30 PM
  • I undersood your issue when i first replied. But it looks like Biztalk treating 997 as just another EDI x12 document and your 997 trading partner values are matching your receive side party setting and it is creating another 997.

    I can understand what's happening but i guess this may be the default behaviour of biztalk (Microsoft can confirm???).

    Ok Tell me, what you need to do with that 997? are you doing any processing or you just needs to archive or you really needs to validate HIPAA compliance for that 997.

    Is your other partner dropping 997 in the same location where he drops 837? Is there any way to distinguish 997 from the file name? file extension? If you can distinguish then read as pass through or you create your own custom 997 schema?

    I can help you based on your reply

    Thanks!

    Dev

     

     

     

     

    Thursday, May 20, 2010 7:36 AM
  • Hi,Samar

    We are changing the issue type to "General Discussion" because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to Question? If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.

    Thank you!


    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support
    Tuesday, May 25, 2010 7:47 AM
    Moderator
  • I had a similar problem and resolved it with adding EDI.IsSystemGeneratedAck == 'true' to the filter rules on the outgoing 997 send ports.

    Find some details here -> http://blog.biztalk-info.com/2009/02/biztalk_2006_r2_edi_gotcha_sending_997s_in_response_to/


    vrStijn

    Friday, March 16, 2012 9:50 AM