R1592 is an extension and enhancement of the GTN direct deposit process
now in place.  As originally introduced back in 1990, it was limited to a
predefined set of organizations with begin and end dates, transit routing
numbers, bank account numbers, and so on for each being stored in
copymember CPWSXNGO.  A limiting factor was that the system could
handle only one bank account number for each organization, that is,
money could not be directed to a personal account number.

When the TIAA-CREF Scholarshare program began, it required the use of
individual employee account numbers for participants, and this feature was
implemented in r1487.  In that release, a new DB2 EDB table, DDG
(Direct Deposit GTN), was created, containing these fields:

EMPLOYEE_ID
DDG_GTN_NUMBER
DDG_ADC_CODE
DDG_TRANSIT_NUM
DDG_ACCT_NUM
DDG_ACCT_TYPE
DDG_SPB_BANK_KEY

and a Direct Deposit GTN indicator was added to the GTN table to
identify eligible deduction numbers.

R1592 is the next step in the evolution of the process, and its primary
purpose is to generalize it in such a way as to make it possible to
extend it to other organizations such as credit unions and banks, and
also bring it more under user control.  It continues the use of the DDG
table to store employee-specific data, but replaces the CPWSXNGO
copymember with a new control table, #45.  This is a case where one
new logical table, the NACHA GTN Organization table, is supported by
two new DB2 tables (NGO and NGL).

The CPWSXNGO copymember groups together sets of GTN numbers
with similar attributes, and the two new tables continue that pattern.  The
NGL 'link' table consists of pairs of link code and GTN number, and the
NGO 'organization' table contains dates, transit routing number, prenote,
and deposit information for each link code.  The result is that multiple GTN
numbers can have a single set of banking information.  Although there must
be a correspondence between link numbers in the two tables, they have
no inherent meaning; they're just unique 2-digit integer values that allow you
to point to a particular entry.  The layouts of the transactions for updating
new table 45 are contained in form UPAY 918.

Other changes included in r1592:

- The release letter observes that '"Surepay" is a proprietary term used by
   Wells Fargo, and should not be used to apply to non-Wells Fargo direct
   deposit activity', and therefore assorted fields and CICS Help are modified
   to use a more general descriptor.  <Editorial note: I find this amusing
   because I was part of the team in 1986 that added Surepay to PPS.  It's
   taken a long time to discover that it's not proper usage.>  The Surepay
   bank table is not changed.

- R1487 established a limit of 10 DDG entries per employee.  R1592
   increases that to 12.

- Two new online screens/function codes  are added for display (IDDG) and
   update (EDDG) of employee direct deposit GTN data.  Until now it has
   only been possible to enter this information via batch transactions.

- Programs are provided for utility access and editing of transactions for
   the new control table.

Further details can be found in the release documents.

TABLE UPDATES
- Data element table transactions are provided.
- Message table transactions are provided.
- Data elements-to-screens table transactions are provided.
- NACHA GTN organization table transactions are -not- provided.
   See comments below.

IMPLEMENTATION

   Jerry Wilcox in a recent PAY-L note stated that 'installation of the "GTN
Direct Deposit" process implemented in PPS Release 1592 is an absolute
prerequisite for the installation of 457(b).'  It is also the last of the
series of
interdependent releases that I identified to payroll managers a couple of
weeks ago.  We must install it with all possible speed in order to meet the
date-mandated requirements of r1599, and even so, it will be very, very tight.
In the interest of speed, we will convert the current CPWSXNGO copymember
values into transactions to build the new NACHA GTN organization table,
and you won't need to do it.  Here is the information we will need from you
to proceed:

- Your regular approval to install the release.

- Identification of the online screen groups to which we should authorize
   the new IDDG and EDDG function codes.  For San Diego we'll need
   instead the name(s) of the appropriate function code groups, and we'll
   take care of adding the entries.

- The installation instruction document calls for EDDG to be added to the
   EEDB menu and for IDDG to be added to both the IEDB and IDDB
   menus.  We will add them to those three menus unless you instruct us
   otherwise, for instance, if you'd rather not list it on the IDDB menu.

We look forward to hearing from you soon.

   bvb