Background Processes Addendum
This chapter is an addendum to the general Defining Background Processes chapter. This addendum describes the background processes that are provided with Oracle Enterprise Taxation Management.
The System Background Processes
How To Set Up A New Extract Processes
The Big Picture of Sample & Submit
The topics in this section describe functionality that is common to system background processes.
Process What's Ready Processes
Referential Integrity Validation Processes
Conversion Processes Executed In The Staging Database
Process What's Ready Processes
Some background processes create and update records that are “ready for processing”. The definition of “ready” differs for every process. For example,
· The payment upload process creates payments for every record that is pending
· The overdue event monitor activates pending overdue events that have reached their trigger date
Processes of this type tend to use a business date in their determination of what’s ready. If the requester of the process does not supply a specific business date, the system assumes that the current system date should be used. If you need to use a date other than the current date, simply supply the desired date when you request the batch process.
The following table lists every background process that processes all data that is “ready”.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Error Generates To Do |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
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 |
Yes |
200/15 |
||
|
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 |
Yes |
300/15 |
||
|
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 |
Yes |
300/15 |
||
|
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 |
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 |
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 |
No |
N/A (only 1 record is inserted) |
|
|
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 |
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 |
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 |
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 |
Yes |
100/15 |
|
|
CIPLOVMB |
The overdue monitor uses your overdue rules to collect overdue debt. Refer to How Does The Overdue Monitor Work? for more information.
|
Yes |
Yes |
2000/15 |
||
|
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 |
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 |
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. |
Yes |
NEXT-STATUS-CD (Next Status Code) NEXT-TR-COND-FLG (Next Transition Condition) |
Yes |
200/15 |
|
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) |
Yes |
2000/15 |
|
|
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 |
Yes |
300/15 |
||
|
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 |
Yes |
300/15 |
||
|
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 |
No |
300/15 |
||
|
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 Code is 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) |
Yes |
200/15 |
|
|
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 |
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 |
No |
200/15 |
|
|
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 |
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 |
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 |
Yes |
100/10 |
|
|
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 |
No |
100/15 |
|
|
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 |
No |
200/15 |
||
|
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 |
Yes |
100/10 |
||
|
CIPCSATB |
The obligation activation process updates pending start and pending stop obligations. |
Yes |
Yes |
200/15 |
Please refer to Column Descriptions for more information on the columns used in the table above.
Monitor Processes
A periodic monitor batch process is provided for any maintenance object whose business object defines a lifecycle. In addition deferred monitor batch process is provided if a business object supplied in the base product required a deferred process for one of its states.
Refer to Monitoring Batch Processes for more information.
Extract Processes
Extract processes extract information that is interfaced out of the system. Processes of this type typically extract records marked with a given run number. If the requester of the process does not supply a specific run number, the system assumes that the latest run number should be extracted. If you need to re-extract an historical batch, you can – simply supply the respective run number when you request the batch process.
Business Intelligence Extracts. If you are using Oracle Utilities Business Intelligence, there will be many other extract processes. These additional processes are responsible for extracting the data sent to the data-warehouse. Please see the product's fact and dimension chapter of the business intelligence documentation for a description of each extract process.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
APAYACH |
CIPPXAPB |
The automatic payment ACH (automated clearing house) download extraction process creates the flat file that is interfaced to the ACH. This process downloads all auto pay download staging records associated with its batch control ID that are marked with a supplied run number. If a run number is not supplied, the process extracts all automatic payment download records marked with the current run number. Note: the ACTVTAPY process updates auto pay download records on their extract date so that they will be downloaded by this process. Refer to Downloading Automatic Payments for more information. |
Yes |
FILE-PATH= directory path into which output should be placed FILE-NAME= name of file into which output should be placed |
NA |
|
APDL |
CIPADAPB |
The A/P download process creates the flat file that is interfaced to your accounts payable software (to cut checks). The process that is delivered has skeletal logic and must be customized by your organization to satisfy the needs of your accounts payable software. In order to adapt the base product program to your specific needs, please following the standard steps: · Copy the base product program to your own program. Your own program should be prefixed with the letters CM (which stands for “taxpayer modification”). This is important as it prevents the upgrade process from overwriting your new logic. · Introduce logic to format the downloaded records into your specific format. · If you need assistance, please contact the implementation support group. This process uses all adjustment extract records associated with its batch control that are marked with a supplied run number. If a run number is not supplied, the process uses all A/P request extract records marked with the current run number. Refer to the A/P Interface for more information. |
Yes |
FILE-PATH= directory path into which output should be placed FILE-NAME= name of file into which output should be placed |
NA |
|
DWLDCOLL |
CIPLXCRB |
The collection agency referral download extraction process creates the flat file that contains referrals to be interfaced to your collection agencies. This process extracts all collection agency referral history records associated with its batch control that are marked with a supplied run number. If a run number is not supplied, the process extracts all referral history records marked with the current run number. The program that is delivered contains skeletal logic that should be used as the basis for your specific processing. The skeletal logic does NOT extract information to a flat file; you must introduce the logic to support your specific flat file format. In order to adapt the base product program to your specific needs, please following the standard steps: · Copy the base product program to your own program. Your own program should be prefixed with the letters CM (which stands for “taxpayer modification”). This is important as it prevents the upgrade process from overwriting your new logic. · Introduce logic to format the downloaded records into your specific format. Note: records are written to the referral history table when a collection agency oriented write-off events are activated. Referral history records may also be added manually by an operator. Refer to The Big Picture of Collection Agency Referrals for more information. |
No |
FILE-PATH= directory path into which output should be placed FILE-NAME= name of file into which output should be placed |
NA |
|
CIPFXGLB |
The general ledger download process creates the flat file that is interfaced to your general ledger software. This process uses all FT / Batch Process records associated with its batch control that are marked with a supplied run number. If a run number is not supplied, the process uses all FT / Process records marked with the current run number. In order to adapt the base product program to your specific needs, please following the standard steps: · Copy the base product program to your own program. Your own program should be prefixed with the letters CM (which stands for “taxpayer modification”). This is important as it prevents the upgrade process from overwriting your new logic. · Introduce logic to format the downloaded records into your specific format. Refer to The GL Interface for more information. |
No |
FILE-PATH= directory path into which output should be placed FILE-NAME= name of file into which output should be placed |
NA |
|
|
CIPCLTPB |
The customer contact letter download process creates the flat file(s) that are interfaced to your letter print software to print letters associated with letter-oriented customer contacts. This process extracts all customer contact records associated with its batch control ID that are marked with a supplied run number. If a run number is not supplied, the process uses all customer contact records associated with its batch control ID that are marked with the current run number. Each downloaded letter’s output is written to a filename that is a concatenation of the letter’s Letter Template Code and the process’s Thread Number. This means that this process can write to multiple files as multiple Letter Template Codes may be downloaded by this process. The information that is extracted and placed on the flat file for each letter is controlled by each customer contact’s letter template’s extract algorithm. Refer to Letter Templates Control The Information Merged Onto Letters for information about how a letter’s flat file records are constructed. The FILE-PATH parameter controls where the output files are placed. The format of the information on the flat file can be either tilde delimited or in a fixed position (based on the FIELD-DELIM-SW parameter). Tilde delimited output is used if you merge the information into a Word template. Fixed position output is used if you merge the information into a template that expects this type of format. You can use the CNTL-REC-SW parameter to cause the extract to produce a control record that contains batch code, run number, number of letters to print, etc. Refer to Printing Letters for more information. |
Yes |
FILE-PATH= directory path into which output should be placed FIELD-DELIM-SW=Y or N CNTL-REC-SW=Y or N |
NA |
|
|
CIPBXBLB |
The bill print process creates the flat file that is interfaced to your bill print software. This process uses all bill routing extract records associated with its batch control that are marked with a supplied run number. If a run number is not supplied, the process extracts all bill routing extract records marked with the current run number. The information that is extracted and placed on the flat file for each bill is controlled by each bill route type’s extract algorithm. Refer to Bill Route Controls The Information Merged Onto Bills for information about how a bill's flat file records are constructed. The FILE-PATH parameter controls where the output files are placed. Refer to Printing Bills for more information. |
Yes |
FILE-PATH= directory path into which output should be placed FILE-NAME= name of file into which output should be placed |
NA |
Please refer to Column Descriptions for more information on the columns used in the table above.
Adhoc Processes
These are background processes that are run on an ad hoc basis (e.g., if you need to back out bills that were created by the billing process).
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra |
Error Generates To Do |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
F1-AVALG |
Java |
This process regenerates algorithm type and their related algorithm information to be displayed by the Application Viewer. It produces a series of XML files in a designated folder under the application viewer /data folder. Refer to Application Viewer Generation for more information on this background process is used. |
No |
No |
NA |
|
|
F1-AVMO |
Java |
This process regenerates maintenance object information to be displayed by the Application Viewer. It reads the meta-data maintenance object information and produces a series of XML files in a designated folder under the application viewer /data folder. Refer to Application Viewer Generation for more information on this background process is used. |
No |
No |
NA |
|
|
F1-AVTBL |
Java |
This process regenerates table and column information to be displayed by the Application Viewer. It reads the meta-data table and related entities and produces a series of XML files in a designated folder under the application viewer /data folder. Refer to Application Viewer Generation for more information on this background process is used. |
No |
No |
NA |
|
|
CIPBMCNB |
The mass bill cancellation process removes an entire batch of bills that were created by the BILLING process. Refer to Canceling A Batch Of Bills After They’re Complete for more information. |
Yes |
BILL-CYC-CD= the bill cycle associated with the bills WIN-START-DT=the bill cycle window start date associated with the bills. This should be entered in the format YYYY-MM-DD. BILL-DT= the date on which the bills were created. This should be entered in the format YYYY-MM-DD. |
Yes |
100/15 |
|
|
CIPBMROB |
The mass bill reopen process reopens an entire batch of bills that were completed by the BILLING process. Refer to Reopening A Batch Of Bills After They’re Complete for more information. |
Yes |
BILL-CYC-CD= the bill cycle associated with the bills WIN-START-DT= the bill cycle window start date associated with the bills BILL-DT= the date on which the bills were created. This should be entered in the format YYYY-MM-DD. |
Yes |
200/15 |
|
|
CIPZLNGB |
This Create New Language batch program duplicates all language specific rows from the source to the target language. Once this program has run you will need to translate the language specific columns. This program can be rerun at anytime. It will only duplicate entries where they do not already exist. Note if you run this program with the "DELETE" action then the source and target language must be the same. If you have any questions, please see your implementation team for more information. |
Yes |
SOURCE-LANGUAGE= source language code TARGET-LANGUAGE= target language code PROGRAM-ACTION= (DELETE or INSERT) |
No |
200/15 |
|
|
UPDERR |
CIPZUESB |
The process updates In Progress threads in an abnormally terminated batch run to be Error. When at least one thread is in Error, this process also updates the status of the batch run to be Error. Refer to Dealing With Abnormally Terminated Background Processes for information about when and why this process would be executed. |
No |
BATCH-CD-IN-PROGRESS = the batch control ID of the abnormally terminated batch process BATCH-NBR-IN-PROGRESS = the run number of the abnormally terminated batch process UPD-ALL-THRDS-SW must be Y or N. A value of Y means that the status of all In Progress threads will be changed to Error. A value of N means that the next parameter must be supplied. BATCH-THRD-NBR-IN-PROGRESS = the thread number whose status should be changed from In Progress to Error. This parameter should only be specified if UPD-ALL-THRDS-SW = N. |
No |
N/A |
Please refer to Column Descriptions for more information on the columns used in the table above.
ToDo Entry Processes
These are background processes whose main purpose is to generate To Do Entry records based on a certain condition. Refer to ToDo Entries Created By Background Processes for the details. The section that appears below simply lists these processes.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
CIPQBCEB |
This background process creates a To Do entry for every billable charge upload record that’s in error. |
No |
200/15 |
||
|
CIPQBIEB |
This background process creates a To Do entry for every bill that’s in error. |
Yes |
200/15 |
||
|
CIPQBSEB |
This background process creates a To Do entry for every bill segment that’s in error. |
Yes |
200/15 |
||
|
CIPQBERB |
This background process creates To Do Entry for any other batch processes that ended in error. A To Do Entry is only created if one does not already exist. |
No |
200/15 |
||
|
CIPQCCCB |
This background process creates a To Do entry for customer contacts that have been flagged to generate a To Do entry on a future date. Note well, most To Do background processes create To Do entries in the pending state. If the customer contact indicates a specific user should be notified (as opposed to notifying a group of users – a role), the To Do entry will be created in the being worked state and it will be assigned to the designated user. |
Yes |
LEAD-DAYS = Number of days before the customer contact’s reminder date that the To Do entry should be created. Valid values of 0 to 99 are acceptable. |
200/15 |
|
|
CIPQCLEB |
This background process creates a To Do Entry for any batch process that has root objects that created an error. A To Do Entry is only created if one does not already exist. |
Yes |
200/15 |
||
|
CIPQDTCB |
This background process creates a To Do entry for deposit control staging / tender control staging records that are in error. |
No |
200/15 |
||
|
CIPQODMB |
This background process creates a To Do entry for every disputed match event |
Yes |
NO-OF-DAYS = Number of days old the match event must be before a To Do entry is created (this prevents young entries from appearing on To Do lists) |
200/15 |
|
|
CIPQONMB |
This background process creates a To Do entry for every open, non-disputed match event |
Yes |
NO-OF-DAYS = Number of days old the match event must be before a To Do entry is created (this prevents young entries from appearing on To Do lists) |
200/15 |
|
|
CIPQNBCB |
This background process creates a To Do entry for every account that doesn’t have a bill cycle but has active obligations. |
Yes |
200/15 |
||
|
CIPQPAYB |
This background process creates a To Do entry for every payment that’s in error or that is unfrozen. |
Yes |
200/15 |
||
|
CIPQPYUB |
This background process creates a To Do entry for every payment staging record that’s in error. |
No |
200/15 |
||
|
CIPQPYEB |
This background process creates a To Do entry for every payment event that’s unbalanced. |
Yes |
200/15 |
||
|
CIPQXAUB |
This background process creates a To Do entry for every XAI Upload Staging in error. |
Yes |
200/15 |
Please refer to Column Descriptions for more information on the columns used in the table above.
Object Validation Processes
These background processes are run to validate the master data objects. These programs are typically only run as part of the conversion and upgrade processes.
Another use for these programs. In addition to validating your objects after conversion or an upgrade, the validation programs listed below have another use. For example, you want to experiment with changing the validation of a person and you want to determine the impact of this new validation on your existing persons. You could change the validation and then run the person validation object – it will produce errors for each person that fails the new validation.
Refer to Validate Information In The Staging Tables for more information about these processes and where their errors appear.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
CIPVACCB |
Validate the account object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVBCGB |
Validate the billable charge object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. STATUS1=validate rows with this status STATUS2=validate rows with this status MAX-ERRORS |
200/15 |
|
|
CIPVCCSB |
Validate collection case |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVSVAB |
Validate the obligation object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVOPPB |
Validate overpayment process object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value |
200/15 |
|
|
CIPVPERB |
Validate the person object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVPRMB |
Validate the location object |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVTXRB |
Validate tax role |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
|
|
CIPVTXFB |
Validate tax form |
Yes |
OVRD-LOW-ID=key value to override the calculated start-key value OVRD-HIGH-ID=key value to override the calculated end-key value SKIP-ROWS= nth row to be processed, for example 10 to process every 10th row. |
200/15 |
Please refer to Column Descriptions for more information on the columns used in the table above.
Referential Integrity Validation Processes
The following table lists every background process that validates transaction data using the same program CIPVRNVB. These programs are typically run as part of the conversion and upgrade processes.
In all cases, the processes are not multi-threaded and do not include extra parameters. In addition, Records Between Commits and Minutes Between Cursor Re-Initiation are not applicable.
Refer to Validate Information In The Staging Tables for more information about these processes and where their errors appear.
|
Batch Control ID |
Description |
|
CIPVAAPV |
Foreign Key validation for Account Automatic Payment |
|
CIPVACHV |
Foreign Key validation for Account Characteristics |
|
CIPVACPV |
Foreign Key validation for Account Person Relationship |
|
CIPVADJV |
Foreign Key validation for Adjustment |
|
CIPVAPAV |
Foreign Key validation for Location Alternate Address |
|
CIPVAPCV |
Foreign Key validation for Account Person Characteristics |
|
CIPVAPRV |
Foreign Key validation for A/P Check Request |
|
CIPVARHV |
Foreign Key validation for Collection Agency Referral History |
|
CIPVARSV |
Foreign Key validation for Credit Review Schedule |
|
CIPVBCHV |
Foreign Key validation for Bill Characteristic |
|
CIPVBCGV |
Foreign Key validation for Billable Charge |
|
CIPVBCLV |
Foreign Key validation for Billable Charge Line |
|
CIPVBFVV |
Foreign Key validation for Rate Factor Value |
|
CIPVBLLV |
Foreign Key validation for Bill Header |
|
CIPVBLMV |
Foreign Key validation for Bill Messages |
|
CIPVBLRV |
Foreign Key validation for Bill Routing |
|
CIPVBSAV |
Foreign Key validation for Bill - Obligation Balance Snapshot |
|
CIPVBSCV |
Foreign Key validation for Bill Segment Calc Header |
|
CIPVBSLV |
Foreign Key validation for Bill Segment Calc Line |
|
CIPVCARV |
Foreign Key validation for Collection Agency Referral |
|
CIPVCCLV |
Foreign Key Validation for Collection Case Log |
|
CIPVCCOV |
Foreign Key Validation for Collection Case Overdue Process |
|
CIPVCCPV |
Foreign Key Validation for Collection Case Log Parameter |
|
CIPVCCSV |
Foreign Key Validation for Collection Case |
|
CIPVCRTV |
Foreign Key validation for Credit Rating History |
|
CIPVCSCV |
Foreign Key validation for Customer Contact |
|
CIPVFTFV |
Foreign Key validation for Financial Transaction |
|
CIPVFTGV |
Foreign Key validation for Financial Transaction Gen Ledger |
|
CIPVFTPV |
Foreign Key validation for Financial Transaction Process |
|
CIPVFTCV |
Foreign Key validation for Financial Transaction Characteristics |
|
CIPVMSGV |
Foreign Key validation for Account Bill Messages |
|
CIPVNBSV |
Foreign Key validation for Pay Plan / Obligation |
|
CIPVNPMV |
Foreign Key validation for Pay Plan Payment Schedule Parameter Values |
|
CIPVNSPV |
Foreign Key validation for Pay Plan Scheduled Payments |
|
CIPVOPCV |
Foreign Key validation for Overpayment Process Characteristics |
|
CIPVOPLV |
Foreign Key validation for Overpayment Process Log |
|
CIPVOPMV |
Foreign Key validation for Overpayment Process Log Parameter |
|
CIPVOPPV |
Foreign Key validation for Overpayment Process |
|
CIPVPAOV |
Foreign Key validation for Person Address Override |
|
CIPVPAYV |
Foreign Key validation for Payment Header |
|
CIPVPYCV |
Foreign Key validation for Payment Characteristic |
|
CIPVPCHV |
Foreign Key validation for Location Characteristic |
|
CIPVPGOV |
Foreign Key validation for Location Geographic location |
|
CIPVPIDV |
Foreign Key validation for Person Identifier |
|
CIPVPNMV |
Foreign Key validation for Person Name |
|
CIPVPPEV |
Foreign Key validation for Person to Person |
|
CIPVPPHV |
Foreign Key validation for Person Phone |
|
CIPVPRCV |
Foreign Key validation for Person Characteristics |
|
CIPVPSAV |
Foreign Key validation for Person Seasonal Address |
|
CIPVPSGV |
Foreign Key validation for Payment Segment |
|
CIPVSACV |
Foreign Key validation for Obligation Characteristics |
|
CIPVSAHV |
Foreign Key validation for Obligation Rate Schedule History |
|
CIPVSAOV |
Foreign Key validation for Obligation Contract Terms |
|
CIPVSAQV |
Foreign Key validation for Obligation Contract Quantity |
|
CIPVSARV |
Foreign Key validation for Obligation Recurring Charge |
|
CIPVSEGV |
Foreign Key validation for Bill Segment |
|
CIPVSMGV |
Foreign Key validation for Obligation Message |
|
CIPVSQTV |
Foreign Key validation for Bill Segment Rate Quantity |
|
CIPVSRRV |
Foreign Key validation for Bill Segment Register Read |
|
CIPVTFCV |
Foreign Key Validation for Tax Form Characteristics |
|
CIPVTFLV |
Foreign Key Validation for Tax Form Log |
|
CIPVTLPV |
Foreign Key Validation for Tax Form Log Parameter |
|
CIPVTNDV |
Foreign Key validation for Payment Tender |
|
CIPVTNCV |
Foreign Key validation for Payment Tender Characteristics |
|
CIPVTXCV |
Foreign Key validation for Tax Role Characteristics |
|
CIPVTXFV |
Foreign Key validation for Tax Form |
|
CIPVTXRV |
Foreign Key validation for Tax Role |
Please refer to Column Descriptions for more information on the columns used in the table above.
Conversion Processes
These background processes are run only when converting or migrating data from external applications into the system. Your company may never use them depending upon your data migration strategy.
Refer to The Conversion Tool for more information about these processes and where their errors appear.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
CNV-ADM |
CIPVADMB |
Creates ADM triggers for converted accounts. |
Yes |
200/15 |
|
|
CIPVCBCB |
This process resets the Balance Control column on all FT's so that the FT's can be included in a balance control (see the last step below) after they have been transferred to production. |
Yes |
200/15 |
Please refer to Column Descriptions for more information on the columns used in the table above.
Conversion Processes Executed In The Staging Database
There are many other background processes that are only executed if you use the conversion tool to load historical data into your production database. These programs perform the following tasks:
· Key Assignment Programs. Background processes of this type assign random, clustered keys to the rows in the staging database.
A separate background process exists for every table with a system-assigned key that is supported by the conversion tool. The program names of these processes are documented in The Conversion Process (scan for all references to “Key Assignment Program” for a matrix containing these program names).
· Insertion Programs. Background processes of this type insert converted rows into production from the staging database.
A separate background process exists for every table that is supported by the conversion tool. The program names of these processes are documented in The Conversion Process (scan for all references to “Insertion Program” for a matrix containing these program names).
Purge Processes
These background processes are used to purge historical records from certain objects that generate a large number of entries and may become unwieldy over time.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
CIPCDBSB |
Purges completed billable charge upload objects. |
Yes |
NO-OF-DAYS = number of days after the creation date that a completed billable charge upload object should be purged |
200/15 |
|
|
CIPPDUSB |
Purges completed tender upload objects. |
Yes |
NO-OF-DAYS = number of days after the related tender’s payment event’s creation date that a completed tender upload object should be purged |
200/15 |
|
|
CIPQDTDB |
Purges completed To Do entries. |
Yes |
NO-OF-DAYS = number of days after the completion date that a completed To Do entry should be purged DEL-ALL-TD-SW = Y or N. If this switch is Y, all completed To Do entries that are old enough will be deleted. If N, the next parameter defines the specific type of To Do entry that will be deleted. DEL-TD-TYPE-CD. This parameter is only used if DEL-ALL-TD-SW is N. It contains the To Do type code whose completed entries will be deleted. |
200/15 |
|
|
CIPXDXUB |
Purges completed XML upload objects. |
Yes |
NO-OF-DAYS = number of days after the completion date that a completed XML upload object should be purged |
200/15 |
Please refer to Column Descriptions for more information on the columns used in the table above.
ConfigLab Processes
The following table lists system background processes used in conjunction with the Configuration Lab. The delivered system background processes are designed to copy sample DB processes from the demonstration database.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
CIPYUPDB |
The apply changes based on compare is used to update the current environment based on the results of a compare from a ConfigLab or Compare Source environment. Refer to Configuration Lab for more information. |
No |
ENV-CODE = environment reference specified as a batch parameter on the batch run used to compare data. DB-PROC-CODE = The Compare DB process used to pull data from ENV-CODE. |
200/15 |
|
|
CIPYSYCB |
The copy "CI_" DB processes is used to compare DB processes from the demonstration database. It is assumed that the demonstration database has been registered as a Compare Source environment reference. Refer to Configuration Lab for more information. |
No |
ENV-CODE = environment reference representing a registered Compare Source environment. STATUS-ON-ADD = default root object status when root object action is Add. STATUS-ON-CHANGE = default root object status when root object action is Change. STATUS-ON-DELETE = default root object status when root object action is Delete. |
200/15 |
Archive and Purge Processes
The following table lists system background processes used in conjunction with the Archive Engine. Note that the DB process that represents an archive or purge procedure defines the batch control used for the first step of a purge or archive. Although, the CIPYCPRB program (used universally for the first step of any archive or purge procedure) is delivered with the system, there are no system batch controls that reference it. It is included in this list for clarity.
For information on how to copy sample Archive and Purge DB processes from the demonstration database, refer to How To Copy Samples From The Demonstration Database.
|
Batch Control ID |
Program Name |
Description |
Multiple Threads |
Extra Parameters |
Records Between Commits / Minutes Between Cursor Re-Initiation |
|
Special - Each archive or purge procedure defines its first step's batch control. |
CIPYCPRB |
The first step of any archive or purge process is to create primary archive roots objects. Note that for Purge DB processes, the environment reference batch parameter is optional. Refer to Archive Engine for more information. |
Yes |
ENV-CODE = environment reference of the target archive environment. TEST-MODE (Y/N) = If Y is specified, the program will write out information about primary roots to a log file. |
200/15 |
|
CIPYCRCB |
The second step of any archive or purge process is to create child archive roots objects. Note that for Purge DB processes, the environment reference batch parameter is optional. Refer to Archive Engine for more information. |
Yes |
ENV-CODE = environment reference of the target archive environment. DB-PROC-CODE = The archive or purge DB process that specifies the batch control used to create primary archive root objects (step 1 of any archive or purge). |
200/15 |
|
|
CIPYRFKB |
The third step of any archive or purge process is to check recursive foreign key relationships. Note that for Purge DB processes, the environment reference batch parameter is optional. Refer to Archive Engine for more information. |
Yes |
ENV-CODE = environment reference of the target archive environment. DB-PROC-CODE = The archive or purge DB process that specifies the batch control used to create primary archive root objects (step 1 of any archive or purge). |
|
|
|
CIPYPARB |
The fourth step of any archive or purge process is to move data to the target archive environment (in the case of an archive), or simply delete it (in the case of purge). Note that for Purge DB processes, the environment reference batch parameter is optional. Refer to Archive Engine for more information. |
No |
ENV-CODE = environment reference of the target archive environment. DB-PROC-CODE = The archive or purge DB process that specifies the batch control used to create primary archive root objects (step 1 of any archive or purge). |
200/15 |
|
|
CIPYCARB |
If desired, this background process may be run instead of AR-DCDT (above). This process calls the Archive Copy Processing algorithm specified on the DB Process Instruction to copy the data to a flat file instead of an archive environment. Note that for Purge DB processes, the environment reference batch parameter is optional. Refer to Archive Engine for more information. |
Yes |
ENV-CODE = environment reference of the target archive environment. DB-PROC-CODE = The archive or purge DB process that specifies the batch control used to create primary archive root objects (step 1 of any archive or purge). MODE = C (Copy data only), D (Delete records only), or B (Both copy and delete). The default is B (Both). |
200/NA |
Column Descriptions
The following descriptions explain the parameters used in the above tables:
· Batch Control ID. As described earlier, every background process has an associated batch control record. This column contains the unique identifier of each process’ batch control record.
· Program Name. This is the name of the program.
· Description. This column describes each background process.
· Multiple Threads. This column indicates if the background process uses the thread number and thread count to control parallel processing. Refer to Parameters Supplied to Background Processes for more information.
· Extra Parameters. This column indicates if the background process uses additional parameters (in addition to those described under Parameters Supplied to Background Processes).
· Error Generates To Do. This column indicates if the background process generates a To Do entry for object-specific errors as described in Processing Errors.
· Records Between Commits / Minutes Between Cursor Re-Initiation. These values represent the maximum number of records between commits to the database and the number of minutes between cursor re-initiations. The process will issue a commit whenever the maximum records threshold has been exceeded. And, whenever a commit is issued, the process checks if the number of minutes between cursor initiation has been exceeded and if so, it will re-initiate the cursor. These values may be overridden when a specific background process is submitted. Refer to Parameters Supplied to Background Processes for more information.
The contents of this section illustrate the periodicity and dependencies between the various background processes described above.
Batch Schedulers and Return Codes
The Archive and Purge Processes
Batch Schedulers and Return Codes
If you use a batch scheduler (e.g., Control-M, Tivoli) to control the execution of your batch processes, it will be interested in the possible values of each process’s return code. The return code is a number that indicates if the process ended successfully. All product processes will return one of the following return code values:
· 0 (zero). A value of zero means the batch process ended normally.
· 2. A value of 2 means the batch process detected a fatal error and aborted.
The Nightly Processes
The following diagram illustrates the dependencies between the batch processes.
The mnemonics in the boxes refer to the individual batch processes described above. When a box contains multiple processes, these processes must be run sequentially. When multiple boxes exist on a timeline, all processes in an earlier box must execute before the subsequent box is executed. Those timelines that appear beneath the first job stream’s timeline indicate when the timeline’s respective processes can be executed in respect of the first job stream.
The following diagram illustrates the daily batch processes for which there are no dependencies.
The mnemonics in the boxes refer to the individual batch processes described above.
No dependencies exist. As you can see, there are no dependencies between the boxes (meaning they may be run in parallel).
The Hourly Processes
The following diagram illustrates the dependencies between the hourly batch processes.
The mnemonics in the boxes refer to the individual batch processes described above. When a box contains multiple processes, these processes must be run sequentially.
No dependencies exist. As you can see, there are no dependencies between the boxes (meaning they may be run in parallel).
The XAI Processes
The following diagram illustrates the dependencies between the XAI background processes. While these processes should be run at least once a day, you may want to consider running them more frequently (depending on how frequently you interface using XAI).
These processes create and/or clean up To Do entries for XAI upload staging or outbound messages in error. They are only applicable if your organization is using the XAI tool because only the XAI tool will mark one of these records in error.
The Letter Processes
To extract information for your various letters, only one background process, LTRPRT, is required regardless of the different types of letters you have. This process simply calls an algorithm plugged-in on the respective letter template to construct its flat-file content.
The following diagram illustrates the dependencies for the letter background process. While this process should be run at least on a daily basis, you may want to consider running it more frequently (depending on how frequently you produce letters).
The mnemonics in the boxes refer to the individual batch processes described above. When a box contains multiple processes, these processes must be run sequentially. When multiple boxes exist on a timeline, all processes in an earlier box must execute before the subsequent box is executed.
The Periodic Processes
The following diagram illustrates the dependencies between the periodic background processes. While many of these processes should be run at least on a monthly basis, you may want to consider running them more frequently (depending on business requirements).
The mnemonics in the boxes refer to the individual batch processes described above.
Few dependencies exist. As you can see, there are few dependencies between the boxes (meaning they may be run in parallel).
The ConfigLab Processes
The following diagram illustrates the dependencies between the ConfigLab processes. The frequency of running ConfigLab processes is implementation specific. For more information on comparing data from an alternate environment, refer to Configuration Lab.
Compare Sources and Targets. The Configuration Lab may be used with environments other than a ConfigLab. In cases where control and account data are pushed to a Compare Target, only the top two batch processes are executed. In cases where control data is pulled from a Compare Source environment, only the bottom two batch processes are executed.
The Archive and Purge Processes
The following diagram illustrates the dependencies between the sample archive and purge processes. The frequency of running archive and purge processes are implementation specific. For more information on archive and purge processes, refer to Archiving and Purging and Archive Engine.
Steps 2, 3 and 4. Note that steps 2 and 3 are the same for all of the sample archive and purge jobs. For step 4, you can select from two background processes: AR-DCDT moves data to a target archive environment (or purges the data) and AR-DCDTF calls an algorithm that copies the data to a flat file. If you want to use AR-DCDTF for other archive jobs, you must develop your own algorithms.
Several background processes delivered with the system are used to interface information out of the system. The topics in this section describe when and how to introduce an additional extract process.
Setting Up Automatic Payment Extracts
You will need an automatic payment extract for every mechanism your company uses to route automatic payment requests to a financial institution / clearing house. For example:
· You will need an automatic payment extract to interface records to the Automated Clearing House (ACH) if you allow taxpayer to pay via credit card or direct debit from a checking account. The APAYACH process delivered with the system is intended to be used to handle this function.
If you need additional automatic payment extract processes, set up the following information:
· Add a new batch control record. Populate the fields as follows:
· Batch Process. Assign an easily recognizable unique ID for the automatic payment extract process.
· Description. Enter a description of the automatic payment extract process.
· Accumulate All Instances. Turn this switch on.
· Use Auto Pay Route Type to define the auto pay extract process to be used for each route type.
Sample and Submit refers to the ability to create Activity Requests. This is functionality that enables an implementer to design an ad-hoc batch process using the configuration tools.
Some examples of such processes are:
· Send a letter to customers that use credit cards for auto pay and the credit card expiration date is within 30 days of the current date.
· Stop auto pay for customers that use credit cards as the form of payment if the credit card has already expired. Notify the customer that their auto pay agreement has been terminated and that they need to call to reinstate.
· Select auto pay accounts that have more than X non-sufficient fund penalties, stop the auto pay agreement and notify the customer.
Note that the terms activity request and sample & submit request may be used interchangeably.
Contents
Activity Type Defines Parameters
Preview A Sample Prior To Submitting
Exploring Activity Request Data Relationships
Defining a New Activity Request
Maintaining Sample & Submit Requests
Activity Type Defines Parameters
For each type of process that your implementation wants to implement, you must configure an activity type to capture the appropriate parameters needed by the activity request.
Preview A Sample Prior To Submitting
To submit a new activity request, a user must select the appropriate activity type and enter the desired parameter values, if applicable.
After entering the parameters, the following actions are possible
· Click Preview to see a sample of records that satisfy the selection criteria for this request. This information is displayed in a separate map. In addition, the map displays the total number of records that will be processed when the request is submitted. From this map you can Save to submit the request, go Back to adjust the parameters or Cancel the request.
· Click Cancel to cancel the request.
· Click Save to skip the preview step and submit the request.
When an activity request is saved, the job is not immediately submitted for real time processing. The record is save in the status Pending and a monitor process for this record's business object is responsible for transitioning the record to Complete.
As long as the record is still Pending, it may be edited to adjust the parameters. The preview logic described above may be repeated when editing a record.
The actual work of the activity request, such as generating customer contact records to send letters to a set of customers, is performed when transitioning to Complete (using an enter processing algorithm for the business object).
Credit Card Expiration Notice
The base product supplies a sample process to find customers that use credit cards for auto pay and the credit card expiration date is within x days of the current date.
To this functionality the following configuration tasks are needed:
· Define an appropriate customer contact class and type to use.
· Define appropriate activity request Cancellation Reasons. Cancellation reasons are defined using a customizable lookup. The lookup field name is C1_AM_CANCEL_RSN_FLG.
· Define an activity type for the business object C1-NotifyExpiringCreditCardTyp. You may define default parameter values for the number of days for expiration and customer contact class and type.
Exploring Activity Request Data Relationships
Use the following links to open the application viewer where you can explore the physical tables and data relationships behind the activity request functionality:
· Click C1-ACM-ACTTY to view the activity type maintenance object's tables.
· Click C1-ACM-ACTRQ to view the activity request maintenance object's tables.
Defining a New Activity Request
To design a new ad-hoc batch job that users can submit via Sample and Submit, first create a new Activity Type business object. The base product BO for activity type C1-NotifyExpiringCreditCardTyp may be used as a sample.
The business object for the activity request includes the functionality for selecting the records to process, display a preview map for the user to review and to perform the actual processing. The base product BO for activity request C1-NotifyExpiringCreditCardReq may be used as a sample. The following points highlight the important configuration for this business object:
· Special BO options are available for activity request BOs to support the Preview Sample functionality.
· Activity Request Preview Service Script. This script is responsible for retrieving the information displayed when a user asks for a preview of a sample of records.
· Activity Request Preview Map. This is the map that is invoked to display the preview sample results.
· The enter algorithm plugged into the Complete state is responsible for selecting all the records that satisfy the criteria and processing the records accordingly.
Setting Up Activity Types
Activity types define the parameters to capture when submitting an activity request via Sample and Submit. To set up an activity type, open Admin Menu, Activity Type.
The topics in this section describe the base-package zones that appear on the Activity Type portal.
Contents
Activity Type List
The Activity Type List zone lists every activity type. The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent activity type.
· The standard actions of Edit, Duplicate and Delete are available for each activity type.
· State transition buttons are available to transition the activity type to an appropriate next state.
Click the Add link in the zone's title bar to add a new activity type.
Activity Type Actions
This is a standard actions zone. The Edit, Delete and Duplicate actions and appropriate state transition buttons are available.
Activity Type
The Activity Type zone contains display-only information about an activity type. This zone appears when an activity type has been broadcast from the Activity Type List zone or if this portal is opened via a drill down from another page.
Please see the zone's help text for information about this zone's fields.
Maintaining Sample & Submit Requests
Use the Sample and Submit transaction to view and maintain pending or historic activity requests. Navigate using Main Menu, Batch, Sample & Submit Request.
Contents
Sample & Submit Request Portal
Sample & Submit Request Query
Use the query portal to search for an existing sample & submit request. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.
Sample & Submit Request Portal
This portal appears when a sample & submit request has been selected from the Sample & Submit Request Query portal.
The topics in this section describe the base-package zones that appear on this portal.
Contents
Sample & Submit
The Sample & Submit zone contains display-only information about an activity (sample & submit) request.
Please see the zone's help text for information about this zone's fields.
Sample & Submit Actions
This is a standard actions zone.
Use the Edit button to modify the parameters. Refer to Preview A Sample Prior to Submitting for more information.
If the activity request is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.
Sample & Submit Log
This is a standard log zone.