Rate changes into the past: how to do it properly and troubleshooting

Quite often there are situations when there's a need to change rates into the past: a partner not sending rates in time, a failed rate import, a missed import email, etc. While changing a rate by itself is quite simple, when making changes to past periods where rates were already used for billing traffic, you need to ensure that these changes comply with your goals.

Before everything else, it needs to be mentioned that rate changes into the past will affect up to 30 days of past traffic by default, so changes into the past must be done with care. This value is configurable, this will be covered later with other related system settings.

Also, please keep in mind that any changes to the rates into the past are recommended to be made through the Add period button rather than the Edit button, since when using the Edit button and changing the active period of an existing rate, gaps are formed that are not covered by any active rate, hence the billing information for such periods may be lost. 

Let's take a look at how auto-rerating process works. When you make any changes to the rates, they are logged, and once an hour the System checks if any changes were made to the past periods. These changes accumulate, until an hour defined by the system setting EDR rerating hour (default value is 1, which is 01:00), when a TASK is launched, rerating EDRs of the affected period. Note, that this period is limited by the system setting Max rerating interval (default value is 30 - days into the past), rate changes for periods older than defined will be ignored by auto-rerating. One task is created per product. You can check pending and completed tasks in the SMS/EDR management/EDR rerating interface. 

If needed, you can launch a pending task ahead of time from there. Once rerating is finished, prices will be changed in EDRs and it will influence the account's balance.

After EDR rerating, financial data, statistics and analytics will become outdated. The financial cubes will be recalculated after a period of time, depending on the system load. You can check the status of recalculation with the help of SMS Analytical cube status (Administration) report, setting Period filter to Financial

The EDR state and DLR state columns must be reflected as 'Ready' (with the recent timestamp in the Last change column). Note, that financial cubes exceeding period defined in system setting Open financial period, days will not be affected by EDR rerating, including balance and existing invoices.

In case the recalculations affected a period for which invoices are already formed, and you want this change to be reflected in them, you can recalculate period for the account in Start\Finance\Invoices (the Recalculate period button) selecting the partner's account and the affected period. If the period includes already confirmed/registered/sent invoices and they must be affected, please deselect the Keep confirmed invoices flag.

If rate changes were applied to a period beyond the one defined in Max rerating interval, it won't be automatically rerated, so if you want these changes to apply, you need to launch a manual rerating task in the SMS/EDR management/EDR rerating interface. 

This can be done by specifying the details for recalculation and pressing Run button. Please note that more specific settings will help to complete the rerating faster, as the System will check less EDRs.

After that, the process is the same - the financial cubes will be recalculated, and the invoices can be recalculated manually afterwards.

Here's the list of system settings affecting EDR rerating:

  • Max rerating interval: defines the maximum period (in days) affected by the daily auto-rerating procedure. The value cannot be set greater than Active EDR day count. Suppose the parameter is set to 30 days and there is a rate for the period 01/01/2018 00:00:00 - 01/01/2019 00:00:00 (today is 01/01/2019). Suppose the price was changed during the day. When auto rerating starts (defined by EDR rerating hour) the period  02/12/2018 00:00:00 - 01/01/2019 00:00:00 (last 30 days) will be recalculated for the rate.
  • Auto rerate current month only (0 - no, 1 yes): if set to 1, even if the rate change is within the maximum timeframe limits (defined by the Max rerating interval System parameter), the auto rerate task start date will be limited by the start of the current month. The default value is 0. If enabled and the Max rerating interval has been reached (for example, it is set to 2), the past 2 days will be re-rated (given that they both fit into the current month)
  • Maximum rerating job count: the maximum number of simultaneously processed manual EDR rerating subtasks. 0 by default, that is, the optimization is disabled. When set to a positive value, the hidden SMS-RERATING-SPLIT-INTERVAL System parameter must be modified as well. To configure it, contact the technical Alaris support team and communicate the code BZ52841. This parameter is primarily used for optimizing system performance.
     
  • EDR rerating hourthe hour when the daily auto-rerating procedure runs.
  • EDR rerating step (in minutes): default value is 30 minutes which means that during rerating of EDRs for the defined period they will be rerated by portions of 30 minutes.
  • Open financial period, days: defines the period in days within which financial data can be changed in the past (starting from the current date). For example, if the parameter is set to 30 and EDR rerating is performed for a period later than a month ago, it will have no effect on financial data (balance, existing invoices, etc.)
  • Active EDR day count: period during which EDRs can be accessed for various operations (such as rerating, invoice generation etc.).
  • Traffic details days count: number of days to store the financial statistics in the System.

Any rate changes can be tracked using the SMS rate change log (Administration) report in the SMS/Reports interface.

If there's a need to apply changes to the data that isn't available, please, contact Alaris Support and describe the matter in detail.

AKBSMS - Alaris Knowledge Base

Related questions:
Uploading rates into the past
Past rate changes
Analytics recalculation
Rate not applied for past data
Unable to update rate for back date
Retroactively updating vendor prices
Rate import into the past
Difference in past rates
Analytics rates not updated

Link to this article: https://helpdesk.alarislabs.com/en/knowledge_base/article/294/category/138/