How Rates Affect The Information On Bill Segments

After product's consumption has been compiled, the system applies the contract's rate to the product's consumption to determine how much to charge the customer. We refer to this process as "rate application". Refer to Rates for detailed information about rates.

Rate application is a very sophisticated process as it can affect every aspect of a bill segment. The following points describe how rate application works at a high-level:

• The read details that were amassed earlier are passed into rate application.
• Next, the total amount of each unique unit of measure / Variance Parameter that's referenced on every read detail is summarized in the bill segment's "service quantity (SQ) details".
• Next, the rate schedule's service quantity rules (if any) are executed. Service quantity rules are used to calculate service quantities (SQ) referenced in the rate that cannot be derived from the read details. For example, if you have a rate that has a charge based on the number of days in the bill period, a service quantity rule would be necessary to calculate the number of days in the bill period.
• Next, the system determines which of the rate's rate versions should be processed. Note, a flag on the rate schedule allows you to control what happens if multiple rate versions are detected during the bill period. A bill segment "calculation detail" is created for each such rate version. Each calculation detail contains the results of executing the rate version's rate components (where a separate bill line is created for each rate component). Each bill line contains:
  • An audit of what was priced.
  • How the printed bill line should look (if the bill lines is printed).
  • How the amount of the bill line should be booked in the general ledger.

• After every rate version is processed, rate application returns the calculation details to the process that called it. This point is important as it means that rate application executes in memory (i.e., it does NOT insert the calculation details on the database, rather, it returns them to whatever process called rate application). Because rate application executes in memory, it can be used to perform billing calculations in many parts of the system. For example:
  • Both online and batch billing use rate application to calculate the charges that are eventually saved on the bill's bill segments.
  • The Rate Check transaction calls rate application when you want to check a rate real-time. When you use this transaction, you enter the product's consumption that's passed into rate application and then rate application shows you the calculation details that result.
  • Plug-ins exist that call rate application to estimate bill segments when adequate billing history doesn't exist. For example, the BUDCALC-PH budget recommendation algorithm calls rate application to calculate a budget amount for a customer without adequate history. Another example is the DEPRECOM-MBT deposit recommendation algorithm. This plug-in calls rate application to calculate a recommended deposit amount for a customer without adequate history.