Setting Up Payment Processing

Use the Payment Grouping Rules page (PMT_CHUNK_DEFN) to define fields to include for a specified payment grouping rule.

Image: Payment Grouping Rules page

This example illustrates the fields and controls on 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 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:

Use the Bank Integration Layouts page (BANK_INTEGRATION) to define layouts and transformation programs for a specific bank.

Image: Bank Integration Layouts page

This example illustrates the fields and controls on the Bank Integration Layouts page. You can find definitions for the fields and controls later on this page.

BANKNAME_%FILEID%_ %yyyyMMdd_HHmmss% 

BANKNAME_00000017_ 20031118_104316

BANKNAME_%FILEID%_ %ddMMyyyy_HHmmss%

BANKNAME _00000018_18112003_105448

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

Use the External Command page (PMT_EXT_COMM_PG) to define command line information to carry out an external toolkit.

Optional if output type is File. This is the external command to carry out after the file is output. This enables you to integrate with third-party toolkits (such as security and communications toolkits) and define command parameters that call executable files, batch files, and command-line functions.

Image: External Command page

This example illustrates the fields and controls on the External Command page. You can find definitions for the fields and controls later on this 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.