Edit Package Training – Session 01

Edit package Overview

OVERVIEW OF EDIT PACKAGE

The BASE II Edit Package is software supplied by Visa for processing

transaction files sent to and received from the VisaNet Interchange Center
(VIC). The Edit Package is the interface between the processing center’s
internal payment processing systems and the VisaNet Access Point (VAP). It
prepares the processing center’s outgoing interchange for transmission to the
VIC and receives and reports on incoming interchange from Visa, preparing it
for final processing by the processing center’s systems.

Edit Package Processing Flow

The Edit Package comprises two processing phases: outgoing interchange
processing and incoming interchange processing.

Outgoing Processing
The term outgoing refers to interchange sent from the member’s processing
center to the VIC. See Figure 1–1.

Pre-Edit Processing
The first part of the outgoing process is performed by software belonging to
the processing center. This is usually referred to as pre-edit processing, since
it is done prior to processing by the Edit Package. Pre-edit processing involves
the capture, editing, and formatting of interchange data. Transactions
submitted into interchange are processed through the processing center’s
pre-edit software, which places this information into a Center Transaction
File (CTF). Once pre-editing is completed, the data is ready to be run through
the Edit Package.

Figure 1–1: Outgoing Interchange

Edit Package Processing
E3OUT, the overall outgoing control program, calls initialization processes at
the beginning of each outgoing Edit Package run and then processes each
transaction found in the CTF.
At the end of processing, the control program produces the necessary reports.
Then the Edit Package produces an Interchange Transaction File (ITF) which
is transferred to a VAP, where it is held until a predetermined collection time.
The transmission of the file is jointly managed by the VAP and the VIC, with
little or no intervention required by center personnel. If a VAP or other
electronic transmission means is unavailable, the file must be mailed to the
VIC.
BASE II System Processing
At a predetermined time, the BASE II System at the VIC dials the VAP and
collects the interchange. As the interchange transactions are received by
BASE II at the VIC, clearing occurs. The transactions are validated, converted
to the appropriate currencies, and totaled and sorted by destination. Fees are
then calculated. At the end of each BASE II cycle, settlement positions are
computed for all members with either incoming or outgoing transactions.

Interchange data are protected from system failure after being accepted by
the VIC. In the event of a failure, the BASE II System can restart processing
where the failure occurred. If requested, interchange files can also be rebuilt
and electronically transmitted to the processing center.

Incoming Processing
The term incoming refers to interchange coming into the member’s processing
center from the VIC. See Figure 1–2.
The overall incoming control program E3IN calls an initialization process at
the beginning of each incoming Edit Package run and then processes each
transaction found in the ITF. At the end of processing, the control program
produces the necessary reports and makes the CTF available for use by the
processing center if there are no severe errors in the interchange file.
Incoming Edit Package files contain:
 Financial and nonfinancial interchange transactions

 Settlement totals

 BASE II System settlement reports

 Edit Package table update transactions

NOTE: To ensure proper application of table update transactions, all

incoming files must be processed. Files must be processed in sequence
by the Central Processing Date (CPD) on which they were created to
properly update the table files.

Post-Edit Processing
Post-edit software, written by center personnel or by an outside vendor,
reformats and processes incoming interchange received from the VIC. This
software prepares interchange so that it can be processed by cardholder and
merchant posting programs and used for other processing center purposes,
such as fraud analysis.

Key Features of the Edit Package

The Edit Package provides maximum flexibility for both installation and daily
processing. The key features that help make the Edit Package flexible are:
 Use of rules and value table files

 Availability of run control options

Rule and Value Tables

Edit Package transaction validation is performed using edit logic stored in
rules table files, rather than hard-coded edits.
When new business enhancements arise, the changes to the edits are
downloaded from the VIC to the processing center through incoming
interchange. This reduces the need to install new Edit Package software
whenever changes are introduced.

Run Control Options

Access to most functions in the Edit Package is available through run control
options. The use of run control options allows processing centers to customize
the Edit Package in a way best suited to their specific processing needs. Run
control options can be modified either at installation time or before each Edit
Package processing run.
Run control options allow the selection of a variety of functions, including:
 Splitting incoming ITFs into multiple CTFs

 Setting tolerance checking limits at the run or item levels

 Establishing duplicate batch detection settings

Edit Package Functions

Edit Package functions can be divided into five groups:
 Environmental—These functions determine the environment in which

the Edit Package is run. Through the use of run control options, the
processing center can modify how the Edit Package software runs in the
individual environments.
 Formatting—One of the functions of the Edit Package is to format CTF

data into ITF data during an outgoing cycle and to format ITF data into
CTF data during an incoming cycle.
The processing center can control some formatting functions so that
outgoing and incoming files and transactions can be more easily processed
by the center’s internal systems.
 Validation—Validation of interchange is a major function of the Edit

Package. In addition to standard validation, processing centers can select

additional forms of validation, such as the setting of tolerance levels at
both the run and item levels. Additional validation functions are
controlled through the use of run control options.

 Reporting—The Edit Package also includes functions for reporting.

Formatted reporting of outgoing and incoming transactions is available.
Processing centers can select which particular transaction codes are
reported.
Formats for dates, time, and numeric values can be modified according to
national standards and are available using run control options.
 PC Edit Package and Edit Package Data Entry Systems—These

systems are available to processing centers whether the Edit Package

runs on a mainframe or a PC. They give processing centers the ability to
key-enter original transactions that can be validated online. The PC Edit
Package and Edit Package Data Entry Systems validation logic uses the
same rule and value tables as the core Edit Package.
Both the PC Edit Package and Edit Package Data Entry System also
provide a mechanism for correcting both transactions rejected by the Edit
Package and transactions returned by the VIC.
Outgoing Edit Package Processing
Outgoing Processing Flow
This section describes the outgoing Edit Package processing cycle. Processes
are listed in the order they occur.
Outgoing Control Program
The outgoing Edit Package is a single-step process controlled by an overall
program that calls many submodules. The outgoing control program, E3OUT,
calls initialization functions as needed at the beginning of each run and then
processes each transaction found in the Center Transaction File (CTF). At the
end of processing, if there were no severe errors, the control program produces
the necessary reports and makes the Interchange Transaction File (ITF)
available for staging on the VisaNet Access Point (VAP).
Figure 3–1 provides a high-level illustration of the processing flow for a
typical outgoing Edit Package run.
Input Requirements
The following items are required before an outgoing Edit Package run can be
executed:
 An outgoing CTF generated by the processing center’s pre-edit program

 The following files, which must reside on a direct access storage device:

– Permanent and Temporary Run Control Options Files

– Incoming Run Hold File
– Account Range Definition (ARDEF) File
– BIN File
– Language File
– Rules File
– History File (indexed and backup)
– Log File (indexed and backup)
– Merged Table File
– Table Control File
– BIN and ARDEF Top Gun History Files (may be initially empty)
Initializing the System
The following processes occur during system initialization:
Search Run Control Options Files
At the start of an outgoing Edit Package run, E3OUT searches the Permanent
and Temporary Run Control Options Files for the following run control
options:
 Center BIN (CENTRBIN)

 Center Code (CENTRCODE)

 Center Name (CENTRNAME)

 Table Date (TABLEDATE)

 Run Date (RUNDATE)

 Run Mode (RUNMODE)

 Table Key (TBLKEY)
 Table Data (TBLDATA)
NOTE: TABLEDATE, RUNDATE, RUNMODE, TBLKEY, and TBLDATA run
control options are not required. If not present in either run control
options file, default values are used.
Load Internal Tables
Next, E3OUT uses the information from the above run control options to load
the following files into internal tables:
 ARDEF File

 BIN File

NOTE: Information from the BIN and ARDEF Top Gun History files
determine the Processing Center’s most frequently referenced BINs and
ARDEFs. and ensure they are loaded into computer memory.
 Language File

 Rules File

E3OUT loads the tables with values needed for the transaction validation
process. If specified, E3OUT calls optional extended service modules to
calculate cutoff dates required to perform timeliness edits for incentive
scheme processing.

Validate Run Control Options

Once the files and tables are loaded, E3OUT validates all run control options,
and:
1. Sets default values for run control options, where necessary
2. Performs cross-validation of run control options to ensure that there are
no conflicting options in the run
3. Stores the run control options in effect for the run in internal tables
4. Writes the run control options in effect for the run to the Log File

Assign Run and Starting Batch Numbers

After validating the run control options, E3OUT references the History File to
assign run and starting batch numbers. Batch numbers start at 1 for each
processing day and are incremented by 1 for each batch processed.

Reruns—If the current outgoing Edit Package run is a rerun, E3OUT verifies
that it has already performed the run for the run date in effect and reuses the
starting batch number in effect for the original run.

Creating the Outgoing ITF

The creation of the outgoing ITF consists of the following processes:

Process CTF
1. Check File Header—If there is a file header, this process verifies that it
is correct. If the file header contains a nonzero Unique File ID, then
E3OUT checks the History File to verify that it is not a duplicate file.
2. Build Logical Transactions—This process reads one Transaction
Component Record (TCR) at a time from the outgoing CTF, validates the
sequence number, and groups the TCRs together to build each logical
transaction.

Validate Transactions
E3OUT passes the TCRs for each logical transaction to the table manipulation
submodule that validates the transaction code. Based on the transaction code,
the table manipulation submodule uses the appropriate transaction layout
from the tables and performs edits against the rules and values defined in the
tables. (See BASE II Clearing Interchange Formats manuals for definitions of
the transaction edits.)
The table manipulation submodule also passes back to E3OUT any errors and
formatted information needed to generate reports.

Perform Optional Processing

After validating transactions, E3OUT performs optional processing,
including:
 Item or run tolerance checking

 Calculates the hash value for each record, if duplicate batch checking via

hashing is selected
Extract Reports
Once optional processing is completed, E3OUT calls the report extract module
which extracts summary and transaction-based report information and passes
it to a work file.
Create ITF
After extracting summary and transaction-based report information, E3OUT
calls the transaction write module. If a transaction was not rejected, it is
written to the outgoing ITF.
Rejected Transactions—If a transaction was rejected and the processing
center has selected the SAVEREJECT run control option, the transaction is
written to the Rejected Item File.
Hash Totals—If the processing center uses an IBM mainframe (MVS and
VSE), a 2-byte hash total field is inserted in each transaction at this time.
CTF Trailers
E3OUT verifies that all batch and file trailers balance, that is, totals read
from the records in the CTF equal the sums of accepted and rejected totals
accumulated by E3OUT during processing. If duplicate batch detection has
been selected using the DUPBATCH option, E3OUT will also compare the
batch hash value or Center Batch ID against the history file values.
ITF Trailers
The Edit Package writes a batch trailer to the ITF every time a batch trailer is
encountered in the CTF. File trailers are written to the ITF at the end of CTF
processing. If more than one CTF is processed, the Edit Package will combine
the CTFs on the ITF. If ITF files are being written to tape or diskette, the Edit
Package will also write a file trailer whenever the tape or diskette is full. A
file header record for the next tape or diskette is then written to the ITF.

Generate TC 50 Text Transactions

Before loading tables for reporting, the Edit Package generates a batch in the
ITF that contains TC 50 text transactions. These transactions contain:
 Edit Package incoming and outgoing environmental information, such as

date of run and version and date of tables used during the run.
 Information showing the version number of the Edit Package software

being used and the level of TIU’s applied.

There is one TC 50 for each record in the Permanent and Temporary Run
Control Options Files. There also is an environmental record and a record for
each run control option used during the previous incoming Edit Package run.

Producing Exception, Control, and Summary Reports

Producing exception, control, and summary reports consists of the following:

Load Tables
After the ITF is created, E3OUT calls the table manipulation submodule to
reload the Rule, Value, and Language Tables with information needed to
generate reports.

Sort Data and Format Reports

Next, E3OUT sorts data for the following reports:
 Validation Exception Detail Report

 Summary reports that summarize the transactions accepted for

interchange
 Optional transaction-based reports that are detail reports of the

transaction information
After sorting data for the above reports, E3OUT calls the appropriate modules
to format the reports.

Updating the History File

If the run was successful, E3OUT updates the History File with the following:
 An outgoing batch record for each batch processed during the run

 An outgoing file record for each file processed during the run

 One outgoing run record

Updating the Top Gun History Files

During transaction validation, E3OUT collected statistics on the number of
BIN and ARDEF table references that was made. At the end of the outgoing
run, these statistics are used to update the BIN and ARDEF Top Gun History
files. The top gun history files determine the most frequently referenced BINs
and ARDEFs for the processing center, and are used during subsequent table
loads to ensure that these BINs and ARDEFs are loaded into computer
memory for faster access.

Updating the Engine Table Usage Message Files

At the completion of each Edit Package run, statistics regarding the dynamic
usage of the Edit Package tables are output to the Engine Table Usage Metric
Files. This information may be requested by Visa to assist in support issues.

Producing the Outgoing Log Report

During an outgoing Edit Package run, data is written to the system log. At the
end of the outgoing run, whatever data was accumulated in the Log File
during the run is written to the EP–199 Log Report.

Exception Conditions
The several types of exception conditions are as follows:

Severe Errors
If a severe error is detected during the outgoing Edit Package run:
 The appropriate severe error message appears in the Validation Exception

Detail Report (EP–100A) and the Log File Report (EP–199)

 An ITF is not created

 Processing of the Edit Package continues to the end of the run, if possible.

If the Reject Message Limit (REJMSGLIM) run control option is specified,

processing stops when the percentage of the transactions processed so far
exceed the percentage specified for the REJMSGLIM option. If the Reject
ITF Limit (REJITFLIM) run control option is specified, error reporting
continues until all transaction in the input file are processed, but the ITF
is not created if the percentage of transactions containing errors for the
entire input file, exceeds the percentage specified on the REJITFLIM
option.

CTF Errors
If any errors are detected during the processing of the CTF, the transactions
with errors are written to the Validation Exception Detail Report (EP–100A)
and are not passed to the ITF. If the SAVEREJECT run control option is
selected, the transactions in error are written to a separate CTF.

Messages
After each outgoing Edit Package run, the banner page on the EP–100A
Validation Exception Detail Report displays a message indicating the status of
the run.

MAJOR FILES USED IN OUTGOING PROCESSING

Table Files
The Edit Package table files consist of two separate loadable table images
called image A and image B. One of the images is used for the current Edit
Package release, while the other image is reserved for possible use with a
future release of the Edit Package.
Each loadable table image consists of four indexed files: ARDEF, BIN,
Language, and Rules files. Each image has two merged sequential copy files,
which include the contents of all four indexed files. During outgoing runs, the
merged files are used only to recover the indexed version of the files when the
existing indexed versions are not usable.
Transaction layouts and edit logic are maintained by TC 54 table updates
received from the VIC through the processing center’s incoming interchange.
This allows business enhancements to be implemented without the need to
update and redistribute Edit Package source code.

Account Range Definition (ARDEF) File