Periodic Meters
A periodic meter has a periodic cycle and a separate value accrues for each period. Similar to balances, periodic meters can have credit limits and thresholds.
Each interval in a periodic meter is identified by an ID and is valid for a different period of time. Each interval can also contain a different amount. This is unlike simple meters, where the entire meter contains one amount.
A periodic charge meter can have a different period than the type of charge it measures (for example, you can have a daily meter for charges to a monthly balance).
You can configure a meter period to close at a configurable interval after the period ends. The interval is the same as the interval between the end of a bill cycle period and when the bill cycle closes and the same as the interval between when a day ends and the close of GL for the day. The interval can be specified in the configuration question Global:How long (in minutes) should period termination be delayed?. The default value in minutes is 240 (4 hours). The maximum value in minutes is 1320 (22 hours).
After a meter period closes, there are no further updates to it. Any usage or charges received after the period closes that would have impacted that period are applied to the current period. Configure the delay interval so that it is large enough to avoid this situation.
SubMan balance queries include a field, HasPeriodClose, in the
MtxPricingBalanceDetailInfo MDC that indicates if periods close after the period ends.
Subscribers can have any number of periodic meters in their wallets and each meter can span a different period. For example, a subscriber can have a daily minutes meter, a weekly minutes meter, and a monthly minutes meter. All periodic meters use the time zone of the subscriber or group, if defined, to determine the start date and time. Days are treated as 24-hour periods, +/- daylight savings time. If the subscriber or group time zone is not defined, the system time zone is used.
For more information about using rate tags in meter filters, see the discussion about filters.
Events
When a meter period closes, an MtxMeterPeriodCloseEvent Event Detail Record (EDR) is generated. The EDR shows the period start and end time, the amount in the meter at the time of the close, and generates the resource ID of the meter. For more information about the MtxMeterPeriodCloseEvent EDR, see MATRIXX Integration.
Updates to periodic meters that close are shown in the
BalanceUpdateArray in EDRs, not in the meter update array. The
BalanceUpdateArray has a separate element for each individual
balance instance, and each individual cycle period of a periodic balance (if the
event impacts more than one period). The elements for periodic balances include the
period start and end time and the interval ID. Each element includes the current
gross value of the balance.
BalanceUpdateArray include the same information that is
included for balances, including the current value of the meter (absolute value).
Separate records are generated in the EDR for each meter instance and for each
period impacted (if an event impacts multiple periods). The Flags
field value Is Meter indicates when the
BalanceUpdateArray entry is a meter. MeterUpdateArray is part of the primary event definition
and is always included in the EDR for the event initiator. For meters with
periods that close, updates are included in the
BalanceUpdateArray of the EDR for the wallet owning the
meter, which could be a secondary event. In a group hierarchy, if the current
meter period is used for the event initiator, then in the parent groups in the
hierarchy the current period is also impacted. Because subscribers and groups in a hierarchy might not have the same time zone, the meter period matching the time of usage or a charge might still be open even if it has closed in a parent group. Therefore, the current period is used if the period for the usage or charge time has closed for either the event initiator or any group above it in the hierarchy.
For more information about primary and secondary events and EDRs, see the discussion about EDR contents in MATRIXX Integration.