Understanding Conversations
Conversation pages track ongoing conversations with customer contacts. For example, you can track invoice and payment issues that you are trying to resolve, as well as other customer inquiries. You can link a conversation to a specific purchase order, invoice, contract, or receivables item. In addition, you can use the PeopleSoft notification feature to send an email to an interested party to announce that a new or existing conversation entry is available to review.
Use the conversations pages as needed to review and update past conversations or to record new ones. If you have ongoing contact or documentation that is related to the same subject or subject topic, you can create new entries for an existing conversation that contain the continued history of the discussion.
You can set up the conversation so that you review it after a specified number of days from the creation date, or you can have a supervisor review it. For review by a supervisor, the system automatically assigns the supervisor who is associated with the user profile of the person who created the entry.
You can also attach documents to a conversation, such as proof of delivery slips, bills of lading, spreadsheets, or text documents.
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 (
), 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.
Promise Status |
Conversation Status |
||
---|---|---|---|
New |
Open |
Closed |
|
Open |
X |
X |
|
Kept |
X |
||
Broken |
X |
X |
|
Cancelled |
X |
X |
|
None |
X |
X |
X |
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 (
).
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.
Creating Actions for Conversations
This example shows how to create an action for a regular conversation with a follow-up action:
Create a new conversation with a follow-up action on the Conversations page.
See the Follow-Up Action Needed Search Page for an example that illustrates the fields and controls on the Conversations page with follow-up action needed.
Run the Condition Monitor to process the CFLU (Conversations Follow Up) condition.
Review the action created on the Customer Action Page. Click the Action link to view the Action Detail page for the selected action.
In this case, click the Alert link for the Conversation Follow Up condition to see the Action Detail page.
You can also review actions created by the Condition Monitor on the Owner Action List Page and on the Collections Workbench.
This example illustrates the fields and controls on the Action Detail page for the Conversation Follow Up (CFLU) Condition.
This example shows how to create an action for a promise-to-pay conversation:
Create a new conversation with a promise to pay on the Conversations Page.
Run the Condition Monitor. Condition Monitor generates the following:
Customer Promise Date Broken (CPDB) condition – When the promise is not met based on promise date, amount, and promise date options.
Customer Promise Date Review (CPDR) condition – When the user specified a promise review action on the Conversations page.
Review the action created on the Customer Action Page. Click the Action link to view the Action Detail page for the selected action.
In this case, click the Action link for the Customer Promise Date Broken or Customer Promise Date Review condition to see the Action Detail page.
You can also review actions created by the Condition Monitor on the Owner Action List Page and on the Collections Workbench.
This example illustrates the fields and controls on the Action Detail page for the Customer Promise Date Broken (CPDB) Condition.
This example illustrates the fields and controls on the Action Detail page for the Customer Promise Date Review (CPDR) condition.
See also Setting Up Conversation Promise Dates.
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.
Setting Up Payment Plans
To set up and create a payment plan:
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.
Initiate a payment plan for a customer using the Create a Payment Plan item action on the Item List Page.
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.