Batch types
The batch type can be selected for inbound and outbound EDI batch type.
Inbound batch
As the inbound Formulary and Benefit batch has no parameters,
is unavailable. Inbound batch processing splits the batch into individual transactions. It also attaches the field values from the batch header and trailer segments to each transaction message as driver control metadata.- Driver Control is populated with a two-level keyed list.
- Inbound batch values are stored
under the
INBOUND_BATCH
key. - The batch header segment for a Formulary Load File is HDR and the trailer segment is TRL.
- The batch header segment for a response file is SHD and the trailer is STR.
- The entire batch message errors if the starting and ending segments are not valid. Special characters similar to "{", "}" and "\" in the data must be preceded by a backslash. This avoids corrupting the keyed-list structure.
Sub-key | Description |
---|---|
RECORD_TYPE |
Header segment (HDR or SHD) |
VERSION_NUMBER |
|
SENDER_ID
|
Only populated for a load file (HDR)
|
RECEIVER_ID |
|
SOURCE_NAME |
Only populated for a load file (HDR)
|
TRANS_DATE
|
|
TRANS_TIME
|
|
ORIG_CONTROL_NUMBER |
Only populated for a response file (SHD) |
ORIG_TRANS_DATE |
Only populated for a response file (SHD) |
ORIG_TRANS_TIME |
Only populated for a response file (SHD) |
ACTION |
Only populated for a load file (HDR) |
EXTRACT_DATE |
Only populated for a load file (HDR)
|
LOAD_STATUS |
Only populated for a response file (SHD) |
TOTAL_RECORDS
|
Only populated for a load file, in TRL at end |
ROWS_IN_ERROR |
Only populated for a response file, in STR at end |
TOTAL_ERRORS
|
Only populated for a response file, in STR at end |
BATCH_START_END |
Batch start/end is used to indicate the first and last messages in a batch. This is necessary because the response batch must correspond to the inbound batch. |
The first message that is extracted from an inbound batch has {
{BATCH_START_END {S} }
.
The last message has { BATCH_START_END {E} }
.
Intermediate messages have { BATCH_START_END { } }
.
This constructs a response file that matches the inbound batch file.
For example, if a batch message has header and trailer as shown here, each
extracted message has these driver control metadata. The
BATCH_START_END
varies.
Message data:
HDR|10|sndr|passwd|rcvr|source|1001|20060103|08150198|FRM|U|20051230|T
… formulary data load transaction segments …
TRL|223
Drivercontrol:
{INBOUND_BATCH {{RECORD_TYPE {HDR}} {VERSION_NUMBER {10}} {SENDER_ID {sndr}} {PASSWORD {passwd}}
{RECEIVER_ID {rcvr}} {SOURCE_NAME {source}} {CONTROL_NUMBER {1001}} {TRANS_DATE {20060103}} {TRANS_TIME {08150198}}
{TRANS_TYPE {FRM}} {ACTION {U}} {EXTRACT_DATE {20051230}} {FILE_TYPE {T}} {LOAD_STATUS {}} {TOTAL_RECORDS {223}}
{ROWS_IN_ERROR {}} {TOTAL_ERRORS {}} {BATCH_START_END {S}} }}
Outbound batch
The outbound batch has an edit screen with these parameters. These are configured from the Outbound tab of the Network Configurator’s Thread Configuration dialog box.
Option | Description |
---|---|
Valid selections are FRM - Formulary and Benefit Load and FRE - Formulary and Benefit Response. This is stored in NetConfig as FRM or FRE. | |
Sender ID | Alphanumeric text up to 30 characters. |
Sender Password | Alphanumeric text up to 10 characters. This displays as asterisks and is stored encrypted. When this screen displays, this field displays as 10 asterisks unless it is blank, in which case it displays as blank. |
Receiver ID | Alphanumeric text up to 30 characters. |
Source Name | Alphanumeric text up to 35 characters |
Valid selections are Full Replace and Update. This is be stored in NetConfig as F or U. | |
Valid selections are Today’s date and No default. This is be stored in NetConfig as T or {}. | |
Valid selections are Production and Test. This is stored in NetConfig as P or T. | |
Control Number Counter |
DRIVERCONTROL
. The counter field is encoded to be
from 1 to 9 characters in length with no padding or leading zeros. DRIVERCTL values
Similar to the other batch types, these values can be supplied or
overridden with settings in DRIVERCTL
metadata.
There are also some values not on the screen that can be set in DRIVERCONTROL
. These settings are sub-keys under the
OUTBOUND_BATCH
key.
Because there are multiple messages coming in, each with potentially
different driver control values, the driver control values accumulate. The
DRIVERCTL
fields accumulate from each message, but blank
DRIVERCTL
do not erase.
For example, if message
A
has driver control fields:
ABC: haha
CDF: hoho
And messages
B
has driver control fields:
CDF: hehe
Then the resulting DRIVERCTL
when the batch is created
is:
ABC: haha
CDF: hehe
Typically, the DRIVERCTL
values for each message
should be the same. This method attempts to be as robust as possible.
Sub-keys under OUTBOUND_BATCH
This table shows the sub-keys under OUTBOUND_BATCH
used by
outbound batch processing:
Sub-key | Description |
---|---|
RECORD_TYPE*
|
If not populated by driver control, then this is set to HDR when
TRANS_TYPE is FRM or set to
SHD when TRANS_TYPE is FRE.
Otherwise, this accepts the value that was passed by driver control. |
SENDER_ID |
Only written for load file (HDR). |
SENDER_PASSWORD |
|
RECEIVER_ID
|
|
SOURCE_NAME
|
SOURCE_NAME is only written for
load file (HDR).
If an outbound control counter file is
specified and a |
TRANS_DATE* |
If not populated by driver control, then this is set to the current date when the batch is processed. |
TRANS_TIME* |
If this is not populated by driver control, then this is set to the current time when the batch is processed. The time stamp specifies hundredths of a second to be displayed. Note that this TCL version only supports seconds, so the hundredths portion is always "00". |
TRANS_TYPE |
This is FRM or FRE. |
ACTION |
This is F or U. |
EXTRACT_DATE |
This is T or { }. Driver control can override this with the correct time stamp. If the value is still T when the batch is processed, then the current date is substituted. This is only written for a load file (HDR). |
FILE_TYPE
|
FILE_TYPE is T or P.
|
TOTAL_RECORDS*
|
TOTAL_RECORDS is only meaningful for a request batch
and is written to HDR. This is calculated from the number of
messages passed in that contained data and cannot be overridden.
|
BATCHSEND*
|
This is a special key that forces the creation of a batch ending with the current message. This is identical to the X12 and NCPDP batch functionality. Any string in this key causes the message to send. Blank, or no key, does not. |
The total records field in the load file trailer cannot be overridden because it is calculated from the number of messages in the batch.
Outbound batch processing also uses some sub-keys from the
INBOUND_BATCH
key of DRIVERCONTROL
. These are
used to populate the originating fields in a response batch header. Using the
INBOUND_BATCH
values for these keys makes the originating
numbers automatically populate if the inbound DRIVERCONTROL
is
copied to the outbound messages.
Sub-keys under INBOUND_BATCH
This table shows the sub-keys used by outbound batch processing:
Sub-key | Description |
---|---|
CONTROL_NUMBER |
This populates "Transmission Number, Originating" in the header. This
applies only to a response type batch
TRANS_TYPE=FRE . |
TRANS_DATE |
This populates "Transmission Date, Originating" in the header. This
applies only to a response type batch
TRANS_TYPE=FRE . |
TRANS_TIME |
This populates "Transmission Time, Originating" in the header. This
applies only to a response type batch
TRANS_TYPE=FRE . |
BATCH_START_END |
This functions similar to BATCHSEND
in OUTBOUND_BATCH . If the value of
BATCH_START_END is E, then it
forces the creation of a batch ending with the current message. This is a useful feature to create response batches. The response batch must correspond to the inbound batch. That is, it contains one response detail segment for each transaction in the inbound batch. Forcing batch creation after the last message of an inbound batch satisfies this requirement. |
To properly generate a response batch from a request batch split, implementation engineers should follow these instructions:
When splitting a request batch, each outbound message is copied to preserve
the DRIVERCTL
, then translated. If the translation
finds an error, then the message has an SDT segment describing the error; if there
is no error, then the message is blank. That is, there is nothing in the data field
but it still has the DRIVERCTL
from the original
message.
In this way, the last message that is blank, or contains an SDT segment, has
the BATCH_START_END
field in DRIVERCTL
set to E. The engine knows that is the end
of the messages and it is time to kick out the completed batch response message.