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 payment processing.

• Set up payment acknowledgment processing.

• Review event log information.

• Use a communications partner for electronic banking.

• Set up remittance advice notifications.

Understanding Electronic Banking

Financial Gateway provides the layouts and functionality needed to process electronic payments and load electronic bank statements 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:

• A File Transfer Protocol (FTP) file server.

• PeopleSoft Integration Broker.

• Hypertext Transfer Protocol (HTTP) using a Uniform Resource Locator (URL).

See Defining Payment Methods.

Transformation Architecture

Transformation programs (or Transforms) are application classes, PeopleSoft Application Engine (AE) programs, and XML Publisher templates 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 PeopleTools PeopleBook: Integration Broker, "Applying Filtering, Transformation, and Translation," Developing Transform Programs

Bank Statement Import Infrastructure

This diagram illustrates the Bank Statement Import process in which a bank's bank statement data file is imported and transformed appropriately by a corresponding transformation program, which contains all the formatting data to stage the files for the Bank Statement Load Process. This load process picks up and transfers the data to the PeopleSoft application tables and makes it available for viewing and editing on the various bank statement pages.

Bank Statement Import process flow from bank to PeopleSoft application.

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 or HTTP server by using PeopleSoft Integration Broker. If you decide to import the bank statement data by using FTP or HTTP, 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, which 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.

Dispatch Payment file generation and transmission process flow.

The Payment Dispatch process 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 or Oracle Payments layout that the bank can receive in its raw form and use to settle payments. Payment layouts have an associated Application Engine program, application class, or XML Publisher template 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—XML Publisher templates, 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 XML Publisher template, transformation Application Engine, or application class 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.

Prenotifications

A payment prenotification (prenote) is a zero-dollar, payment file sent to a debtor's bank to test if payments can be made to a creditor through that bank account. Financial Gateway processes prenotes similar to other payment files. Although prenotes can be sent using various payment methods, they are most often used as a prelude to ACH payment processing.

ACH prenotes:

• Are zero-dollar, payment files.

• Can be sent alone or included among payments from the same debtor to different creditors.

• Have the transaction entry code of "28," signifying a prenotification of payment.

EFT layouts are also used for transmitting direct debit prenotes in Financial Gateway. You must select the Supports Prenotes check box in the Bank Integration Layout Component to enable Financial Gateway to transmit prenotes. (Banking, Administer Bank Integration, Bank Integration Layout)

See Direct Debits.

Bank Payment Acknowledgments Infrastructure

The infrastructure of the payment acknowledgments functionality is similar, though less complex, to the bank statement import infrastructure. This diagram illustrates the transmission of four types of payment acknowledgement data from a bank that received the payments from the PeopleSoft Dispatch Payments program to the PeopleSoft application that sent that payments.

Payment acknowledgment import process flow from receiving bank to PeopleSoft applications.

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. Four 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 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.

   • A third type of acknowledgment notifies the sender of payment errors that resulted in a failed processing attempt.

   • The fourth type of acknowledgment notifies the sender of prenotification errors. A prenotification is a file sent to the debtor's bank to test if payments may be made to a creditor through the debtor's bank account.

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.

3. 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.

   In the case of prenotes, Tracking the status of prenotes between a debtor's bank account and a particular creditor is the responsibility of the source system. Financial Gateway does not track prenote status.

4. 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 (optional)

  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.

• 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 additional miscellaneous layouts in the layout catalog that are used for importing various kinds of data.

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

Delivered Payment Layouts

You can view these layouts by accessing the Layout Catalog page. (Banking, Administer Bank Integration, Layout Catalog, Layout Catalog page)

PeopleSoft delivers these bank payment layouts:

Delivered system-defined payment layout properties:

Delivered Bank Statement Layouts

You can view these layouts by accessing the Layout Catalog page. (Banking, Administer Bank Integration, Layout Catalog, Layout Catalog page)

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 or a later version 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

You can view these layouts by accessing the Layout Catalog page. (Banking, Administer Bank Integration, Layout Catalog, Layout Catalog page)

PeopleSoft delivers these Payment Acknowledgment layouts:

Delivered Miscellaneous Layouts

You can view these layouts by accessing the Layout Catalog page. (Banking, Administer Bank Integration, Layout Catalog, Layout Catalog page)

PeopleSoft delivers these additional layouts:

See Setting Up and Using the Financial Sanctions Service.

See Maintaining Pool Positions.

See Maintaining Equities.

See Also

Importing Security Definitions and Market Values

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 PeopleTools 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 PeopleTools 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

PeopleTools 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 (Banking, Administer Bank Integration, Layout Catalog).

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 (Banking, Administer Bank Integration, Code Mappings) 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 (Set Up Financials/Supply Chain, Product Related, Treasury, Enter Event Code Definition).

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 PeopleTools PeopleBook: Workflow Technology, "Adding Events and Routings"

Setting Up PeopleSoft Integration Broker for Bank Statements, Payments, and Payment Acknowledgements

PeopleSoft Integration Broker is delivered with many integration points to send and receive data with a third-party system. These integration points are implemented using service operations. PeopleSoft delivers the service operations in PeopleSoft Integration Broker with a default status of Inactive. You must activate each service operation before attempting to send or receive data from a third-party source.

The service operations for PeopleSoft Financial Gateway include:

Setting Up Service Operations

To activate a service operation, complete the following steps in PeopleSoft Integration Broker:

1. Activate the service operation.

   On the General tab of the Service Operations component, select the Active check box for the applicable service operation version. If the desired version is not the default version for the service operation, the default version must also be activated.

2. For asynchronous service operations only, verify the queue is running.

   On the General tab of the Service Operations component, select the View Queue link at the bottom of the page. On the Queue Definitions page, verify the Queue Status field has a value of Run.

3. Activate the service operation handlers.

   Note. This step does not apply to all service operations.

   On the Handlers tab of the Service Operations component, select the value of Active in the Status field for all needed handlers.

   • For inbound asynchronous service operations, activate the OnNotify handler.

   • For inbound synchronous service operations, activate the OnRequest handler.

   • If you are using chunking on an outbound service operation, activate the OnRoute handler.

4. Activate the service operation routings.

   On the Routings tab of the Service Operations component, activate a routing definition for each node that will send or receive data. To activate a routing, select the check box next to the routing definition and click the Activate Selected Routings button.

   • Activate an inbound routing to receive data into PeopleSoft Financial Gateway.

   • Activate an outbound routing for sending data to a third-party system or another PeopleSoft product.

   • Activate a local routing for sending data using an effective-dated outbound service operation.

   • Activate a local routing to receive inbound flat files.

   • You must activate at least one routing if the data is being sent in an XML format.

   • You can skip this step if a batch publish rule is set up to post to a flat file only.

5. Verify the routing definition parameters.

   On the Routings tab of the Service Operations component, select the link attached to the routing definition name. This link accesses the Routing Definitions component. Select the Parameters tab and complete the following steps:

   • Confirm the external alias name in the External Alias field for the routing is correct. When sending or receiving data, the Integration Broker determines which routing to use by referring to the external alias name, not the routing name.

   • Add or verify the transform programs on this routing definition. A routing definition defines the sending and receiving nodes for a transaction and specifies any inbound and outbound transformations to invoke. A transform program is a type of PeopleSoft Application Engine program that can convert data from one format to another; for example, from XML to a flat file. Use a transform program when one node sends a request or response message with a data structure different from the structure required by the other node. Many pre-defined routings are delivered with transform programs. You must decide, based on your unique situation, to change, remove, and add transform programs. For example, some delivered transform programs convert data to the EDI format, if you are not using EDI then you will want to use a different routing definition or remove that transform program from the routing definition.

6. Verify the node from the routing is active.

   Go to the Node Definitions page and verify the Active Node check box has been selected for any sender or receiver nodes used in the routings that you activated on your Service Operations-Routings page. Financial Gateway communicates with the third-party bank using an Integration Broker node with a specified connector. 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.

7. For an outbound service operation, verify the node or routing is connected to the correct network.

8. For inbound service operations using a flat file, define the inbound file rule and run control parameters:

   • For X.12 formatted EDI files, use the Inbound File Loader Rules page and the Inbound File Processing run control under the Integration Broker menu.

   • For PeopleSoft formatted files, use the File Inbound page and the Inbound File run control under the Enterprise Components menu.

Note. For complete information on the setup and use of service operations, see the PeopleTools PeopleBook: Integration Broker for your PeopleTools release.

See Also

PeopleTools PeopleBook: Integration Broker

PeopleTools PeopleBook: Integration Broker Administration

Pages Used to Set Up PeopleSoft Integration Broker

Defining Integration Broker Settings for Payments

Access the Node Definitions page (PeopleTools, Integration Broker, Nodes, 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

PeopleTools PeopleBook: Integration Broker

PeopleTools PeopleBook: Integration Broker Administration, "Using Listening Connectors and Target Connectors," Working with AS2 Connectors

Defining Integration Broker Settings for Bank Statements and Payment Acknowledgments

Access the Connectors page (PeopleTools, Integration Broker, Nodes, Connectors 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 a 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 either PUT or GET. The system will always use GET when importing a bank statement regardless of which value is entered in this field.
   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

PeopleTools PeopleBook: Integration Broker

PeopleTools PeopleBook: Integration Broker Administration, "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 Used 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 (optional)

  See Defining Event Notifications.

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

  See Setting Up PeopleSoft Integration Broker for Bank Statements, Payments, and Payment Acknowledgements.

• Encryption Profile (optional)

  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 (Banking, Administer Bank Statements, Bank Statement Codes).

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 (Banking, Administer Bank Statements, Bank Statement Codes, Transaction Codes tab).

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 (optional)

  See Defining Event Notifications.

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

  See Setting Up PeopleSoft Integration Broker for Bank Statements, Payments, and Payment Acknowledgements.

• Encryption Profile (optional)

  See Understanding File Encryption.

• External Commands (optional)

  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 (Banking, Administer Bank Integration, Payment Grouping Rules).

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 in 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 file grouping rule. You can change file grouping rules to accommodate a layout with a specific bank's requirement. To define a file grouping rule, enter the fields to group for a payment type.

There are essentially three layers of filtering that determines how payments are grouped together:

1. Initially the system groups all payments by bank code, setID, payment layout, and payment method.

   This level of filtering is hard coded in the system and cannot be changed or overwritten.

2. Next, the payment file grouping rules, entered in the top grid, further define how the payments are grouped together, thus determining how many payment files are ultimately created during the payment load process.

3. Finally, the payment batch grouping rules define how payments within a file are grouped together.

PeopleSoft delivers the following grouping rules:

Payment Batch Grouping Rules

This set of fields adds an additional level of filtering that further defines how payment lines and payments are grouped together in a file. Because some payment layouts have additional requirements, this feature allows users to further define the logic for grouping payments. An example is the payment layout using ISO 20022 XML messages (credit transfer initiation and STP credit transfer). After the payments have been grouped together in a file based on the file grouping rules, they can be further grouped by fields such as business unit, source system, currency code, payment date, and payment ID. The maximum number of additional grouping fields is ten.

Defining Bank Integration Layouts for Payments

Access the Bank Integration Layouts page (Banking, Administer Bank Integration, Bank Integration Layouts )

Layout	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

Layout Options

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 Banking, Administer Bank Integration, External Accounts, Payment Method page).

See Also

Defining Payment Methods

Defining External Toolkit Commands

Access the External Command page (Banking, Administer Bank Integration, External Command).

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 (optional)

  See Defining Event Notifications.

• Node Definition (optional)

  See Setting Up PeopleSoft Integration Broker for Bank Statements, Payments, and Payment Acknowledgements.

• Encryption Profile (optional)

  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 (Setup Financials/Supply Chain, Product Related, Treasury, Review Event Log).

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

Search Criteria

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

PeopleTools PeopleBook: Integration Broker

PeopleTools PeopleBook: Integration Broker Testing Utilities and Tools

Using Remittance Advice in Financial Gateway

Financial Gateway enables users to send remittance advice for direct debit and EFT requests to an assigned customer contact. Both Cash Management and Deal Management leverage Financial Gateway to settle Treasury payments and can utilize remittance advice functionality.

Remittance Advice functionality in Financial Gateway is based off of the Payment Detail Entry table (PMT_DETAIL_TBL) and additional remittance advice attributes entered on the Remittance Advice Attributes page.

The remittance notification process generates reports using XML Publisher's bursting feature to send an email.

If a vendor or customer requires a change to the notification template, the user must add the new template in the Report Definition ID field on the Source Registration page and also add it to the Bursting page in XML Publisher.

See Registering a Source Application with Financial Gateway.

See PeopleTools PeopleBook: XML Publisher for PeopleSoft Enterprise, "Defining Report Definitions," Setting Bursting Options

Pages Used to Send Remittance Advice

Creating the Remittance Advice Report Definition

Access the Remittance Advice Attributes page (click the Remittance Advice Attributes link on the Beneficiary Bank page).

Enter the remittance destination email address, an optional second email address, the remittance report name, template ID, and language preference for the XML report.

See Defining Settlement Instructions.

See Also

Specifying Template Destination Information

Specifying Destination Information

Sending Advance Payment Notifications

Access the Advance Payment Notification page (Financial Gateway, Process Payments, Advance Payment Notification, Advance Payment Notification).

Advance payment notifications are sent for future collections to satisfy the SEPA requirement to send prior notification of intended collection instructions to the bank. You can choose to send the notification on a specific date or a specified number of days in advance of payment. Processing instructions are sent to the ADV_NOTICE application engine program.

Resending Advice Notifications

Access the Resend Notification page (Financial Gateway, Process Payments, Resend Advice Notification, Resend Notification).

Enter the parameters and click Run.