Promise To Pay Breach Is Not Triggered By Pin_collections_process (Doc ID 2288566.1)

Last updated on SEPTEMBER 20, 2017

Applies to:

Oracle Communications Billing and Revenue Management - Version 7.5.0.0.0 and later
Information in this document applies to any platform.

Symptoms

On :  BRM 7.5.0.15.0 version, Collections Manager

The following two scenarios exhibit the problem wherein Promise To Pay (PTP) is not breached, and hence there is no call to breach policy opcode op_collections_pol_handle_breach_promise_to_pay, which is required by the user for certain customization to be carried out.

Scenario 1: pin_collections_process is executed exactly at the same time as DUE_T of the promise to pay (ptp) action

pre-req:

  1. Create a simple collections scenario as per example in knowledge article:
    How To : Test Collections Feature In BRM (Doc ID 2037361.1)
  2. From Permissioning Center, create a Person, create Role and add all Collections Center restrictions (cannot create promise to pay actions without this)


Steps to reproduce:

  1. 1 Jan : create account
  2. 1 Feb : run pin_bill_accts, due date of bill is 3 March
  3. Account will enter collections after 5 days from due, then move pin_virtual_time to 9 March
  4. 9 Mar : run pin_collections_process.  Now account will enter collection
  5. 9 Mar : launch Collections Center, login as the 'Person' created above in Permissioning Center, search for the above /billinfo that has now entered into collection, create a promise to pay, 'payment due before' = 24 march ( for example ), with 4 installments
  6. Four promise to pay actions will be created with 'pending' status
  7. Check the DUE_T of the PTP actions, for example :
     
  8. 24 Mar : move pvt in mode 1 (for testing) to this date Mar 24 00:00:00 2017, this is same as DUE_T of the first ptp action shown above
  9. Do not make any payment, and now run pin_collections_process in order to breach the PTP action


Actual result:

The first 'promise to pay' action will change to COMPLETED status, the other three 'promise to pay' action will remain in PENDING status. There is no PTP breach (check in events generated), nor there is a call to the breach policy opcode op_collections_pol_handle_breach_promise_to_pay

Expected result:

Now the first 'promise to pay' action will change to COMPLETED status, the other three 'promise to pay' action will change to CANCELLED status. This means there is a PTP breach (check in events generated), AND hence there must be a call to the breach policy opcode op_collections_pol_handle_breach_promise_to_pay

Note:

If step 8 is modified with the time as Mar 24 00:00:01 2017  (one second later in the day ), result is as expected.

Scenario 2: PTP is invoked on same day when billinfo enters into collections with a scenario having entry days "0"

pre-req:

in collections scenario, change entry date to 0

Steps to reproduce:

  1. 1 Jan : create account
  2. 1 Feb : run pin_bill_accts, due date of bill is 3 March
  3. Account will enter collections after 0 days from due, so move pvt to 3 March
  4. 3 Mar : run pin_collections_process.  Now account will enter collection
  5. 3 Mar : launch Collection Center, login as the 'Person' created above in permissioning center, search for the above billinfo that has now entered into collection, create a promise to pay, 'payment due before' = 15 march ( for example ), with 3 installments
  6. Three promise to pay actions will be created with 'pending' status. check due_t of the first PTP action, it will be 14 March.
  7. 14 Mar : move pvt in mode 2 (no need to move in mode 1 as in previous scenario)
  8. Do not make any payment, and now run pin_collections_process in order to breach the PTP action


Actual result:

The first 'promise to pay' action will change to COMPLETED status, the other three 'promise to pay' action will remain in PENDING status. There is no PTP breach (check in events generated), nor there is a call to the breach policy opcode op_collections_pol_handle_breach_promise_to_pay

Expected result:

Now the first 'promise to pay' action will change to COMPLETED status, the other three 'promise to pay' action will change to CANCELLED status. This means there is a PTP breach (check in events generated), AND hence there must be a call to the breach policy opcode op_collections_pol_handle_breach_promise_to_pay

Changes

 

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms