SA Type - Algorithms

Open Admin > Customer > SA Type > Search and navigate to the Algorithm page to define the algorithms that should be executed for service agreements of a given type.

Description of Page

The grid 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 (descriptions of all possible events are provided below).
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 processes. The absence of an algorithm may prevent the system from operating correctly.

The following table describes each System Event for which you can define algorithms.


System Event	Optional / Required	Description
Bill Completion	Optional	These algorithms are executed whenever a bill is completed for an account that contains a non-canceled service agreement of this type. The following situations necessitate the definition of a completion algorithm on an SA type: - As explained under Technical Implementation of A/R Transfer and Technical Implementation of Routing Billable Charges To Service Providers, when a bill is completed, the system needs to set up the data necessary to interface any "master" SA's charges to the service provider and to transfer the receivable balance from the customer to the service provider. The system will only do this if you specify an appropriate algorithm on the master SA types. - As explained under Billing For SAs Covered By The Non-Billed Budget, when a bill is completed for accounts that have a Non-Billed Budget SA, the system needs to distribute the Non-Billed Budget's credit balance to the covered SAs. The system will only do this if you specify an appropriate algorithm on the NBB SA types. - As explained under Overpayment Segmentation, when a bill is completed, the system may apply an excess credit from a prior overpayment to an account's service agreements. Note. Algorithms of this type are called for all non- Canceled service agreements, regardless of whether or not they are billed. If your algorithms should only be processed under certain conditions (for example, only process this algorithm for Active service agreements), then it is the responsibility of the algorithm to check the conditions before continuing.
Bill Eligibility	Optional	These algorithms are executed during billing and allow logic to be introduced to check additional criteria to determine if an SA is eligible for billing.
Break NBB SA	Optional	These algorithms are executed when a Non-Billed Budget is manually stopped via the Non-Billed Budget maintenance page . Note that the Payment Arrangement algorithm and the Break Pay Arrangement algorithm are mutually exclusive.
Break Pay Arrangement	Optional	These algorithms are by executed by severance events when the event is created for payment arrangement SAs. This algorithm should be specified on SA types with a special role of Payment Arrangement to perform special actions that take place when a customer breaks a payment arrangement. Refer to Monitoring Payment Arrangements for more information about breaking payment arrangements.
Budget Eligibility	Optional	These algorithms are executed when determining in a service agreement is eligible for budget. Algorithms of this type are only applicable on SA types that are marked as eligible for budget and may be used to override that setting and indicate that the service agreement is not eligible. For example, maybe service agreements in a certain rate are not eligible. Or perhaps service agreements with a given characteristic value are not eligible.
Cut Process Rule	Optional	These algorithms are executed to create a cut process for service agreements of this type. Refer to The Big Picture Of Cut Processes for more information.
FT Freeze	Optional	These algorithms are executed whenever a financial transaction is frozen that is linked to a service agreement of this type. The following situations necessitate the definition of an FT freeze algorithm: - As explained under Technical Implementation of Routing Consumption To Service Providers, when a master SA's bill segment is frozen, the system must check if there are any service providers who need the bill segment's consumption. If so, it sets up the data necessary to interface the master SA's consumption (snapshot on the bill segment) to the service provider(s). The system will only do this if you specify an appropriate FT Freeze Algorithm on the master SA types. - As explained under Technical Implementation of Paying The Service Provider, when a financial transaction (FT) is frozen that is associated with a sub SA, the system must check if this FT should trigger the "payment" of a service provider. If so, it has to create an adjustment to increase how much we owe the service provider. The system will only do this if you specify an appropriate FT Freeze Algorithm on the sub SA types.
High Bill Amount	Optional	This algorithm type checks for high bill amounts during batch billing. A bill threshold amount can be defined on a service agreement. By default the system compares this threshold amount to the bill segment amount during batch billing. If the bill segment amount exceeds the given threshold value, a bill error is generated. No proration takes place on the threshold amount if the bill segment's consumption period falls outside of the rate frequency's normal period. This algorithm may be used to override the default system behavior. It will prorate the SA's bill threshold amount before comparing it to the batch bill segment amount if the consumption period falls outside of the rate frequency's normal period.
Landlord Reversion	Optional	These algorithms are used to create, update or cancel a service agreement for a landlord when service is started, stopped or updated for a premise that references a landlord agreement. Algorithms of this type are called: - When starting a new SA (start initiation) - When stopping an SA (stop initiation) - When canceling a pending start SA - When changing the stop / start dates of back-to-back service agreements
Loan Interest Charge	Optional	These algorithms are executed whenever the interest charge needs to be calculated for a loan, such as when the loan amortization schedule is created and when a bill segment is created for a loan SA. This algorithm should be specified on SA types with a special role of Loan. Refer to Defining Loan Options for more information.
Loan Periods and Amount	Optional	These algorithms are executed whenever a user clicks the Calculate button on Loan - Main or on the Start SA Confirmation dialog for a loan SA. It calculates either the number of periodic payments or the payment amount (depending on whether the user specifies the number of payments or the payment amount as input). This algorithm should be specified on SA types with a special role of Loan. Refer to Defining Loan Options for more information.
Loan Schedule	Optional	These algorithms are executed whenever the system needs to create a loan amortization schedule for a loan, such as when you renegotiate the terms of a loan on Loan - Main . This algorithm should be specified on SA types with a special role of Loan. Refer to Defining Loan Options for more information.
Override Proration Days	Optional	This algorithm is invoked from rate application, right after base has determined if proration applies. It is used to override base days, normal days and “is within proration window” indicator, which were determined by base logic. Only one algorithm may be plugged-in to this system event. This is available only in the calculation rule based rating engine.
Payment Arrangement	Optional	These algorithms are by executed to handle the creation, breaking and canceling of payment arrangement SAs. This algorithm should be specified on SA types with a special role of Payment Arrangement to perform special actions that take place during the lifecycle of a payment arrangement. Refer to Monitoring Payment Arrangements for more information about payment arrangements. Note that the Payment Arrangement algorithm and the Break Pay Arrangement algorithm are mutually exclusive.
Payment Freeze	Optional	These algorithms are executed whenever a payment is frozen. The following situations necessitate the definition of such an algorithm: - For a loan SA, such an algorithm is required to create a frozen adjustment that transfers any credit balance resulting from an overpayment to the loan's principal balance. Refer to Defining Loan Options for more information.
Pre-Bill Completion	Optional	These algorithms are executed immediately prior to bill completion when a bill contains a bill segment for a service agreement whose SA type has such an algorithm. The following situations necessitate the definition of such an algorithm: - If you want to delete a bill segment that's in error on the last night of a bill cycle when there are other bill segments that aren't in error, use such an algorithm.
Process NBB Scheduled Payment	Optional	These algorithms are executed by the NBB Scheduled Payment Processing background process whenever a scheduled payment is due. If the Non-Billed Budget SA is unmonitored, this algorithm is not called. This algorithm should be specified on Non-Billed Budget SA types to create the necessary adjustments for the Non-Billed Budget SA.
Proposal SA Acceptance	Optional	These algorithms are executed when a proposal service agreement is accepted. Refer to Enabling The Creation Of A Real Service Agreement for more information.
Proposal SA Bill Segment Generation	Optional	These algorithms are executed to generate simulated bills segments for a proposal service agreement . Refer to Enabling The Generation Of Simulated Bill Segments for more information.
Proposal SA Creation	Optional	These algorithms are executed when a proposal service agreement is created. Refer to Enabling The Automatic Generation Of Billing Scenarios for more information.
SA Activation	Optional	These algorithms are executed when a service agreement status changes from Pending Start to Active. It performs any additional activities that are necessary to activate an SA. The following situations necessitate the definition of such an algorithm: If you want to create a customer contact to indicate that a non-billed budget has been activated, use such an algorithm.
SA Cancel	Optional	These algorithms are executed when a service agreement status changes to Canceled. It performs any additional activities that are necessary to cancel an SA. An example of when you may use this algorithm is that perhaps your business rules dictate that the creation of a payment arrangement should create a credit rating history transaction. When a payment arrangement SA is canceled, the credit rating should be updated with an end date.
SA Creation	Optional	These algorithms are executed when a service agreement is created. The following situations necessitate the definition of such an algorithm on an SA type: - If you want to create a To Do entry whenever a new service agreement of a given type is added, specify such an algorithm. - If you want to automatically activate SAs of a given type (instead of waiting for the background SA activation process to run), specify such an algorithm. - If you want to create a Workflow Process when a service agreement of a given type is added, specify such an algorithm.
SA Information	Optional	We use the term "SA information" to describe the basic information that appears throughout the system to describe a service agreement. The data that appears in "SA information" is constructed using this algorithm. Plug an algorithm into this spot to override the "SA information" algorithm on installation options or the system default "SA information" if no such algorithm is defined on installation options.
SA Renewal	Optional	These algorithms are executed by the Service Agreement Renewal background process whenever an SA is due for renewal or when the user clicks the Renew button (for Non-Billed Budgets ). It performs any activities that are necessary to renew an SA and returns the new renewal and expiration dates for the SA.
SA Stop	Optional	These algorithms are executed whenever a service agreement's status changes from pending stop to stopped. The following situations necessitate the definition of a SA stop algorithm: - For Non-Billed Budgets to distribute any remaining credit balance from the Non-Billed Budget SA to the covered SAs, you must specify such an algorithm. - For service credit memberships that have a refundable membership fee, an SA Stop algorithm attempts to refund the fee if this is the last SA linked to the membership that is being stopped.
SA Stop Initiation	Optional	These algorithms are executed whenever a service agreement's status becomes pending stop. The following situations necessitate the definition of a stop initiation algorithm on an SA type: - As explained under Finalizing Pending Stops, service agreements are normally transitioned from pending stop to stopped by a background process (or manually). For Non-Billed Budget SAs to transition to stopped automatically (without waiting for the background process), you must specify such an algorithm. When does a SA become pending stop? Service agreements typically become pending stop when a user initiates a request to stop service on Start Stop - Main. A severance process with an Expire SA severance event causes a service agreement to become pending stop (when the event is executed). Additionally, the Stop Expired Service Agreements background process starts the process to initiate the stop of an SA when the expiration date is on or before the process date.
Start Stop Field Work	Optional	These algorithms are executed to create the field activities necessary to start and stop service. Refer to Starting Service and Field Activities and to Stopping Service and Field Activities for a description of when algorithms of this type are called. The following situations necessitate the definition of a start stop fieldwork creation algorithm: - If a service agreement has field activities created to start and stop service at its service points, its SA type must have an appropriate start stop field work creation algorithm.