NCPDP Telecom batch standard
The NCPDP Telecom Batch Standard uses a file layout format that is used to encapsulate NCPDP Telecom transactions.
The batch file consists of Header, Data, and Trailer sections.
Transaction header and trailer
The header and trailer must be present in every transmission:
Transaction Header 1 per file
Transaction Detail Data
Transaction Detail Data
. . . . up to 9,999,999,997 records per file
Transaction Trailer 1 per file
The
Transaction Header
and
Transaction Trailer
segments are fixed-length
segments. The
Transaction Detail Data
segment contains all of the
NCPDP Telecom transaction.
Batch standard v1.0 and v1.1 differences
This table shows the differences between version 1.0 and 1.1 batch headers:
Version 1.0 batch header | Version 1.1 batch header |
---|---|
The Batch Number field is 5 characters long. | The Batch Number field is 7 characters long. |
There is no receiver ID field immediately preceding the last End-of-Text character. | There is a receiver ID field of 24 characters immediately preceding the last End-of-Text character. |
This table shows the difference between versio 1.0 and 1.1 batch trailers:
Version 1.0 batch trailer | Version 1.1 batch trailer |
---|---|
The Batch Number field is 5 characters long. | The Batch Number field is 7 characters long. |
NCPDP Telecom batch transaction example
(STX)00T1234567890123456789022229876747199412011632T11ABCDEFGHYTEWQASDXZAQ1234(ETX)
(STX)G110000543219999993201...............(ETX)
(STX)G110000543229999993201...............(ETX)
(STX)9998767470000000004Initial Test (ETX)
Batch processing
Processing is handled by standard Tcl procedures in the thread. This table shows the driver control keys that are used to control these procedures.
{BATCHTYPE NCPDP} |
Identifies the current message as an outbound accumulating batch. |
{TRANSACTIONID nnn} |
Sets the transaction control number programmatically. If no control number is specified, then the default is to start at one (1) and increment. |
{BATCHID nnn} |
Sets the batch control number programmatically. If no control number is specified, then the default is to use a counter. |
{BATCHSIZE nnn} |
Programmatically controls the maximum batch size. The default would be to use a value stored in NetConfig. |
{BATCH SEND} |
When a message happens with this key set, it indicates that a batch should be generated. This would typically be under the control of a timer. |
The outbound procedure examines the driver control for the
{BATCHTYPE NCPDP}
key.
If it finds this key, then it holds on to the message by not supplying a disposition. This leaves the message in the recovery database. The message handle is stored in a global variable for later use.
If an outbound message does not have this key, then it is a transaction that should be accumulated in the outbound batch.
If no outbound batch exists, then one is created.
After a message is accumulated in the outbound batch, the new batch is
released. The new batch has a disposition of OVER
which places it in the inbound queue. The original message is stopped. The inbound
procedure takes a message that contains {BATCHTYPE
NCPDP}
and gives it a disposition of OVER
. This returns it to the outbound queue where it waits for more
messages to be accumulated. This ensures that the batch is always properly
recovered. When there is a crash or thread that is stopped then started, the batch
messages are redelivered to outbound processing and re-held.
A problem happens, though, when two messages are processed outbound
before the batch message is re-delivered to the outbound procedure. The best method
of handling this is to permit the processing of another {BATCHTYPE NCPDP}
message, which flows back around. The outbound
procedure continues to remember the original batch handle. Any batch message that
arrives and is not the currently remembered batch must be appended to the original
batch. The original batch gets OVER
and the later
batch is stopped. This technique ensures that messages remain in order both for
normal processing or recovery.
The stored batch is sent out with a CONTINUE
disposition. This is sent when the maximum number of messages
is received or a {BATCH SEND}
message is received.
Messages accumulating in a batch must be stored in the recovery database if recovery is enabled.
Inbound NCPDP Telecom batches
Inbound NCPDP Telecom batches are supported with an EDI Batch attribute for inbound threads. If EDI Batch type NCPDP Telecom is specified for an inbound thread, then all inbound messages are treated as batches.
Each inbound message is split into individual transactions for processing. Values from the batch header and trailer are attached to the individual transaction metadata.
For example:
(STX)00T1234567890123456789022229876747199412011632T11ABCDEFGHYTEWQASDXZAQ1234(ETX)
(STX)G110000543219999993201...............(ETX)
(STX)G110000543229999993201...............(ETX)
(STX)9998767470000000004Initial Test (ETX)