SeanHoppe.com Cleo Best Practices 997 Functional Acknowledgements Explained
997 Functional Acknowledgements Explained
Cleo EDI Integrator trading partners may be set up to both send and receive 997 functional acknowledgements under functional group “FA”. 997s are created to send for any X12 transaction received into Extol. 997s may be received for any outbound X12 transaction generated by the software. Functional acknowledgements are a means of tracking whether trading partners are receiving data sent to them via the inbound 997, or notifying trading partners that X12 transactions were received and whether or not that received data was accepted with no errors, accepted with errors, or rejected. Beginning with Extol Release 5.5e, syntax validation was added based on inbound maps for the creation of outbound 997s to trading partners with the proper trading partner setup and specification via a data area if some syntax errors that would typically allow translation to continue to reject. If the data area is not set up to stop for all syntax errors at the unwrap phase, the reject response code should not be used unless the error code generated will cause a fatal translation.
**NOTE** - DO NOT SET YOUR TRADING PARTNER MESSAGE CLASS LEVEL TRADING PARTNER DETAILS 2 SCREEN UP TO GENERATE OR RECEIVE 997S FOR 997S. BE SURE YOU DEFAULT THE FIRST 2 PARAMETERS TO “N” FOR THIS SCREEN. It could issue a never ending loop between you and your trading partner.
Inbound 997 message class for trading partner setup:
To receive an inbound 997 for a trading partner, functional group code “FA” must be set up for that trading partner. Setting this message class up for a trading partner will allow Extol to receive 997s for a trading partner and mark the X12 transaction acknowledged. ISA/IEA and GS/GE control numbers must be tracked and be consecutive by interchange and group for a trading partner to be able to accept and use inbound 997s successfully.
- Message ID – 997 Message Class – FAGRPRCV
Outbound 997 message class for trading partner setup:
The same functional group code “FA” is used for both sending and receiving 997s for a particular trading partner. The direction code for the group should reflect that this group code may be sent and received by the trading partner if the 997 will be bi-directional for a trading partner. Using the outbound 997 allows mapping validation, and acceptance or rejection of X12 data based on that validation without manual intervention. Extol enables a business to set up a process for the creation and sending of the 997s. A trading partner must be generating unique and typically consecutive ISA/IEA and GS/GE control numbers for the X12 transactions being sent through Extol. This can usually be addressed in a trading partner agreement for both sending and receiving the 997 transaction.
- Message ID – *ACK Message Class – *ACK
Outbound acknowledgements may be created from option “6” in the mailroom, the CRTFADTA may be called from a command line when the Extol libraries are present in a users library list, or the CRTFADTAB command may be set up in a CL program and scheduled to run.
Outbound 997 generation also requires set up on the Trading Partner Details 2 screen at the trading partner level for 997 processing to occur for all inbound transactions or the trading partner message class level for specific inbound transactions for which you wish to generate a 997. The following print screen displays an example trading partner message class level setup. Details for the setup will follow. The print screen also indicates the unwrap data area flag in the setup instructions to follow will allow the file to continue processing for non-fatal syntax errors.
Acknowledgement level to send:
Place a question mark "?" in the parameter to find all acceptable values. However, note that segment and element level data will only be validated if the following values are used.
- N No acknowledgement used
- I Interchange lvl; all ints
- G Group level; all groups
- M Message lvl; msgs in err
- O Message level; all msgs
- P Msg lvl;msgs in err S/E
- Q Msg lvl;all msgs S/E
- E Element lvl; msgs in err
- F Element level; all msgs
- S Segment lvl; msgs in err
- T Segment level; all msgs
The code table L_ALG_FAMC (Ack level to generate to message class for FA) will need additional entries for Ack levels of ‘P’ and ‘Q’. The entries are only required if you are generating outbound acknowledgements and you are using the new acknowledgement level codes of ‘P’ and/or ‘Q’.
The code table entries must contain the name of the functional acknowledgement message class you are using; in most cases this will be FNACK1. Here is an example of the entries to be added to the code table:
Ack level to Outgoing FA generate Sequence message class P 10 FNACK1 Q 11 FNACK1
Segment and element EDI data will only be validated when the “Acknowledgement level to send” is set to element level, segment level, or message level with segment/element validation. Interchange, group, and message level values do not check elements or segments, i.e. levels I, G, M, O.
The data area EXACKUNW controls processing of acknowledgements within the unwrapping process. The data area flags can be ‘Y’ or ‘N’. Here is a list of the flags used and the affect they have on the unwrapping and acknowledgement processes:
Flag | Value ‘N’ | Value ‘Y’ |
Pos. 1 | Will suppress message level ack error 1, and group level ack errors 1, and 2 (Transaction Set Not Supported, Functional Group Not Supported, and Functional Group Version Not Supported; no message class) | Will use Trading Partner values to determine acknowledgment level to process (Trading Partner Message Class would not have been found for these errors). |
Pos. 2 | No unwrap error for segment and element level acknowledgements that cause the message to be rejected.’ | Any segment or element level acknowledgments that cause a reject of the message will force an unwrap error for the message. |
Pos. 3-5 | For future use | For future use |
Pos. 6 | Will suppress group level | Functional group will be validated. Will use |
By: Sean Hoppe on