Transaction Code (Transaction Control)

The lowest level in the hierarchy is the Transaction Code. All transaction codes are defined on the Transaction Control (DCTRL) reference page. All transaction codes must be unique within the application and not just within a transaction type.

Additions and changes to Transaction Control are expected in any application. Care should be taken when establishing custom transaction codes because the same value may appear as a delivered code in a future upgrade. Unlike many other warnings about setting up custom data, transaction codes are slightly different. Many of the names of custom transaction codes are those used in prior Advantage or other applications. To change the codes that users have become familiar with, is a decision often decided against. Therefore, adequate documentation should be maintained on any custom transaction code setup so that it will not be lost when an upgrade presents a new baseline code that is identical. One way to make custom codes unique, when the opportunity exists to establish a new code, is to use a delivered code followed by a number. Outside of the budgeting area, which uses numbers to tie to a budget structure, accounting transaction codes delivered will not contain numbers. Delivered transaction codes attempt to serve as acronyms, and will not contain numbers.

The primary fields on the Transaction Control (DCTRL) page are as follows with several common ones omitted.

As there are many options for controlling different types of transaction functionality disbursed across this setup page, the help for each control has been grouped into the following sections where similar controls are grouped even further. This order is different from that presented online to facilitate the initial setup of data on this page, which is a critical function to all implementations and subsequent upgrades where new Transaction Codes will be used.

The options presented in this section will apply to all transaction types (or nearly all because of certain transaction type exceptions) and are invoked even before an instance of a transaction is presented for data entry or update.

Field Name	Field Description
Online Creation	When true, new, modification, or cancellation drafts of a transaction code can be created online. A user's security settings would be evaluated to see if the type of draft can be created.
Offline Required	When true, the transaction code should only be created offline. Transaction codes that are for interfaces and created only by batch programs often have this control set to true.
Create	When true, new draft version is allowed. Only the Transaction Function of New is controlled by this option. A user's security settings will still be evaluated for creating the transaction code.
Transaction Unit Required	When true, the Transaction Unit field must be used in transaction creation for identification or security purposes.
Auto Numbering	Three settings determine if auto numbering has to be used: Prohibited – Will not allow automatic numbering so a Transaction ID must be supplied. Required – Automatic numbering is required. Optional – A Transaction ID can be supplied or generated. There are no cross edits between this field and the Auto Numbering (ADNT) page.
Minimum Transaction ID Length Maximum Transaction ID Length	Optional controls that will establish a minimum or maximum Transaction ID length to be more restrictive than the limits on the Application Parameter (APPCTRL) records for Minimum Transaction ID Length and Maximum Transaction ID Length. The Auto Numbering (ADNT) page also edits the Format Field Length field against these controls.
Modify	When true, modification draft versions are allowed. Only the Transaction Function of Modification is controlled by this option. A user's security settings will still be evaluated for modifying the transaction code. Even is marked true, those transaction types that do not allow modifications by design will not allow the action.
Cancel	When true, cancellation draft version is allowed. Only the Transaction Function of Cancellation is controlled by this option. A user's security settings will still be evaluated for cancelling the transaction code. Even is marked true, those transaction types that do not allow cancellations by design will not allow the action.
Alternate Page Code	When a transaction has an alternative view, such as a wizard, the page code for that alternate view should be specified in this field. Completion will enable the View link via the Related Action row-level menu in a worklist. With this action an approver can open an alternate view of a transaction instead of selecting the transaction link to open the standard view. If the transactionAltPageReference property is enabled in the metadata for an application page, then on clicking the transaction hyperlink on that page, the transaction will be opened in the alternate page code view based on the alternate page code defined in this field. If the transactionAltPageReference property is disabled for an application page, the transaction will not be opened in the alternate page code view even if the alternate page code is defined in this field. Also, when a user clicks on any of the transaction hyperlinks in an email sent to the user as part of the Workflow Process Email notification, the system opens the transaction in an alternate page code view based on the value given in this Alternate Page Code field for that transaction code.
Include Attachments on Copy	When this check box is selected, all existing attachments are included within the new transaction when a user modifies an existing transaction using the Activity Folder or Manage Employee Profile page. Attachments can be deleted from the copied transaction if they are not required. Note, changes are required at the transaction level before this check box can be used for a transaction. Currently, this check box only works with Garnishment (GARN), Family Court-Family Arrears-Bankruptcy (FAMC), and Levy (LEVY) transactions when modified from the Deduction Management (DEDM) activity folder and Pay (MEIPAY) landing page.

The options presented in this action will apply to all transaction types (or nearly all because of certain transaction type exceptions) and are after an instance of a transaction is presented for data entry or update and do not apply to just a single transaction tab.

Field Name	Field Description
Collaboration	When true, the Collaborate action for a transaction code. This is the first of several system configurations to use the collaboration function.
Submit	When true, the submit action is allowed by users online. A user's security settings will still be evaluated for submitting the transaction code. When false, the system must perform the submit action. If a transaction code should be allowed to be submitted online, this control should be set to True. If a batch job should only submit the transaction code, this control should be set to No. The default for this indication is True. A user's security settings would be evaluated to see if submitting the transaction code is allowed at the individual level as this DCTRL option is at the system level.
Submit Phase	A setting of Pending means there will be the evaluation of workflow rules with the submit action. A setting of Final means workflow rules will not be evaluated.
Workflow Process	A choice of four values control what type of workflow evaluation will be done: None - No workflow evaluation even if the Submit Phase is Pending. Internal – Advantage workflow will be evaluated if the Submit Phase is Pending. External - 3rd party workflow application integrated into CGI Advantage Financial will be evaluated if the Submit Phase is Pending. Both Internal and External – Both Advantage and 3rd party workflow will be evaluated if the Submit Phase is Pending.
Workflow Asynchronous Processing	When false, after the final approval is applied and there are no new errors, then the transaction will go to final. When true, after the final approval is applied and there are no new errors, the transaction does not go directly to final but stays in pending. It will take another Submit action for the transaction to leave pending and go to final.
Single Approvals Enforced	When true, a user is allowed to apply only one approval to a transaction and the Single Approvals Enforced indication on the Approval Rules (IWF08) page is. When false, a user can apply multiple approvals unless the Single Approvals Enforced indication on the Approval Rules (IWF08) page is true.
Approval Bypass	When true, if the transaction is submitted into workflow, a user with sufficient security settings can choose to bypass all approvals and submit the transaction.
Override Pending Phase	When there are override errors with a transaction code with workflow setup, there are three values that control the override and the approval: Allowed only after reaching - Overrides to be applied in pending and not draft. Required before reaching – Overrides have to be applied in draft. Allowed before or after reaching – Overrides can be applied to either pending or draft
Recurring Transaction	When true, records can be added to the Future Transaction Triggering (FDT) page to create copies of the transaction.
Component-Specific Application Resource	When true, a tab-specific application resource should be used for tab security so that the system performs security authorization at the transaction tab level as the application resource rather than transaction code.
Log Discard	When true, all discards of draft transactions will be tracked on the Transaction Discard Log (DSCRDLOG) page.
Apply Effective Dates Unchanged Edit	When checked, allows users to ensure the effective dates are updated for all transactions that affect the timeline maintained tables. When checked, if transaction affecting the timeline maintained tables are modified without changes to effective dates then an overrideable error message is generated.
Infer Home Department	This setting is the second point in the security configuration to infer the Home Department for users. The first is the Infer Home Department and Unit indication on the User Information (SCUSER) security page. When that is true, the system then looks to this transaction configuration for whether or not the inference should happen for a specific transaction code. As the inference does not occur during batch processing, this setting does not apply to transaction codes that will only be created by system processing.
Infer Home Unit	When using Unit for security purposes for a transaction code, this setting is the second point in the security configuration to infer any Home Unit defined for users. The first is the Infer Home Department and Unit indication on the User Information (SCUSER) security page. When that is true, the system then looks to this transaction configuration for whether or not the inference should happen for a specific transaction code. As the inference does not occur during batch processing, this setting does not apply to transaction codes that will only be created by system processing. A setting of true is only allowed for this field if the Infer Home Department indication is also true.

Refer to the "Transaction Code (Transaction Control)" topic in the Financial Administration User Guide for information on the options provided on this page in the Advantage Financial application.

Field Name	Field Description
Transaction Category	The inferred transaction category value from the transaction type value entered.
Transaction Type	Every transaction code must be assigned to a transaction type.
Transaction Code	Each transaction code is identified by a unique identifier.
Sub Type	The optional transaction sub type to which a transaction code will be defined.
Home Application	One of a variety of choices will designate that a resource (transaction code in this case) belongs to a certain application. This required value will be used when filtering pages such as the Transaction Catalog and Worklists based on the application to which a user has logged into.