997 / 999 Generation for EDI-X12 document

In the case of an EDI-X12 document that is received from the trading partner, it can be acknowledged in 2 ways.

• 1.       By sending 997, i.e. Functional Acknowledgement

• 2.       By sending 999, i.e. Implementation Acknowledgement

Even though the usage of the both document are similar, the 997 can be used to verify the syntactical correctness of the document, where as the 999 does indicates the relational analysis of the control structure as well.

In the case of 997 generation for X12 version 5010 and higher, there are additional elements (optional) generated as below

<Element-480>005010</Element-480>
<Element-1705>Implementation Convention Reference</Element-1705>

In addition to this, Oracle B2B (AS11) also validates the 997/999 during the translation to native against the default pre-seeded 997/999 definition. Hence while implementing the solutions using Oracle B2B (AS11); it is a suggested practice to use 999 for the version 5010 or above.

Cloud Computing and B2B

After a Heavy buzz on Cloud computing with all giants marching towards Cloud computing, I was just thinking on how B2B as a domain go with the "Cloud" :) :)
Can look at different angles.... B2B vendors, B2B users, and B2B service providers

At the outlook... a good prospect for all B2B users... and here is my SWOT analysis :) :)

Strength:

• Software as a service available at the door step!!!
• no investment for hardware
• easy to use
• no maintenance hazzles
• helpful for common man, as the details are abstracted and no need of technical knowledge

Weakness:

• At times data integration cost might be cheaper than investing on cloud .. In this EAI world, there might be chances that services provided by different clouds can be varying..which might lead to invest in different clouds
• If 2 trading partners in different cloud, the Synchronous communication, performance in stress.. to be watched out

Opportunity

• No Hardware investment
• Globalisation, the next avtar of e-commerce.. :)
  

Threat

• Security constraints.. Specifically in B2B world, the sharing the signing, encryption credentials might be a threat
• Response time between message exchange also a thought to be given to.. as the HL7 world...or few of EDI world have a Heavy transactions and requires faster response time
  
• Inter cloud connectivity, communication ...
• Too many clouds
• technical competencies, innovations might go down
• Hardware ppl to watch out !!!!
• Terms and conditions are controlled by cloud owners

Wanna check your EDI knowledge????

Answer these Questions :

• What are the various protocols in use?
• Why should you use EDI?
• What is the structure of EDI message
• What is EDI envelope?
• Which part of the EDI message constitutes the envelope?
• What is the message format before translation
• What is the message format after translation
• Who does the translation
• What do you mean by control number
• How many control numbers are there in an EDI message and what are they
• Why do you need so many control numbers for one edi message
• How are various segments are distinguished in an edi message
• How do I get to know number of segments (segment count) in an EDI message?
• What are delimiters
• Are there any default delimiters?
• If there are default delimiters, can it be over written
• What is the format of delimiter (a. ASCII b. Hex)
• What do you mean by functional acknowledgment
• How different is it from acknowledgement in B2B world
• What is internal properties
• Can I put multiple messages into one and send to trading partner?
• What is batching?
• When and why is batching required?
• Which are all the various verticals use batching?
• Can I use batching to send one document to multiple TPs? If Yes, how different is this from broadcast feature? If No, how can I achieve this usecase
• Can I send multiple docs to more than one TP using batching technique?
• Does validation of payload validates the envelope?

EDI Batching

Batching of messages are an important feature for mostly in transport, logistics, retail world. Batching is a processing of a bunch of messages of similar types. These bunc of messages may belong to one or more trading partners. There would be multiple messages being exchange in a transport, logistics, retail world between two partners, and batching of messages of same document type and revision makes the process easier for both the parties. For example, if all the purchase orders are batced together, it is easy to process all the orders at once and there by avoid multiple exchange of messages and easier for shipping andother purposes.

Since EDIFACT or X12 are the widely used documents in retail industry, batching of EDI document becomes very helpful.

Multiple questions comes to mind... :)

1. How will/should the batch message behave if one of the document is with error?
2. How do we handle if the batching has to periodical and for ever?
3. Can we batch all the PO's for multiple trading partners?

... and so on...

Answer is Yes. It depends on the business logic behind.

-- We can have an option to exclude the error message and batch rest of them Or... we can error out all the messages that is part of that batch!!
-- It is possible batch all the POs of different trading partners. The native payload would have different envelops for different trading partners.

Also, we can have another option of count based batching!!!! Yes... we can have a count being set on the number of messages to be batched.. along with repetitive batching. Depending on either of the criteria, the batch can be triggered!!!


One of the products that provides all these options is .. .Oracle AS B2B ...!!!

Adding a special instruction/ Note to an EDI document

EDI document provides a place holder to provide special instruction or a Note as part of EDI document. This enables the trading partners to add special instructions as part of the actual document. This particular element has been reformed from V3010 to V4010.

In the case of V 3010, it is available as part of NTE element

NTE01     363     Note Reference Code
NTE02     3     Free Form Message


In the case of V 4010, it has been moved as part of Advertising Demographic Information.

MTX01     363     Note Reference Code
MTX02     1551     Message Text



Sample list of qualifiers are :
PUR Purchasing
ADD Additional Information
CAI General Business Description
....

A Retail Usecase using X12

1. The Seller expects the buyer/customer to sent a Request for Quotation (840) for the product.

a. Send the Functional Acknowledgement (997) (optional)

2. The seller replies with a Response to Request for Quotation (843), providing prices and shipping details for the item(s) requested.

Alternatively, user can also send the Inventory Inquiry/Advice (846) instead of the above 2 steps

a. Send the Functional Acknowledgement (997) (optional)

3. Upon the satisfaction of response, the buyer/customer sends a Purchase Order (850)

a. Send the Functional Acknowledgement (997) (optional)

4. Also, receives either a Purchase Order Acknowledgment (855)

a. Send the Functional Acknowledgement (997) (optional)

Optionally,

5. Buyer/Customer sends Purchase Order Change Request (860) - Seller Initiated message in response.

a. Send the Functional Acknowledgement (997) (optional)

6. Seller initiates a Purchase Order Change Acknowledgment/Request (865)

a. Send the Functional Acknowledgement (997) (optional)

7. Once the goods are delivered, seller initiates the Invoice (810)

a. Send the Functional Acknowledgement (997) (optional)


8. Finally, there would be a Payment Order/Remittance Advice (820) from the buyer/customer to the seller.

a. Send the Functional Acknowledgement (997) (optional)

Iinterchange acknowledgment (TA1) Vs Functional Acknowledgment (997)

Details soon...

Significance of ISA11 from V4020 onwards in X12

There has been numerous changes happened between 4010 and 4020 revision of x12 standard. One such change is in the segment ISA 11.

In 4010 version, ISA 11 used to hold the "Interchange Control Standards Identifier", which means, the Code to identify the agency responsible for the control standard used by the message that is enclosed by the interchange header and trailer

e.g :
ISA*00*          *00*          *ZZ*GlobalChips    *ZZ*Acme           *080630*0350*U*00401*110000001*0*P*\~GS*PO*GlobalChips*Acme*20080630*0350*1101*X*004010

Here ISA 11 holds the value "U", indicating "U.S. EDI Community of ASC X12, TDCC, and UCS"

After 4020 Onwards, ISA11 is used as the repetition separator. This is a delimiter and not a data element.
This field provides the delimiter used to separate repeated occurrences of a simple data element or a composite data structure. The value has to be different from any of the data element separator or component element separator or the segment terminator

e.g:

ISA*00*          *00*          *ZZ*Acme           *ZZ*GlobalChips    *081217*0634*^*00404*100000001*0*P*\~GS*PR*Acme*GlobalChips*20081217*0634*1001*X*004040~ST*855*1001

In the above example the ISA11 holds ^ as delimiter

Repetition seperator : ^ (ISA 11)
Data Element Separator = “*” (Character no.4 of ISA)

Note: keeping "U" as a value at ISA11 (repetition separator) as like in 4010, might not be a good option as the character "U" will be used at many places in a payload.
For example: currenecy holds the value as "CUR" in the payload and by using "U" as a repetition separator, the message will not process as expected.

Date time field in an EDI Message

An EDI message has 3 parts, i.e Interchange, group and transactionset, to which the message comply to. Each of these sections has a date time field.

Why does an EDI message has Date and time field in Interchange, group as well as the transaction set?

All the three date/time elements are having specific purpose in an EDI message and are used to intepret at various levels

1. The Interchange date is the date of envelop creation date. Ideally this would be the latest date among all.

2. Group is optional element, it is used to group various transaction sets depending on the business requirement.

3. The Transactionset date is the date in which the particular EDI message was created. In the case of batching, the messages might get created at varied intervals and the transaction set date/time will hold this value.

APERAK Vs CONTRL in EDIFACT

APERAK stands for application error and acknowledgement message. Along with acknowledging the sender about the receipt of the message, it also indicates the sender about the rejection due to errors encountered during the processing of message in an application.

CONTRL message used to indicate the syntactical correctness of the message. Along with acknowledging the sende about the receipt of the message, it also acknowledges on the acceptance or the rejection of the message based on the syntactical check done

Significance of UNA segment in EDIFACT

This segment explains the list of delimiters used to parse the various elements of EDIFACT message. The list of delimiters used in the EDIFACT message is indicated using this UNA segment. This is the first segment of the native payload and it is optional. The UNA segment is followed by the six unique delimiters used in the EDI payload and is shown below.


UNA:+.? '

In this,
: (colon)Sub-elementseparator
+ (plus sign)Element Separator
. (period)Decimal Notation
? (question mark) Release Indicator
(space)Repetition Separator
' (single quote)Segment Terminator.

These are the default delimiters. It is also possible to override the above default delimiters. In case, if the delimiters are non-default, and UNA segment is missing, the EDIFACT message becomes invalid

Example:

UNA:+.? 'UNB+UNOB:1+GlobalChips:ZZZ+Acme:ZZZ+080630:0432+5002'UNG

In this example,
1. The elements UNB and UNOB are separated by +
2. The date time element as 2 sub elements i.e date and time, which is separated by :
080630:0432
3. The UNB and UNG segments are separated by '

Significance of AK1, AK2, AK9 in X12 for the document Type 997

The document type 997 refers to the Functionall acknowledgement of the X12 business message.

The primary purpose of a Functional Acknowledgement is to acknowledge the receipt of Business Message indicating if the message received was syntactically correct or Not. The result of a Functional Acknowledgement indicated if the incoming message is

A - Accepted
E - Accepted, But Errors Were Noted.
M - Rejected, Message Authentication Code (MAC) Failed
P - Partially Accepted, At Least One Transaction Set Was Rejected
R - Rejected
W - Rejected, Assurance Failed Validity Tests
X - Rejected, Content After Decryption Could Not Be Analyzed


Negative Functional Acknowledgements are used to report X12 syntax errors. This would not
indicate implementation guide syntax errors

A FA message has various segments, indicating various inferences w.r.t to original incoming
business message, and here are few important ones:


AK1

AK1 is used to respond to the functional group header and to start the acknowledgement for a
functional group. There shall be one AK1 segment for the functional group that is being
acknowledged. In this, AK102 is the control number assigned to the group being acknowledged.

This is used to correlate the group segment of the original incoming message. This indicates
the control number assigned by the sender of the original transmission. This value corresponds
to the value sent in GS06 for the original transmission.

Since the Group segment is NOT mandatory in an EDI document, the FA correlates only if the
control number for group segment is present in the original message


AK2

AK2 is used to start the acknowledgement of a transaction set within the received functional
group. The AK2 segments shall appear in the same order as the transaction sets in the
functional group that has been received and is being acknowledged.

In this, AK202 is the control number assigned to the transaction being acknowledged, This is
the control number of the original business message, which is in ST02 for the original
transmission. AK2 loop will also contain AK5 segment indicating the acceptance and rejection of
message based on syntac of transactionset. The exact segment in AK5 is, AK501. The codes will
be the one among the mentioned above (A, E, M, P, R, W, X)

AK9

This segment would represent the Functional Group Response Trailer.

AK901 represents the code indicating accept or reject condition based on the syntax editing of
the functional group. The codes will be the one among the mentioned above (A, E, M, P, R, W, X)

Welcome to EDI Gurus

Greetings and a warm welcome to the EDI Aspirants. :)

Here is an effort to put together and share the knowledge of various Business Verticals involving EDI Document.

This blog would try to cover almost everything about EDI, interms of

1. Helping the user community to in solving the business usecases using EDI
2. Explaining significance on various document types available
3. Also, not the least the respective implementation mechanisms on Oracle AS B2B for the various usecases
4. Compitative EDI Offering from various vendors.
5. and many more .... :)

Last but not the least and most unique about this effort is even you can be part of the blogging community. Why wait, shoot a mail to edi@edigurus.com for adding your cool stuff in EDI.

Happy Blogging !!