1. Dunning considering oldest due date for performing dunning action
Solution- There is a configuration to decide the due date to be considered for performing collections/dunning on the account. For example if we have configured (due date +1) to take the first action for collections, BRM can consider the oldest or the earliest due date for the same. Below is the scenario -
i.If the entry criteria of collections is greater than 5$.
ii.Customer billed outstanding for the month of Jan is 3$ on 28th Jan (Due date is 28th of the month)
iii. Customer billed outstanding for Feb month is 1$ on 28th Feb
iv. Customer billed outstanding for Mar month is 1$ on 28th Mar.
On 28th Mar, customer total billed outstanding is 5$ and hence customer qualifies for entering collection scenario. So if the system considers the oldest due date(28th Jan), the dunning action will be taken on 28th March itself whereas if the system considers the earliest due date (28th Mar), the dunning action will be taken on 29th March. In our project the requirement was to consider the earliest date and run dunning on 29th March.
There is a configuration in CM "old_overdue_behavior", we changed the value to 0 to consider the latest bill.
# fm_collections
# If the value of the old_overdue_behavior is 0
# The latest bill due date is considered to calculate the over due date.
# If the value of the old_overdue_behavior is 1
# The earliest bill due date is considered to calculate the over due date.
# The default will value will be 0.
2. Billing didn't run at 1am since the billing delay period was set to 0:3
Solution- There is a configuration in CM "config_billing_delay" (Specifies a delay for disabling the automatic triggering of billing)
We changed the setting to 0:1 in order to start the billing of customer at 1am.
3. DB Locks encountered in bal_grp_t during order provisioning since the table was locked for update
Solution- After deploying patchset 12 on BRM 7.4 version, the instance of bal_grp_t locking issue is minimal.
When orders are provisioned in BRM from CRM through AIA this table is selected for update, and blocking locks are observed sometimes, but after the Oracle patch deployment the issue is resolved.
4. Field missing in JCA adapter due to which profile was not created
Solution - This issue was observed when some custom fields are created in BRM which were not recognized by AIA in case of opcode call through AIA. Whenever custom fields are created corresponding classes related to the custom fields class files should be added in the pcmext.jar and then BRMJCAAdapter.rar file should be deployed in AIA. After deploying the new RAR the custom field was recognized by AIA and the issue got resolved.
5. If the product has proration on exit, if the end date is preponed by set_prodinfo, appro amount will be refunded.
Solution - We configured a product with proration on exit, which caused refunds to customer when end date was set to earlier date, so we then changed the configuration to charge for entire cycle and then pre-poned the end date, issue was resolved.
6. Pipeline crashing when trying to rate cdr for account which has purchased more than 50 discounts.
Solution - Issue was observed whenever pipeline was trying to rate a cdr for an account having more than 50 purchased discounts. Pipeline was crashing and giving memory dump at that instance. Oracle provided a patch for this issue which resolved the pipeline crash.
There were few instances where pipeline crashed due to insufficient memory on the application server. To resolve this issue we have increated the memory thresold value parameter "ShutdownFreeMemLimit" to 15.
7. When cycle_start_t field is set to 2nd or 3rd of the month the cycle charges and related monthly free minutes where not provided to accounts
Solution - There were some customers which were created on 30th of the month and the requirement was to start the charging from 1st of the month. For this scenario some customers purchased start date used to get set to 2nd or 3rd, and cycle forward event didn't use to get created and the monthly benefits like free usage were not given to the customers.
In order to resolve this we made sure that date is set to 1st of the month to apply the MRC from 1st of the month. If there are any accounts left with incorrect start date, we called PCM_OP_SUBSCRIPTION_CYCLE_FORWARD opcode on that account to apply MRC and provide free minutes for the month.
Solution- There is a configuration to decide the due date to be considered for performing collections/dunning on the account. For example if we have configured (due date +1) to take the first action for collections, BRM can consider the oldest or the earliest due date for the same. Below is the scenario -
i.If the entry criteria of collections is greater than 5$.
ii.Customer billed outstanding for the month of Jan is 3$ on 28th Jan (Due date is 28th of the month)
iii. Customer billed outstanding for Feb month is 1$ on 28th Feb
iv. Customer billed outstanding for Mar month is 1$ on 28th Mar.
On 28th Mar, customer total billed outstanding is 5$ and hence customer qualifies for entering collection scenario. So if the system considers the oldest due date(28th Jan), the dunning action will be taken on 28th March itself whereas if the system considers the earliest due date (28th Mar), the dunning action will be taken on 29th March. In our project the requirement was to consider the earliest date and run dunning on 29th March.
There is a configuration in CM "old_overdue_behavior", we changed the value to 0 to consider the latest bill.
# fm_collections
# If the value of the old_overdue_behavior is 0
# The latest bill due date is considered to calculate the over due date.
# If the value of the old_overdue_behavior is 1
# The earliest bill due date is considered to calculate the over due date.
# The default will value will be 0.
2. Billing didn't run at 1am since the billing delay period was set to 0:3
Solution- There is a configuration in CM "config_billing_delay" (Specifies a delay for disabling the automatic triggering of billing)
We changed the setting to 0:1 in order to start the billing of customer at 1am.
3. DB Locks encountered in bal_grp_t during order provisioning since the table was locked for update
Solution- After deploying patchset 12 on BRM 7.4 version, the instance of bal_grp_t locking issue is minimal.
When orders are provisioned in BRM from CRM through AIA this table is selected for update, and blocking locks are observed sometimes, but after the Oracle patch deployment the issue is resolved.
4. Field missing in JCA adapter due to which profile was not created
Solution - This issue was observed when some custom fields are created in BRM which were not recognized by AIA in case of opcode call through AIA. Whenever custom fields are created corresponding classes related to the custom fields class files should be added in the pcmext.jar and then BRMJCAAdapter.rar file should be deployed in AIA. After deploying the new RAR the custom field was recognized by AIA and the issue got resolved.
5. If the product has proration on exit, if the end date is preponed by set_prodinfo, appro amount will be refunded.
Solution - We configured a product with proration on exit, which caused refunds to customer when end date was set to earlier date, so we then changed the configuration to charge for entire cycle and then pre-poned the end date, issue was resolved.
6. Pipeline crashing when trying to rate cdr for account which has purchased more than 50 discounts.
Solution - Issue was observed whenever pipeline was trying to rate a cdr for an account having more than 50 purchased discounts. Pipeline was crashing and giving memory dump at that instance. Oracle provided a patch for this issue which resolved the pipeline crash.
There were few instances where pipeline crashed due to insufficient memory on the application server. To resolve this issue we have increated the memory thresold value parameter "ShutdownFreeMemLimit" to 15.
7. When cycle_start_t field is set to 2nd or 3rd of the month the cycle charges and related monthly free minutes where not provided to accounts
Solution - There were some customers which were created on 30th of the month and the requirement was to start the charging from 1st of the month. For this scenario some customers purchased start date used to get set to 2nd or 3rd, and cycle forward event didn't use to get created and the monthly benefits like free usage were not given to the customers.
In order to resolve this we made sure that date is set to 1st of the month to apply the MRC from 1st of the month. If there are any accounts left with incorrect start date, we called PCM_OP_SUBSCRIPTION_CYCLE_FORWARD opcode on that account to apply MRC and provide free minutes for the month.
No comments:
Post a Comment