Setting Up Common Components for Bank Statement, Payment, and Payment Acknowledgment Processing

These application pages are common to setting up the three electronic banking processes:

• Layout Catalog

  The Layout Catalog is a repository of information that is used for establishing how data should be formatted when processing bank statements, payments, and payment acknowledgements.

• Code Mappings

  For Bank Statement Import processing, you map external bank codes to their internal PeopleSoft equivalents to ensure efficient statement processing.

  For Dispatch Payment processing, the Code Mappings page is used to associate PeopleSoft input code values with external bank output code values.

• (Optional) Event Code Definition

  You can setup events that can occur during Bank Statement Import and Dispatch Payment processing so that interested parties will be notified by email of those events.

• (Optional) Encryption Profile

  You can use encryption algorithms to secure statement and payment files that are sent between your organization and your bank.

The Layout Catalog is the central repository for information regarding all supported bank payment, payment acknowledgment, and bank statement layouts. After a layout is added to this component, it is available for use within the system. The component contains all the information about a layout—such as the transformation Application Engine program or application class that contains the logic to process the layout—that the system needs at setup and runtime. This component can be configured to meet each bank's specific formatting needs.

See Layout Catalog Page.

Code Mappings enable you to define the mappings between external system codes with their equivalent internal PeopleSoft codes. For example, PeopleSoft stores 03 account types as checking accounts, and the required code for the EDI 820 bank statement layout is DA for deposit account. Code mappings are used to map these hard-coded field values to each other so that the transformation program component can use them. This allows a single transformation program to be used across multiple banks even though the program may need different code mappings.

Code mappings are most useful for fields that may change for every bank. Bank statement processing uses mappings for three fields: bank statement codes, reconciliation or "recon" codes, and statement activity types. For example, a bank identifies certain miscellaneous fees with the numeric code 564. If you define it as a Bank Fee, you can assign the input value of 564 to the output value of BKFEE. Other banks may use a different value to identify bank fee.

See Defining Statement Activities.

There are three levels to the code mapping data-structure hierarchy:

• Code Map Group: The highest level, this is a container for all the fields for a given code map set. For instance, a code map group could represent all the code mappings for a particular bank.

• Code Map Header: The second level, this represents a particular field for which the transformation Application Engine obtains the code map.

• Code Map Items: The items contain all the possible input and output values for a particular field or header.

To access Code Mappings defined in the database, use an application class entitled CodeMapper within the transformation program.

CodeMapper()

getDefault(String groupID, String fieldName)

getInput(String groupID, String fieldName, String outputVal)

getOutput(String groupID, String fieldName, String inputVal)

initializeRowset(String groupID)

/* Import the code mapping class into the people code where it is to be 
called */

import TR_CODE_MAPPING:Utilities:CodeMapper;

/* Initialize the object (this initiates the constructor for the class */
&oMapper = create CodeMapper();

/* Initializes the object to contain the data for the given Group */
&oMapper.initializeRowset(&strGroupID);

/* Obtain the output value for the given Group ID, the field called 
"BANK_STMT_CODE" and the value in &strInput */
&strOutput = &oMapper.getOutput(&strGroupID, "BANK_STMT_CODE", &strInput);

The files that are sent to and received from your bank during the Dispatch Payment and Bank Statement processes can be encrypted and decrypted. This functionality is provided by the PeopleSoft Encryption Technology (PET), which supports several industry standard encryption formats that are used by a large number of banks. To enable encryption and decryption, you need to create encryption profiles in PeopleTools. For complete instructions on setup and configuration, see PeopleTools: Security Administration.

The general steps for setting up an encryption profile are:

1. Consult your bank to determine a common algorithm to use.

   Most likely, your bank will support either the PGP, SMIME, or PKCS#7 format.

2. Install the required toolkit to produce the encryption format.

   PGP requires a software developer kit to be purchased from the PGP Corporation. PKCS#7 requires OpenSSL. Some OpenSSL files are delivered with PeopleTools. Installation instructions can be found in PeopleTools: Security Administration.

3. Load public and private keys into the PeopleTools PET Keyset store.

   PGP, SMIME, and PKCS7 require a key pair to be generated. PGP functionality requires a secondary utility called PGP Mail to help facilitate managing and creating keys. OpenSSL provides a command line where X509 key pairs can be generated. In either case, you will need to exchange public keys with your bank and load the banks public keys into the keystore.

Use the Layout Catalog page (PMT_FORMAT_CATLOG) to create new or modify existing bank statement, payment, and payment acknowledgment layouts by defining transformation processing details, payment methods, parameters, and properties.

Image: Layout Catalog page (1 of 2)

This example illustrates the fields and controls on the Layout Catalog page (1 of 2). You can find definitions for the fields and controls later on this page.

Image: Layout Catalog page (2 of 2)

This example illustrates the fields and controls on the Layout Catalog page (2 of 2). You can find definitions for the fields and controls later on this page.

Define the file layouts, output type, and integration options that a particular bank supports. The catalog stores information about the layout, the program name containing the logic to generate or process the layout, and additional required setup or processing parameters that the layout requires.

If the bank does not support any of the delivered layouts or has a modified version of a delivered layout, you can create a new layout or edit a delivered layout. After a new or modified layout is added to the Layout Catalog, it is available for use in the system.

If you are adding new layouts or editing existing layouts for an organization's payment processing requirements, you must first create the new layout before you can continue this setup procedure. Follow the procedures to create a new layout that are outlined in the sections Defining Payment Grouping Rules, Defining Code Mappings for Banks Statements, Payments, and Payment Acknowledgments, and Creating Payment Layouts. Then add the new layout to the Layout Catalog.

See Understanding the Layout Catalog.

See Code Mappings Page.

See Creating Payment Layouts.

Layout Properties

Layout Properties are information that is needed by a transformation program to successfully create and process a layout. A layout property can be anything, but generally is either a data value that is needed by a layout that is not captured in the system or a processing flag that is needed by a transformation program. These properties are defined at design time, bound with values at setup time, and available to the transformation program at runtime. The values for these defined properties are captured at setup time for every bank.

For example, the layout property SENDER_ID, which is used by the EDI 820 payment layout, identifies the ID of the party that is sending the file. No field is defined in Financial Gateway to store this value, yet this layout requires the property at runtime. Adding SENDER_ID to the layout properties allows this value to be set up for every bank. At runtime, this value is available to the transformation program to be included in the 820 layout.

Property Code	Displays the name of the layout field. Important! If you specify a default, file-extension value for the FILEEXT property code, you must enter a period before the file extension. For example, you enter .TXT, not TXT.
Type	Specify the property code data type: Date, Number, String, Time, or Yes/No.
Property Level	This determines where the property will be set up: bank, account, or system level. For payment layouts, this also determines where in the PAYMENT_DISPATCH IP this value is available to the transform program. System and bank level properties are available in the PMT_HEADER_PROP record. Account level properties are available in the PMT_BATCH_PROP record. For payment files, the layout property values are included in the PAYMENT_DISPATCH IP for use in transformation programs at runtime. The records PMT_HEADER_PROP and PMT_BATCH_PROP contain these values. If you are creating a new transformation program and need to capture some setup information, such as company TAXID, a layout property would be added to the Layout Catalog. It would be set up at bank of account level. You can then use this information in the PAYMENT_DISPATCH message of the transformation program.
Required	Select to indicate that this property code is required.
Read Only	Select to make this property code a display-only value. This type is good for system settings that need to be captured, but do not vary by bank.
Max Length (maximum length)	Enter the maximum character length. At setup time, the entered value is validated to ensure that it is not longer than the maximum length and is the type specified (for example, string, number, yes/no, and so on).
	Click the Allowed Values icon to access the Allowable Format Properties page (PMT_FORMAT_VALUES), where you can select the type of list option to apply as the allowed format property. Select one of these list options: All Code Map Groups A code map group defines the mapping between external bank codes with their equivalent internal PeopleSoft codes for both bank statement and bank payment processing. List of Values This list limits the choice of allowable values for a property code. For example, the PAYREQEIP layout limits the FILETYPE property values to either a CSV or FIXED format.
Default Value	Enter a property-code, default value. You can override this value when defining integration layouts for a bank or account.
Sequence	Enter sequence numbers to prioritize the property codes. Properties with lower numbers will be displayed first at setup time. During the transformation process, the system processes property codes from the lowest to the highest value.

Use the Code Mappings page (TR_CODE_MAPPINGS) to define input and output values for mappings of a selected code map group.

Image: Code Mappings page

This example illustrates the fields and controls on the Code Mappings page. You can find definitions for the fields and controls later on this page.

This page enables you to define the mapping between external bank codes with their equivalent internal PeopleSoft codes for both bank statement and bank payment processing.

Bank statement processing uses mappings for three fields: Bank Statement Codes, Reconciliation Codes, and Statement Activity Types.

For example, a financial organization identifies certain miscellaneous fees with the numeric code 564. If you define a statement activity type of Bank Fee (BNKFEE), you can assign the input value of 564 to the output value of BNKFEE.

Use the Event Code Definition page (TR_EVENT_CD_DEF_PG) to enter codes for system events, and define actions for the system to perform when they occur.

Image: Event Code Definition page

This example illustrates the fields and controls on the Event Code Definition page. You can find definitions for the fields and controls later on this page.