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, Edit 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.
This table shows the sub-keys that are populated by inbound batch processing:
Sub-key Description
RECORD_TYPE Header segment (HDR or SHD)
VERSION_NUMBER
SENDER_ID Only populated for a load file (HDR)

PASSWORD

RECEIVER_ID
SOURCE_NAME Only populated for a load file (HDR)

CONTROL_NUMBER

TRANS_DATE
TRANS_TIME

TRANS_TYPE

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)

FILE_TYPE

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.

Note: The only selection for version is "1.0." The Message Count and Interval fields work the same as with other EDI batches. All of the header fields are required in the final message. They can be left blank on the screen as they can be set and overridden with DRIVERCONTROL in each message.
This tabled shows the options on the Outbound tab of the Network Configurator’s Thread Configuration dialog box:
Option Description
Transmission File Type 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
Action Valid selections are Full Replace and Update. This is be stored in NetConfig as F or U.
Extract date Valid selections are Today’s date and No default. This is be stored in NetConfig as T or {}.
File Type Valid selections are Production and Test. This is stored in NetConfig as P or T.
Control Number Counter
This is the counter name used to generate control numbers. A standard counter file with this name is created in the process directory if one does not already exist. The created counter starts at 1 and wraps after 999999999. This field can be left blank in which case no counter is used and the user must supply the control number in 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*

VERSION_NUMBER

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

COUNTER

CONTROL_NUMBER*

SOURCE_NAME is only written for load file (HDR).

COUNTER is the counter file name to generate the transaction control number field. This is ignored if CONTROL_NUMBER is specified.

CONTROL_NUMBER is for when a control number is set with driver control. This is remembered and used for every outbound batch until it is updated by another value.

If an outbound control counter file is specified and a CONTROL_NUMBER sub-key is supplied, then the sub-key value is used and the counter does not increment.

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

LOAD_STATUS*

FILE_TYPE is T or P.

LOAD_STATUS is only meaningful for a response batch and is written to SHD. The default is 01 for "file loaded correctly". A failed message sets this field to the appropriate error value for the entire batch.

TOTAL_RECORDS*

ROWS_IN_ERROR*

TOTAL_ERRORS*

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.

ROWS_IN_ERROR and TOTAL_ERRORS are only meaningful for a response batch and are written to STR. These are calculated from the number of SDT messages 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.
Note: The asterisk (*) indicates the sub-key is not available on the configuration screen.

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.