This chapter describes Oracle Communications Billing and Revenue Management (BRM) bill suppression and explains how to implement it.
Before reading this chapter, read "About Billing".
By default, BRM finalizes a bill at the end of each billing cycle. When a bill is finalized, the status of its bill items is changed from pending to open so that they stop accumulating charges and so that payments can be applied to them. In addition, a due date is added to the bill. If necessary, an invoice is generated for the bill. A new bill is created to handle bill items for the next billing cycle.
Bill suppression, however, enables you to postpone finalizing a bill until the end of a future billing cycle. When a bill is suppressed, it is extended to include bill items for the next cycle, and the bill continues to accumulate charges until the end of that cycle.
Important:
Charges accrued during all cycles in which a bill is suppressed do not age, get invoiced, go into collections, or have a due date set for them until suppression ends and the bill is finalized.You use bill suppression to avoid sending out unnecessary bills and incurring wasteful expenses. For example, if the cost to create and mail a bill is greater than the balance due, you can suppress the bill until its balance due is greater than its production costs.
Bills can be suppressed in several ways:
All types of bill suppression can be overridden by exceptions. See "Exceptions to Bill Suppression".
Note:
To suspend bills, see "About Suspending Billing of Accounts and Bills". Unlike bill and account suppression, bill suspension inactivates bill units.At the end of a billing cycle, BRM can automatically suppress bills whose balance is less than a user-specified minimum required to finalize a bill. Such bills are suppressed for one billing cycle. If their balance is still below the minimum at the end of that cycle, they are suppressed for another billing cycle.
Note:
Bills with negative balances are not suppressed.
If both bill suppression and open item purging are enabled for a bill unit (/billinfo object), the bills for the bill unit are always suppressed because its bill total will always be 0. For more information about open item purging, see "Enabling Events Associated with Open Items to Be Purged" in BRM System Administrator's Guide.
If the number of consecutive billing cycles for which a bill is suppressed reaches your specified maximum number of cycles, the bill is generated even if its balance is still below the minimum. This ensures that an excessive amount of time does not pass between customer bills.
To implement automatic bill suppression, you specify minimum balance amounts and maximum cycle limits for each customer segment that includes accounts whose bills you want to suppress automatically. A customer segment's specifications apply to all the bill units in the accounts that belong to the segment.
For example, a customer segment for low-usage accounts with bad payment histories might have a bill-generation threshold of only $5 and a limit of only three consecutively suppressed cycles, whereas a customer segment for high-usage accounts with good payment histories might have a bill-generation threshold of $15 and a limit of six consecutively suppressed cycles.
Note:
If an account belongs to more than one customer segment, the lowest minimum balance and the lowest maximum cycle settings associated with the customer segments apply to the account. These settings can be from different customer segments.For example, account X belongs to customer segments A and B. Segment A's minimum balance is $5 and its maximum cycle setting is 4. Segment B's minimum balance is $10 and its maximum cycle setting is 2. Thus, account X's minimum balance is $5 (from segment A) and its maximum cycle limit is 2 (from segment B).
For more information, see "Automatically Suppressing Bills".
Manual bill suppression enables you to suppress individual bills programmatically or through a custom user interface on a case-by-case basis.
For example, if you use automatic bill suppression, you can use manual bill suppression to suppress bills whose balance does not qualify for automatic suppression, as in this situation: Customer A's account belongs to customer segment X. The minimum balance required to finalize bills associated with accounts in customer segment X is $10. Midway through the current billing cycle, customer A's balance is $105, so his bill does not qualify for automatic bill suppression and will be finalized at the end of the billing cycle. Because customer A is having cash flow problems, however, he calls a customer service representative (CSR) and asks her to suppress his bill for two billing cycles. Using an interface that interacts with the manual bill suppression feature, she manually suppresses his bill for the requested number of cycles.
Note:
Unlike automatic bill suppression, the default manual bill suppression feature does not use customer segments.For more information, see "Manually Suppressing Bills".
Manual account suppression enables you to suppress accounts on request. With this feature, customers who will not be using their account for an extended period of time can retain all their services and connection IDs without accumulating any of the charges usually associated with their account.
Optionally, charges associated with one account-level deal can accumulate during account suppression. You can use this deal to handle any special fees you want to charge while an account is suppressed. For example:
Charge a purchase fee for suppressing an account.
Charge a low monthly cycle fee for retaining a suppressed account's services and connection IDs.
Note:
Unlike automatic bill suppression, account suppression does not use customer segments.For more information, see "Manually Suppressing Accounts".
A suppressed account differs from an inactive account as shown in Table 10-1:
Table 10-1 Differences between Suppressed and Inactive Accounts
| Condition | Account Type | Status |
|---|---|---|
|
Is the account inactive? |
Suppressed account |
No. |
|
Is the account inactive? |
Inactive account |
Yes. |
|
Are the account's services inactive? |
Suppressed account |
Yes. |
|
Are the account's services inactive? |
Inactive account |
Yes. |
|
Are the account's bills finalized? |
Suppressed account |
No. Accrued charges do not age, get invoiced, or go into collections. |
|
Are the account's bills finalized? |
Inactive account |
Yes. Charges accrued before the account is inactivated age, get invoiced, and go into collections. |
|
Can new charges accrue in the account? |
Suppressed account |
Yes. Optionally, charges associated with one account-level deal can accrue. |
|
Can new charges accrue in the account? |
Inactive account |
No. |
|
Does the status of the account's child accounts change? |
Suppressed account |
No. Subordinate (nonpaying) child account bills are finalized. Their charges continue to accrue in the suppressed parent account's bill that is not yet finalized. |
|
Does the status of the account's child accounts change? |
Inactive account |
Yes. All child accounts that have subordinate (nonpaying) bill units are inactivated. |
|
Is sponsorship affected? |
Suppressed account |
No. Member accounts' sponsored charges continue to accrue in the suppressed owner account's unfinalized bill. Note: To prevent sponsor owner accounts from being suppressed, add the appropriate logic to the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode. |
|
Is sponsorship affected? |
Inactive account |
Yes. Sponsorship is suspended. Formerly sponsored charges accrue in member account bills while the owner account is inactive. |
|
Is discount sharing affected? |
Suppressed account |
No. Member account events continue to impact the balance of the suppressed discount sharing group owner's unfinalized bill. |
|
Is discount sharing affected? |
Inactive account |
Yes. Member account events impact member accounts' balances, not the inactive owner account's balance. |
All types of bill suppression can be overridden by exceptions. The default exceptions are listed in Table 10-2:
Table 10-2 Exceptions to Bill Suppression
| Exception | Description |
|---|---|
|
Payment received |
The receipt of a payment requires that a bill be finalized to record the payment against the bill. By default, this exception is disabled. To enable it, see "Customizing Bill Suppression Exceptions". |
|
Adjustment or credit applied |
If an adjustment or a credit is made to an account, the bill is finalized to notify the customer about the change in the balance. |
|
Maximum consecutive cycle suppressions exceeded |
The maximum number of consecutive billing cycles for which a bill can be suppressed is specified for the customer segment to which the bill's account belongs. See "Associating Bill Suppression Information with Customer Segments". Note:
|
|
First or last bill |
An account's first and last bills are always finalized at the end of their billing cycles, even if their balance is below the minimum balance required to finalize bills. |
|
Account closed |
Bills associated with closed accounts cannot be suppressed. |
To add or delete exceptions, see "Customizing Bill Suppression Exceptions".
Important:
The Bill Now command, in Customer Center, and on-demand billing for deals and plans do not override bill suppression. Although they finalize a suppressed bill, they do not:Reset the counter in the /billinfo object that tracks consecutively suppressed billing cycles (PIN_FLD_NUM_SUPPRESSED_CYCLES).
End manual bill or manual account suppression.
Exceptions do not end manual bill or manual account suppression. Rather, they cause the PCM_OP_BILL_MAKE_BILL opcode to do the following:
Finalize the manually suppressed bill at the end of its current billing cycle.
Reset the counter in the /billinfo object that tracks the bill's consecutively suppressed billing cycles (PIN_FLD_NUM_SUPPRESSED_CYCLES) to 0.
Decrement the counter in the /billinfo object that tracks the bill's remaining manually suppressed cycles (PIN_FLD_SUPPRESSION_CYCLES_LEFT) by 1.
For example, a bill is manually suppressed for 10 billing cycles. At the end of the fifth cycle, however, it is finalized because of an exception. At that time, the bill's consecutively suppressed cycles counter is reset to 0, and its remaining manually suppressed cycles counter is decremented by 1. Because the latter counter was also decremented by 1 at the end of the four previous suppressed billing cycles, its value is now 5, which indicates that the bill should be suppressed for 5 more cycles.
To implement automatic bill suppression, perform these tasks:
To implement manual bill suppression, see "Manually Suppressing Bills".
To implement manual account suppression, see "Manually Suppressing Accounts".
To set up automatic bill suppression:
Set up customer segments in your system and add accounts to them. See "Creating and Managing Customer Segments" in BRM Managing Customers.
Note:
Whether or not you set up customer segments, all accounts belong to customer segment 0. Thus, to implement automatic bill suppression without creating customer segments, perform step 2 for customer segment 0. The suppression specifications associated with customer segment 0 apply to all the accounts in your system.For each customer segment that includes accounts whose bills you want to suppress automatically, specify the following information:
Minimum balance required for a bill to be finalized.
Maximum number of consecutive billing cycles that a bill can be suppressed.
See "Associating Bill Suppression Information with Customer Segments".
To implement bill suppression, edit the bill suppression configuration file (pin_bill_suppression.xml) and then load its contents into the /config/suppression object in the BRM database.
Caution:
The utility that loads bill suppression settings into the database overwrites all existing bill suppression settings. When updating the settings, you cannot load new settings only. You must load settings for each customer segment every time you run the utility.Open the pin_bill_suppression.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory, where BRM_Home is the directory where you installed BRM components.
In the file, specify the following information for each customer segment that contains accounts whose bills you want to suppress:
Minimum balance required for a bill to be finalized.
Maximum number of consecutive billing cycles that a bill can be suppressed.
Save and close the file.
Use the following command to run the "load_pin_bill_suppression" utility from the directory in which the pin_bill_suppression.xml file is located:
load_pin_bill_suppression pin_bill_suppression.xml
Important:
When you run the utility, the pin_bill_suppression.xml and business_configuration.xsd files must be in the same directory. By default, both files are in BRM_Home/sys/data/config. See "Validating Your Bill Suppression Configuration File Edits".
This utility needs a configuration (pin.conf) file in the directory from which you run the utility. For information about creating configuration files for BRM utilities, see "Creating Configuration Files for BRM Utilities" in BRM System Administrator's Guide.
If you do not run the utility from the directory in which pin_bill_suppression.xml is located, include the complete path to the file, for example:
load_pin_bill_suppression BRM_Home/sys/data/config/pin_bill_suppression.xml
For more information, see "load_pin_bill_suppression".
Stop and restart the Connection Manager (CM). See "Starting and stopping the BRM system" in BRM System Administrator's Guide.
To verify that the bill suppression information was loaded, display the /config/suppression object by using Object Browser or the robj command with the testnap utility.
For general instructions on using testnap, see "Using testnap" in BRM Developer's Guide. For information about reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
In the BRM_Home/sys/data/config/pin_bill_suppression.xml file, you specify the following information for each customer segment that includes accounts whose bills you want to suppress automatically:
Minimum balance required for a bill to be finalize.
Maximum number of consecutive billing cycles that a bill can be suppressed.
To edit this configuration file, open it in an XML editor or a text editor.
In the file, the CustomerSegmentArray parent element must contain a CustomerSegment child element for each customer segment to which you want to add bill suppression information. A CustomerSegment child element looks like this:
<CustomerSegment ID="int">
<MinBillAmount>decimal</MinBillAmount>
<MaxSuppressionCycles>int</MaxSuppressionCycles>
</CustomerSegment>
To specify bill suppression information for a customer segment, add a CustomerSegment child element to the CustomerSegmentArray parent element. In the child element, specify values for the items listed in Table 10-3:
Table 10-3 Customer Segment Bill Suppression Elements
| XML Element or Attribute | Description | Possible Values |
|---|---|---|
|
ID |
The ID of the customer segment. Customer segments are defined in an array in the /config/customer_segment object. The index of each array entry is the ID of a customer segment. The IDs of the customer segments to which an account belongs are specified in the PIN_FLD_CUSTOMER_SEGMENT_LIST field of the /account object. |
Any nonnegative integer. Note:
|
|
MinBillAmount |
Minimum balance required to finalize a bill. If the balance is less than this amount, the bill is automatically suppressed. |
Any positive number with two decimal places. Note: Although balances are stored in account currency, this value is not converted to a particular currency. For example, if this value is 5.00, it represents 5 US dollars, 5 Australian dollars, 5 euros, and so on. |
|
MaxSuppressionCycles |
Maximum number of consecutive billing cycles for which a bill can be suppressed. |
Any integer greater than 0. |
The following is a sample pin_bill_suppression.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<BusinessConfiguration
xmlns="http://www.portal.com/schemas/BusinessConfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.portal.com/schemas/BusinessConfig business_configuration.xsd">
<!-- Sample file. Modify according to guidelines -->
<BillSuppressionConfiguration>
<CustomerSegmentList>
<CustomerSegment ID="1001">
<!-- Bad customer -->
<MinBillAmount>5.55</MinBillAmount>
<MaxSuppressionCycles>2</MaxSuppressionCycles>
</CustomerSegment>
<CustomerSegment ID="1002">
<!-- Good customer -->
<MinBillAmount>99.99</MinBillAmount>
<MaxSuppressionCycles>5</MaxSuppressionCycles>
</CustomerSegment>
</CustomerSegmentList>
</BillSuppressionConfiguration>
</BusinessConfiguration>
After editing the contents of the XML file, you use the "load_pin_bill_suppression" utility to load the contents of the file into the /config/suppression object in the database. See "Associating Bill Suppression Information with Customer Segments".
Before loading the contents of the file, the utility validates the contents against the file's schema definition. If the contents do not conform to the schema definition, the load operation fails. The schema definition is in this file:
BRM_Home/xsd/pin_bill_suppression.xsd
The XML file is not directly linked to its schema definition file. Instead, it is linked to this XSD reference file:
BRM_Home/sys/data/config/business_configuration.xsd
For more information about the XSD reference file, see "About Validating XML Configuration Files" in BRM System Administrator's Guide.
To suppress and unsuppress bills manually, call the PCM_OP_BILL_SET_BILL_SUPPRESSION opcode. This opcode enables you to accomplish the following tasks programmatically or through a custom user interface:
Suppress a bill for a specified number of billing cycles.
Unsuppress a manually suppressed bill.
If you use customer segments to set the maximum number of consecutive billing cycles that bills can be suppressed, be careful not to suppress bills manually for more than the specified maximum number of cycles (see "Associating Bill Suppression Information with Customer Segments"). When a suppressed bill exceeds the maximum consecutive cycle number, a suppression exception triggers BRM to generate the bill (see "Exceptions to Bill Suppression"). This might confuse customers who requested that their bills be manually suppressed for a longer period of time.
To determine the maximum number of consecutive cycles for which a bill can be suppressed:
Find out which customer segments the bill's account belongs to by checking the PIN_FLD_CUSTOMER_SEGMENT_LIST field in the /account object.
Check the PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES field of the appropriate customer segment in the /config/suppression object.
Note:
If an account belongs to more than one customer segment, the lowest PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES value associated with the segments applies.
If an account belongs to no customer segments, the PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES value of the default customer segment (ID 0) applies.
If an account belongs to no customer segments and your system has no default customer segment, the bill can be suppressed for an unlimited number of consecutive cycles.
To determine the current number of consecutive billing cycles for which a bill has been suppressed, check the PIN_FLD_NUM_SUPPRESSED_CYCLES field of the /billinfo object.
For more information, see "About Manual Bill Suppression".
To implement automatic bill suppression, see "Automatically Suppressing Bills".
To implement manual account suppression, see "Manually Suppressing Accounts".
Manual account suppression enables you to accomplish the following tasks programmatically or through a custom user interface:
Suppress an account immediately or on a specified future date. To do this, call the PCM_OP_BILL_SET_ACCOUNT_SUPPRESSION opcode.
Optionally, this opcode can purchase one account-level deal for the account to handle any purchase and cycle fees you want to associate with account suppression. The deal POID must be passed to the PIN_FLD_DEAL_OBJ field of the opcode's input flist.
If you use customer segments to set the maximum number of consecutive billing cycles that bills can be suppressed, be careful not to suppress accounts manually for more than the specified maximum number of cycles (see "Associating Bill Suppression Information with Customer Segments"). When a suppressed bill exceeds the maximum consecutive cycle number, a suppression exception triggers BRM to generate the bill (see "Exceptions to Bill Suppression"). This might confuse customers who requested that their bills be manually suppressed for a longer period of time.
To determine the maximum number of consecutive cycles for which a bill can be suppressed:
Find out which customer segments the bill's account belongs to by checking the PIN_FLD_CUSTOMER_SEGMENT_LIST field in the /account object.
Check the PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES field of the appropriate customer segment in the /config/suppression object.
Note:
If an account belongs to more than one customer segment, the lowest PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES value associated with the segments applies.
If an account belongs to no customer segments, the PIN_FLD_MAX_SUPPRESSED_BILL_CYCLES value of the default customer segment (ID 0) applies.
If an account belongs to no customer segments and your system has no default customer segment, the bill can be suppressed for an unlimited number of consecutive cycles.
To determine the current number of consecutive billing cycles for which a bill has been suppressed, check the PIN_FLD_NUM_SUPPRESSED_CYCLES field of the /billinfo object.
Unsuppress an account immediately or on a specified future date. To do this, call the PCM_OP_BILL_SET_ACCOUNT_SUPPRESSION opcode.
Note:
If a suppression deal was purchased when the account was manually suppressed, the deal's POID must be passed to the FLD_DEAL_OBJ field of the opcode's input flist to cancel the deal.For more information, see "About Manual Account Suppression".
To implement bill suppression, see "Automatically Suppressing Bills" or "Manually Suppressing Bills".
The following opcodes are used to suppress bills and accounts:
PCM_OP_BILL_POL_CHECK_SUPPRESSION. See "How BRM Determines Whether Bills Should Be Suppressed".
PCM_OP_BILL_SET_BILL_SUPPRESSION. See "How BRM Suppresses Bills".
PCM_OP_BILL_SET_ACCOUNT_SUPPRESSION. See "How BRM Suppresses Accounts".
PCM_OP_BILL_REMOVE_ACCOUNT_SUPPRESSION. See "How BRM Ends Manual Account Suppression".
After performing the accounting activities at the end of a bill unit's billing cycle, the PCM_OP_BILL_MAKE_BILL opcode calls the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode to find out whether the bill should be finalized or suppressed. The PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode performs these tasks:
Checks the PIN_FLD_PAY_TYPE field in the input flist to determine if the bill unit is subordinate. If it is, the opcode determines that it should not be suppressed.
From the cached /config/suppression object, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode gets the following information for the customer segment or segments specified in the PIN_FLD_CUSTOMER_SEGMENT_LIST field of the opcode's input flist:
The minimum balance required for the bill to be generated.
The maximum number of consecutive billing cycles for which the bill can be suppressed.
Note:
If the account belongs to multiple customer segments, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode gets the lowest minimum balance and the lowest maximum cycle settings associated with the segments. The lowest settings do not have to be associated with the same customer segment.
If the input PIN_FLD_CUSTOMER_SEGMENT_LIST field contains a customer segment ID that is not associated with suppression information, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode uses bill suppression information associated with the default customer segment (ID 0).
If the input PIN_FLD_CUSTOMER_SEGMENT_LIST field is empty, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode uses bill suppression information associated with the default customer segment (ID 0).
If either of the two preceding items is true and the cached configuration object has no default customer segment or if the object is not in the cache, the bill does not qualify for automatic bill suppression (see "About Automatic Bill Suppression").
The PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode checks whether any of the following is true:
The amount due (PIN_FLD_TOTAL_DUE) on the bill is less than the minimum balance specified in the customer segment.
Note:
This check is not done on bills that do not qualify for automatic bill suppression. See step 2.The account is suppressed.
When an account is manually suppressed, the PIN_FLD_ACCT_SUPPRESSED field in each /billinfo object associated with the account is set to 1. This value is put in the PIN_FLD_ACCT_SUPPRESSED field of the opcode's input flist.
The number of remaining manually suppressed billing cycles is greater than 0.
This value comes from the PIN_FLD_SUPPRESSION_CYCLES_LEFT field of the /billinfo object.
The PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode makes one of the following determinations:
If none of the preceding conditions is true, the bill should not be suppressed.
If at least one is true, the bill should be suppressed.
If the bill should be suppressed, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode checks for any exceptions to that suppression.
Note:
For a list of default exceptions, see "Exceptions to Bill Suppression".
To add or delete exceptions, see "Customizing Bill Suppression Exceptions".
To check for exceptions, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode gets and uses the following information:
Adjustment events associated with the bill's account. If an adjustment occurred after the last bill was generated, the bill must be finalized.
Note:
In addition to adjustment events, if the payment received exception is in effect, the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode gets payment events associated with the account. In such cases, if a payment was received after the last bill was generated, the bill must be finalized. By default, this exception is commented out of the opcode. To uncomment it, see "Adding Bill Suppression Exceptions".The value in the input flist PIN_FLD_NUM_SUPPRESSED_CYCLES field, which indicates for how many consecutive billing cycles, the bill has been suppressed. If the value is equal to the maximum number specified in the customer segment, the bill must be finalized. See "Associating Bill Suppression Information with Customer Segments".
Note:
If the maximum number of consecutive billing cycles for which the bill can be suppressed is 0 or missing (see step 2), this exception does not apply, and the bill can be suppressed for an unlimited number of consecutive billing cycles.The value in the input flist PIN_FLD_LAST_BILL_OBJ field. If NULL, it means that this is the bill unit's first bill and it must be finalized.
The value in the PIN_FLD_STATUS field in its input flist. If the value indicates that the status of the bill's account is closed, this is the bill unit's last bill and it must be finalized.
The PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode then makes one of the following determinations:
If an exception exists, the bill cannot be suppressed.
If no exception exists, the bill can be suppressed.
The PCM_OP_BILL_POL_CHECK_SUPPRESSION output flist contains the values listed in Table 10-4. PCM_OP_BILL_MAKE_BILL uses these values to determine whether the bill should be suppressed or finalized:
Table 10-4 Output Flist for PCM_OP_BILL_POL_CHECK_SUPPRESSION
| Output Flist Field | Value | Meaning |
|---|---|---|
|
PIN_FLD_RESULT |
0 |
Bill should not be suppressed. |
|
PIN_FLD_RESULT |
1 |
Bill's balance is below the minimum required to finalize it, so bill should be automatically suppressed. |
|
PIN_FLD_RESULT |
2 |
Bill is manually suppressed. |
|
PIN_FLD_RESULT |
3 |
Account is manually suppressed. |
|
PIN_FLD_EXCEPTION |
0 |
No exception. |
|
PIN_FLD_EXCEPTION |
1 |
Payment, adjustment, or credit exception. |
|
PIN_FLD_EXCEPTION |
2 |
First bill exception. |
|
PIN_FLD_EXCEPTION |
3 |
Closed account exception. |
|
PIN_FLD_EXCEPTION |
4 |
Maximum cycle exception. |
All types of bill suppression can be overridden by exceptions. For more information about the exceptions, see "Exceptions to Bill Suppression".
The PCM_OP_BILL_SET_BILL_SUPPRESSION policy opcode handles manual bill suppression. See "About Manual Bill Suppression".
This opcode performs the following tasks:
Suppresses a bill for a specified number of billing cycles.
If the opcode's input flist PIN_FLD_SUPPRESSION_CYCLES_LEFT field contains a value greater than 0, the opcode sets the PIN_FLD_SUPPRESSIOIN_CYCLES_LEFT field in a specified /billinfo object with that value.
This value represents the number of consecutive billing cycles for which the bill is to be suppressed. At the end of each billing cycle, PCM_OP_BILL_MAKE_BILL subtracts 1 from this value in the /billinfo object. When the value reaches 0, bill suppression ends.
Unsuppresses a manually suppressed bill.
If the PIN_FLD_SUPPRESSIOIN_CYCLES_LEFT field in a /billinfo object contains a value greater than 0, the bill is manually suppressed for the specified number of billing cycles. To end the suppression early, call PCM_OP_BILL_SET_BILL_SUPPRESSION, specify the appropriate /billinfo object in the input PIN_FLD_POID field, and set the input PIN_FLD_SUPPRESSION_CYCLES_LEFT field to 0.
Generates an /event/audit/suppression/bill object each time it suppresses or unsuppresses a bill.
The PCM_OP_BILL_SET_ACCOUNT_SUPPRESSION opcode suppresses an account immediately or on a specified future date. See "About Manual Account Suppression".
This opcode performs the following tasks:
Inactivates all services and products associated with the account specified in the PIN_FLD_POID field of its input flist.
Optionally purchases an account-level deal for the account.
The deal POID must be specified in the PIN_FLD_DEAL_OBJ field of the opcode's input flist. It is the only active deal that can be associated with a suppressed account. You can use it to handle any purchase and cycle fees that you want to charge for suppressing the account.
In each /billinfo object associated with the account, sets the PIN_FLD_ACCT_SUPPRESSED field to 1.
Generates an /event/audit/suppression/account/on object.
To suppress the account on a future date, set the PIN_FLD_END_T field in the PCM_OP_BILL_SET_ACCOUNT_SUPPRESSION input flist to the appropriate date. When a date is specified in this field, the opcode schedules a call to itself on that date.
The PCM_OP_BILL_REMOVE_ACCOUNT_SUPPRESSION opcode ends manual account suppression immediately or on a specified future date.
This opcode performs the following tasks:
Removes any suppression deal associated with the account.
Reactivates all services and products associated with the account specified in the PIN_FLD_POID field of its input flist.
In each /billinfo object associated with the account, sets the PIN_FLD_ACCT_SUPPRESSED field to 0.
Generates an /event/audit/suppression/account/off object.
To end account suppression on a future date, set the PIN_FLD_END_T field in the PCM_OP_BILL_REMOVE_ACCOUNT_SUPPRESSION input flist to the appropriate date. When a date is specified in this field, the opcode schedules a call to itself on that date.
To manage bill suppression exceptions in your BRM system, customize the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode to perform these tasks:
Deleting Bill Suppression Exceptions
Important:
To perform these tasks, you should be familiar with the following topics:C or C++ programming
The Portal Communication Module (PCM) application programming interface (API)
The Portal Information Network (PIN) library
See "Understanding the PCM API and the PIN Library" in BRM Developer's Guide.
Before reading this section, read "Exceptions to Bill Suppression".
To add a bill suppression exception to your system:
In the fm_bill_pol_check_suppression.c file, make the appropriate modifications to these functions:
fm_bill_pol_get_suppression_reason
This function checks both for reasons to suppress a bill and for exceptions that override reasons to suppress.
fm_bill_pol_get_payment_adjustment_event
If the new exception is based on an event, add the appropriate event class to the eventsBuf array in this function:
char eventsBuf[2000] = "'/event/billing/adjustment/account',\
'/event/billing/refund/cash','/event/billing/refund/cc',\
'/event/billing/refund/check','/event/billing/refund/dd',\
'/event/billing/refund/payorder','/event/billing/refund/postalorder',\
'/event/billing/refund/wtransfer','/event/billing/reversal/cc',\
'/event/billing/reversal/check','/event/billing/reversal/dd',\
'/event/billing/reversal/payorder',\
'/event/billing/reversal/postalorder',\
'/event/billing/reversal/wtransfer'";
/***********************************************************
* Payment exceptions are being commented/taken out of the
* eventBuf buffer. If required these event ids can be
* included into the buffer in order to consider the payment
* exceptions.
***********************************************************/
/*'/event/billing/payment/cash',\
'/event/billing/payment/cc','/event/billing/payment/check',\
'/event/billing/payment/dd','/event/billing/payment/payorder',\
'/event/billing/payment/postalorder',
'/event/billing/payment/wtransfer'*/
Note:
By default, the payment-received suppression exception is commented out of the preceding code and is thus disabled. To enable it, remove the comment symbols (/* and */) enclosing the payment events.In the BRM_Home/include/pin_bill.h file, add the appropriate enumerated name and value to the bill_suppression_exceptions variable:
typedef enum bill_suppression_exceptions {
PIN_NO_EXCEPTION = 0,
PIN_DUE_TO_PAYMENT_ADJUSTMENT_MADE = 1,
PIN_DUE_TO_FIRST_BILL = 2,
PIN_DUE_TO_ACCOUNT_CLOSED = 3,
PIN_DUE_TO_MAX_ALLOWED_SUPPRESSION_COUNT_REACHED = 4
} bill_suppression_exceptions_t;
Do not duplicate a value, and do not delimit the last name-value pair with a comma. If you add a name-value pair to the end of the existing list, add a comma to the end of the preceding name-value pair.
The values are used to populate the PIN_FLD_EXCEPTION field of the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode's output flist.
To delete a bill suppression exception from your system:
In the fm_bill_pol_check_suppression.c file, delete or comment out the appropriate code in these functions:
fm_bill_pol_get_suppression_reason
This function checks both for reasons to suppress a bill and for exceptions that override reasons to suppress.
Caution:
Do not remove logic used by processes that check for other exceptions.fm_bill_pol_get_payment_adjustment_event
If the deleted exception is based on an event, remove the appropriate event class from the eventsBuf array in this function:
char eventsBuf[2000] = "'/event/billing/adjustment/account',\
'/event/billing/refund/cash','/event/billing/refund/cc',\
'/event/billing/refund/check','/event/billing/refund/dd',\
'/event/billing/refund/payorder','/event/billing/refund/postalorder',\
'/event/billing/refund/wtransfer','/event/billing/reversal/cc',\
'/event/billing/reversal/check','/event/billing/reversal/dd',\
'/event/billing/reversal/payorder',\
'/event/billing/reversal/postalorder',\
'/event/billing/reversal/wtransfer'";
/***********************************************************
* Payment exceptions are being commented/taken out of the
* eventBuf buffer. If required these event ids can be
* included into the buffer in order to consider the payment
* exceptions.
***********************************************************/
/*'/event/billing/payment/cash',\
'/event/billing/payment/cc','/event/billing/payment/check',\
'/event/billing/payment/dd','/event/billing/payment/payorder',\
'/event/billing/payment/postalorder',
'/event/billing/payment/wtransfer'*/
In the BRM_Home/include/pin_bill.h file, delete or comment out the appropriate enumerated name and value from the bill_suppression_exceptions variable:
typedef enum bill_suppression_exceptions {
PIN_NO_EXCEPTION = 0,
PIN_DUE_TO_PAYMENT_ADJUSTMENT_MADE = 1,
PIN_DUE_TO_FIRST_BILL = 2,
PIN_DUE_TO_ACCOUNT_CLOSED = 3,
PIN_DUE_TO_MAX_ALLOWED_SUPPRESSION_COUNT_REACHED = 4
} bill_suppression_exceptions_t;
If you remove the last name-value pair, also remove the comma at the end of the preceding name-value pair.
The values are used to populate the PIN_FLD_EXCEPTION field of the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode's output flist.