Setting Up Electronic Banking Using Financial Gateway

This chapter provides an overview of electronic banking and discusses how to:

• Set up components that are common to bank statement, bank payment, and bank payment acknowledgment processing.

• Set up bank statement processing.

• Set up bank payment processing.

• Set up payment acknowledgment processing.

• Review event log information.

• Use a communications partner for electronic banking.

Understanding Electronic Banking

Financial Gateway provides the layouts and functionality needed to load electronic bank statements, electronic payments, and payment acknowledgments. You can also edit and expand the delivered functionality to suit your organization's needs.

You will probably want to implement both the bank statement import and payment dispatch functionality; however, you can implement just one or the other. When the payment processing is implemented, users can implement payment acknowledgment functionality as well. This chapter discusses the delivered functionality and configuration instructions.

You can import a variety of bank formatted files by:

• Using an FTP server.

• Using PeopleSoft Integration Broker.

See Defining Payment Methods.

Transformation Architecture

Transformation programs (or Transforms) are application classes or PeopleSoft Application Engine (AE) programs that contain logic to convert source data into new output layouts. Transforms use Integration Point (IP) messages either as the source data or the transform output, depending on the direction. By using an AE for transformations, any PeopleTools technology, such as PeopleCode, Rowsets, File Layout Object, and XSLT, can be used to facilitate the creation of output layouts. Using these tools, you can create new layouts and maintain them in the standard PeopleSoft Application Designer environment. After you create a transformation program, you can register the program in the Layout Catalog for use in the processes.

For bank statement processing, the transformation program processes the bank statement as the data source. The formatting logic of the transformation AE or application class then converts the data into the BANK_STATEMENT_LOAD_VERSION_2 or BANK_ACCT_ANALYSIS_LOAD IP message that is then loaded into the system.

Payment Transformation programs do the opposite by processing the data that is contained in the PAYMENT_DISPATCH IP message into a new payment layout.

The Payment Acknowledgment Transformation Application Engine program processes the inbound data from the bank into the PAYMENT_ACKNOWLEDGE message.

Note. The delivered transformations, though developed to industry standards, are designed to be customized to meet the specific requirements of individual financial institutions.

See Enterprise PeopleTools 8.46 PeopleBook: Integration Broker, “Applying Filtering, Transformation, and Translation,” Developing Transform Programs

Bank Statement Import Infrastructure

This diagram illustrates the Bank Statement Import process.

Bank Statement Import process

The Bank Statement Import process involves the following steps:

1. A bank administrator enters information pertaining to a bank statement data file.

   This initiates the File Import Application Engine process (IMPORT_FILES), which functions as an interface or shell to define the necessary commands for the system to import bank statements.

2. The File Import Application Engine reads the file's layout definition data (which is stored in the Layout Catalog) and calls the appropriate transformation process that corresponds to the file layout.

3. Each transformation Application Engine or application class handler has corresponding application classes that, combined with the balance and transaction codes (defined on the Balance Code and Transaction Code pages) and code mapping information (defined on the Code Mappings page), contain all of the required formatting logic to stage the data.

   Using the appropriate IP message, the transformation application engine loads the data into the staging tables.

4. After the data is loaded into the staging tables, the Bank Statement Load Application Engine process (TR_BSP_LOAD) transfers the data from the staging tables to the application tables. This process also checks for duplicate entries and verifies that the data will load into the application tables properly.

   When the data is in the application tables, it is available for viewing and editing on the various bank statement pages.

Using the Import Bank Statements page, you can configure the File Import Application Engine process to manage various import methods. The functionality can load data from a flat file or transmit file data from an FTP server by using PeopleSoft Integration Broker. If you decide to import the bank statement data by using FTP, you must also set up the standard and bank statement import-specific settings for Integration Broker. After you define the Integration Broker settings, you can select the Use Integration Broker check box under Advanced Options on the Import Bank Statements page to send the bank statement to other processes after it has been loaded.

See Defining Integration Broker Settings for Bank Statements and Payment Acknowledgments.

Bank Payment Infrastructure

This diagram illustrates the Payment Dispatch process.

Dispatch Payment process

The Payment Dispatch process provides the functionality to generate payment files in a variety of layouts and securely transmit them to the financial institution or place the files in a directory for another system to transmit. This design provides a flexible infrastructure that enables the user to define a variety of payment layouts, and encryption algorithms that are compatible with the financial institution. It also provides a structure that enables you to easily create new layouts or modify existing ones.

When you dispatch settlements for processing, you activate the Dispatch Payments Application Engine process (PMT_DISPATCH). This process uses metadata that is defined at the bank setup level, the payment dispatch IP message (PAYMENT_DISPATCH), and payment-layout transformation Application Engine programs to create formatted payment files. This overall process is called the Payment Dispatch process.

The Payment Dispatch process brings together all the payment file processing features to:

1. Gather the bank setup metadata, such as bank integration information, payment method, payment layout, bank communication and encryption information, and payment grouping rules.

2. Generate the PAYMENT_DISPATCH IP message.

   The outbound Payment Dispatch IP is used as a data source for the transformation process. File layouts are created from the data that is contained within this message.

3. Transform the Payment Dispatch IP to the appropriate PeopleSoft Financials, global, payment layout that the bank can receive in its raw form and use to settle payments. Payment layouts have an associated Application Engine program or application class that generates a formatted file.

4. Encrypt data by using PeopleTools security encryption.

5. Transmit the final formatted file, by publishing it to PeopleSoft Integration Broker functionality, or writing to a file and calling an external command to transmit the file.

The PAYMENT_DISPATCH IP message is a structure to facilitate publishing payments. The supported payment methods are Automated Clearing House (ACH), Electronic Funds Transfer (EFT), direct debits (DD), and wire transfers (WIR). The IP message contains a superset of all information that is needed to settle multiple payment types on a global scale. This information includes representative parties, such as the payment originator, bank of origin, destination, destination bank, and the various settlement identification information that is required in different countries. The IP message can be received directly by the financial institution for processing in its raw format, with no transformation work required. Conversely, the IP message can be processed by a transformation program that transforms the IP message into an industry-standard, payment-file layout.

The system uses the PAYMENT_DISPATCH IP as the data source for file transformation programs—Application Engine or application classes—to format payment output files. You set up the transformation program in the Layout Catalog. There you specify layout information, such as the transformation Application Engine or application class t that contains the logic to generate the layout, layout-specific parameters, and supported payment methods.

Note. You can configure transformation Application Engine programs to use a combination of PeopleCode, file layouts, application classes, and XSLT to format files.

Bank Payment Acknowledgments Infrastructure

The infrastructure of the payment acknowledgments functionality is similar, though less complex, to the bank statement import infrastructure.

Payment acknowledgment import process

The Payment Acknowledgment Import process involves the following steps:

1. The File Import Application Engine process (IMPORT_FILES) downloads the payment acknowledgment into the system. Two types of acknowledgement are possible.

   The first acknowledgment—file acknowledgement—is sent after the payment file has been received and has passed basic bank validation involving checking for required fields and valid bank ID numbers. After the file has passed bank validation, and before actual settlement of the payment contents, an acknowledgement is generated to confirm whether the file is valid to continue processing or is in error.

   The second possible acknowledgement—payment acknowledgement—is sent after the actual payment has been processed by a clearing network or settlement process. The second acknowledgement can take the form of either a paid confirmation or an error message. Depending on the type of payment, a bank reference to the transaction, such as a federal reference number, may be included.

2. The Payment Acknowledgment Import Application Engine reads the file's layout definition data (which is stored in the Layout Catalog) and calls the transformation program—application class or the Payment Acknowledgment Transformation Application Engine (PMT_ACK_EIP)—to convert it into a PAYMENT_ACKNOWLEDGE message and load the data into the application tables.

   Payments and payment files in the Financial Gateway system are updated in accordance with the contents of the acknowledgements. If the source systems are set up to handle payment status updates, then the payments and payment files are also updated in the source systems as well.

3. Users access the Review Acknowledgment Files page to view a listing of the payment acknowledgment files.

Methods of Bank Communications

You can use various methods of communications to send payments to banks and receive bank statements and payment acknowledgements. Certain setup tasks are required based on the method that you use.

You can send payments that are outbound from Financial Gateway using:

• File Server

  Financial Gateway sends the payment files to a specified directory on a file server. The bank uses a third-party communications tool kit to transfer the payment files from the server to the bank.

• Integration Broker

  Financial Gateway sends the payment files to an Integration Broker node, which communicates with the bank using a specified connector—FTP, AS2, or HTTP.

You can import bank statements and payment acknowledgements from a bank using:

• File Server

  The bank uses third-party communications tool kit to transfer the bank statement or payment acknowledgement files to a specified directory on a file server. Financial Gateway uses the IMPORT_FILES Application Engine processes to import them into the system.

• Integration Broker

  The bank sends the bank statement or payment acknowledgement files to an Integration Broker node, which communicates with the Financial Gateway using a specified connector—FTP, AS2, or HTTP.

Use this table as a guide to determine the application page that you must set up to transmit a particular file type.

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

To define event code notification, use the Enter Event Code Definition component (TR_EVENT_CD_DEF_GBL).

This section discusses how to set up components that are used to:

• Import bank statements.

• Dispatch payments.

• Import payment acknowledgements.

Components Common to 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.

• Event Code Definition

  You can define events that can occur during Bank Statement Import and Dispatch Payment processing for which interested parties will be notified by email.

• Node Definition (optional)

  Define nodes only if PeopleSoft Integration Broker is used to transmit files between Financial Gateway and the bank.

• Encryption Profile (optional)

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

Understanding the Layout Catalog

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 is configurable to meet each bank's specific formatting needs.

Note. PeopleSoft also provides two additional layouts in the layout catalog: one for importing investment pool data that is used in Cash Management, and one for importing stock quotes that are used in Deal Management.

See Configuring Bank Statement, Payment, and Payment Acknowledgment Layouts.

See Maintaining Pool Positions.

See Maintaining Equities.

Delivered Bank Payment Layouts

PeopleSoft delivers these bank payment layouts:

Delivered Bank Statement Layouts

PeopleSoft delivers these bank statement layouts:

Note. You can import bank-statement, data files using the PSBD2 layout if you have Cash Management 8.8 installed and are using a third-party, communication toolkit that has the capability of processing files in XML format. Sample files that can be used as guidelines for transforming bank-statement, date files into the PSBD2 layout can be found on Customer Connection.

Delivered Bank Payment Acknowledgment Layouts

PeopleSoft delivers these Payment Acknowledgment layouts:

Understanding Code Mapping

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.

Class CodeMapper

To access Code Mappings, which is defined in the database, use an application class entitled CodeMapper within the transformation program. This table provides the details of the CodeMapper Application Class (Package - TR_CODE_MAPPING.Utilities).

Note. The CodeMapper application class should only be accessed by advanced users to customize their layouts or create a new layout program.

The following code sample illustrates how to use the CodeMapper class within PeopleCode:

/* 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);

Understanding File Encryption

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 PeopleTools Pluggable 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 Enterprise PeopleTools 8.46 PeopleBook: 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 Enterprise PeopleTools 8.46 PeopleBook: 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.

Note. Installing PGP Mail may cause encryption errors if you install it on the same machine as the PeopleSoft Process Scheduler and the PGP SDK.

Also, OpenSSL provides some documentation on their Web site to help with the preceding setup task. See http://www.openssl.org/docs/HOWTO/. The PKCS#7 keys should not be self-signed certificates. They must be signed by a real Certification Authority (CA), such as VeriSign or your bank, or signed by a CA that you created with OpenSSL.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Security Administration

Pages Used to Set Up Common Components for Bank Statement, Payment, and Payment Acknowledgment Processing

Configuring Bank Statement, Payment, and Payment Acknowledgment Layouts

Access the Layout Catalog 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 Defining Code Mappings for Bank Statements, Payments, and Payment Acknowledgments.

See Creating Payment Layouts.

Layout Details

Supported Payment Methods

This group box appears only for payment layouts and is used for defining the specific payment methods that are supported by the payment layout.

Select a layout payment method. Values are:

• Automated Clearing House

• Direct Debit

• Electronic Funds Transfer

• Wire Transfer

See the payment layout table for a list of delivered layouts and their corresponding payment methods.

See Understanding the Layout Catalog.

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.

Defining Code Mappings for Bank Statements, Payments, and Payment Acknowledgments

Access the Code Mappings page for the bank statement or payment layout.

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.

Defining Event Notifications

Access the Event Code Definition page.

Notify Flag	Select for the system to send an email or workflow message to the specified party if this event occurs.
Recipient Type	Select Person if the message recipient is a specific employee. Select Role if the message recipients should include all users in a specific role, such as a manager.
Notify Template	Select the message text template.
Notify To	This field is dependent on the selected Person/Role field value. If you select Person, enter the email address of the person to notify. If you select Role, enter the role name. Note. To enable this email-notification functionality, you must setup and configure the PeopleTools Simple Mail Transfer Protocol (SMTP) functionality. See Enterprise PeopleTools 8.46 PeopleBook: Workflow Technology, “Adding Events and Routings”

Defining Integration Broker Settings for Payments

Access the Node Definitions page.

Payment files can be sent to the Integration Broker for communication with your bank. The Integration Broker contains a set of communication connectors that will provide connectivity with most banks. The most common connectors used are the FTP, FTPs, AS2, HTTP, HTTPS, FILE, and JMS.

The Bank Integration Layouts component enables you to specify an output type for payment files. If you select message (Integration Broker), then a node must be entered. At runtime, the payment will be asynchronously published to this node in the Integration Broker. Integration Broker then provides the communication functionality.

Before you begin enabling Integration Broker messages, you must set up the basic integration broker settings, such as Gateway, and application server with messaging enabled, domain active, channels active, messages active, and so on.

Defining the settings to process payment files through PeopleSoft Integration Broker using an output-type message is a four-step procedure:

1. Create a node definition that represents the bank on the Node Definitions - Node Info page.

2. Add a transaction on the Node Definitions - Transactions page.

   Specify a Transaction Type of Outbound Asynchronous, and specify a Request Message of PMT_FLAT_FILE.

   You must create a corresponding outbound, asynchronous, transaction-type message for the node definition. PeopleSoft delivers the PMT_FLAT_FILE message for the delivered layouts. Both the layouts and the corresponding message are configured to be published to the Integration Broker. To implement payment processing functionality, select the PMT_FLAT_FILE message.

3. Complete the transaction and message details by clicking the Edit link.

4. Complete the Connectors page.

   Define connector properties information at the node or node transaction level on the Connectors page.

   Integration Broker comes with a variety of connectors that can be used. The primary connector for use with banks is the FTPTARGET connector. This enables you to send files using FTP and FTPs to your bank.

   If you use Integration Broker with the FTP connector ID FTPTARGET and leave the FILENAME parameter blank, the PMT_DISPATCH process will override this property and generate a unique filename for each message using the Bank Integration Layout properties FILENAME and FILEEXT to generate this value.

   Some banks, however, require all files to be sent under the same filename. Therefore, define the connector property FILENAME with a value to ensure that all files are delivered to the bank with the same filename.

Note. You can configure your Integration Broker node to use an AS2 connector.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker, “Using Listening Connectors and Target Connectors,” Working with AS2 Connectors

Defining Integration Broker Settings for Bank Statements and Payment Acknowledgments

Access the Node Definitions page.

Note. This section describes how to set up an Integration Broker node for importing bank statement files and payment acknowledgment files from an FTP server. Files can also be imported from a bank using a file server—a method that doesn't employ Integration Broker nor require setting up an Integration Broker node.

To set up an Integration Broker node for importing files from an FTP server:

1. Create an new node, name it, and enter a description for the node.

   Leave the default values for all the other fields.

2. On the Connectors page, select FTPTARGET in the Connector ID field.

   The appropriate properties for the FTP Target connector are displayed.

3. Enter the appropriate property values:

   FTPS	A yes (Y) or no (N) value. Determines whether the target FTP server requires a secured FTP connection or not.
   HOSTNAME	The host name of the FTP server. For example, for the URL ftp://www.hostname.com, the host name would be www.hostname.com.
   METHOD	The FTP method that is being used. Enter GET.
   PASSWORD	The password that corresponds to the USERNAME value to access the FTP server. This value must be encrypted. To obtain an encrypted version of the password, use the Password Encryption Utility at the bottom of the page.
   TYPE	The type of files that are to be transferred—ASCII or BINARY.
   USERNAME	The user name that is used to access the FTP server.
   Send Uncompressed	A yes (Y) or no (N) value. Determines whether to send files compressed or not.

Note. The system uses values that are defined on the Bank Statement Import page to automatically override two node connector properties, DIRECTORY and FILENAME.

Note. You can configure your Integration Broker node to use an AS2 connector.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker, “Using Listening Connectors and Target Connectors,” Working with AS2 Connectors

Setting Up Bank Statement Processing

This section describes the components that you use for setting up the Bank Statement Import process and discusses how to:

• Define balance codes.

• Define transaction codes.

Components That You Use to Set Up Bank Statement Processing

Use these application pages to set up the Bank Statement Import process.

• Balance Codes

  Define codes that are used for bank statement balances.

  See Defining Balance Codes.

• Transaction Codes

  Define codes that are used for bank statement transaction information.

  See Defining Transaction Codes.

• Code Mappings

  Define the mappings between external system codes with their equivalent internal PeopleSoft codes.

  See Defining Code Mappings for Bank Statements, Payments, and Payment Acknowledgments.

• Layout Catalog

  See Configuring Bank Statement, Payment, and Payment Acknowledgment Layouts.

• Event Code Definition

  See Defining Event Notifications.

• Node Definition (required only if you are using Integration Broker)

  See Defining Integration Broker Settings for Payments.

• (Optional) Encryption Profile

  See Understanding File Encryption.

Note. If you create new layouts or modify existing ones for an organization's bank-statement-processing requirements, you must add them to the Layout Catalog.

Pages Used Exclusively for Setting Up Bank Statement Processing

Defining Balance Codes

Access the Balance Codes page.

Assign balance codes to each balance line and determine how the reconciliation process manages them. Assign a balance code to each balance entry that is received electronically or entered manually.

Defining Transaction Codes

Access the Transaction Codes page.

The system assigns transaction codes to each bank-statement-transaction line during electronic load or manual entry. The transaction code determines how reconciliation processes the specific line item.

See Also

Defining Statement Activities

Setting Up Payment Processing

To define external commands, use the External Command component (PMT_EXT_COMM_CMP_GBL).

This section lists the pages and functionality that are involved in Financial Gateway electronic banking payment processing:

• Payment Grouping Rules

  Definitions of rules that determine what payments can be grouped together in the same file.

  See Defining Payment Grouping Rules.

• Layout Catalog

  See Configuring Bank Statement, Payment, and Payment Acknowledgment Layouts.

• Code Mappings

  See Defining Code Mappings for Bank Statements, Payments, and Payment Acknowledgments.

• Event Code Definition

  See Defining Event Notifications.

• (Optional) Node Definition (required if you are using Integration Broker to transmit payment files.)

  See Defining Integration Broker Settings for Payments.

• (Optional) Encryption Profile

  See Understanding File Encryption.

• (Optional) External Commands

  Captures the setup information that is needed to call third-party toolkits to provide encryption and communication of payment files. External commands can be used when you are transmitting payment files using FTP.

  See Defining External Toolkit Commands.

• Bank Integration Layouts

  This component is the main setup component where file layouts, output type, and integration options are associated with a bank.

  See Defining Bank Integration Layouts for Payments.

• External Account - Payment Method - Financial Gateway Options: Captures how each account's payment method is settled and in what layout.

  Payments can be settled through the Financial Gateway Dispatch Payments or Payables' Pay Cycle Manager.

  See Defining Payment Methods.

How you set up the payment processing functionality depends on the implementation. Because each organization or bank has differing payment layout requirements, delivering all possible layout variations to suit all needs would be exceedingly difficult. If you use the delivered functionality and do not need to make any modifications or changes, you have fewer setup tasks.

If you are creating new layouts or editing existing layouts for an organization's payment processing requirements, you need to first create the payment layout and all its supporting functionality. Specifically, you need to define payment grouping rules and code mappings, and you must also create the file layout objects and formatting logic for new (or modified) payment layouts.

Note. If you create new layouts or modify existing ones for an organization's payment-processing requirements, you must add them to the Layout Catalog.

Pages Used Exclusively for Setting Up Payment Processing

Defining Payment Grouping Rules

Access the Payment Grouping Rules page.

Each payment layout specification defines rules for grouping payments into the file. Grouping rules determine how payments are grouped together into payment files. Certain layouts require a different file for every payment, and other layouts require a separate file for each different business date of a file. For example, the SWIFT MT103 payment layout requires that only one payment exist in a file; therefore, the associated grouping rule is SINGLEPAYMENT.

Other layouts have different rules. For example, CCD+ files can contain payments from multiple accounts and multiple processing dates, so the grouping rule is BANK, and payments for this bank can be included in the same file. For layouts requiring payments to be processed on the same day, you can use the BANKDATE grouping rule. You can change grouping rules to accommodate a layout with a specific bank’s requirement. To define a grouping rule, enter the fields to group for a payment type.

PeopleSoft delivers the following grouping rules:

Defining Bank Integration Layouts for Payments

Access the Bank Integration Layouts page.

Layout ID	Select a layout from the Layout Catalog to enable for this bank. Values that are defined for the layout automatically populate the Layout Properties region.
View Layout Details	Click to access the Layout Catalog page and view details of the payment layout.

File Output Type

Supported Payment Methods

This group box displays payment methods that are supported by this layout.

Layout Properties

A payment layout can have a number of layout properties. Three layout properties are available, however, that all payment layouts contain. This table provides examples of how to set up each of them.

BANKNAME_%FILEID%_ %yyyyMMdd_HHmmss% 

BANKNAME_00000017_ 20031118_104316

BANKNAME_%FILEID%_ %ddMMyyyy_HHmmss%

BANKNAME _00000018_18112003_105448

Creating Payment Layouts

To create a new payment layout:

1. Work with the organization or financial institution and develop the requirements for the payment layout.

   If a usable file layout object is delivered by PeopleSoft, analyze the gap between the delivered file layout object and the layout requirements.

2. Define a new file layout object.

   You can save a delivered file layout object with another file name and then edit it, or you can create a new file layout object.

3. Implement the formatting logic.

   PeopleSoft delivers the formatting logic in application classes that are included in the TR_FORMAT Payment package. Use the delivered application classes, extending the logic of an existing class (or extend from the BaseFormatter application class) so as to take advantage of the delivered logic.

   For example, suppose that you want to create a new CDDFormatter file layout object that includes PeopleSoft-delivered logic and also enters a value in an optional field, Individual ID, in the entry detail record for tracing purposes. To do this, use the following code for the application class NewCCDFormatter:

   import TR_FORMAT:Payment:CCDFormatter;
   class NewCCDFormatter extends CCDFormatter
   		method populateEntryDetail (&rec as Record);
   end-class
   
   /* constructor */
   method NewCCDFormatter
   		%Super = create CCDFormatter ();
   end-method
   
   /* override parent method here */
   method populateEntryDetail
   		/+ &rec as Record +/
   
   		%Super.populateEntryDetail (&rec);
   
   		Local &myIndividualIDVal;
   
   		/* add logic to get your &myIndividualIDVal here */
   
   		&rec.ACH_INDIVIDUAL_ID.Value = &myIndividualIDVal;
   
   end-method;
   	
   

4. You can either create an Application Engine to call the new formatter class or specify in the layout to use the new formatter class. If choosing the Application Engine approach, write a wrapper Application Engine to invoke the new formatter class and pass in your File Layout object name.

   To do this, you can copy an application class invoker Application Engine, changing the payment formatter name (such as CCDFormatter) to the new payment layout name, and changing the file layout object name to the new file layout object name.

5. Define a new Layout Catalog entry.

   In addition to any parameters that you must define for this new Layout Catalog entry, define a transformation program name to the wrapper Application Engine or the new formatter class that you created in step 4.

6. To use the new layout, set up a bank account payment method (on the External Accounts - Payment Method page).

See Also

Defining Payment Methods

Defining External Toolkit Commands

Access the External Command page.

Optional if output type is file. This is the external command to execute after the file is created. External commands are a way to execute a third-party communication or security toolkit. They allow the output Filepath and Filename to be passed to a third party to initiate additional processing.

Setting Up Payment Acknowledgment Processing

This section lists the pages and functionality that are used to process payment acknowledgments in Financial Gateway:

• Code Mappings

  See Defining Code Mappings for Bank Statements, Payments, and Payment Acknowledgments.

• Layout Catalog

  See Configuring Bank Statement, Payment, and Payment Acknowledgment Layouts.

• Event Code Definition

  See Defining Event Notifications.

• Node Definition

  See Defining Integration Broker Settings for Bank Statements and Payment Acknowledgments.

• (Optional) Encryption Profile

  See Understanding File Encryption.

Reviewing Event Log Information

This section discusses how to review event log information.

Page Used to Review Event Log Information

Reviewing Event Log Information

Access the Review Event Log page.

Enter the search parameters and click Search. Results appear in the Review Event Details grid.

Using a Communications Partner for Electronic Banking

To establish the integration between Financial Gateway banking functionality and financial institutions, refer to the installation and implementation materials that the chosen bank's communications provider provides.

PeopleSoft provides the following set of IP messages that enable data to pass between PeopleSoft applications and a communications partner:

• BANK_STATEMENT_LOAD_VERSION_2: Used for inbound or outbound previous and same-day bank statements.

• BANK_ACCT_ANALYSIS_LOAD: Used for inbound and outbound fee analysis.

• PAYMENT_DISPATCH: Used for outbound payment information.

• PAYMENT_ACKNOWLEDGE: Used for inbound bank payment acknowledgments.

Note. You and the bank's third-party communications partner are responsible for complying with the PeopleSoft inbound and outbound IP message formats, and for ensuring data encryption, security, and communication between the organization and its banks. PeopleSoft is not responsible for this aspect of the implementation. In addition, the performance time to retrieve and submit bank statement information is limited by the bank communication partner's software. PeopleSoft is responsible only for the performance time of the generation and receipt of the publish/subscribe Application Messaging.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Integration Testing Utilities and Tools