Process What's Ready Processes

ACTVTAPY

CIPPAAPB

This process marks each auto pay download staging record with the batch control associated with its auto-pay source's route type. It also stamps the respective batch control's current run number on each record.

Note: The APAYACH background process uses the information on this staging table to create the flat file that is used to interface information to the ACH. The BALAPY background process uses the information on this staging table to create automatic payment tender controls.

Refer to Activating Automatic Payments for more information.

Yes

MAX-ERRORS

Yes

200/15

APAYCRET

CIPPACRB

This process creates automatic payments for bills whose automatic payment creation has been deferred until the extract date. This extract date is stamped on the bill and is used by this background process to select all bills whose automatic payment extract date is on or before the supplied business date. It calls the automatic payment creation algorithm plugged in on the installation record to create the automatic payments. Note that the algorithm supplied does not distribute and freeze the automatic payments that are created. This is handled by the complementary background process APAYDSFR.

Refer to Installation Options - Billing and Automatic Payments for more information.

Yes

MAX-ERRORS

Yes

300/15

APAYDSFR

CIPPADFB

This process distributes and freezes automatic payments whose distribution date (indicated on the download staging record) is on or before the supplied business date. Payments that have been distributed (e.g., manually) are frozen if the above criterion is satisfied.

This job complements the APAYCRET background process and the PPAPAY background process when the Autopay Creation Option on the installation record is set to Create on Extract Date.

Refer to Installation Options - Billing and Automatic Payments for more information.

Yes

MAX-ERRORS

Yes

300/15

BALAPY

CIPPBAPB

This process creates a new tender control (with an associated deposit control) for each batch control and run number encountered for extracted automatic payments that are not already linked to a tender control.

Afterwards, this process balances the open tender and deposit control records.

Note: Automatic payment staging records are activated by the ACTVTAPY process and extracted by the APAYACH.

Refer to Creating Automatic Payment Tender Controls for more information.

No

MAX-ERRORS

Yes

200/15

BCASSIGN

CIPFBCAB

This process assigns the Pending balance control group to new FT's (i.e., those without a balance control group).

Refer to The Big Picture of Balance Control for more information.

Yes

MAX-ERRORS

No

200/15

BCGNEW

CIPFBCGB

This process creates a Pending balance control group if one doesn't already exist.

Refer to The Big Picture of Balance Control for more information.

No

MAX-ERRORS

No

N/A (only 1 record is inserted)

BCGSNAP

CIPFBCSB

The balance control snapshot and verification process has two functions:

1. It summarizes the number and value of the financial transactions on the current Pending balance control group record.

2. It verifies the financial integrity of your system.

The value of the VERIFY-ONLY-SW parameter controls which of these functions is performed:

- If VERIFY-ONLY-SW = "N", the system summarizes the new financial transactions under the current Pending balance control and verifies that the balances summarized on every historical balance control group are consistent with the financial transactions associated with this balance control group (i.e., it checks the financial integrity of the system).

- If VERIFY-ONLY-SW = "G", the system only summarizes the new financial transactions under the current Pending balance control (i.e., the verification step is not performed).

- If VERIFY-ONLY-SW = "Y", the system verifies that the balances summarized on every historical balance control group are consistent with the financial transactions associated with this balance control group (i.e., it checks the financial integrity of the system).

Note: You may want to use the VERIFY-ONLY-SW parameter to improve system performance. For example, you can generate the balance control summary nightly (run the process with the switch set to "G") and validate the balance control summaries weekly (run the process with the switch set to "Y").

Refer to The Big Picture of Balance Control for more information.

No

VERIFY-ONLY-SW

MAX-ERRORS

No

200/15

BCU1

CIPCBC1B

The first phase of the billable charge upload staging process validates and defaults information on to billable charge upload staging records.

Refer to Billable Charge Upload Background Processes for more information.

No

MAX-ERRORS

No

N/A

BCU2

CIPCBC2B

The second phase of the billable charge upload staging process creates billable charges for the new billable charge upload staging records.

Refer to Billable Charge Upload Background Processes for more information.

Yes

MAX-ERRORS

No

200/15

BILLING

CIPBBILB

The bill cycle process creates bills for accounts with an "open" bill cycle.

Refer to Batch Billing for more information.

Yes

MAX-ERRORS

Yes

100/15

C1-ADMOV

CIPLOVMB

The overdue monitor uses your overdue rules to collect overdue debt. Refer to How Does The Overdue Monitor Work? for more information.

Yes

MAX-ERRORS

Yes

2000/15

C1-ADUP1

Java

This is the first of two background processes that load the contents of the adjustment upload staging records into the various adjustment tables.

The background process performs high level validation and identifies the obligation for each of the adjustment upload staging records.

If any errors are found, the status of the Adjustment Staging Control is set to Error . If no errors are found, the status of the Adjustment Staging Control is set to In Progress.

Refer to Interfacing Adjustments for more information.

Yes

ADJ-STG-CTL-ERR-TD-TYPE (To Do Type for Staging Control Errors)

ADJ-STG-CTL-ERR-TD-ROLE (To Do Role for Staging Control Errors)

ADJ-UPL-STG-ERR-TD-TYPE (To Do Type for Adj Staging Errors)

ADJ-UPL-STG-ERR-TD-ROLE (To Do Role for Adj Staging Errors)

MAX-ERRORS

Yes

300/15

C1-ADUP2

Java

This is the second of two background processes that load the contents of the adjustment upload staging records into the various adjustment tables.

This process creates adjustments for adjustment upload staging records with a Pending status where the Obligation ID is populated. The upload staging status is changed to Complete.

Refer to Interfacing Adjustments for more information.

Yes

MAX-ERRORS

Yes

300/15

C1-ADURS

Java

This process picks up all adjustment upload staging records that are In Suspense. For each record, it calls the 'Resolve Suspense' plug-in for the adjustment upload staging's adjustment type.

It's the algorithm's responsibility for performing the appropriate logic to resolve the suspense.

The background process can be run periodically according to the implementation's requirements.

Refer to Interfacing Adjustments for more information.

Yes

MAX-ERRORS

Yes

300/15

C1-APYDF

Java

This process distributes and freezes automatic payments using payment distribution rules.

The background process reads all the automatic payment records whose scheduled distribution date is on or before the business date. For each record, payment(s) and pay segment(s) are created using the payment event's distribution rule(s). Payments are frozen.

Yes

MAX-ERRORS

Yes

200/NA

C1-CALPI

Java

This process brings P&I up to date to the input business date for all obligations.

Refer to

Refer to The Big Picture of Penalty and Interest for more information.

Yes

MAX-ERRORS

Yes

200/NA

C1-CSTRS

CIPQTRCB

The case scheduled transition process transitions cases to a nominated next status or transition condition at a scheduled time. The process selects all open cases whose current status is linked to the process' batch control code and are allowed to transition from their current status to the chosen next status or condition (i.e. where a corresponding transition rule exists for the case type/status combination) based on the input algorithm parameters.

Yes

NEXT-STATUS-CD (Next Status Code)

NEXT-TR-COND-FLG (Next Transition Condition)

MAX-ERRORS

Yes

200/15

C1-FBTC

Java

This process balances the tender controls associated with processed form batch header records.

It is run at the very end of the upload process when all of the following are true:

a) The form batch headers are in a completed state.

b) All the form upload staging records in each batch are in some final state - e.g. form added, etc.

c) The tax or registration forms created from the upload records are in some final state or are suspended. (Any payments would have been created at any of these states.)

Yes

restrictToFrmBatchHeaderID (Restrict By Form Batch Header ID)

maxErrors

Yes

10/15

C1-ODET

CIPLOETB

The overdue / cut event manager activates all overdue and cut events whose trigger date is on or before the supplied business date. Refer to How and When Events Are Activated for more information. This process also has the responsibility of recursively activating later events that are dependent on the completion of earlier events.

For overdue or cut events that are in the Wait state, this process runs the associated waiting algorithm for the event type to determine if the object the event is waiting for is complete (and then triggering the dependent events when it completes).

Populate an Overdue Process Template in the input parameter to limit the processing to overdue processes for this template.

Yes

OD-PROC-TMP-CD (Optional)

MAX-ERRORS

Yes

2000/15

C1-PEPL1

CIPPEL1B

This is the first of three background processes that load the contents of the payment event upload staging records into the various payment tables.

It first creates new deposit and tender control records, and then updates the payment event upload staging records with the corresponding Tender Control ID.

Next, it processes each incomplete record as follows: It updates the record's Tender Account ID with the account ID returned by the Determine Tender Account algorithm defined on the distribution rule. If the Pay Event Process ID field is not populated, it is set equal to the tender account ID. If no error was encountered, it transitions the record from to Pending.

Refer to Interfacing Payments Using Distribution Rules for more information.

Yes

MAX-ERRORS

Yes

300/15

C1-PEPL2

CIPPEL2B

This is the second of three background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of this process is to create payment events, payment tenders and payments and transition the corresponding staging records from Pending to Complete.

Refer to Interfacing Payments Using Distribution Rules for more information.

Yes

MAX-ERRORS

Yes

300/15

C1-PEPL3

CIPPEL3B

This is the last of three background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of this process is to update the status of the related deposit and tender controls from open to balanced.

Refer to Interfacing Payments Using Distribution Rules for more information.

Yes

MAX-ERRORS

No

300/15

C1-PAYPA

CIPGACRB

The Pay Plan scheduled payment autopay create process creates autopay records for any scheduled pay plan payments where the account is set up for autopay and the pay plan is not excluded from autopay.

For more information about pay plan auto payments, refer to Automatic Payment and Pay Plans.

Yes

MAX-ERRORS

Yes

300/15

C1-PAYPS

CIPGNPSB

The pay plan scheduled payment process performs processing for scheduled payment records with a payment date on or before the process business date.

After processing, the scheduled payment status is updated to processed.

For more information, refer to Processing Scheduled Payments.

Yes

MAX-ERRORS

Yes

300/15

C1-RDAMT

CIPFFTRB

This process looks for financial transactions linked to each obligation that are older than X days (where X is defined on the installation record) that sum to zero. If it finds such FTs, it marks them as "redundant". Redundant FTs do not have to be accessed by the various SQL statements that accumulate an account or obligation's balance.

Yes

MAX-ERRORS

Yes

100/10

CASETRAN

CIPQCSTB

This batch process is responsible for calling the algorithm that determines if a case should be transitioned to a new state. Refer to Automatic Transition Rules for the details.

If Restrict To Case Type Code is specified, only cases of this type will be analyzed to determine if they should be transitioned to a new state.

If Restrict To Status Codeis specified, only cases in this status will be analyzed to determine if they should be transitioned to a new state. Note, if this parameter is specified, a Restrict to Case Type Code must also be defined.

Yes

CASE-TYPE-CD (Restrict To Case Type Code)

CASE-STATUS-CD (Restrict To Status Code)

MAX-ERRORS

Yes

200/15

GLASSIGN

CIPFGLAB

The GL account number assignment process assigns GL account numbers to the GL details associated with financial transactions. Refer to The GL Interface for more information.

Yes

MAX-ERRORS

Yes

200/15

GLS

CIPFGLEB

The create general ledger download staging process creates a download staging record for every financial transaction that is ready for download.

This process populates the FT / Batch Process table with the unique ID of all financial transactions to be interfaced to the general ledger. This process marks each staging record with the GL interface's batch process ID (defined on the installation record). It also stamps the respective batch control's current run number on each record.

Note: The GLDL background process uses the information on this staging table to create the consolidated journal entries that are interfaced to your general ledger.

Refer to The GL Interface for more information.

Yes

MAX-ERRORS

No

200/15

PUPL

CIPPUPLB

The upload payments process creates payment events, payments, and tenders using the records in the various payment staging tables.

Refer to Interfacing Payments From External Sources for more information.

Yes

MAX-ERRORS

No

100/15

PY-RPE

CIPPRPEB

The resolve payments in error process attempts to resolve the following payment errors automatically:

• A valid account was found but no active obligation exists.

Refer to Resolving Exceptions Automatically for more information.

Yes

MAX-ERRORS

No

200/15

SAACT

CIPCSATB

The obligation activation process updates pending start and pending stop obligations.

Yes

MAX-ERRORS

Yes

200/15