Base Package SQ Rules

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