SQ Algorithm | Algorithm Type | What It Does | Parameters Used |
Bill Credits for Electric Consolidated Billing | BC | This SQ rule creates a Characteristic Type / Value to handle consolidated billing credits. These values are used by one or more bill factors referenced in the rate components to vary the amount associated with a given bill line. The characteristic type and value are generated if a service provider (SPr) provides consolidated billing for its customer. These credits are applied irrespective of whether the SPr provides full or partial consolidated billing and whether or not the customer takes both gas and electric services. SA Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated. Service Type tells the system the service type associated with electricity (as the characteristic value returned differs for electric-only service providers). The Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows: • BR Dual Commodity Value if the SPr provides bill ready consolidation for more than one service • BR Electric Only Value if the SPr provides bill ready consolidation for electric only • RR Dual Commodity Value if the SPr provides rate ready consolidation for more than one service • RR Electric Only Value if the SPr provides rate ready consolidation for electric only | Param 1 = SA Relationship Type Param 2 = Service Type for Electric Param 3 = Characteristic Type - Billing Credit Param 4 = Characteristic Value - BR Dual Commodity Value Param 5 = Characteristic Value - BR Electric Only Value Param 6 = Characteristic Value = RR Dual Commodity Value Param 7 = Characteristic Value = RR Electric Only Value |
Bill Credits for Gas Consolidated Billing | CT | This SQ rule creates a characteristic type / value if a service provider provides consolidated billing for the customer being billed. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line. The characteristic type and value are generated if a customer's gas service provider (SPr) provides consolidated billing (i.e., the service provider has a billing relationship of " they bill for us "). The Service Type tells the system how to identify gas service. The SA Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated. If the above conditions are true, the Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows: • CTA Credit Residential if the customer class matches the Customer Class for Residential • CTA Credit Non-Residential if the customer class does not match the Customer Class for Residential | Param 1 = Service Type Param 2 = SA Relationship Type Param 3 = Customer Class for Residential Param 4 = Characteristic Type - CTA Credit Param 5 = Characteristic Value - CTA Credit Residential Param 6 = Characteristic Value - CTA Credit Non-Residential |
Bill days (Days) | DY | This SQ rule calculates the total number of days in the bill period. This algorithm is necessary if you have charges that are based on the number of days of service (e.g., a minimum charge that varies based on the days of service). Refer to Calculated Minimum Charges and Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides for good examples of when to use such an SQ rule. | No parameters are used. |
Characteristic Value | CV | This SQ rule creates an entry in the SQ array containing the sum of the characteristic values of a given Characteristic Type. The values are accumulated from the entity defined in the parameter list. Resulting Quantity (expressed in the Output UOM / TOU / SQI) = the sum of the characteristic values of a given Characteristic Type. Characteristic Source determines the entity that holds the characteristic values: • If Characteristic Source is"SA", the characteristic value effective on the bill start date for the Characteristic Type (P1) and SA Id is returned. • If Characteristic Source is "ACCOUNT", the characteristic value effective on the bill start date for the Characteristic Type (P1) and Account Id is returned. • If Characteristic Source is "PREMISE", the characteristic values are accumulated from all premises linked to the SA ID. • If Characteristic Source is "SP", the characteristic values are accumulated from all service points linked to the SA ID. If Minimum Value is greater than zero and the resultant characteristic value is less than the specified Minimum Value, an error is generated. | Param 1 = Characteristic Type Param 2 = Characteristic Source Param 3 = Minimum Value |
Check Load Factor | LF | This SQ rule generates a To Do entry if a customer's actual demand exceeds a fixed demand amount (and actual kWh exceeds a calculated kWh ). The actual algorithm is as follows: Retrieve maximum demand from SQ collection as the greatest of kW/Peak, kW/Part Peak and kW/Off-Peak. If this maximum demand <= Threshold Maximum Demand, escape the routine. If this maximum demand > Threshold Maximum Demand: • Compute 'Calculated kWh' = Threshold Maximum Demand * total days in bill period, times 24. • If Actual kWh/'Calculated kWh' > 1, create a To Do Entry (using the To Do Type and To Do Role (if specified)). The base package includes the To Do Type LF to use for this parameter value, unless you've set up your own. | Param 1 = UOM of demand (e.g., KW) Param 2 = TOU of peak period Param 3 = TOU of off-peak period Param 4 = TOU of part peak period Param 5 = UOM of actual KWH (e.g., KWH) Param 6 = Threshold maximum demand Param 7 = To Do Type Param 8 = To Do Role (optional) |
Consumption History | CH | This SQ rule adds an entry in the SQ array that contains a given amount of historical consumption. This algorithm can return MAX (maximum), MIN (minimum), SUM (total) or AVG (daily average) consumption as defined by the Operator. It retrieves this consumption from the SA's historical bill segments (from the service quantities that are stored on the bill segments). UOM / TOU / SQI define the type of historical consumption that is retrieved. The historical period whose consumption is accessed is defined by EITHER: • Number of Historical Periods (a period is defined by the rate schedule's frequency) or • The previous historical season (defined by Start Month/Day and End Month/Day). PLEASE SPECIFY EITHER OF THE ABOVE PARAMETERS. Note. If the system finds historical bills with a period outside the normal period for the rate's frequency, proration takes place if the input UOM does not Measure Peak. The algorithm accesses consumption data starting from the most recent bill going backwards. As soon as an irregular bill period is encountered, the system attempts to determine appropriate consumption for a "normal" period by prorating the irregular bill based on actual data from previous bills. For example, if historic bills for a monthly rate cover § Jan 1 - Feb 1 • § Feb 1 - Mar 1 • § Mar 1 - Mar 15 When the next bill is generated, the system attempts to calculate the historic consumption going backwards. It will determine consumption for Feb 15 - Mar 15 by taking the consumption for the March bill and adding consumption the time from Feb 15 to Mar 1 by prorating the consumption on the February bill. Then, it attempts to determine consumption for Jan 15 - Feb 15 by taking the remaining consumption for February and adding consumption from the time from Jan 15 to Feb 1 by prorating the consumption on the January bill, etc. Once enough historical bills have been processed, any days "leftover" from the earliest bill as a result of this proration logic are simply ignored. If the input UOM measures peak, no proration of historical quantities occurs. If no UOM is specified as input (i.e., only an SQI), the system assumes that the quantity should behave as if it does not measure peak. | Param 1 = Season Start Month / Day (MM/DD) Param 2 = Season End Month / Day (MM/DD) Param 3 = Number of Historical Billing Periods Param 4 = UOM Param 5 = TOU Param 6 = SQI Param 7 = Operator |
Contract Quantity | CQ | This SQ rule is used to create an entry in the SQ array for a given Contract Quantity Type specified in a SA. If multiple values are effective during a bill period, the Proration Rule determines what happens. (See below). Resulting Quantity (expressed in the Output UOM / TOU / SQI) = the value of a given Contract Quantity Type in a SA. If multiple values are effective during a bill period the Proration Rule determines what happens: • If Proration Rule is 'Use Contract Quantity effective at Beginning of Bill Period' (i.e., CQBD ), SQ Amount = Contract Quantity effective at the start of the bill period. • If Proration Rule is 'Use Contract Quantity effective at End of Bill Period' (i.e., CQED ), SQ Amount = Contract Quantity effective at the end of the bill period. • If Proration Rule is 'Maximum' (i.e., CQMA ), SQ Amount = largest Contract Quantity effective in the bill period. • If Proration Rule is 'Minimum' (i.e., CQMI ), SQ Amount = smallest Contract Quantity effective in the bill period. • If Proration Rule is 'Prorate' (i.e., CQPR ), SQ Amount = Sum of all prorated contract quantities (calculate the number of days in the bill period (X); calculate the number of days in the bill period that each contract quantity is effective (Y(i)); prorate each contract quantity (i) = (Contract Quantity(i) * Y(i) /X)). | Param 1 = Contract Quantity Type Param 2 = Proration Rule: CQBD, CQED, CQMA, CQMI, CQPR |
Direct Access Credits | CD | This SQ rule creates a characteristic type / value to handle credits issued to the customer for participating in direct access. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line. This rule always creates a characteristic type equal to Characteristic Type DA Credit. The characteristic value will be set as follows: • If the service agreement being billed has a service agreement relationship with either the ESP Relationship Type or the CTA Relationship Type, a characteristic value of Characteristic Value - DA Customer will be created. • If not, a characteristic value of Characteristic Value - Non DA Customer will be created. | Param 1 = ESP Relationship Type Param 2 = CTA Relationship Type Param 3 = Characteristic Type - DA Credit Param 4 = Characteristic Value - DA Customer Param 5 = Characteristic Value - Non DA |
Early Pay | EP | This SQ rule is only used if you provide customers with early payment discounts via a discount on their next bill segment. This rule works as follows: • First, it determines if the prior bill segment's bill was paid before its due date. It does this by retrieving the customer's balance as of the prior bill's due date - 1 day. If this amount is <= zero, it checks if a payment exists with a payment date on or after the bill's bill date and before the bill's due date. If yes, processing continues. • A characteristic type / value is created where the value holds the number of days early (and the characteristic type is equal to Char Type - Number of Days Early). • In addition, this routine accumulates the sum of the bill lines on the prior bill segment for which the early payment discount is eligible. It does this by accumulating all bill lines that reference a given characteristic type and value (where characteristic type is equal to Char Type - Eligible For Early Pay Disc, and Char Value - Eligible For Early Pay Disc). It populates the total amount in the service quantity defined on the SQ rule. This means that you must define this characteristic type / value on each rate component whose resultant value is eligible to receive an early payment discount. This rules anticipates the early pay discount being levied using two rate components: • The first would be an FCPO rate component that holds the amount eligible to receive the discount. This would be an SQ rate component where the service quantity is the value produced by this SQ rule, and the price would be 1 (or -1). In addition, this rate component would need eligibility rules so that it is only applied if the number of days early (held in the characteristic type / value produced by this algorithm) is > 0. • The second would be an "apply to" rate component (where the apply to value is a percentage applied to the first rate component). In addition, this rate component would need eligibility rules so that it is only applied if the number of days early is within a certain tolerance (e.g., > 0). You could create several of these types of rate components if the discount percent differs based on the number of days early. | Param 1 = Char Type - Number of Days Early Param 2 = Char Type - Eligible For Early Pay Disc Param 3 = Char Value - Eligible For Early Pay Disc |
Mathematical Functions | MA | This SQ rule performs mathematical functions on service quantities prior to rate application. There are three major groups of parameters: 1) Quantity 1 (identified by a service quantity's UOM/TOU/SQI). 2) Mathematical operand 3) Quantity 2 (identified by a service quantity's UOM/TOU/SQI or a Bill Factor) For example, if you want to add together two SQ entries, these values would contain: 1) the unique identifier of one of the SQ's (in parameters 1 through 3) 2) the "+" symbol (in parameter 4) 3) the unique identifier of the other SQ (in parameters 5 through 7) It should be stressed that Quantity 2 can either reference a bill factor (param 8) or an SQ entry (parameters 5 through 7). If both are specified, the bill factor is used. The two default values (param 9 and param 10) are only used if Quantity 1 and/or Quantity 2 reference SQ's / bill factor that are not present at billing time. There are three ways to use these default values: - If you want to multiply a SQ by a constant value, define the SQ in Quantity 1 and the constant value in Param 10, i.e., you don't have to specify anything in Param's 5 through 8. - If you want a default value used if the system cannot find a SQ that matches the UOM/TOU/SQI, define this value in Param 9 and/or Param 10. - If you use a bill factor to define Quantity 2 (in Param 8) and you want a default value used if the system cannot find a char type / value for a specific customer, the default value is defined in Param 10. The following mathematical operands use only Quantity 1. ABS, NEGATE, ROUND, FLOOR (meaning to round down), CEILING (meaning to round up), SIN, ASIN, COS, ACOS, TAN, ATAN, LOG, LOG10, EXP, EXP10, SQRT The following mathematical operands use both Quantity 1 and Quantity 2: +, -, *, /, **, MOD, <, <=, >, >=, =, <>, MAX, MIN, AVG The following mathematical operands use both Quantity 1 and Quantity 2 and return a value of 1 if the comparison is true and a value of 0 if the comparison is false: <, <=, >, >=, =, <> | Quantity 1: Param 1 = UOM of service quantity entry Param 2 = TOU of service quantity entry Param 3 = SQI of service quantity entry Or Param 9 = Decimal number Mathematical Operand: Param 4 = operand symbol (i.e., +, -, *, /) Quantity 2: Param 5 = UOM of service quantity entry Param 6 = TOU of service quantity entry Param 7 = SQI of service quantity entry Or Param 8 = Bill factor ID Or Param 10 = Decimal number |
Maximum Service Quantity | MQ | This SQ rule compares a quantity (either measured or created via a previous SQ rule) against a contract quantity and returns whichever is larger. Resulting Quantity (expressed in the Output UOM / TOU / SQI) = greater of quantity for UOM / TOU / SQI OR service agreement quantity for Contract Quantity Type | Param 1 = UOM Param 2 = TOU Param 3 = SQI Param 4 = Contract Quantity Type |
Meter Ownership | MO | This SQ rule returns SQI = number of meters that are not owned by the company per day. It applies if a service provider owns a direct access customer's meter or a customer owns its own meter. The system expects an SA Relationship to exist with the Meter Ownership/Services Relationship Type. If a Relationship exists where the service provider is a third party, the number of meters linked to this SA is counted and returned. | Param 1 = Meter Ownership/Services Relationship Type |
Meter Service Credits | MD | This SQ rule creates a characteristic type / value to handle credits issued to the customer because a customer's meter is read by a 3rd party service provider. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line. It applies if a service provider (SPr) provides meter reading services for its customer. These credits are applied irrespective of whether or not the customer takes both gas and electric service and the method the SPr uses to read the meter. Meter Reading Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated. Service Type tells the system the service type associated with electricity (as the characteristic value returned differs for electric-only service providers). The Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows: • MDMA Dual Commodity Value if the ESP provides meter reading for more than one service • MDMA Electric Only Value if the ESP provides bill ready consolidation for electric only | Param 1 = Meter Reading Relationship Type Param 2 = Service Type for Electric Param 3 = Characteristic Type - MDMA Credit Param 4 = Characteristic Value - MDMA Dual Commodity Value Param 5 = Characteristic Value - MDMA Electric Only Value |
Number of Meters | NM | This SQ rule calculates the number of meters (actually service points) linked to the service agreement. | No parameters are used |
Power Factor | PF | This SQ rule calculates power factor. It will also create a To Do entry if the resultant power factor exceeds a user-defined threshold value. Resulting Quantity (expressed in the Output UOM / TOU / SQI) = Average Power Factor Percentage (N3 format, no decimals) = COSINE (ARCTANGENT (value of UOM4/TOU5/SQI6 / value of UOM1/TOU2/SQI3)) * 100 If the calculated power factor exceeds Power Factor Threshold Percent, a To Do entry is created (using the To Do Type and To Do Role). The base package includes the To Do Type PF to use for this parameter value, unless you've set up your own. | Service Quantity ID of kWh • Param 1 = UOM1 • Param 2 = TOU1 • Param 3 = SQI1 Service Quantity ID of kVarh • Param 4 = UOM2 • Param 5 = TOU2 • Param 6 = SQI2 Param 7 = To Do Type Param 8 = To Do Role Param 9 = Power Factor Threshold Percent |
Required UOM/TOU Validation | PF | This SQ rule verifies if one UOM/TOU quantity is non-zero then the other should be non-zero too. UOM1/TOU1/SQI1 is the ID of the first SQ entry. UOM2/TOU2/SQI2 is the ID of the second SQ entry. | Service Quantity ID1 • Param 1 = UOM1 • Param 2 = TOU1 • Param 3 = SQI1 Service Quantity ID2 • Param 4 = UOM2 • Param 5 = TOU2 • Param 6 = SQI2 |
Season Days | SD | This SQ rule is used to create an entry in the SQ array that contains the number of days in the current bill period that fall in a defined season. Resulting Quantity (expressed in the Output UOM / TOU / SQI) = number of days in the current bill period that fall in Season Start and Season End. For example, if bill period = 03/15/99 to 04/15/99 and Season Start date = 04/01 and Season End date = 10/31, then resulting quantity = 15. | Param 1 = Season Start (MMDD) Param 2 = Season End (MMDD) |
Seasonal Usage | SU | This SQ rule is responsible for taking a non-seasonal UOM/TOU/SQI and producing a seasonal UOM/TOU/SQI, depending on the bill period. For example, if you have a meter which only measures on and off peak consumption, but a rate that bills for summer on peak and summer off peak consumption, then this rule will be used. Resulting value = value of UOM1/ TOU1/ SQI1 * (value of UOM2/ TOU2/ SQI2 / value of UOM3/ TOU3/ SQI3) | Normal consumption Param 1 = UOM1 Param 2 = TOU1 Param 3 = SQI1 Number of days in the season Param 4 = UOM2 Param 5 = TOU2 Param 6 = SQI2 Number of days in the billing period Param 7 = UOM3 Param 8 = TOU3 Param 9 = SQI3 |
Sum | SM | This SQ rule adds up several quantities (either measured or created via a previous SQ rule). This algorithm would be useful when you need to add together "time-of-use" registers because there are charges in the rate that are for the total amount of consumption regardless of when it was used. Resulting Quantity (expressed in the Output UOM / TOU / SQI) = Quantity for UOM (in param 1) TOU (in param 2) SQI (in param 3) + Quantity for UOM (in param 4) TOU (in param 5) SQI (in param 6) + Quantity for UOM (in param 7) TOU (in param 8) SQI (in param 9) | Quantity 1 Param 1 = First UOM Param 2 = First TOU Param 3 = First SQI Quantity 2 Param 4 = Second UOM Param 5 = Second TOU Param 6 = Second SQI Quantity 3 Param 7 = Third UOM Param 8 = Third TOU Param 9 = Third SQI |