none
How to configure the receiving of 997s? RRS feed

  • Question

  • Let's say we are a company (party defined as "US") that has to send 850s to another party ("THEM").

     

    After reading the documentation, I am still not sure if I'm understanding how to receive 997s from the "THEM" party. We, the "US" party, are sending some EDI 850 files to "THEM" using a dynamic send port in an orchestration supporting multiple parties. This is working fine, and the edi files for "THEM" are generated as expected.

     

    I went to the EDI Properties for the "THEM" party and under the ACK Processing and Validation Settings, I selected "Functional ACK (Integrated with ACK Reporting)". Then what? I tried creating a Receive Location with the EdiReceivePipeline, dropping the 997 from "THEM" into it, but I obviously get errors as "there is no subscribing orchestration or send port".

     

    Also when I look at the EDI Status Reports, I see the EDIs that were sent to them, but the "Interchange Status" for each one of them says "ACK not expected".

     

    Any help on this issue? What am I doing wrong?

     

    Thanks

    Tuesday, May 15, 2007 5:56 PM

Answers

  • There are no settings in PAM for both X12 and EDIFACT that indicate on an outgoing interchange that a functional ACK (997) or Technical ACK (TA1) is required. However, both X12 and EDIFACT standards do have a field in the payload to indicate the generation of an ACK. 

    For X12, setting ISA14 to 0/1 indicates TA1 not required/required for that interchange. There is no field in the payload for X12 that indicates generation of 997.

    For EDIFACT, setting UNB9 to 0 means no ACK expected, 1 means Functional ACK expected and 2 means Technical ACK expected.

    These settings will be applied for an interchange through {standard} Interchange Envelope Generation under Global or Party where standard = X12/EDIFACT.

     

    In status reporting, the Interchange Status allows "ACK not expected" and "ACK expected". ACK expected means a Technical ACK is expected for that document and vice versa. So setting ISA14 to 1 will result in "ACK expected". For EDIFACT, setting UNB9 to 0 and 1 will result in "ACK not expected" (since 0 means no ACK and 1 means a Functional ACK) and 2 will result in "ACK expected".

     

    I hope this clarifies the issue. Let me know if you need more help

     

    Thanks

    Mohsin

    Thursday, May 24, 2007 9:04 PM

All replies

  • Hi Steven,

     

    Did you ever get ay resolution on this?  I am facing the same issue

    Thursday, May 17, 2007 10:34 PM
  • Greetings all,

     

    Am tinkering with 997s as well and am at the same point where I get the "Ack not expected".

     

    So, poking around the X12 Properties - Party as a Interchange Sender, I can't find anything stating 'functional acknowledgement required' 

     

    So the question is, how do we indicate for an outgoing interchange that a functional acknowledgement is required?

     

    Thanks in advance..

    Thursday, May 24, 2007 5:42 PM
  • There are no settings in PAM for both X12 and EDIFACT that indicate on an outgoing interchange that a functional ACK (997) or Technical ACK (TA1) is required. However, both X12 and EDIFACT standards do have a field in the payload to indicate the generation of an ACK. 

    For X12, setting ISA14 to 0/1 indicates TA1 not required/required for that interchange. There is no field in the payload for X12 that indicates generation of 997.

    For EDIFACT, setting UNB9 to 0 means no ACK expected, 1 means Functional ACK expected and 2 means Technical ACK expected.

    These settings will be applied for an interchange through {standard} Interchange Envelope Generation under Global or Party where standard = X12/EDIFACT.

     

    In status reporting, the Interchange Status allows "ACK not expected" and "ACK expected". ACK expected means a Technical ACK is expected for that document and vice versa. So setting ISA14 to 1 will result in "ACK expected". For EDIFACT, setting UNB9 to 0 and 1 will result in "ACK not expected" (since 0 means no ACK and 1 means a Functional ACK) and 2 will result in "ACK expected".

     

    I hope this clarifies the issue. Let me know if you need more help

     

    Thanks

    Mohsin

    Thursday, May 24, 2007 9:04 PM
  • Hi

        while ur configuring  receving of 997s

                   go to parties properties and envelope seeting just say functional acknowledgements =Always

                    this should resolve ur problem

    santhoshkk

    Thursday, May 31, 2007 6:05 AM
  • Greetings,

     

    Thanks for the overview on Technical vs Functional Acks.  I appreciate it.

     

     Functional Acks are like any other Edi document and can be processed as such. The partner receiving the Edi document from you can configure his party settings so as to generate functional acks for the documents he receives from you. You can receive the functional acks and process them to take corrective action if there were validation error at the partners end in receiving your document.

     

    Just to run through a scenario for acks:

     

    I get a PO from Guido's Grocery that I have to transform from a x12-5010 to an x12-4010 and pass onto Luigi's Lemon Farm.

    Guido drops his 850 into the location where I get it from.  He is expecting a 997 from me to indicate "I got it"

    So I configure the Guido party to generate 997s on receipt of a file.  No problem.  Guido drops his file, I get it, I ack it with a functional ack to Guido (As configured on the X12 Properties - Party as an Interchange Sender - Ack Generation and Valiation Settings - Generate 997 is checked) My send picks up the 997 and sends it to Guido.

     

    Given that I acked the document (I got it successfully), the ball is in my court, it's no longer Guido's problem because as far as he is concerned, I have the file (assuming the ack reports no errors.)

     

    Now I have to take that file, transform it to 4010 and send it to Luigi so he can get Guido his lemons he ordered.

     

    Given that I want a acknowledgement that Luigi processed the file (ie: I want a 997) I configure Luigi such that he gets the 850.  I also configure the 997 reporting (As configured on the X12 Properties - Party as an Interchange Receiver - Ack Generation and Valiation Settings - Functional Acks (Integrated with Ack Reporting) is checked).  This, according to the help tells BizTalk to expect a Functional Acknowledgement from the receiver (Luigi in this case -- This was the setting I was asking about earlier in the thread "How do I configure requirement of a 997).

     

    So, Luigi pick up his 850 that I generated and processes.  Now he tosses a 997 somewhere for me to grab.  BizTalk picks it up and processes it and the question now is "What happens with the 997 I just picked up?".  I don't want to pass that functional ack back to Guido as I already acknowledged his 850 document.  I am guessing BizTalk does some sort of reporting with it.

     

     

     

    Monday, June 4, 2007 10:47 PM
  • Thanks for the responses, they are all very useful.

     

    However I am still facing an issue with the format of the 997s (the separators). It looks that all the 997s that come in have to have a ":" as a data element separator, and a "~" as a segment terminator; no carriage returns are recognized. My client requires the format of the 997s to be something similar to the following:

     

    997 Sample
    ISA~00~          ~00~          ~14~THEM           ~ZZ~US            ~070524~0417~U~00400~000000537~0~P~<
    GS~FA~THEM~US~20070524~0417~537~X~004010~ST~997~0001
    AK1~PO~317
    AK2~850~000118979
    AK5~R~AK9~R~1~1~1
    SE~6~0001
    GE~1~537
    IEA~1~000000537

     

    However BizTalk is not recognizing this as a valid format, and it is throwing errors in the Event Log like this one:

     

    The interchange with id '000000537', with sender id 'THEM           ', receiver id 'US             ' had structural error in/before the first functional group

     

    Any suggestion on how to fix this? By the way, all the outbound documents from US to THEM are being formatted properly with the correct separators ("~", and carriage returns).

     

    Thanks

    Friday, June 8, 2007 5:16 PM