Hello.
I am trying to create (back to the drawing board kind of) a common key or some method of relating a single record in a flat file to a single ST after batching from the public queue. Something that will survive the batching process. Eliminating batching is not an option.
Currently, I am taking values in the flat file record that are mapped in the X12. For example, I have an account number, serial number and a dolar value. all three of which will make a transaction unique. Those 3 values are mapped into the X12 where I can retreive them by doing a light convert to values and extracting them there as well, long story short, in the delivery service. That way, when the 997 comes back, I can tell our customeer that the 3rd transaction from the 8th account in the original parent file was rejected. The results from each step are reported to an external DB.
The problem there, is if the business partner sends the exact same one again, I can not record the new transaction as unique while maintaining the relationship in the acknowledgement since the key I produce will be the same. Is there some corelation ID unique to the ST that I can extract (that survived the public queue) from the batched edi that was produced in the flat file parsing process?
The control numbers from the ISA, GS and ST should combine to give a unique ID. You might be able to use just GS and ST control numbers, depending upon how you’re generating your GS control number.
Yes, those are a unique combination and are used elsewhere to relate to the existing ID we are creating, but do not relate me back to the original flat file record otherwise.
Let me re-state the issue in a less abstract way.
in the course of a day, 3 file come in containing a total of 1000 unique transactions.
transaction 10 from the second file has internal data that when combined create a “unique ID”.
all 1000 transactions are parsed, translated, queued, and then batched.
In the delivery process, the 500th ST contains those same elements used in the corresponding flat file record are extracted to relate. The internal ID for the GS along with the GS02 and ST02 are published. so when the 997 comes back in TN is able to relate and extract the 3 key combination and publish that ST#500 from that batch was tagged as error.
We publish the 3 key combination as a new status to the receiving BU application and all is right in the world. Until the business decides to fix the problem and resend the exact same transaction a day later.
What I need to do, is replace the 3 key combination with a TN/IS generated GUID created in the initial receive of the single record that will survive the batch process, and can be retrieved by the delivery service. The fact that the 3 key combo is not truly unique when they resend intentionally or by accident needs to be replaced with something TN knows as unique to the transaction, but common to both sides of the process.
I’m with you on the flat file, translation, batching and FA reconciliation at TN. Sounds like you’re doing some custom stuff in the delivery to store the 3 values (keyed by GS and ST data) and then some more custom stuff during FA reconciliation. Cool approach.
Are you trying to support having the BU application do reconciliation? Instead of or in addition to the account number, serial number and dollar value you want to send a GUID? How will they know what to match that to?
Am I missing something in the IS/TN to BU application leg of the notification? How does the duplicate notification (presumably a success indicator on the subsequent try) cause issues for the BU app? IS/TN will need to pass something the BU app understands, correct? If so, then IS/TN can’t really be the component that generates that, it probably needs to be the BU app.
yes, this is for BU level recon. We do our X12 EDI-tracking table recon for our own records, but post a process status update to a series of tables. We take the internal ID for the EDI batch and publish it along with the control numbers. That have a ralation to the GUID (that id which I want to improve) and the whole external recon works great. We can show the lifecycle for any transaction. We may even in the future be able to tie a PO from one group, to the invoice from an other to the RA from a 3rd.
so, we receive the flat file record, and we get a TNdoc id
we generate X12 ST which has a doc ID
we batch it up and then all is lost inside the batch as it is a black box that spits out a product of all the transactions which were so nicely labled. Except that we extracted those user key values from the payload before we send. So in a perfect world where we never have to see that doc again after the FA comes back. and if the FA never comes back, we dont care, its some one elses problem to trace. We are in our happy place.
However, just like old girlfriends, we can never discount one popping out of the woodwork whether it be intentional, incidental or a bad nightmare. and we may need to process that transaction again as a new document. so the GUID we produce is no longer globally unique as the name suggests.
I know one solution would be to require a release number in the user data. If this were a PO, we could do it. but this is not for any single transaction type. so Im hoping there is some TN ID that would be carried from the initial receive that would be downstream of batching.
The prospects of a data element that isn’t in a segment field surviving the batch process isn’t promising. In a couple of other clients where I’ve done EDI I implemented a custom batching process. It still used the built-in TN batch service but wrapped it so I could do stuff before and after the batch.
The main feature was that the resulting batch document was TN related to the included transaction set documents (Side note: it is quite odd that the batch process doesn’t do this). When the transaction set documents were generated they were TN related to the original doc (XML, flat file, whatever). Then, when the FA came back, the process could traverse all the related docs: batch doc → transaction set doc → initial doc and mark them with the appropriate user status.
The transaction set doc and initial doc can have custom attributes defined for them. In your case, the initial doc might have a filename or whatever that you store. The transaction set doc might have the filename/whatever and a line number (if you track that during flat file processing). Then as you’re doing FA processing you can look up these custom attributes and do whatever.
A custom batch process is probably more of a change than you’re looking to do though. But I can’t think of a less-intrusive way to get something across that batch service boundary.