Understanding Conversations

Collectors and receivable managers are challenged with keeping track of outstanding customer payments and automating the follow up on unfulfilled promises. Streamlining of this business process enables users to identify the risk of future promises and to indicate that a pre-emptive follow up will be required for any new promises. A collections analyst can enter a promise to pay by a customer and track and manage that promise within the Conversations component.

Your system administrator can predefine several promise date options. These include:

• Number of days that are tolerated past the promise date before further action is required.

• Percentage of the payment amount that is acceptable.

• Broken promise action.

• Values that a user can override.

These options are set by the system administrator on the Promise Date Options page (Set Up Financials/Supply Chain > Product Related > Receivables > Credit/Collections > Promise Date Options), and the selected values appear as default field values in the Promise of Payment group box of the Conversations page.

Condition Monitor automatically processes promised payments. Condition Monitor selects the CPDR (Customer Promise Date Review) condition and processes the promised payment conversations that required a review and a creates appropriate action list items. Condition Monitor also automatically processes promised payments that have broken promises by selecting the CPDB (Customer Promise Date Broken) condition, which selects the broken promises and creates action list items. The Customer Promise Date Broken program closes promise date conversations with a status of Broken, no promise date action, and no review scheduled after the promise date. The program also closes promise date conversations when a user selects the Done check box on the Conversations page, which indicates that the broken promise was reviewed and no review date was selected after the promise date.

The CFLU (Conversations Follow Up) condition does not select promise date conversations. When a collections analyst creates a new conversation on the Conversations page and selects the Promise of Payment check box, the conversation is considered a promise date conversation and the promise status is set to Open. Once a conversation is marked as a promise of payment conversation, the collections analyst must enter a promise date and the amount that the customer promised to pay in order to save the conversation.

Depending on the promise made by the customer and a review of this promise, the system assigns a Promise Status of:

• Open

• Kept

• Broken

• Cancelled

• None

  This status is used for conversations that are not promise date conversations.

The status of a conversation can be New, Open, or Closed. This table displays each of the promise statuses that are possible based on the status of the conversation.

The Promise Status is typically set and updated by Condition Monitor processing. When a promise date conversation is created, the promise status is set to Open. Condition Monitor updates the status to either Kept or Broken. Promise date conversations are closed manually by the user or automatically by the Condition Monitor program. These are the general rules governing the conversation status:

• When a user creates a promise date conversation, the conversation status is New. When users want Condition Monitor to process the conversation for promise dates, they update the status of the promise date conversation to Open.

• If the Condition Monitor evaluates a promise as Kept, the conversation is closed.

• If the Condition Monitor evaluates a promise as Broken with no broken promise action, the conversation is closed.

• If the Condition Monitor evaluates a promise as Broken and there is a broken promise action, the conversation remains open until the user selects the Done check box to indicate that the action has been completed and closes the conversation.

• Any user can open a closed conversation and manually override the promise status. If the user overrides the promise status to a status of Kept or Broken, the conversation can be closed. If the promise status is Open, then the conversation cannot be closed. If the promise status has been overridden to Cancelled, the conversation can still remain open.

  A user can exclude a promise from being included in the metrics, mark a promise as fulfilled, or override an unfulfilled promise as fulfilled.

  To override a promise status, a user must select the Override Promise Status check box and an override reason. A user can change the promise status and change the reason code multiple times, but you cannot change override status. This indicates that the promise status has been overridden by a user and has been changed automatically by Condition Monitor. If users make a mistake, they can select and save the appropriate status.

  A broken promise action is based on a valid action, which you set up in the system. The user ID for a broken promise action is associated with the user that receives an action item based on the broken promise action. If the user assigned to the broken promise action reviews the broken promise and selects the Done check box, the promise status changes to broken and the conversation is closed.

  If a payment is received, the system can set the action items for review or set a broken promise as completed and the action no longer appears on the user's action list. Metrics are reported for each customer based on a promise to pay status of Kept, Broken, and Open. However, metrics are not tracked for promise payments with a status of Cancelled, because these promises were intentionally cancelled with the intention of not recording or reporting them as a promise to pay. A history of the status changes is not collected or reported. This includes any history of manual overrides that change a status from Broken to Kept, Broken to Open, or Broken to Cancelled.

  Users can create, update, and review promise date conversations on Conversations tab of the Collections Workbench in PeopleSoft Receivables (Accounts Receivable > Customer Accounts > Collections Workbench).

See Understanding the Collections Workbench

Promise Review

In addition to assigning a user an action item to review a broken promise, you can also ensure that a promise is reviewed by the appropriate personnel based on your selections in the Promise Review group box. You can select a review date, the review action required, which is usually an action performed prior to the promise date, and the user ID of the individual that you want to perform the review. The reviewer performs the review action and can, if necessary, indicate that a supervisor needs to review the promise. The reviewer can also indicate any follow up action that may be required and select the date that this action was completed. The promise date does not affect this date, because the conversation may need reviewing after the promise date.

See Conversations Page.

See Setting Up Promise Date Options for a Customer.

See Using the Collections Workbench

PeopleSoft Receivables enables you to create payment plans for item balances. Using this feature you can define a payment plan and plan type, select items to include in the plan, and create installments.

Several Receivables pages include a payment plan (PLAN ID) column, such as Collections Workbench, Receivables Worksheets,Credit Card Worksheets, and Delinquent Accounts. The column provides a payment plan ID for each item. The ID is a link that you can use to access the corresponding payment plan (Payment Plan Page) for the item.

Payment plan installment items can be included in statements, dunning, and overdue charges by selecting the Correspondence options for the PPI entry type on the Entry Type Page.

In addition, you can use the Payment Plan Report to view payment plan information for a customer. The report provides a detailed view of items included in a payment plan and installments.

See Payment Plan Report Page

Setting Up Payment Plans

To set up and create a payment plan:

1. Specify payment plan defaults for a business unit using the Receivables Options - Payment Options Page. Example of payment plan defaults are Maximum Installments and Default Plan Type.

   You also have the option of using the General Information - Bill To Options Page to specify plan defaults.

2. Initiate a payment plan for a customer using the Create a Payment Plan item action on the Item List Page.

3. Define payment plan and generate installments using the Payment Plan Page.

Note: Drafts, Direct Debits, Selecting source items across business units, Selecting source items with multiple currencies, Cancelling a plan, Discounts, and Payment Plans for VAT and India Business Units do not support Payment Plan.