Problems receiving 997 functional acknowledgement data

Thanks!

Hi,

There are EDI status reports built into R2. They are located on the Group Hub page of the Admin console. You might have to scroll down to see them. You can see the parties, control ids and other stuff.

The problem I am having is that the inbound 997s are not updating the Interchange status from "Ack Expected" to "Accepted". What are the Interchange statuses for your 810s

Seems like your orchestration is not subscribing to the 997s. Try turning off the send port writing out the inbound 997. If there are no subscriptions to the message then it will be suspended. You can then try to troubleshoot why the orch won't get the 997. The message will not be suspended if there is at least one subscription to it.

Good luck,

Mike

Hi Josh,

I am new to EDI concepts, I am facing the same problem like you mentioned. We are sending 850 to vendor and they respond with 997 Schema. We are using Biztalk 2006 R2.

As you mentioned in your post, how did u grab the Group Control number..since it is genarated by Biztalk when you use the EdiSend pipeline

It seems 997 doesn't have the Order(invoice) number. So I can't create correlation on PO number and wait for ACK.

How did u mange to get work your requirement That helps me in my case...

Please give some suggession...You can respond on my mail ID: suresh.bodapati@hotmail.com

I couldn't find anything in internet.

Thanks in advance....

Thanks for your reply Josh..

What mike is pointing is Once we receive ACK messages the orchestration should pick up that message(receive port with edireceive pipeline) and do the processing. Since these ACKs don't have any PONumber or something to find out the matching order..we could n't do any opertation. Biztalk EDI process matches the ACKs with ICA Control number which is genarated by biztalk automatically when we use the EdiSend pipeline. So we don't have any control on ICA number.

So really I feel we can't do anything on 997 ACKs other than checking the status in Group Hub page.

Thanks..

Suresh.

Mike:

I experienced the same problem. The issue is that the report is "baised" towards EDIFACT.

In EDIFACT ... it is typically the INTERCHANGE that gets acknowledged.

In X.12 ... it is the FUNCTIONAL GROUP that gets acknowledged (not the interchange).

If you look at the BAMPrimaryImport database and then navigate to the bam_InterchangeStatusActivity_Completed table and open it (use SQL Management Studio)

You will see columns labelled "IsInterchangeAckExpected" and "IsFunctionalAckExpected".

It appears that if the interchange is X.12 then the former is set to 0 and the latter is set to 1.

I have not done any EDIFACT yet, but I suspect that it is the reverse.

I have not found a way to query for interchanges were a functional ack is expected using the single standard report dealing with 997s provided with R2.

Basically ... the reports that ship with R2 are (IMO) completely inadequate in terms of giving you what you need to actually implement real world EDI processes.

I am guesssing that Microsoft's solution is for you to develop BAM reports yourself.

Curt

Just to clear out some confusion, in both X12 and EDIFACT, both the interchange and the functional group can be acknowledged. In X12, Interchange ACK is known as TA1 and the Functional ACK is 997. In EDIFACT, both these acks are called CONTRL acks, the difference being that the Functional ACKs have additional loops in it.

The "ACK expected" flag just points out that a TA1 is expected (not a 997). This usually is the case if ISA14 on the outbound message is set to 1 (which means the person receiving this message should generate a TA1). Once a TA1 is received for an interchange, that ACK expected is changed!

Hope this clears out any confusion. I will investigate further on how to correlate a 997 with an outbound message and post my findings here.

Thanks

Mohsin Kalam

www.mohsink.com - Blog about Microsoft BizTalk R2 EDI

Moshin:

Thanks for the clarification on the TA1 versus 997. This was helpful. I have not done TA1s.

I still have a problem because the EDI Status Report - "EDI Interchange and Correlated ACK Status" does not appear to provide a mechanism for querying for only those X.12 interchanges which contain at least one functional group which has not beel acknowledged by a 997 after "x" number of days.

If you could tell me how to get such a report it would be appreciated.

I have started to look at BAM but I cannot get the BAM add-in installed ... most likely because I am not running the latest Office Suite.

Another problem I have encountered is that the schema for the ST:02 element appears to be incorrect.

<xs:element name="X12_997_Root">

...

- <xs:element name="ST02">

- <xsimpleType>

- <xs:restriction base="X12_N0">

<xs:minLength value="4" />

<xs:maxLength value="9" />

</xs:restriction>

"X12_N0" appears to indicate a numeric field while "X12_AN" appears to indicate an alphanumeric field.

According the the standards documentation I have (Foresight) the ST:02 is AN.

If any Trading Partner uses an alpha prefix it won't work.

Hi,

I had the same question about checking for EDIs not Acked. I posted some sql code to check the Acks

in "Processing Inbound 997 Acks" http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=2097809&SiteID=1

I haven't seen any ST02 values that have not been numbers.

Thanks,

Mike

Mike:

Do you have / have you found any information like a database diagram for the BAM Primary Import Tables

The SQL you posted was very helpful. I learned more about BAM this week and it from what I could see BAM does not provide a mechanism for "joining" various BAM Primary Import tables to create a new BAM View that could be displayed in the BAM portal. For that it appears we would need to create new database views and then create a GUI for the user using something like SharePoint Portal.

We are also struggling with how to capture "Tracking Data". This would be things like PO# on 850s, Bill-of-Lading# on 856s, and Invoice# on 810s. Tracking data needs to be available so that we can query by PO# to find all the outbound interchanges containing a PO# and whether or not they have been acknowledged for example.

We could use BAM to collect the tracking data ... but not sure what we would need to add as a field to allow the data to be linked to the other BAM Primary Import tables.

The problem is that the map produces X.12 XML but only the document including the ST-SE. The interchange segments get added when it goes through EDISend pipeline which writes directly to the BAM tables.