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 divisions for each state AND you have financial services related customers in each state, you must define Customer Class Controls for each division in respect of the financial services related customer class. Open Admin Menu, Customer Class, Controls tab to maintain this information.

Description of Page

The Customer Class Controls scroll contains business rules governing accounts that belong to a Division and Customer Class. The following fields should be defined for each 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 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 division).
Use Immediate Refund to indicate whether you want to process immediate refund for the accounts which belong to the customer class.

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.

CAUTION: These algorithms are typically significant system processes. The absence of an algorithm may prevent the system from operating correctly.

The following table lists and describes the system events to which you can attach algorithms in a customer class:
System Event	Optional / Required	Description
Autopay 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. Click here to see the algorithm types available for this system event.
Bill Cancel	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. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
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 in no information linked to the bill. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
Bill Segment Information	Optional	When a customer class has an algorithm associated with this system event, the algorithm is called when a bill segment is generated. This algorithm generates the bill segment information string, which appears on the bill. It concatenates the fields and delimiters specified as parameters in the algorithm. You can maintain separate bill segment information string for each type of bill (i.e. customer class), such as individual bill, list bill, and SAP bill.
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. Click here to see the algorithm types available for this system event.
Late Payment Charge 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. CAUTION: Just because an account's customer class allows late payment charges to be calculated doesn't mean the account's delinquent contracts will be levied late payment charges. In addition, a delinquent contract's contract type must reference a late payment charge algorithm. Refer to Contract Type - Main for more information about contract 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 / division combination. Click here to see the algorithm types available for this system event.
Levy an 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 / division combination. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
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 / division combination. Click here to see the algorithm types available for this system event.
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 / division combination. Click here to see the algorithm types available for this system event.
Payment Cancellation	Optional	Algorithms of this type are called when a payment is canceled. Click here to see the algorithm types available for this system event.
Payment Distribution	Required	This algorithm is called to distribute a payment amongst an account's contracts. 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 / division combination. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
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 contracts. 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. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.
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. Click here to see the algorithm types available for this system event.