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.

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.

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.

CreationCreation

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.
New Transaction With Inactive Department	When true, a new transaction (version 1) can be created with an inactive department as the Transaction Department. When false, the Transaction Department must be valid in the current fiscal year as determined from the Application Date. Modification and Cancellation transaction versions do not read this setting as those always allow an inactive Transaction Departments to account for open transactions at the time the department was deactivated. This control does not apply to department fields within the transaction.
Transaction Unit Required	When true, the Transaction Unit field must be used in transaction creation for identification or security purposes.
New Transaction With Inactive Unit	When true, a new transaction (version 1) can be created with an inactive unit as the Transaction Unit. When false, the Transaction Unit must be valid in the current fiscal year as determined from the Application Date. Modification and Cancellation transaction versions do not read this setting as those always allow an inactive Transaction Units to account for open transactions at the time the unit was deactivated. This control does not apply to unit fields within the transaction.
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.

Processing ActionsProcessing Actions

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	The Collaboration setting, when checked, allows the transaction to use the collaboration function. 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
Journal Posting	This control works in conjunction with the Real Time Journal Posting record on Application Control. When the Journal Posting is Synchronous and Real Time Journal Posting is True, posting lines will post when the transaction going to final. When the Journal Posting is Synchronous and Real Time Journal Posting is False, posting lines will not post when the transaction going to final but will require a run of the Journal Engine system process to get the posting lines into the journals. When the Journal Posting is Asynchronous and with any setting for Real Time Journal Posting, posting lines will not post when the transaction going to final but will require a run of the Journal Posting Initiator and Journal Engine system processes to get the posting lines into the journals. The most common use of this control is for transaction codes that may have incorrect information that would need to be corrected. To do so would require a cancellation of all transactions and the re-entry of the transactions with correct information. This would effectively result in three times the number of postings required if the first transactions had been correct. One example is the check number field on automatic disbursements. If the application is assigning check numbers and pre-printed check stock is used that is out of order, then system assigned numbers will not equal those of the printed checks.
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.
Enforce Transaction Department Validation	This flag determines if the system will validate the value entered in certain fields on Procurement transactions against the Transaction Department to verify that the entered value is authorized for that specific Transaction Department. This flag is only used by the following Transaction Types: Requisition (RQ), Solicitation (SO), Purchase Order (PO), Master Agreement (MA), Invoice (IN), Receiver (RC), Termination (TM), Performance Evaluation (PE), and Renewal (RN).
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.

HeaderHeader

The options presented in this section will apply to most transaction types (limitations are called out) and apply to fields found on the Header tab.

Field Name	Field Description
Transaction Entry Start Transaction Entry End	An optional date that provides the ability to restrict the Record Date of a transaction code from being before or after a certain date. To enforce this limit the Time Restriction field must Limited by Days or Limited by Both. This control is different from the Effective From and To dates in that those are invoked before a transaction is even created using the System Date.
Time Restriction Time Restriction Severity	There are a number of time limits that can be placed on a transaction code, when necessary. Valid values are: No Limit – None Transaction Control time limits apply Limited by Accounting Periods – Limits enforced from setup on the Allowed Accounting Periods for Transaction Code (AAPDC) page. This is the recommended limit to keep transactions out of the special Annual Close accounting periods of 0 and 99 if those periods are not kept close until running the Annual Close Process. Limited by Days – Limits from dates supplied in the Transaction Entry Start and Transaction Entry End apply Limited by Both – Limits on accounting periods and transaction entry dates A choice of three severities: Warning, Override, and Reject are available when a Time Restriction edit is in place.
Transaction Minimum Transaction Maximum	Optional controls that will establish an amount that the header tab of a transaction code must be greater than or less than. A minimum of $99.99 will ensure that a transaction total is $100.00 at a minimum. An amount of ($0.01) will ensure that a transaction total is $0.00 at a minimum. A maximum of $100.01 will ensure that a transaction total is $100.00 at a maximum. An amount of $0.01 will ensure that a transaction total is $0.00 at a maximum When either is exceeded, the Min/Max Severity level will be used when the error is issued. When a value of $0.00 exists in either field, the application considers there to be no minimum or maximum.
Minimum/Maximum [Min/Max] Severity	A choice of three severities: Warning, Override, and Reject are available for both the Transaction Minimum and Transaction Maximum edits.
Transaction Name	When true, the Transaction Name field on the Header tab is required.
Transaction Description	When true, the Transaction Description field on the Header tab is required.Tr
Transaction Header Contact Required	When true, a Header Contact Code is required. Only transaction codes within the JV, ABS, and PR transaction types read this control.
Transaction Total Required	When true, the Transaction Total or Expected Amount on the Header tab will be required. When populated this amount is compared to a system-calculated total to ensure complete and accurate data entry of currency amounts. A secondary use of the field will be with the entry of an Accounting Profile on the Header tab to generate records on the Accounting tab. This indication should not be used for any transaction code that can be created by a system process because there are no batch processes that populate the header amount. The CR, ABS, RE, ITI, IET, and CH transaction types read this control.
Cited Authority Required when Referencing MA	For the spending transaction types that contain the Cited Authority field, this control defines the data entry requirement for the field with the following values: Transaction Referencing a Master Agreement (MA) Not Required Never infer from MA User entered value will be accepted Can be left blank Required (Hard Inference) Always infer from MA Overwrite user entered value. If blank on MA, make it blank on referencing transaction. Issue warning that system has infer value from MA even a blank value. Required (Soft Inference) Only infer from MA when Blank User entered value will be accepted If blanked out, infer it from MA. In case MA has it blank, no inference.
Cited Authority Required on non-reference AL	Stand Alone Transactions Not Required Optional field Can be left blank User entered value will be accepted (should be valid on Cited Authority table) Required Required field Error is issued if left blank User entered value will be accepted (should be valid on Cited Authority table)
Cited Authority Required on Referencing Transaction	For the Purchase Order transaction types that contain the Cited Authority field, this control defines the data entry requirement for the field with the following values: Transaction referencing transactions other than Master Agreement (MA): Not Required Never infer from Purchase Order (PO) User entered value will be accepted Can be left blank Required (Hard Inference) Always infer from PO Overwrite user entered value. If blank on PO, make it blank on referencing transaction. Issue warning that system has inferred value from PO even a blank value. Required (Soft Inference) Only infer from PO when Blank User entered value is accepted If blanked out, infer it from PO. If blank on PO, no inference.
Modification Reason	When true, the Modification Reason field is required for a Travel transaction to record the reason for modifying or cancelling a transaction.
Future Date	When true, a Record Date after the current Application Date is allowed.
Past Date	When true, a Record Date that is before the current Application Date is allowed.
Future Accounting Period	When true, a Period that is before the defaulting accounting period of the current Application Date is allowed.
Past Accounting Period	When true, a Period that is after the defaulting accounting period of the current Application Date is allowed.
Future Fiscal Year	When true, a Fiscal Year that is after the defaulting fiscal year of the current Application Date is allowed.
Past Fiscal Year	When true, a Fiscal Year that is before the defaulting fiscal year of the current Application Date is allowed.
Budget Control Reduction	When true, those transactions that display a Header tab field by the same name will allow a user to select this option to turn the control level of any budget control error received down one level of severity. Please note a warning remains a warning. The PYRL and JV transaction types read this option.
Fund Balance Control Reduction	When true, those transactions that display a Header tab field by the same name will allow a user to select this option to turn the control level of any fund balance control error received down one level of severity. Please note a warning remains a warning. The PYRL and JV transaction types read this option.
Cash Balance Control Reduction	When true, those transactions that display a Header tab field by the same name will allow a user to select this option to turn the control level of any cash balance control error received down one level of severity. Please note a warning remains a warning. The PYRL and JV transaction types read this option.
Infer Deposit Ticket Number	When true, will enable the inference of the Next Available Deposit Ticket Number field from the Bank reference page if the Deposit Ticket field on a Cash Receipt is blank. This control only applies if the Use Deposit Reconciliation option is true and the Print Deposit Ticket option is false on the Revenue tab of the System Options reference page.
Infer Deposit Date	When true, will enable the default of the Deposit Date field on a Cash Receipt to the Application System Date when the Deposit Date is blank. This control only applies if the Use Deposit Reconciliation option is true and the Print Deposit Ticket option is false on the Revenue tab of the System Options reference page.

VendorVendor

The options presented in this section will apply to a limited number transaction types (limitations are called out) and apply to fields found on the Vendor tab.

Field Name	Field Description
Vendor Rule	Enforces that a valid and active vendor must be entered with valid values of Optional, Required, and Prohibited. Certain transaction types will always require a vendor, thus do not use this rule.
Miscellaneous Vendor	Enforces that a valid and active miscellaneous vendor must be entered with valid values of Required, Prohibited, and Optional.
TIN Number & Type for Miscellaneous Vendor	A set of options exist to control entry of taxpayer identification fields: Not Required – Information is never required but allowed. Overrideable – Information is required but can be left blank with an override applied by a user with sufficient override authority. Required – Information is always required. Required for Reportable Funding Only – Information is required only if the Object, Sub Object, BSA, or Sub BSA on any Accounting line has the setup in the 1099 Income Code field on the respective reference page. Overrideable for Reporting Funding Only - Information is required as the option above but can be left blank with an override applied by a user with sufficient override authority. The PR, ABS, and MD transaction types read this control.
Customer Rule	Enforces that a valid and active customer account must be entered with valid values of Optional, Required, and Prohibited. Certain transaction types will always require a customer account, thus do not use this rule.
Disable Inference of Vendor Address	When true, the established Vendor Name, Alias, Contact, and Address Information will not overlay any values supplied to the transaction.
Disable Inference of Contact Information	When true, the established Contact Name and other contact information will not overlay any values supplied to the transaction.
Vendor Invoice	When true, Vendor Invoice Number required. The ABS and PR transaction types read this option.
Vendor Invoice Line Number Default	When true, Vendor Invoice Line Number will default to 1. The ABS, MD and PR transaction types read this option.
Vendor Invoice Date	Three values control data entry for the Vendor Invoice Date Required field: Yes: Vendor Invoice Date is required when Vendor Invoice Number is supplied. No: Vendor Invoice Date is optional when Vendor Invoice Number is supplied. Default: When Vendor Invoice Date is blank the Application Date defaults and the Vendor Invoice Number is populated. The PR, ABS, and MD transaction types read this option.
Invoice Acceptance/Sign Off Date	When true, Invoice Acceptance/Sign Off Date is required. The ABS and PR transaction types read this option.
Tracking Date	When true, Tracking Date is required. Exactly what date is being tracked is determined by policies and procedures. The PR, ABS, IN, and MD transaction types read this control.
Future Tracking Date	When true, the Tracking Date field will allow a date later than the current Application Date.
Transaction Vendor Contact Required	When true, Vendor Contact Name and Vendor Contact Phone number are required. Only transaction codes within the IN, PO, ABS, and PR transaction types read this control.
Allowed Vendor Type	A set of options exist to control which type of vendors are allowed on the transaction: Commodity – Only Commodity Vendors will be allowed, the vendor records on Vendor Customer (VCUST) table with Commodity Vendor flag checked. Service – Only Service Vendors will be allowed, the vendor records on Vendor Customer (VCUST) table with Service Vendor flag checked. Both – All vendor records from Vendor Customer (VCUST) table will be allowed.
Disable Miscellaneous Vendor 1099 Information Updates	This option exists to stop the updates of a 1099 Information (1099I) record for a miscellaneous vendor code when the Legal Name and Address Information are different from the existing record. The 1099 Journal will still be updated with all information. The Payment Request, Accounting Based Spending, Manual Disbursement, Journal Voucher and Payroll transaction types read this setting.

AccountingAccounting

The options presented in this section will apply to a limited number of transaction types (limitations are called out) and apply to fields found on the Vendor tab.

Field Name	Field Description
Default Event Type	Any event type marked as the default for a transaction code on the When the Allowed Event Types for Transaction Code table (AETDC) reference page is displayed in this field.
Transaction Reference	Enforces that a reference to another transaction be made with a Reference Type of Partial, Final, and Inverse with valid values of Optional, Required, and Prohibited. The Reference Type of Memo is not controlled by this setting and can only be enforced by Event Type Requirements setup. This rule only applies to the reference fields found at the accounting line transaction tab. Additionally, it is only the reference fields common to accounting lines and not any special references.
Infer Codes	When true, a reference that is a Reference Type of Partial, Final, or Inverse will infer all the chart of account (COA) codes from the referenced accounting line to the referencing accounting line.
[COA] Precedence	To control COA consistency between referencing and referenced accounting lines, there are three choices: Exact – All COA fields must be exactly the same, including blanks. Additional Codes Allowed – All COA fields completed on the referenced accounting line must be the same on the referencing, but fields originally left blank can be completed. None – Changes can be made to any COA field. COA Precedence control does not apply to the BSA, Sub BSA, OBSA, or the Sub OBSA fields.
Rollup Precedence	To control COA rollup consistency between referencing and referenced accounting lines, there are three choices exist. This is most likely done for any rollups that are budgeted, but can be expanded to include other rollups. Exact – All rollups must be exactly the same, including blanks. Additional Codes Allowed – All rollups inferred on the referenced accounting line must be the same on the referencing, but rollups originally left blank can be inferred. None – Changes can be made to any rollup.
Rollup Exception(s) Rollup Exception Precedence	When all rollup values should not be enforced the same, the Rollup Exception functionality enables the definition of certain rollups to have a different precedence rule than that of Rollup Precedence. Whether the number of rollups that should be restricted is smaller or the number that should not be restricted is smaller will drive setup. Available choices for a value or values in this field are from a listing of all rollups defined to the application. That listing is maintained in a database page with no direct online view called R_ROLLUP_EXCP. If an implementation finds that there are elements or sub elements that should have a different precedence than that of the COA Precedence rule, then those pages can be added to the page and selected as exceptions. One choice available that is not a rollup is the Table Name value of 'R_DEBT_DEBTINST'. This record controls the Debt ID field found on certain transactions. The Rollup Exception Precedence has the same three values as the Rollup Precedence for control.
Service Date Severity	For a select list of transaction types, this control is read to control Service From and To date entry: No Error - The two service dates will default if not manually supplied. Error – Service dates will not default, and the dates are made required fields. When defaulting, if there is a Record Date entered then it will be the default. If Record Date is blank, then the current Application Date will default. The transaction types that read the control are: Internal Exchange Transaction (IET), Internal Transaction Initiator (ITI), Internal Transaction Agreement (ITA), Accounting Based Spending (ABS), Payment Request (PR), Automatic Disbursement (AD), and Manual Disbursement (MD). As service dates are very important for accurate accrual accounting because goods and services are often paid for at a different time than received, this control should be set according to an implementation's accrual reporting needs.
Service Data Editing	For Transaction Types IN, PR, and ABS (Sub type GAX), this field controls additional service date editing beyond the dates being required with the Service Date Severity setting. In fact, use of two settings for this field implies that the Service Date Severity setting is required on referenced as well as referencing transactions. This field includes the following valid values: No editing - No additional editing will occur with service dates beyond the fact the dates have to be valid, only one cannot be entered, and the to date cannot be before the from date. Use referenced transaction only - If there is no partial or final reference to another transaction, then this type of edit will not occur. If there is a partial or final reference, then the Service From and Service To dates of the referencing commodity line (PR or IN) must be equal to or within the Service To and Service From dates of there referenced commodity line. If on the ABS, then the edit is between the referencing and referenced accounting line. Use COA Settings - This choice leads the ABS/PR to look first at any Appropriation codes of each accounting line under a commodity line first to see how if the Appropriation is restricted by this edit or not. If restricted, then the system will look at any Department Object, Sub Object and Object on each accounting line to determine the type of COA edit. Please see the COA Service Date Editing section for more information on this particular setting.
Program Period Inference	Controls whether or not Program Period will infer or not using special inferences for that COA element with the Program Period Infer From and Infer To dates found on the Program Period reference page: Reporting Basis – The Reporting Basis field on the Major Program reference page determines how the inference is done. This option can only be selected for spending, Fixed Asset, and Internal Costing transaction types. Accrual - Pre-Encumbrance and Encumbrance transactions use Record Date. Accrued and Cash Expenditure transactions (referencing an encumbrance or not) use Service From. Cash - Pre-Encumbrance, Encumbrance, Accrued Expenditures, and Cash Expenditure transactions all use Record Date. However, it is the disbursement that provides the Program Period used in the Reimbursement process. Encumbrance - Pre-Encumbrance and Encumbrance transactions use Record Date. Accrued and Cash Expenditures that reference an encumbrance use the Program Period is on the encumbrance. Required-No Inference - Manual entry of the Program Period is required. Prohibited –Major Program should not be used with Program Period. Reference – Inference will be from the referenced accounting line. If there is no referenced accounting line, the Reporting Basis is used if a spending transaction; otherwise, the Record Date will be used. This option cannot be selected for the Fixed Asset Transaction Type. Record Date – Inference will use Record Date. This option cannot be selected for the Fixed Asset Transaction Type. None – No special date inference will be used. Transaction Types: Spending: Pre-Encumbrances (RQ Transaction Type and ABS Transaction Type with GAP Sub Type) Spending: Encumbrances (PO Transaction Type and ABS Transaction Type with GAE Sub Type) Spending: Accrued Expenditures (PR Transaction Type and ABS Transaction Type with GAX Sub Type) Spending: Travel (TRVL Transaction Type) Cash Expenditures (AD, MD, IET, ITA, ITI, and DC Transaction Types) Fixed Assets (FA Transaction Type) Internal Costing (ICT Transaction Type)
Accounting Line Description	When true, the Line Description field on the Accounting tab is required.
Offset BSA Override	When true, values can be supplied on the OBSA (Offset Balance Sheet Account) and Sub OBSA fields on the Accounting tab.
Soft Close Override	When true, a user with sufficient override authority can choose to override the error for a soft closed period or fiscal year being issued from any of the following pages: Fiscal Year (FY), Fiscal Year by Fund (FYFD), Fiscal Year by Department (FYDEPT), Accounting Period (APD), Accounting Period by Fund (APDFD), or Accounting Period by Department (APDDEPT).
Hard Close Override	When true, a user with sufficient override authority can choose to override the error for a soft closed period or fiscal year being issued from any of the following pages: Fiscal Year (FY) or Accounting Period (APD). Please note an override of a hard closed fiscal year will require additional entries to close and roll that adjustment forward as if processed by the Annual Close Process.
Inactive COA	When true, the common error message for an inactive COA element, sub element, and rollup code is suppressed.
Override BFY Staging	When true, the system will change the severity of the error for invalid activity according to Budget Fiscal Year Staging error from a severity of Reject to Override. A user with sufficient override authority can then choose to apply the override to allow the exception to process.
Change Closed Accounting Line	When true, a user can change the chart of account values (given that is allowed by the precedence rules) on an Accounting tab record if a portion or all of the record has been closed. A user's security settings will still be evaluated for modifying the transaction code. When false, the line will have to be modified down to equal the closed amount and a new accounting line entered for that open amount.

CommodityCommodity

The options presented in this section will apply to those transactions with commodity lines. The number of controls is limited, since there are other reference pages that define commodity controls such as Procurement Transaction Control.

Field Name

Field Description

Commodity Line Description

To control information in the Commodity Line Description field of those transaction types that have a Commodity tab there are three settings:

Required – The field is required and will not default from Commodity setup.
Not Required – The field is not required, but if left blank then it will default from Commodity setup.
Defaulted – The field will always default from Commodity setup, it will even overlay a value manually supplied.
Not Applicable – This is the setting for those transaction types that do not have commodity information.

The MA, PO, PR, RN, RQ, SO, SR, and EV transaction types read this control.

Limited ControlsLimited Controls

The options presented in this section will apply to just a single transaction type or apply to other areas of CGI Advantage such as Vendor Self Service.

Field Name	Field Description
Include in VSS Financial Inquiries	When true, enables display in VSS.
Allow PDF Print in VSS	When true, a vendor can access a PDF file in VSS for the transaction. This indicator is only applicable for agreement and invoice transaction codes.
VSS Award/Order Type	Four values are used to define different award categories within VSS: Contract, Delivery Order, Master Agreement and Purchase Order. The Purchase Order category applies to both commodity and non-commodity based orders.
Restrict VSS Access	When true, will default the Restrict VSS Access indication on Vendor Customer Creation (VCC) and Vendor Customer Modification (VCM) transaction types so information from them do not appear in VSS.
Update Vendor Transaction History	When true, the system will track all Vendor Customer Creation (VCC) and Vendor Customer Modification (VCM) transaction types.
Cash Balance Level	Optional cash balancing control can be applied to transaction codes in the Journal Voucher transaction type. No Balancing – There will no cash balancing. Balance at Transaction Level – The total debit and credit updates to cash has to be equal. Balance at Fund And Sub Fund – The total debit and credit updates to cash for each Fund and Sub Fund combination has to be equal. Not Applicable – Although other transaction types do not read this control, this is the setting that should be made outside of the Journal Voucher. The cash indicator found on the Posting Code (PSCD) page is used to define what is considered cash. Separate error messages exist for each level of cash balancing and the Message (MESG) page can be used to set an appropriate severity of each.
Include BFY in Journal Voucher Balancing	When true, Budget Fiscal year is included along with Fiscal Year, Fund, Sub Fund, and Accounting Period when balancing debits and credits.
Event Type Required	When true, the transaction code belonging to the Journal Voucher transaction type requires an event type to be entered on all accounting lines. Journal Vouchers with an event type have an added level of control that will limit users to just the posting codes of that event type.
Calculate Backup Withholding Backup Withholding Amount Error Severity	When true, the system will calculate withholding on Manual Disbursement accounting lines and populate the Withholding Amount field if it is blank. When false, backup withholding will not be calculated and will have to be entered manually if it applies. Four severity levels exist to control the entry of Backup Withholding by comparing it to what is system-calculated: Warning, Overrideable, Error and No Error.
Disable Payee Contact ID Inference	When true, the Payee Contact ID for the Payee Vendor will not infer on a Manual Disbursement so that it has to be entered on a Manual Disbursement.
Use Soft Inference for Payee Contact Name	When true, the Payee Contact Name from the selected Payee Contact ID will only infer if the Payee Contact Name field is blank on a Manual Disbursement. This field does not change the inference of the other contact information (phone, e-mail, etc.). When false, the Payee Contact Name will always infer to what has been established for the vendor.
Update Reimbursement History	All Cash Receipt and Receivable transactions created by the Reimbursement Output process update the Reimbursement History page, by default. When it is desired that manually created transactions for reimbursement billing update the same inquiry, set this field to true. Then all transaction types created manually, or uploaded with the funding COA elements populated, update the inquiry as well for a complete listing of all reimbursement billings and collections.
Payment Type	Payment Type exists on the Payment Request and Accounting Based Spending transactions and is used by the Automated Interest Calculation process to determine if interest is applicable to the disbursement request. Payment Type can be used for reporting and other editing purposes. Payment Types are established on the Payment Scheduling and Interest Control (PSIC) page. When this field is true, Payment Type is required on all accounting lines.
Fixed Asset Intent	When true, a Fixed Asset Intent (FN) transaction must be referenced on an accounting line when that line contains a fund also marked as a Fixed Asset Intent Fund on the Fund reference page.
Business Tax Edit	When true, the Business Tax Number with status as active and Compliance as yes will be allowed on the transactions. If set to false, no validations for Business Tax Number will be performed. The ABS, PR, and IN transaction types read this option.
Allow Invoicing in VSS	When true, the vendor user in the VSS application can create and process an Invoice (IN) transaction against the PO transaction. If set to false, the vendor user in the VSS application cannot process an IN transaction against a PO transaction type.
CEC Invoice Error Severity for Matching	When set to No Error, the system does not issue error A901 on CEC transactions when a valid Invoice transaction reference is not provided. If set to Error, the system issues error A901 on CEC transactions when a valid Invoice transaction reference is not provided. The CEC Sub Type transactions read this option.