Customer Class - Controls
You must define a variety of business rules for every division in which a customer class has customers. For example, if you operate in both California and Nevada AND you have CIS divisions for each state AND you have residential customers in each state, you must define Customer Class Controls for each CIS division in respect of the residential customer class. Open Admin > Customer > Customer Class > Search and then navigate to the Controls page to maintain this information.
Description of Page
The Customer Class Controls scroll contains business rules governing accounts that belong to a CIS Division and Customer Class. The following fields should be defined for each CIS Division:
• Use Days Till Bill Due to define the number of days after the bill date that the customer's bill is due. If the due date is a weekend or company holiday, the system will move the due date forward to the next workday (using the workday calendar defined on the account's CIS division).
• Specify the Budget Plan that defaults onto new accounts belonging to this customer class. Please note that an account's budget plan may be subsequently modified if the account has special budget processing needs. Refer to Setting Up Budget Plans for more information.
• Use Min Credit Review Freq (Days) to define the maximum number of days that can elapse between the reviews of an account's debt by the account debt monitor. Note, a value of zero ( 0 ) means that accounts in this customer class will be reviewed every day.
• Use Credit Review Grace Days to define the number of days after the bill due date that an account should be reviewed by the account debt monitor.
• Turn on the Late Payment Charge if customers in the class / division combination are eligible for late payment charges.
• Use LPC Grace Days to define the number of days after a bill's due date that a late payment charge will be generated (if the various LPC algorithms allow such - refer to How Late Payment Charges Get Calculated for the details). If the grace date falls on a weekend or holiday, the system moves the grace date to the next available workday (using the workday calendar defined on the account's CIS division).
• Specify an Access Group to default an access group onto an account based on the account’s CIS Division and customer class. This will override the access group defaulted from the user’s default access group. Note: the access group defined here will not apply if a Customer Class Control - Determine Access Group algorithm is defined and successfully returns an access group.
The grid that follows contains Algorithms that control important functions in the system. You must define the following for each algorithm:
• Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
• Specify the Sequence and Algorithm for each system event. You can set the Sequence to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
Warning: 
These algorithms are typically significant system processes. The absence of an algorithm may prevent the system from operating correctly.
You can define algorithms for the following System Events:
System Event
Optional / Required
Description
Auto Pay Amount Over Limit
Optional
This algorithm is called to handle the situation when a system-initiated automatic payment is created that exceeds the customer's maximum withdrawal limit. Specifically, this algorithm is called when:
- The account has a maximum withdrawal limit on their automatic payment options
- The system attempts to create an automatic payment that exceeds this amount
- The automatic payment algorithm that's plugged into the installation record has logic that invokes this algorithm when the above conditions are true
If you do not plug-in this type of algorithm and the above situation is detected, the automatic payment will be created and no error will be issued.
Refer to How To Implement Maximum Withdrawal Limits for more information.
Bill Completion
Optional
When a bill for an account is completed, bill completion algorithms are called to do additional work.
Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process.
Bill Eligibility
Optional
Algorithms for this plug-in spot are called when generating a bill in batch billing. It provides the ability to determine if an account is ineligible for billing and should therefore be skipped from further processing.
If an eligibility algorithm is not used, a bill is created for any account in the open bill cycle and is later deleted by the billing process if it detects that there is no information linked to the bill.
Bill Segment Freeze/Cancel
Optional
When a bill segment for an account in this customer class / division is frozen or canceled, an algorithm of this type may be called to do additional work.
Refer to Bill Segment Lifecycle for more information about freezing and canceling bill segments.
Cancel Bill
Optional
This algorithm provides the ability to include additional cancel logic when canceling online.
Algorithms of this type can be called in two modes: D (Determine Bill Page Buttons) and X (Cancel Bill). Mode 'D' governs whether an action button to cancel the bill will appear on the Bill page and mode 'X' performs the actual cancellation logic.
Determine Access Group
Optional
When an account is added or an account’s CIS Division or customer class is changed, this plug-in spot can be used to determine the appropriate access group. This plug-in spot allows more complex logic to be defined, such as checking the access group on the main person’s others account’s.
If a determine access group is not used, the access group can be defaulted from the customer class control or the user.
FT Freeze
Optional
When an FT is frozen, this algorithm is called to do additional work.
For example, if you practice Open Item Accounting, you will need such an algorithm to handle the cancellation of match events when a financial transaction is canceled that appears on a match event. Refer to How Are Match Events Cancelled? for more information about cancellation.
LPC Eligibility
Required if the customer class / division is eligible for late payment charges
This algorithm is called by the late payment process to determine eligibility for late payments.
Just because an account's customer class allows late payment charges to be calculated doesn't mean the account's delinquent service agreements will be levied late payment charges. In addition, a delinquent service agreement's SA type must reference a late payment charge algorithm. Refer to SA Type - Main for more information about SA type late payment charge issues. Refer to How Late Payment Charges Get Calculated for more information about late payment charges in general.
Note: 
Only One Algorithm. Only one late payment charge eligibility algorithm may be defined for a customer class / CIS division combination.
Levy NSF Charge
Optional
This algorithm is called when a payment is canceled with a cancellation reason that indicates an NSF.
Refer to NSF Cancellations for more information about what happens when a payment is canceled due to non-sufficient funds.
Note: 
Only One Algorithm. Only one algorithm to levy an NSF charge may be defined for a customer class / CIS division combination.
Order Completion
Optional
When an order is completed for a customer linked to this customer class, this algorithm is called to do additional work (e.g., create a customer contact). You need only specify this type of algorithm if you require additional work to be performed when an order is completed for customers who belong to this customer class.
Overpayment Distribution
Required
When a customer pays more than they owe, this algorithm is called to determine what to do with the excess funds. Refer to Overpayment Segmentation for a description on how to configure the system to handle your overpayment requirements.
Note: 
Only One Algorithm. Only one overpayment distribution algorithm may be defined for a customer class / CIS division combination.
Override Due Date
Optional
An account's bill due date will be equal to the bill date plus its customer class' Days Till Due. If you need to override this method for accounts in a specific customer class, specify the appropriate algorithm here.
Note: 
Only One Algorithm. Only one due date override algorithm may be defined for a customer class / CIS division combination.
Payment Cancellation
Optional
Algorithms of this type are called when a payment is canceled.
Payment Distribution
Required
This algorithm is called to distribute a payment amongst an account's service agreements. Refer to Payment Distribution for more information about how payment distribution works.
Note: 
Only One Algorithm. Only one payment distribution algorithm may be defined for a customer class / CIS division combination.
Payment Freeze
Optional
When a payment is frozen, this algorithm is called to do additional work. If you practice Open Item Accounting, you will need such an algorithm to link the payment's financial transactions to the match event that was originally created when the payment was distributed. Refer to Payments and Match Events for more information.
Post Bill Completion
Optional
When a customer class has algorithms of this type, they are called after the completion of a bill for an account linked to this customer class.
Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process.
Pre Bill Completion
Optional
When a customer class has algorithms of this type, they are called immediately before completion starts for an account linked to this customer class. These algorithms have the potential of:
• Deleting a bill. You might want a pre completion algorithm to delete a bill if a condition is detected that should inhibit the sending of a bill to a customer (e.g., the bill just contains information about recent payments).
• Aborting the completion process and creating a bill exception. If the algorithm indicates this should be done, the bill is left in the pending state and a bill exception is created describing why completion was aborted. You might want a pre completion algorithm to do this if, for example, integrity checks detect there is something wrong with the account or its service agreements. If the integrity check fails, the bill can be left in the pending state and a bill exception created describing why.
Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process.
Quote Completion
Optional
When a quote is completed for a customer linked to this customer class, this algorithm is called to do additional work (e.g., create a customer contact). You need only specify this type of algorithm if you require additional work to be performed when a quote is completed for customers who belong to this customer class.
Write Off Method
Required if you allow users to write-off debt real time using the write off transaction
When a user presses the create button on the write off transaction, this algorithm is executed to write-off the selected debt. Refer to The Ramifications of Write Offs in the General Ledger for more information.