Receiving Payments Electronically

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

Receive lockbox deposits.
Use electronic banking to process payments.
Use electronic data interchange (EDI) and split stream processing.
Receive cash drawer payments.
(JPN) Receive electronic funds transfer (EFT) payments.
Check electronic payment errors.
Correct errors.

Understanding Electronic Payment Processing

The Payment Loader Application Engine process (AR_PAYLOAD) processes all payments that are received through an electronic payment process. Payment Loader processes the following types of electronic payments:

Lockbox
EDI
Bank statements
EFT files

Payment Loader also processes payments entered using the Cash Drawer Receipts feature.

This diagram illustrates how the process works:

Entering payments electronically using Payment Loader

The Payment Loader process performs the following tasks:

Edits data for internal integrity.
Checks for duplicate deposits or payments.
Assigns defaults and deposit IDs.

Note. The Load Cash Drawer Receipts Application Engine process (CDR_LOADPMT) assigns the deposit ID to payments that you enter using the Cash Drawer Receipt feature.
Assigns document sequence numbers if you enabled document sequencing at the installation level and the general ledger (GL) business unit level.
Creates cash control accounting entries based on settings at the bank account and business unit options.
Matches split stream remittance advices and their cash, depending on the request parameters that you specify for split stream processing.
Assigns the user ID of the individual that created the run control for the Payment Loader process to the Deposit Control record (DEPOSIT_CONTROL) in the User ID (ORPRID) and Assigned User ID (ASSN_OPRID) fields for each electronic deposit.

Note. If another user accesses and modifies the deposit in the Regular Deposit component (PAYMENT_ENTRY), the system automatically changes the assigned user ID to the individual who modified the deposit. When you apply the payment, the system updates the Applied User ID (APPLIED_OPRID) field on the Payment Record (PAYMENT) with the user ID of the person who applied the payment. The values in the User ID and Assigned User ID fields on the Deposit Control record remain the same. You must run a query to see the values in the APPLIED_OPRID field.

The process processes all payments that are received through an electronic data interface. It moves the payment data from the staging tables to these payment application tables:

PS_DEPOSIT_CONTROL
PS_PAYMENT
PS_PAYMENT_ID_ITEM
PS_PAYMENT_ID_CUST
PS_PAY_MISC_DST

You can load EDI transactions or run the Lockbox SQR process (AR25001) many times a day to load multiple transmissions into the staging tables. Then at the end of the day, run the Payment Loader process once to load the data into the application tables and process all the received payments.

Prerequisites

Before you perform electronic payment processing, you must:

Assign a default entry type, entry reason, and system function to adjustment reasons for each setID on the Receivables Definition - Bank/Payment Options page.
If you use cash control accounting, define your cash control method on the Receivables Definition - Accounting Options 2 page.
Define the bank accounts where you will deposit the payments in the External Accounts component (BANK_EXTERNAL).
Assign a business unit to the bank accounts from which you receive deposits on the External Accounts - Account Information page.
Define group types for payments on the Group Type page.
Define deposit types on the Deposit Type page.
Set up qualifiers for payment reference information on the Reference Qualifier page.
Set up adjustment reason codes.

Setting Up Group Types and Group Origins

Defining Additional Processing Options

Defining External Account Information

Receiving Lockbox Deposits

This section provides an overview of lockbox processing and the lockbox process flow and discusses how to:

Run the Lockbox SQR process (AR25001).
Run the Payment Loader process.
Review lockbox deposit control information.

Understanding Lockbox Processing

Lockbox deposits automatically update deposit and payment information from a bank or payment collection system. Each lockbox file can have multiple lockboxes. Each lockbox can have multiple deposits with multiple payments. Each deposit is identified by the bank and bank account it came from. Each payment can be in a different currency.

The Lockbox process accepts deposits with these payment methods: CHK (check), EFT (electronic file transfer), and GE (giro - EFT). If an invalid value is found in the lockbox file, the process assigns a default payment method as follows:

Uses the payment method assigned to the deposit type that shares the same setID as the deposit business unit.
Uses the payment method specified on the Receivables Options - Payment Options page for the deposit business unit.
Uses check as the payment method for the deposit.

We provide you with a record layout for lockbox transmissions that mirrors the online deposit entry pages and is ANSI X12-compatible. We designed the interface guidelines for recording deposit and payment information to provide you with all of the information that you currently receive from your lockbox.

See Also

Receiving Information from a Lockbox

Understanding the Lockbox Deposit Process Flow

Perform these steps to receive electronic payments:

Run the Lockbox process to load data from the flat file into the staging tables.
Run the Payment Loader process to move the data from the staging tables into the payment application tables.

Note. You can combine the Lockbox and Payment Loader processes in a PeopleSoft Enterprise Process Scheduler job and run them together.
View the Application Engine error messages in the Process Monitor.

The Payment Loader process compares the control totals and counts with the calculated totals at all levels (deposit, lockbox, and file). If they do not match, the process issues an error message. Batch level errors have an Out of Balance status.
Review the received control totals on the Lockbox Run Information page.
Check for errors at the deposit level on the All Deposits or Incomplete Deposits pages.
Correct errors on the deposit and payment entry pages and on the Payment Interface Duplicates page.
If you use cash control accounting and there is a duplicate or out of balance deposit, run the Cash Control Application Engine process (AR_CASHCNTL) to create the cash control accounting entries after correcting the errors.

Pages Used to Receive Lockbox Deposits

Page Name	Object Name	Navigation	Usage
Lockbox	LOCKBOX_REQUEST	Accounts Receivable, Payments, Electronic Payments, Retrieve Lockbox Files. Lockbox	Run the Lockbox SQR process that imports lockbox files to the staging tables.
Payment Interface	PAYLOAD_REQUEST	Accounts Receivable, Payments, Electronic Payments, Process Payment Interface, Payment Interface	Run the Payment Loader process for lockbox deposits.
Lockbox Run Information	LB_CONTROL_AMTS	Accounts Receivable, Payments, Electronic Payments, Review Deposit Information, Lockbox Run Information	View the control totals for the lockbox deposit. This page compares the payment count and amount with the lockbox totals.

Running the Lockbox SQR Process

Access the Lockbox page.

Name of Lockbox File

Enter the name of the file that contains deposits from one or more lockboxes. This value can be up to 80 characters long. Do not specify the file path.

Note. If the file is on the client, you must run the process on the client. If the file is on the server, you must run it on the server.

Running the Payment Loader Application Engine Process

Access the Payment Interface page.

Select the Lockbox check box.

Reviewing Lockbox Deposit Control Information

Access the Lockbox Run Information page.

Lockbox ID	Displays the ID that was processed.
Transmission Date/Time	Indicates the time that the file was transmitted.
Processed Date/Time	Indicates the time that the Payment Loader process processed the lockbox.

Control Information

Displays the control information from the lockbox, the calculated results and the difference for the deposit count, payment count, and payment amount. The difference should be zero. If not, errors exist in the lockbox.

Using Electronic Banking to Process Payments

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

Load unreconciled payments for individual statements.
Load unreconciled payments for all statements.

Understanding Electronic Banking

Receivable provides support for electronic banking. The following diagram illustrates how the process works:

Electronic banking process flow

Process Flow for Electronic Banking

To process bank statement payments:

Run the Import Bank Statement Application Engine process (BSP_IMPORT) to import the electronic statements into the staging tables and to load the bank statement data from the staging tables into the Bank Statement tables.
Run the Bank Reconciliation Application Engine process (FSPRECON) on the AutoRecon Manager page.

You must reconcile the bank statement at the payment level and not at the deposit level by assigning the BNK_RCN_PAYMENT reconciliation rule to the bank account.

You can also manually reconcile bank statements.

The process verifies whether the receipts on the bank statement with a TRANSACTION_CODE of C exist as payments in the PS_PAYMENT table. The process marks receipts that are found on the PS_PAYMENT table as reconciled. The process marks those not found as unreconciled and gives the receipts an NTF (not found in system) status.

Note. Documentation about receiving bank statements, the Transaction Loader process, and the Automatic Reconciliation process is in the PeopleSoft Enterprise Bank Setup and Processing 8.9 PeopleBook.
Load any unreconciled payments that have the NTF status into the payment tables and create cash control accounting entries for the payments if you selected the appropriate settings at the bank account and business unit options.

Use one of these options to load the data:
- Run the Bank Statement Processing Application Engine process (AR_BNKSTMT) to load specific bank statement data.
- Run the Payment Loader process to load data for all bank statements.
  
  The Bank Statement Processing process handles only the payments that are processed by the Bank Reconciliation process. It does not evaluate unprocessed payments in the bank statement tables.
  
  If you use the Bank Reconciliation cash control accounting method that records the debit to cash when the payment or trade receipt is reconciled on the bank statement, you must reconcile your bank statements. With the Bank Reconciliation cash control method, the system debits cash only when a deposit is reconciled to payments that were previously recorded in Receivables. The debit to cash is the reconciled deposit amount.
  
  You must run the Bank Statement Processing process twice to generate the cash control entries if you use the Bank Reconciliation cash control accounting method. In the first run, you load the unreconciled deposits into Receivables as new payments. The second time that you run the Bank Statement Processing process for a bank you generate the cash control entries. Another option is to use the Cash Control process after loading the bank statement into Receivables to generate the accounting entries.
  
  Note. You can combine the Reconciliation process and the Bank Statement Processing process in one Process Scheduler job. However, the combined Process Scheduler job can be run only from the Reconciliation page.
If you use cash control accounting and you encounter errors, fix the problem and then run the Cash Control process to create the cash control accounting entries.
View the Application Engine error messages in the Process Monitor for the Payment Loader process.

Receiving and Updating Bank Statements

Reconciling Statements

Prerequisites

Before you use electronic banking to process payments, you must set up the statement codes to determine the payment method for each bank transaction line. If a statement code is not matched to a payment method, the system assigns CHK (check) as the payment method.

Pages Used to Process Payments Using Electronic Banking

Page Name	Object Name	Navigation	Usage
Bank Statement Interface	BNKSTMT_REQUEST	Accounts Receivable, Payments, Electronic Payments, Load Bank Statements, Bank Statement Interface	Load unreconciled payments for specific statements into Receivables by running the Bank Statement Processing process.
Payment Interface	PAYLOAD_REQUEST	Accounts Receivable, Payments, Electronic Payments, Process Payment Interface, Payment Interface	Load unreconciled payments for all statements into Receivables by running the Payment Loader process.

Loading Unreconciled Payments for Individual Statements

Access the Bank Statement Interface page.

Bank ID and Bank Account Number	Enter the bank ID and account number into which the deposits were made.
Statement ID	Specify the bank's statement identification number to identify which statement to process.

Loading Unreconciled Payments for All Statements

Access the Payment Interface page.

Select the Bank Statement check box.

Using EDI and Split Stream Processing

This section provides overviews of EDI processing, split stream processing, and the EDI payment process flow, lists prerequisites, and discusses how to:

Load business documents into staging tables.
Confirm that data loaded successfully.
Run the Payment Loader process.
Delete unmatched customer or item remittances.

Understanding EDI Processing

Receivables provides the ability to receive a payment (cash and remittance advice combined) or just the remittance (remittance information without cash) in an EDI transmission.

When you receive the remittance advice and the cash information at different times and through different channels, you can use a variety of methods to match them. This helps you identify and apply the payments.

Receivables supports both European and U.S. EDI formats. The European EDI standard is EDIFACT, and the supported format is CREEXT. The U.S. standard is ANSI-X12; its supported format is 820. In both formats:

One transmission can contain a payment (cash and remittance information combined) or just cash.
One transmission can contain only a remittance (the corresponding cash information to be transmitted separately).

This scenario introduces the need for split stream processing.

Understanding Split Stream Processing

Split stream processing matches and unites the two parts of a payment, the cash information and the remittance advice, when they are received at different times and possibly from different data sources. EDI, lockbox, and bank statement processing support the transmission of cash by itself. Only EDI processing supports the transmission of a remittance advice by itself or cash and remittance.

Note. The Payment Loader process matches remittance information in the staging tables with cash information that is in either the staging tables or the application tables. You can use the Remittance Delete pages to find and delete unmatched remittances in the staging tables.

Split Stream Examples

Typically both the cash information and the remittance advice are received through EDI, as shown in the following example:

Example of a complete EDI payment

In this example, the customer sends you two EDI transmissions. The remittance advice is sent directly to you. The cash information is sent to the customer's bank, then to your bank, and then to you. As a result, you receive two separate EDI transmissions, one with cash and one with remittance information. You use split stream processing to match them and form the complete payment (linked cash and remittance information).

The common denominator for all methods of receiving split stream data is that the remittance information is received by EDI; only the source of the cash information varies. The method that customers use to send the cash to their bank or to your bank is irrelevant to split stream processing. Your only concern is how your bank transmits the cash information to you: as an EDI transmission, in a lockbox file, or, as in the following example, as a receipt on a bank statement:

The bank sends a bank statement that details cash information

The following example shows transmission of cash information by way of a lockbox:

The bank sends a lockbox file that provides the cash information

U.S. and European business practices differ. In the United States, you usually receive payment in a lockbox file, but you are unlikely to receive payments from bank statements. In Europe, you probably do not use a lockbox, but you probably receive payments from bank statements.

Understanding the EDI Payment Process Flow

To receive payments and remittance information in an EDI file:

By using a third-party translator, translate the file into a PeopleSoft business document format.

See Receiving Payments in an EDI File.
Publish the data in the business document in the Application Messaging queue.

The subscriber program loads the data into data tables.
Confirm that the data loaded.
Run the Payment Loader process to move the data from the staging tables into the payment application tables.
View PeopleSoft Enterprise Application Engine messages.
Check for errors at the deposit level on the All Deposits or Incomplete Deposits page.
Correct errors in the deposit and payment entry pages and the Payment Interface Duplicates component (ERROR_CORRECTION).
If you use cash control accounting and you have a duplicate out-of-balance deposit, run the Cash Control process to create the cash control accounting entries.

See Creating Cash Control Accounting Entries.

Understanding Business Unit Determination

If you receive a business unit for a deposit in the EDI file, the system assigns that business unit to the deposit. Otherwise, it uses the business unit that you assigned to the bank account on the External Accounts - Account Information page. If both business units are missing, the system uses the business unit that is assigned to the operator that runs the Payment Loader process.

Prerequisites

Use the PeopleSoft Enterprise Integration Broker to set up the EDI interface.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Integration Broker

Enterprise PeopleTools PeopleBook: PeopleSoft Integration Tools and Utilities

Pages Used for EDI and Split Stream Processing

Page Name	Object Name	Navigation	Usage
File Inbound	EO_FILE_INBOUND	Enterprise Components, Integration Definitions, Inbound File Rule, File Inbound	Define the path, name of the flat file, and file layout for the inbound bank file.
Inbound File	EO_FILETOMSG	Enterprise Components, Integration Definitions, Initiate Processes, Inbound File Publish, Inbound File	Load banking data from a flat file into the staging tables using the EOP_PUBLISHF Application Engine process. You can also use an external system to publish data directly in the Application Messaging queue.
EC Business Doc Links	EC_BUSDOC_02	PeopleTools, EDI Manager, View EDI Audit Trail, Business Document Summary, EC Business Doc Links	Verify that data was loaded into the EC tables at the subscribing bank.
Summary	EC_BUSDOC_01	PeopleTools, EDI Manager, View EDI Audit Trail, Business Document Summary, Summary	Confirm that the banking data loaded successfully.
Payment Interface	PAYLOAD_REQUEST	Accounts Receivable, Payments, Electronic Payments, Process Payment Interface, Payment Interface	Define the run parameters for the Payment Loader process and run the process.
Delete Remittance - Customer	MATCH_ERROR_CU	Accounts Receivable, Payments, Electronic Payments, Delete Remittance, Customer	Delete unmatched customer remittances in the staging tables.
Delete Remittance - Item	MATCH_ERROR	Accounts Receivable, Payments, Electronic Payments, Delete Remittance, Item	Delete unmatched item remittances in the staging tables.

Loading Business Documents into Staging Tables

Access the File Inbound page.

To set up and use the EDI process:

Use the File Inbound page to set up the file identifier to point to a file.

File Identifier	Displays an identifier pointing to the file.
Inbound File	Enter the path and file name that you want for the inbound flat file when you import into the Receivables system.
Index Flag	Select only if the inbound file is an index file.
File Layout ID	Enter an ID that identifies the file layout.
LUW Size, Program Name, and Section	Leave blank.
Create Message Header and Create Message Trailer	Clear these check boxes.
Definition Name	Change the value to PAYMENT_LOAD.
Message Name	Change the value to PAYMENT_LOAD.

Enter run parameters on the Inbound File page.

File Identifier

Enter the file identifier that you defined on the File Inbound page.

Index Flag

Select only if the inbound file is an index file.
Click Run to run the EOP_PUBLISHF process, which loads data from the file and publishes the data as application messages.

Select the following process name on the Process Scheduler Request page: EOP_PUBLISHF.
Use the Process Monitor to verify that the process completed successfully.
Verify that the subscriber processed the message and loaded the data into EC tables on the EC Business Doc Links page.

The value for the EC Completion Status field should be Done.

Confirming That Data Loaded Successfully

Access the Summary page.

Status

Verify that the status is Loaded.

See Also

Enterprise PeopleTools PeopleBook: Supported Integration Technologies

Running the Payment Loader Application Engine Process

Access the Payment Interface page.

EDI 820

Select if loading EDI data from the United States.

EDI CREEXT

Select if loading EDI data from a European country.

Match Split Stream Data

Select to include split stream matching as part of the payment data load process.

Match Payments Already Loaded

Select to match remittance information with cash information that you already loaded into the payment application tables.

EDI Trace Number

Select if you receive both the cash and remittance by EDI. The transmissions have matching trace numbers. The trace numbers are unique, so the two pieces can be matched by using these criteria.

Payment Amount and Payment ID

Select if you require customers to include the payment ID (this could be the check number) and payment amount in the remittance advice. The cash and remittance are matched if they have the same payment amount and payment ID.

Date, Amount and Payment ID

Select if the customer includes the payment date on the remittance. European companies use Value Date as an additional matching field. (Estimated and actual value dates determine the float.) In the United States, use the accounting date of the payment when this criteria is applied. The cash and remittance are matched if they have the same date, amount, and payment ID.

Customer ID and Payment ID

Select if the cash has a magnetic ink character recognition ID (MICR ID) with it and the remittance has a customer ID. The cash and remittance are matched if they have the same payment ID and the cash MICR ID points to the remit from customer ID that is on the remittance.

Deleting Unmatched Customer or Item Remittances

Access the Remittance Delete - Customer page or the Remittance Delete - Item page.

Remittance Status

Select the remittance status to search for and display in the list. Values are:

Unmatched: Displays unmatched remittances in the file. This value is available only if unmatched remittances exist in the file.

Not Processed: Displays unprocessed remittances. This value is available only if remittances in the file were not processed.

Delete

To remove the unmatched remittances from the staging tables, select the Delete check box next to each remittance that you want to delete and click the Delete button.

If the cash information precedes the remittance information and you have already run the Payment Loader process for the cash information, the cash information is already loaded into the payment application table. Thus, the applicable remittance information does not match the cash information. Instead, the applicable remittance information remains in the staging tables as unmatched unless you run the option that matches the payment that you already loaded into the payment application table. You can manually correct this by deleting the unmatched remittance information on the Regular Deposits - Totals page. Then enter the remittance information with its associated payment in the reference information fields on the Regular Deposits - Payments page.

See Also

Entering Regular Deposit Totals

Entering Regular Deposit Payment Information

Receiving Cash Drawer Payments

This section provides an overview of cash drawer receipt processing and discusses how to update payment application tables.

Understanding Cash Drawer Receipt Processing

PeopleSoft enables you to enter an order and the payment for the order at the same time for counter sales using the Cash Drawer Receipts feature. To load the cash drawer payments into Receivables, run the Load Cash Drawer Receipts process to update the payment staging tables, and run the Payment Loader process to load the data in the payment staging tables into the payment application tables.

Customers can pay for an order with multiple payment methods, for example cash, check, and credit card—each as a separate payment. Each payment that the Load Cash Drawer Receipts process interfaces to Receivables should have the order number and possibly other reference information to enable you to apply the payment to the item associated with the order.

The cash drawer accepts these payment methods: gift vouchers, cash, checks, and credit, debit, or procurement card authorizations. However, the Load Cash Drawer Receipts process does not interface gift voucher information to Receivables. When the Load Cash Drawer Receipts process sends information for payments made by credit, debit, or procurement card authorizations, the payment method is EFT. Also, the payment method for the items paid for with these authorizations is EFT. The reason that these items have an EFT payment method is to differentiate these items from items with a credit card payment where you run the Receivables Credit Card process (AR_CRCARD) to create the payments and a payment worksheet in Receivables. The payments can be either full payments or deposits for an order.

The Load Cash Drawer Receipts process populates the Payment ID field with different values depending on the payment method as shown in this table:

Payment Method	Payment ID
Cash	Cash drawer receipt number
EFT (debit, credit, or procurement card)	Authorization code
Check	Check number

The cash drawer setup defines which bank and bank account to use for payments that you enter in the cash drawer. The setup also defines which receivables business unit is associated with each cash drawer. The system assigns the next available deposit ID to the cash drawer transaction for the deposit business unit. This table shows how the Load Cash Drawer Receipts process maps the fields on the cash drawer transaction to the fields in the payment staging tables:

Cash Drawer Receipt Fields	Payment Staging Table Fields
Deposit Business Unit	LOCKBOX_ID
Deposit ID	LOCKBOX_BATCH_ID
Payment Sequence Number	PAYMENT_SEQ_NUM

The system creates a separate deposit for all payments with the same payment method. For example, it creates three deposits if applicable: one for cash payments, one for EFT payments, and one for checks.

Note. The Payment Loader process only processes payments with a cash payment method if they originate in the cash drawer receipts interface.

After you load the cash drawer receipts into the payment application tables, use Payment Predictor to apply the payments to the items associated with the orders. We recommend that you interface the items from Billing into Receivables and post them before running the Payment Predictor process.

Setting Up and Maintaining a Cash Drawer

Using the Cash Drawer

Page Used to Receive Cash Drawer Payments

Page Name	Object Name	Navigation	Usage
Payment Interface	PAYLOAD_REQUEST	Accounts Receivable, Payments, Electronic Payments, Process Payment Interface, Payment Interface	Define run parameters for the Payment Loader process to load cash drawer payments into the payment application tables.

Updating Payment Application Tables

Access the Payment Interface page.

Select the Cash Drawer Receipts check box.

(JPN) Receiving EFT Payments

This section provides an overview of the EFT payment process flow and discusses how to:

Load EFT payment files.
Run the Payment Loader process.

See Also

EFT Draft Process Flow

Selecting EFT Layouts

Understanding the EFT Payment Process Flow

To process EFT payments:

Run the AR_DRAFT_EFT Application Engine process to load the EFT files into the Payment staging table (AR_PAYMENT_EC).

The process extracts regular payments from the file if the creation date equals the accounting date (due date). If the customer name can be resolved to a customer ID, the system also creates a customer staging record (AR_IDCUST_EC). The process uses the Kijitsu file layout.
Run the Payment Loader process to move the data from the staging tables into the payment application tables.
View Application Engine messages.
Check for errors at the deposit level on the All Deposits or Incomplete Deposits page.
Correct errors in the deposit and payment entry pages and the Payment Interface Duplicates component.
If you use cash control accounting and you have a duplicate out-of-balance deposit, run the Cash Control process to create the cash control accounting entries.

See Creating Cash Control Accounting Entries.

Prerequisites

You must associate the customer IDs with the customer names in the EFT files on the Customer EFT Name page.

Pages Used to Receive EFT Payments

Page Name	Object Name	Navigation	Usage
Load EFT Payments	DR_EFT_REQUEST	Accounts Receivable, Drafts, Create Drafts, Receive Draft Payments, Load EFT Payments	Use to load regular payments from an EFT file.
Payment Interface	PAYLOAD_REQUEST	Accounts Receivable, Payments, Electronic Payments, Process Payment Interface, Payment Interface	Define run parameters for the Payment Loader process to load EFT payments into the payment application tables.

Loading EFT Payment Files

Access the Load EFT Payments page.

Process

Select Payments or Both to process the regular payments in the EFT file.

Note. If you select Both the process loads draft and regular payments.

Review

This field is used only for draft processing.

File Name

Enter a name for the EFT file. The name of the EFT file must be unique. The file must be loaded into the directory on the application server defined by %PS_SERVDIR%\FILES, where %PS_SERVDIR% is the directory where the application server domain is defined. If you process the EFT file using Process Scheduler, then you need to load the file into %PS_HOME%\appserv\prcs\ <database name>\files.

After the system processes the file, it updates a table (DR_FILE_NAME) on the database with the name of the flat file that has been loaded. Using a unique file name prevents drafts or payments from being entered into the system twice. Only the file name is stored, not the path.

Running the Payment Loader Application Engine Process

Access the Payment Interface page.

Select the EDI 820 check box.

Checking Electronic Payment Errors

This section provides an overview of electronic payment errors and list pages used to check electronic payment errors.

Understanding Electronic Payment Errors

The Payment Loader process checks for formatting errors and duplicates. These error are corrected as follows:

Nonnumeric characters in numeric fields are replaced with zeros.
Invalid dates in date fields are replaced with the current date.
Duplicate deposits in lockbox and EDI deposits are placed on hold, with an indicator on the Payment Interface Duplicate - Totals page.

The system uses different criteria to identify duplicates, depending on the type of deposit:
- If two lockbox deposits with the same deposit unit and lockbox ID are received, the system uses four criteria to determine whether they are duplicates: bank, bank account, deposit date, and control totals.
- For EDI deposits, if two payments with the same payment ID are received, the system uses the following criteria to determine whether they are duplicates: bank, bank account, deposit date, amount, and deposit unit.

The system groups duplicate payments into deposits and marks them as duplicates.

Online error correction is available for any payments that do not transfer smoothly. If a deposit is out of balance and contains errors, you can access it on the All Deposits or Incomplete Deposits pages.

Pages Used to Check Electronic Payment Errors

Page Name	Object Name	Navigation	Usage
All Deposits	DEPOSIT_ALL	Accounts Receivable, Payments, Review Payments, All Deposits, All Deposits	Check a specific deposit ID number or scan any or all of your deposits at one time. Displays control totals and status information for a single deposit at a time.
Incomplete Deposits	DEPOSIT_INCOMPLETE	Accounts Receivable, Payments, Review Payments, Incomplete Deposits, Incomplete Deposits	Track down deposits that are not completely processed. View the payment amount in the deposit that is still in process, summarize out-of-balance deposits or view the list of incomplete deposits by operator. The deposits contain a mix of posted and unposted payments.

Correcting Errors

This section provides an overview of error correction and discusses how to correct duplicate deposits.

Understanding Error Correction

Error correction involves comparing and matching your recorded business transactions with the bank transactions. If the totals or control amounts are out of balance on the Regular Deposit - Totals page, then the deposit is unbalanced. You must correct the errors.

Use these indications to determine whether the deposit is balanced:

If the difference on the Regular Deposit - Totals page is zero, then the deposit is balanced.
If the difference is not zero, then there are errors.
If the control total amount and entered total amount are the same on the Regular Deposit - Totals page, then the deposit is balanced.

You can delete a deposit that has unmatched remittance information or you can balance unmatched deposits using the Regular Deposit Balancing component (BALANCING).

Note. The Regular Balance Balancing component is available only if the deposit is out of balance.

See Also

Correcting Balancing Errors

Pages Used to Correct Errors

Page Name	Object Name	Navigation	Usage
Totals	PAYMENT_DATA1	Accounts Receivable, Payments, Online Payments, Regular Deposit, Totals Accounts Receivable, Payments, Online Payments, Regular Deposit Balancing, Totals Accounts Receivable, Payments, Electronic Payments, Correct Duplicate Payments, Totals	Review deposit totals and delete duplicate deposits created by the payment interface.
Payments	PAYMENT_DATA2	Accounts Receivable, Payments, Online Payments, Regular Deposit, Payments Accounts Receivable, Payments, Online Payments, Regular Deposit Balancing, Payments Accounts Receivable, Payments, Electronic Payments, Correct Duplicate Payments, Payments	Provide detailed information for each payment in a regular deposit.
Action	PAYMENT_DATA3	Accounts Receivable, Payments, Online Payments, Regular Deposit Balancing, Action Accounts Receivable, Payments, Electronic Payments, Correct Duplicate Payments, Action	Select an action to save the deposit or delete the deposit.

Correcting Duplicate Deposits

Access the Correct Duplicate Payments - Totals page.

Hold Duplicate

If this is not a duplicate deposit, clear the Hold Duplicate check box and make the deposit available for payment processing. If this is a duplicate deposit, click the Delete Deposit button to delete the deposit.

This field is visible only if the Payment Loader process marked a lockbox deposit as a duplicate or if an EDI deposit contains duplicate payments.

Note. If no lockbox or EDI deposit errors exits, the Correct Duplicate Payments component is unavailable.

File Identifier	Enter the file identifier that you defined on the File Inbound page.
Index Flag	Select only if the inbound file is an index file.

EDI 820	Select if loading EDI data from the United States.
EDI CREEXT	Select if loading EDI data from a European country.
Match Split Stream Data	Select to include split stream matching as part of the payment data load process.
Match Payments Already Loaded	Select to match remittance information with cash information that you already loaded into the payment application tables.
EDI Trace Number	Select if you receive both the cash and remittance by EDI. The transmissions have matching trace numbers. The trace numbers are unique, so the two pieces can be matched by using these criteria.
Payment Amount and Payment ID	Select if you require customers to include the payment ID (this could be the check number) and payment amount in the remittance advice. The cash and remittance are matched if they have the same payment amount and payment ID.
Date, Amount and Payment ID	Select if the customer includes the payment date on the remittance. European companies use Value Date as an additional matching field. (Estimated and actual value dates determine the float.) In the United States, use the accounting date of the payment when this criteria is applied. The cash and remittance are matched if they have the same date, amount, and payment ID.
Customer ID and Payment ID	Select if the cash has a magnetic ink character recognition ID (MICR ID) with it and the remittance has a customer ID. The cash and remittance are matched if they have the same payment ID and the cash MICR ID points to the remit from customer ID that is on the remittance.