Does anyone know if it’s possible to extract attributes or assign attribute values using the built-in services for EDI doc types?
Thanks.
Chris,
Check out Pg. 26 of the EDIforTN User Guide. It states ‘content-based processing rules depend on user- defined document attributes, which you cannot create for EDI documents at this time.’ Maybe in the near future…
Regards,
Devan
Does anyone know if this feature is present in 6.0?
Can’t comment on what 6.0 may or may not have (haven’t looked at it) but thought I’d ask what you’re trying to do to see if someone might have an approach that will work pre-6.0.
The reason for 6.0 reference is that we have 6.0 but we need to move some processes to production ASAP for business reasons. Until that is done I can’t to evaluate 6.0 or look at. As I understand it some of what we are doing will be throw away under 6.0 hence the reason for moving to production under 4.6 with minimal development.
My situation is as follows:
I have an outbound application flat file that is mapped to an EDI X12 870 Order Status. The flat file contains a unique ID that needs to be passed back to the application along with the 997 Functional Acknowledgement. The reason for not using the Order Number is that an Order can generate more than one status.
Currently this ID is not part of X12 870 as it is not required by the partner. My initial idea was to make it part of the 870, say a REF segment and then extract it as an attribute. Hence my first question in the post.
My flat file is posted to TN as a Generic “Outbound Application Flat File” using wm.tn.doc:createNewEnvelope, wm.tn.doc:addPartContent, and wm.tn:submit. See [url=“wmusers.com”]wmusers.com
This file could be an Order Status or an Invoice. At that point TN doesn’t know. Once the Generic file is recognized the rule kicks of a flow service that then determines what type of flat file it is and passes it to the appropriate flow.
I’m looking for a way to attach each ID to each 870 in TN so that I can pass it back to the application with the accompanying 997.
Any ideas??
Thanks.
Chris,
I’m a little fuzzy on when the file or EDI message is posted to TN in your service, so I may be a little off base here. But anyway, have you thought about using the unique ID as the 870 envelope control numbers (ISA13 and GS06)? This would force the 997 to reference the same number in it’s AK102 field.
Regards,
Devan
> I’m looking for a way to attach each ID to each 870 in TN
> so that I can pass it back to the application with the
> accompanying 997.
Hi Chris - This could be a kludgy workaround:
Can you store the unique ID as a plain text content part instead of a bizdoc attribute?
You can store any number of additional content parts for a bizdoc using the service: “wm.tn.doc:addContentPart” . The only requirement is to name content part references uniquely.
Sonam
Devan,
interesting but would that cause the document to fail validation as those elements are populated by validate?
Sonam,
The problem with that I think is that the flow service post a complete X12 Envelope. TN turns that into one document for the Envelope, one for the Group and one for each 870. As far as I understand I don’t have control over posting the 870 documents I just post the envelope.
Comments?
Chris - I’m not an EDI expert but…
From what I understand, you cannot attach new content parts to each of the multiple “870” document bizdocs created by an X12 envelope… is that correct?
Chris,
The only way it would invalidate the envelope is if the unique ID exceeds the maximum length of the fields I mentioned above.
Check out the EDI Core Component User Guide for more info. The wm.b2b.edi.util.addGroupEnvelope and wm.b2b.edi.util.addICEnvelope services allow you to set the control numbers if you want, otherwise they are automatically populated.
Regards,
Devan
Chris:
I concur that adding a content part isn’t doable. By the time the 870 is created, you no longer have control and thus never get the opportunity to add a content part (or set a custom attribute for that matter).
I also think Devan is on to something. The only issue I see is that this would require only 1 870 per functional group. This may or may not be doable depending upon your integration.
The only control number of interest is GS06. Set that on the way out when you do enveloping. When the 997 comes back, the AK102 field will have your unique number. No lookups required. Of course if this unique number is longer than 15 chars, it’s back to the drawing board.
If the control number approach doesn’t work out, you might consider wrapping the X12 string inside your own envelope structure in conjunction with custom delivery service. We can cover that in more detail if need be.
Rob,
I liked Devan suggestion and just emailed the app group about the criteria for the unique ID.
Why the concern about 1 870 per group?
Please explain as I may be missing something.
Thanks.
Rob,
Don’t bother the light just went on in the closet.
Thanks.
You mentioned that the unique number is an attribute of the 870/order status. A group is capable of holding multiple 870s. Thus, if you place multiple 870s in a single group then the group number identifies only one of the 870s and the others become “orphans” which cannot be uniquely acknowledged. But if you already have a 1-to-1 relationship between the flat-file and the 870 then you should be okay.