Understanding Item and Payment Conversion

Convert only open items or convert both open and closed items. Make this decision based on the requirements of your system, the quality of data in your existing system, the amount of historical data that you want in PeopleSoft Receivables after conversion (before ongoing processing begins), and the level of effort that you can devote to the conversion process.

The advantages of converting only open items include:

• Less complex interface programming requirements.

• Smaller conversion effort, in terms of the amount of data and related balancing activity.

• Simplified table setup for areas such as entry type and entry reason definition.

  If the codes that are used in your existing system have changed over time, it may be simpler to create corresponding codes in PeopleSoft Receivables only for planned, ongoing use.

The disadvantages of converting only open items may include:

• No historical data available in PeopleSoft Receivables for history areas such as average days late.

• Research into closed items through your existing system, either online or through reports, during whatever period of time the accounts receivable and credit personnel need the closed item information.

For converting open items, evaluate whether to bring in only the current balance on the item or to also include transaction detail that may be in the balance.

For example, suppose in your existing system you have an invoice with an open balance. The balance is a result of the original invoice, minus a credit memo that is applied against it. With PeopleSoft Receivables, you can convert the item with its current balance or bring in both the original invoice and the credit memo.

To bring in the balance only, the conversion interface program creates one pending item. When you bring in both the invoice and the credit memo, you create two pending items, each containing the same business unit, customer ID, and item ID. You assign an appropriate entry type to each item as well as an amount and a number of other values. The Receivables Update process creates one row in the Item Table (PS_ITEM) for the item and two rows in the Item Activity table (PS_ITEM_ACTIVITY), one for each pending item. That is, after you post both pending items, PS_ITEM contains the balance for the item, and PS_ITEM_ACTIVITY contains all rows that affected the balance.

For converting closed items, create two pending items with the same amount: one to open the item and the other to close it. PeopleSoft Receivables does not support the direct entry of a closed item; a pending item cannot have an amount of zero.

To understand the alternatives for converting payment information, you should understand how payment processing works in PeopleSoft Receivables.

The goal of all payment application methods—express deposit, the payment worksheet, and the Payment Predictor Application Engine process (ARPREDCT)—is to create pending groups for posting. These payment application methods enable the cash applier to identify what is paid and to create necessary adjustments without having to construct the group directly. In this way, you can process deposits and payments that you received from the bank from the perspective of their source documents.

The end result of payment application, regardless of the method used, is one pending group for each payment: a row in PS_GROUP_CONTROL and one or more rows in PS_PENDING_ITEM, depending on how many items were paid by the payment.

If you have already entered the deposit information and applied the payment in a zero balance form in your current system, no real value exists in creating deposits and payments, and then reapplying the payments to create groups to send through the Receivables Update process. Directly creating the pending items that reflect the result of your current application process is more efficient than using our online or background processes to create the items, reenter these payments, and then reapply them to items. You have already accomplished this matching in your current system.

To understand how to construct these pending items, you need to understand the use of item entry types and automatic entry types.

Use of the line item feature is an important implementation decision that affects conversion planning and scope. The conversion implications of using line items include:

• Deciding whether the line item needs a different entry type and, optionally, an entry reason, to categorize it.

• Developing the pending items that are required to open and close each line item after the closed items are converted.

• Developing the pending items that are required to support transaction details for converted line items, whether open or closed.

This table describes the significance of two important date fields on the PS_PENDING_ITEM table:

Two conversion approaches using these date fields are available:

• When converting only open items:

  • Choose a common conversion date and place this date in the Accounting Date field.

  • Place the invoice date (or accounting date equivalent field) in the As Of Date field, and base payment terms and aging rules on the As Of Date field value.

    This approach records the converted items in one fiscal year and accounting period only, but maintains the original invoice date for terms and aging. The Accounting Date and As Of Date fields on the pending items from billing usually contain the same value if you choose this method.

• When converting open and closed items and developing history data within the PeopleSoft system from the converted activity, use the appropriate date that is associated with the activity in the existing system as the accounting date on the related pending items.

  This approach also establishes an accounting calendar that spans all the possible converted accounting dates and ensures that the open period range in the business unit options table is broad enough to span all accounting periods. Thus, the system records all converted activity in the fiscal year and accounting period in which it occurred.

Eight fields in the PS_PENDING_ITEM table contain related document information that the system uses for processing or page displays:

• DOCUMENT (and DOCUMENT_LINE)

• PO_REF

• BILL_OF_LADING

• ORDER_NO

• CONTRACT_NUM

• INVOICE

• LC_ID

• AG_REF_NBR

The maintenance worksheet uses the Document field to facilitate matching unless you enter your own matching criteria. When you specify on the worksheet that the system match items, it matches by comparing the item ID and item line number with the document and document line number of each item in the worksheet. Oracle designed this matching capability for instances in which subsequent activity against an invoice, such as a debit or credit memo, is assigned its own item ID by the originating billing system, with the original item ID supplied as reference information.

If you have this requirement in your application and want to use the matching feature in the maintenance worksheet, you should use the Document field—and line item, if necessary—to hold this information when you create pending items for debit memo and credit memo transactions.

You can display all of the fields on the preceding list without customization on the Item List inquiry page and on the worksheet application pages (payment, draft, maintenance, and transfer). If you have reference-type information for your business that requires this type of display, you may want to use one of the reference fields on the preceding list rather than a user field to hold critical application reference information.

One additional consideration when you are processing subsequent debits and credits from a billing system is whether to swap the document reference and item ID as part of your interface program. For example, your billing system assigns subsequent debit and credit memos their own item ID, but also supplies the original item ID in a reference field. Consider setting up your interface so that it can detect this condition, and have it place the document reference in the Item ID field (with a line number if appropriate) and the item ID in the Document reference field.

The Receivables Update process automatically matches the subsequent activity to the original item and saves you online maintenance activity.

Oracle provides 22 user-defined fields on the PS_PENDING_ITEM table in the delivered system that are exclusively for your use. These fields are known as user fields. The following table lists the fields:

You may want to make two types of modifications to user fields:

• Changing the manner in which the fields are updated.

• Adding more fields.

UPDATE %Table(RP_USER_TAO) 
SET USER1 = RP_I_USER1 
WHERE PROCESS_INSTANCE = %Bind(PROCESS_INSTANCE) 
AND USER1 = ' '

UPDATE %Table(RP_USER_TAO) 
SET USER1 = RP_I_USER1 
WHERE PROCESS_INSTANCE = %Bind(PROCESS_INSTANCE) 
AND RP_I_USER1 <> ' '

You need to make several decisions about how you use the accounting entry capabilities of PeopleSoft Receivables, including:

• How your billing system and PeopleSoft Receivables work together or separately to send accounting entries to your general ledger system.

• Whether you create accounting entries for pending items that are imported from your billing system directly in your billing interface program or enable PeopleSoft Receivables to create them for you.

• How you provide accounting entry information for items that you convert from your existing system.

These decisions depend on whether you use more than one accounts receivable line for each pending item.

Because your interface program builds groups for conversion and ongoing interface purposes, you must take several things into consideration in terms of group size and group structure. The most important consideration is how the group control and status information enables the operator to tie back to the source system for either conversion or ongoing interface balancing.

You use two fields on PS_GROUP_CONTROL to categorize groups: Origin and Group Type. Origin typically refers back to the source system, and Group Type represents the type of activity. Possible uses of these fields include:

• Establishing different origins for conversion groups from ongoing billing interface groups.

• Establishing different group types for conversion groups.

• Establishing a different group type for open and closed items and limiting a group to containing either open or closed items.

• When converting open and closed items with the intent of establishing history, creating one group for each month of activity that you convert and using the Group ID field to indicate the time frame.

No optimal size exist for a group in terms of how many pending items the group should contain. After balancing back to the source system is considered, other issues include:

• Slight processing overhead that is associated with a group, meaning that fewer groups with more pending items in each will then process more quickly.

• An online environment that contains some restrictions for the number of rows that can appear on a page.

  You can use two page formats to view external groups online. For the first page type, you view items in a scroll and scroll up or down to see all the items. In this type of page group, the number of pending items that you can display without receiving a page processor error is between 50 and 100, depending on how many pending distribution rows exist.

  For the second type of page, one pending item appears at a time. For example, PeopleTools limits the number of pending items in the list to 255 for some lists.

  Although you may think from this example that a group should never contain more than 255 pending items, a larger group works quite well for several reasons. For example, you have a group containing 5,000 pending items. The first time the group is posted, none of the 5,000 pending items are posted. Each of the items is unlikely to have a unique error. When you bring up the first 255 rows on an error correction page, you may discover that most of them have the same error, such as an invalid payment term. You correct the value on the setup table and post the group again. Then you find that most of the pending items are posted and you have only a few remaining rows to correct.

  After you work out setup-related conversion issues and have your ongoing interface established, the number of errors that occur, if any, should be minimal. To facilitate this process, you will find helpful the task of first developing test conversion and interface groups that contain a sample of the data that you process. This helps to eliminate setup issues and enables you to process the group size for conversion and ongoing interfaces that best suit business control and balancing.

If you are converting or importing activity by using a foreign currency, you need to consider how the groups are composed. You can choose to bring in more than one currency within the same group or to limit groups to a single currency.

If you plan to create accounting entries during background processing, you must perform currency conversion in advance on the pending items and any pending VAT information or pending taxes for India that you are converting or importing.