The lowest level in the hierarchy is the Document Code. All document codes are defined on the Document Control table. All document codes must be unique within the application and not necessarily within a document type.
Additions and changes to the Document Control table are expected in any application. Care should be taken when establishing custom document codes because the same value may appear as a delivered code in a future upgrade. Unlike many other warnings about setting up custom data, document codes are slightly different. Many of the names of custom document codes are those used in prior Advantage or other applications. To change the codes users have become familiar with is a decision often decided against. Therefore, adequate documentation should be maintained on any custom document 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 document codes delivered will not contain numbers. Delivered document codes attempt to serve as acronyms, and will not contain numbers.
The fields on the Document Control (DCTRL) table by section are as follows:
Field Name |
Field Description |
Document Category |
The inferred document category value from the document type value entered. |
Document Category Name |
The inferred document category name associated with the document category on the Document Category table. |
Document Type |
Every document code must be assigned to a document type. This document type will provide the data structure for the document code as well as many document-specific edits and update logic. Values entered must be a valid value on the Document Type table. |
Document Type Name |
The inferred document type name associated with the document type on the Document Type table. |
Document Code |
Each document code is identified by a unique identifier from 1 to 8 characters/digits in length that must be unique within the application and not just within a document type. |
Document Name |
Each document code requires a name to be used for identification and reporting purposes that can be up to 60 characters/digits in length. This name should match the Description field on the Application Page Registration entry for the document code for consistency. |
Document Short Name |
Each document code requires a short name to be used for identification and reporting purposes that can be up to 15 characters/digits in length. |
Sub Type |
The optional document sub type to which a document code will be defined. Values entered must be a valid on the Document Sub Type table. Leaving this value blank when a document type has specific sub type logic will cause that logic not to be invoked on the document code. |
Sub Type Name |
The inferred document sub type name associated with the document sub type on the Document Sub Type table. |
Home Application |
One of a variety of choices will designate that a resource (document code in this case) belongs to a certain application. This required value will be used when filtering pages such as the Document Catalog and Worklists based on the application to which a user has logged into. |
Effective From |
When the application should not allow any use of a document code before a certain date, that calendar date is entered as the Effective From date. The infrastructure of the application will not recognize the document code as being valid when the application date is before this Effective From date. In fact, the application will state that no entry for the document code can be found on the Document Control table. This date is optional and is the most restrictive for controlling when a document code can be used as the date stops document creation, modification, and editing. |
Effective To |
When the application should not allow any use of a document code after a certain date, that calendar date is entered as the Effective To date. The infrastructure of the application will not recognize the document code as being valid when the application date is after this Effective To date. In fact, the application will state that no entry for the document code can be found on the Document Control table. This date is optional and is the most restrictive for controlling when a document code can be used as the date stops document creation, modification, and editing. |
Active |
An indication that will allow all types of new drafts (new, modification, and cancellation) of a document code if those individual actions are also allowed. Selected is the default value for the flag. |
Field Name |
Field Description |
Default [Def] Event Type |
When the Allowed Event Types for Document Code table has specified an event type as the default for a document code (this table is discussed later in this Document Configuration section), that event type will appear in this Def Event Type field. From here, it will default to the accounting line of the document code upon the Validate or Submit action being taken with no event type specified. |
Document [Doc] Entry Start |
An optional control that provides the ability to restrict the Document Record Date of a document code from being before a certain date. To enforce the start date edit, the Time Restriction field must be set to Limited by Days or Limited by Both. This control is different from the Effective From date in that it is invoked after a document version is created when the first validation is performed on the document with a manually entered Document Record Date or an inferred one from the Application Control table. The Effective From date edits before a document version is even created using the System Date. |
Document [Doc] Entry End |
An optional control that provides the ability to restrict the Document Record Date of a document code from being after a certain date. To enforce the end date edit, the Time Restriction field must be set to Limited by Days or Limited by Both. This control is different from the Effective To date in that it is invoked after a document version is created when the first validation is performed on the document with a manually entered Document Record Date or an inferred one from the Application Control table. The Effective To date edits before a document version is even created using the System Date. |
Document Minimum |
An optional control that will establish an amount that the header component of a document code must be above. An amount of $99.99 will ensure that a document total is $100.00 at a minimum. An amount of ($0.01) will ensure that a document total is $0.00 at a minimum. When the minimum is exceeded, the Min/Max Severity level will be used when the error is issued. When a value of $0.00 exists in the field, the application considers there to be no minimum, and $0.00 is also the default. |
Document Maximum |
An optional control that will establish an amount that the header component of a document code cannot be below. An amount of $100.01 will ensure that a document total is $100.00 at a maximum. An amount of $0.01 will ensure that a document total is $0.00 at a maximum. When the maximum is exceeded, the Min/Max Severity level will be used when the error is issued. When a value of $0.00 exists in the field, the application considers there to be no minimum, and $0.00 is also the default. |
Minimum/Maximum [Min/Max] Severity |
A choice of three severities: Warning, Override, and Reject are available for both the Document Minimum and Document Maximum edits. The severity setting is not used if the minimum or maximum amounts are $0.00 as those values are considered as 'no limits' by the application. Warning is the default value. |
Vendor Rule |
A choice of three values: Required, Prohibited, and Optional are available to control vendor code data on a document code. When set to Required, there must be a vendor/customer code entered on the document that is an active vendor. When set to Optional, a vendor/customer code that is an active vendor can be entered or left blank. When set to Prohibited, then a vendor/customer code cannot be entered. The value must be Prohibited if the Customer Rule is Required. The default value is Optional. Care should be taken that this rule not conflict with the Event Type Requirement rule of the same name for the event types allowable for the document code. Additionally, certain document types will always require a vendor/customer code, thus do not use this rule as other document types. |
Customer Rule |
A choice of three values: Required, Prohibited, and Optional are available to control customer code data on a document code. When set to Required, there must be a vendor/customer code entered on the document that is an active customer. When set to Optional, a vendor/customer code that is an active customer can be entered or left blank. When set to Prohibited, vendor/customer code cannot be entered. The value must be Prohibited if the Vendor Rule is Required. The default value is Optional. Care should be taken that this rule not conflict with the Event Type Requirement rule of the same name for the event types allowable for the document code. |
Referenced [Ref] Document Rule |
A choice of three values: Required, Prohibited, and Optional are available to control referencing that is a reference type of Partial, Final, or Inverse on a document code. When set to Required, there must be a reference of one of those types. When set to Optional, a reference can be entered of any type or left blank. When set to Prohibited, a reference of one of those three types cannot be entered. Only a Memo reference or no reference at all will be allowed. The default value is Optional. This rule only applies to the reference fields found at the accounting line document component. Additionally, it is only the reference fields common to accounting lines and not any special references. Care should be taken that this rule not conflict with the Event Type Requirement rule of the same name for the event types allowable for the document code. Additionally, it should not conflict with setup for the document code on the Document Event Types table in BFY Staging. |
Chart of Accounts [COA] Precedence |
A required choice of three values: Exact, None, and Additional Codes Allowed are available to control the Chart of Account element and sub element values between a referencing and referenced accounting lines for the Partial, Final, and Inverse reference types only. When set to Exact, which is the default, all values must be the same on the referencing line as the referenced line. This setting should be accompanied by a check in the Infer Codes field. When set to Additional Codes Allowed, any values on the referenced line should not change on the referencing line. Any values left blank on the referenced line can be completed or left blank on the referencing line. This setting should also be accompanied by a check in the Infer Codes field. When set to None, there will be no comparison of values between the referencing and referenced lines. With this setting, the Infer Codes flag can either be checked or not, depending on how much the COA will likely change. The COA Precedence control does not apply to the BSA, Sub BSA, OBSA, or the Sub OBSA fields. The control does apply to all other COA elements and sub elements, but not any rollups. |
Rollup Precedence |
A required choice of three values: Exact, None, and Additional Codes Allowed are available to control the rollup values between a referencing and referenced accounting lines for the Partial, Final, and Inverse reference types only. When set to Exact, all rollup values must be the same on the referencing line as the referenced line. When set to Additional Codes Allowed, any rollup values on the referenced line should not change on the referencing line. Any rollup fields left blank on the referenced line can be completed or left blank on the referencing line. When set to None, which is the default, there will be no comparison of rollup values between the referencing and referenced lines. |
Rollup Exception(s) |
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 the Rollup Precedence field. The most common application of this feature is when budgeting is done at the rollup level. In such a case, it is often desired that the rollup budgeted not change between referencing but all other rollups are allowed to change. Available choices for a value or values in this field are from a pick list of all rollups defined to the application. That listing is maintained in a database table 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 tables can be added to the table 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 documents. The exceptions field defaults to blank and does not require any values. Any value manually entered must be valid on the table mentioned above that is used by the pick feature. |
Rollup Exception Precedence |
If one or more values are specified in the Rollup Exception(s) field, a choice of three values: Exact, None, and Additional Codes Allowed is made to control the rollup exception fields between a referencing and referenced accounting lines for the Partial, Final, and Inverse reference types only. When set to Exact, all exceptions must be the same on the referencing line as the referenced line. When set to Additional Codes Allowed, any exceptions not completed on the referenced line can be completed on the referencing line or left blank. When set to None, which is the default, there will be no comparison of the exceptions between the referencing and referenced lines. |
Time Restriction Severity |
A choice of three severities: Warning, Override, and Reject are available when a Time Restriction edit is in place. The default is Warning. |
Time Restriction |
A choice of no restriction and three types of time restrictions are available: No Limit, Limited by Days, Limited by Accounting Periods, and Limited by Both. When set to Limited by Days, values established in the Doc Start Date and Doc End Date will restrict use of the document code. When set to Limited by Accounting Periods, values established on the Allowable Accounting Periods for Document Code (AAPDC) table will restrict use of the document code. When set to No Limit, which is the default, then there will be no time restriction limiting even if the dates or the APPDC table have values. It is suggested and the application is delivered with all document codes being limited by accounting periods. This is done to prevent users from manually entering the accounting periods of 0 and 99, which are for the Annual Closing process. |
Override Pending Phase Indicator [Override Pend Phase Ind] |
A choice of three values: Allowed only after reaching, Required before reaching, and Allowed before or after reaching control when any applicable overrides can or should be applied for a document with a Pending Submit Phase. When set to Allow only after reaching, the document code will not allow overrides to be applied unless the document is in pending and not draft. When set to Required before reaching, which is the default, any necessary overrides must be applied before the document code can be submitted to pending. When set to Allowed before or after reaching, any necessary overrides can be applied whether the document code is in draft or pending. |
Submit Phase |
The submit action on a document with no rejection errors or override errors will look to this Submit Phase field to determine if the document should go to final or go to pending so that workflow rules can be evaluated. Unless Submit Phase is set to Pending, no workflow rules established in the CGI Advantage Administration application will be evaluated. If there are no workflow rules for a document code, the Submit Phase should be set to Final to eliminate application resources from searching for workflow rules. The default is Final and a blank value is not allowed for this field. |
Workflow Process Indicator |
A choice of four values: None, Internal, External, and Both Internal and External exist to control what type of workflow, if any, will be used. When set to None, which is the default, there will be no workflow evaluation even if the Submit Phase is Pending. When set to Internal, the workflow rules established on the Approval Setup (IWF08) table in the CGI Advantage Administrator application will be evaluated. When set to External, workflow rules in a 3rd party workflow application integrated into CGI Advantage Financial will be evaluated. When set to Both Internal and External, workflow rules in the CGI Advantage Administration application and an integrated 3rd party workflow application will be evaluated. The last three options only occur when the Submit Phase is set to Pending. |
Workflow Asynchronous Processing |
When set to No, which is the default, a document that meets an internal workflow rule will be sent into the appropriate worklist. After the final approval is applied to the document and there are no new errors, then the document will go to final. When set to Yes, the behavior after the final approval is different. The document does not go directly to final but stays in pending. It will take a user applying another submit action for the document to leave pending and go to final. |
Single Approvals Enforced |
This flag indicates whether a user is allowed to apply multiple approvals to the same document. If this checkbox is not selected then a single user is allowed to apply multiple approvals to the same document, unless the Single Approvals Enforced flag on the Approval Rules (IWF08) page is selected. If the Single Approvals Enforced flag on the Document Control (DCTRL) page is selected, then the Single Approvals Enforced flag on the Approval Rules (IWF08) page is not referenced by CGI Advantage and multiple approvals to the same document are not allowed by a single user. |
Service Date Severity |
For those document types with Service Date fields: Internal Exchange Transaction (IET), Internal Transaction Initiator (ITI), Internal Transaction Agreement (ITA), Accounting Based Spending (ABS), Payment Request (PR), Automatic Disbursement (AD), and the Manual Disbursement (MD); this control is read to determine if service dates should default or have to be manually entered. If set to No Error, then the Service To and From dates will default to the document record date. If set to Error, then the user must enter a Service From date at a minimum. The default is No Error and a blank value is not allowed for this field. 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. |
Infer Codes |
When a reference that is a reference type of partial, final, or inverse is performed on a document code with this flag set to Yes, the chart of account values from the referenced accounting line will be inferred to the referencing accounting line. If this flag is set to No, values will not be inferred to the referencing document. The default is Yes for the flag. A setting of Yes is the most appropriate for a document code that references others and has at least one of the three precedence settings equal to Exact or Additional Codes Allowed. |
Journal Posting Control |
One of two values: Synchronous Posting and Asynchronous Posting exist to control whether a document code will have posting lines that are marked as 'Ready to Post' when the document goes to final. A blank value is not allowed for the field. If set to Synchronous, which is the default, then the Journal Posting field will be set to 'Ready to Post' when the document codes go to final. If real time posting is enabled on the Application Control table, then that posting line will be posted along with the document going to final and that have a Journal Posting value of 'Posted'. If real time posting is not enabled, the posting line will remain 'Ready to Post' until the Journal Engine batch job is run and the posting line posted. If set to Asynchronous Posting, then the Journal Posting field will be set to 'Not Ready' when the document goes to final. The Journal Posting Initiator batch job would then have to be run to change the Journal Posting field to 'Ready to Post' and then the Journal Engine to post the line and change the value to 'Posted. The most common use of this control is for document codes that may have incorrect information that would need to be corrected. To do so would require a cancellation of all documents and the re-entry of the documents with correct information. This would effectively result in three times the number of postings required if the first documents 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. |
Program Period Inf |
This field determines whether the Program Period Code (PPC) should be inferred onto documents (by Document Code), and if so, how it should be inferred. This field can have one of the following values: Reporting Basis, Reference, Record Date, or None. Refer to field level help for more information on this field. |
Include in VSS Financial Inquiries |
This flag determines if financial transactions with the selected Document Code are displayed to vendors in the Financial Transactions section of VSS. The types of transactions that are displayed in VSS include agreements, scheduled payments, disbursements, and invoices. Vendors can inquire, view, download, print and create invoices via the VSS application.. |
Allow PDF Print in VSS |
This flag determines if a vendor can access a PDF file in VSS for transactions with the selected Document Code. This flag is only applicable for agreement and invoice document codes. |
VSS Award/Order Type |
The VSS Award/Order Type field is used to define the award type for Document Codes that are agreements. This field is used to define the sort sequence for agreements in the Financial Transactions section and can also be used by vendors to search for specific types of agreements. Valid values include Contract, Delivery Order, Master Agreement and Purchase Order. The Purchase Order category applies to both commodity and non-commodity based orders. |
Restrict VSS Access |
Selection of the Restrict VSS Access flag prevents Vendor/Customer records from being displayed in the Vendor Self Service (VSS) application. The value in this field is inferred on the Vendor Customer Creation (VCC) and Vendor Customer Modification (VCM) document types, if the Restrict VSS Access field on the document is blank. |
Cash Balance Level |
This field determines whether or not a Document Code for the Journal Voucher (JV) Document Type will have to balance cash entries and at what level. 1 – No Balancing, 2 – Balance at Document level, and 3 – Balance at Fund & Sub Fund level. If the value is 1, then no cash balance editing will be done. If the option is 2 or 3, then the JV will determine which accounting lines are cash by using the cash indicator found on the Posting Code (PSCD) page. 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. |
Auto Numbering |
This field determines if auto numbering is Prohibited, Required or Optional when generating this document code’s document ID. When a document code should never be created with a manually entered Document ID, this control should be set to Required. If a manually entered Document ID should always be entered for the document code, this control should be set to Prohibited. If automatic numbering should be optional for a document code, then this field should be set to Optional. There is no default for the control and the field cannot be left blank. There are no cross edits between this field and the Auto Numbering (ADNT) page. |
Min Doc ID Length |
An optional field to store a minimum Document ID length for a document code. The default value is blank. When a document code should have a different minimum Document ID length than what is configured on Application Parameters (APPCTRL) Minimum Document ID Length record, that length is entered in this field. The Auto Numbering (ADNT) page edits the Format Field Length field against this DCTRL field. If blank on DCTRL, the APPCTRL control is used. If entered on DCTRL, the APPCTRL control is not used. |
Max Doc ID Length |
An optional field to store a maximum Document ID length for a document code. The default value is blank. When a document code should have a different maximum Document ID length than what is configured on Application Parameters (APPCTRL) Maximum Document ID Length record, that length is entered in this field. The Auto Numbering (ADNT) page edits the Format Field Length field against this DCTRL field. If blank on DCTRL, the APPCTRL control is used. If entered on DCTRL, the APPCTRL control is not used. |
Document Contact Required |
A flag to enforce a Contact Code be entered on the header of a document code. When unchecked, contact information is optional. Only document codes within the JV, ABS, and PR document types read this control. |
Disable Vendor Address Info |
This control should be set to Yes if the Vendor Name, Alias, Contact, and Address Information should not override the user’s entry with values from the Vendor table. The default is No. If set to No, the Vendor Name, Alias, Contact, and Address Information will always be inferred from the Vendor table. |
Disable Vendor Contact Info |
If selected, the flag prevents the Vendor’s Contact Name and contact information provided on the Vendor Line of the document from being overridden by an automatic inference from VCUST. |
Require Fixed Asset Intent |
When checked this document must reference a Fixed Asset Intent (FN) document when the Fund being used is marked as Fixed Asset Intent Fund on the FUND table. |
Log Document Discard |
The Log Document Discard flag provides the ability to track discarded (deleted) draft documents. When checked the system logs all documents that have been discarded / deleted to the Document Discard Log (DSCRDLOG) page that can be queried. Documents discarded before the flag is checked are not tracked. Also, the page tracks only discarded drafts, not to be confused with using the discard action to create a cancellation document. However, if that cancellation draft is discarded, it will be tracked. |
Include BFY in JV Balancing |
The Include BFY in JV Balancing flag determines if BFY is included or excluded in the JV Balancing Logic. If checked (set to True), the JV balancing logic includes BFY in addition to the current balancing fields of Fiscal Year, Fund, Sub Fund, and Accounting Period. |
Infer Deposit Ticket Number |
The Infer Deposit Ticket Number flag on the Document Control (DCTRL) page indicates whether the Deposit Ticket field on the Cash Receipt (if blank on Validate/Submit) should be inferred from the Next Available Deposit Ticket Number field on the Bank (BANK) table. This flag can only be selected if the Document Type is CR for the selected record. Note: This flag only applies if the Use Deposit Reconciliation flag is selected and the Print Deposit Ticket flag is not selected on the System Options (SOPT) table for the current Fiscal Year. When this functionality is used and the Next Available Deposit Ticket Number is inferred onto the CR, the value on the BANK table is then incremented by 1 even if that Cash Receipt is not submitted to Final. |
Infer Deposit Date |
The Infer Deposit Date flag on the Document Control (DCTRL) page indicates whether the Deposit Date field on the Cash Receipt (if blank on Validate/Submit) should be inferred from the Application System Date (APPL_SYS_DT) parameter on the Application Parameters (APPCTRL) table. This flag can only be selected if the Document Type is CR for the selected record. Note: This flag only applies if the Use Deposit Reconciliation flag is selected and the Print Deposit Ticket flag is not selected, or if the Use Deposit Date Only flag is selected on the System Options (SOPT) table for the current Fiscal Year. |
Field Name |
Field Description |
Document Name Required |
When a document code should have a value in the Document Name field on the document header, this control should be set to Yes. The default is No. |
Document [Doc] Description Required |
When a document code should have a value in the Document Description field on the document header, this control should be set to Yes. The default is No. |
Accounting Line [AL] Description Required |
When a document code should have a value in the Line Description field on the accounting line component, this control should be set to Yes. The default is No. |
Event Type Required |
Most document types require an event type to be entered on all accounting lines. The Journal Voucher is one that does not. The event type is entered on the Line Group component of that document. When a Journal Voucher should always have an event type, this control should be set to Yes. 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. The default for this flag is Yes, which will have no processing impact on document codes that are not in the JV document type. |
Cited Authority Required |
This field is set up on the Document Control (DCTRL) table, and can have one of the following values:
All document types performing the Cited Authority validation will perform a look-up to this table to see if the document meets the requirement for use of a Cited Authority. Documents not using a Cited Authority will not reference this value on the Document Control table. |
CL Description Required |
This field indicates whether the CL Description field on the selected commodity-based document is Required, Not Required, or Defaulted |
Document Total Required |
This field is applicable to the CR Document Type only. If selected, the Document Total field on the Header of the CR document is required and must equal the system calculated Actual Amount field. If the Document Total Required field is not selected, the Document Total field on the CR is optional but if populated, will still be verified against the Document Actual Amount. |
Offline Required |
When a document code should only be created offline, this control should be set to Yes. The default is No. When set to Yes and a user attempts to create a document on the Create tab of the Document Catalog, an error will be issued. When set to No, either online or offline creation is allowed. Document codes that are for interfaces and created only by batch programs often have this control set to Yes. |
Automatic [Auto] Numbering Required |
When a document code should never be created with a manually entered document ID, this control should be set to Yes. The default is No. When set to Yes, if a user tries to create a document from the Create tab of the Document Catalog and does not check the Auto Number flag, an error will be issued. When set to No, either manually entered or automatically generated document numbers can exist for a document code. |
Document Unit Code Required |
When a document code should require a Document Unit value in the document identification for security purposes, this control should be set to Yes. The default is No. By having a Document Department and Unit, security will be enabled at any organizational level from Government Branch through Unit. Without a Unit, no organizational element below Department can be inferred for security. When the control is set to No, Document Units can be entered or left blank. |
Vendor Invoice Required |
For those document types that contain Vendor Invoice fields, this control can make that Vendor Invoice Number required if set to Yes. When set to No, the default, Vendor Invoice information can be completed or left blank. The Accounting Based Spending (ABS) and Payment Request (PR) document types are the only document types which read this option. |
Vendor Invoice Line No Default |
The Vendor Invoice Line No Default flag controls whether the Vendor Invoice Line Number should automatically default when a Vendor Invoice Number is entered on documents of the PR, ABS, or MD document type. Valid options for this field are: Yes (selected) or No (not selected). The default value for this field is, No (not selected). For detailed information about this field, refer to field level help. |
Vendor Invoice Date Required |
The Vendor Invoice Date Required field controls whether the Vendor Invoice Date is required when a Vendor Invoice Number is entered on documents of the PR, ABS, or MD document type. Valid options for this field are: Yes, No, or Default. The default value for this field is, No. For detailed information about this field, refer to field level help. |
Tracking Date Required |
The Tracking Date Required flag controls whether the Tracking Date is required on documents of the PR, ABS, IN, and MD document types. When checked the date goes from being optional to required, collecting date information. Exactly what date is being tracked is determined by policies and procedures. |
Payment Type Required |
The Payment Type Required flag controls whether a user has to make a selection in the Payment Type field on the accounting line of document codes in the PR and ABS document types that request payment. When checked the information goes from being optional to required, collecting a Payment Type. The Payment Type will be used by the Automated Interest Calculation batch job should interest be applicable to the payment. If not, the Payment Type is for reporting purposes. The Payment Scheduling and Interest Control (PSIC) is the page where Payment Types are established. |
Invoice Acceptance/Sign Off Date Required |
For those document types that contain the Invoice Acceptance/Sign Off Date, this control can make that date required if set to Yes. When set to No, the default, the Invoice Acceptance/Sign Off Date can be entered or left blank. The Accounting Based Spending (ABS) and Payment Request (PR) document types are the only document types which read this option. |
Field Name |
Field Description |
Future Document [Doc] Date Allowed |
If users and batch programs are to be allowed to enter document record dates that are greater than the Application Date, then this control should be set to Yes. The default is No. If set to No, no dates greater than the current can exist for the document code. This field is only applicable for accounting documents. |
Past Document [Doc] Date Allowed |
If users and batch programs are to be allowed to enter document record dates that are less than the Application Date, then this control should be set to Yes. The default is No. If set to No, no dates less than the current can exist for the document code. This field is only applicable for accounting documents. |
Future Accounting Period [Acctg Prd] Allowed |
If users and batch programs are to be allowed to enter accounting periods that are greater than the default accounting period for the Application Date as determined on the Calendar Date table, then this control should be set to Yes. The default is No. If set to No, no accounting periods greater than the current can exist for the document code. This field is only applicable for accounting documents. |
Past Accounting Period [Acctg Prd] Allowed |
If users and batch programs are to be allowed to enter accounting periods that are less than the default accounting period for the Application Date as determined on the Calendar Date table, then this control should be set to Yes. The default is No. If set to No, no accounting periods less than the current can exist for the document code. By checking this control, it will prohibit the entry of adjustment accounting periods in the prior year to be used on the document code. This field is only applicable for accounting documents. |
Future Fiscal Year [FY] Allowed |
If users and batch programs are to be allowed to enter fiscal years that are greater than the default fiscal year for the Application Date as determined on the Calendar Date table, then this control should be set to Yes. The default is No. If set to No, no fiscal year greater than the current can exist for the document code. This field is only applicable for accounting documents. |
Past Fiscal Year [FY] Allowed |
If users and batch programs are to be allowed to enter fiscal years that are less than the default fiscal year for the Application Date as determined on the Calendar Date table, then this control should be set to Yes. The default is No. If set to No, no fiscal year less than the current can exist for the document code. This field is only applicable for accounting documents. |
Offset Override Allowed |
If users are to be allowed the option of entering an offset balance sheet account (OBSA) on a document code instead of letting them default, then this control should be set to Yes. When set to Yes, a user will not have to enter the offset, but is given the option. If there is no default balance sheet available for the offset posting code of the event type used, then the user will certainly have to enter the OBSA. When set to No, which is the default, a user will be allowed to enter a value in the OBSA accounting line field. |
Soft Close Override Allowed |
If users with appropriate override authority should be allowed to override a soft closed accounting period or fiscal year error, then this option should be set to Yes. If set to No, which is the default, the soft close errors will be issued as reject errors without override ability. |
Hard Close Override Allowed |
If users with appropriate override authority should be allowed to override a hard closed accounting period or fiscal year error, then this option should be set to Yes. If set to No, which is the default, the hard close errors will be issued as reject errors without override ability. |
Inactive Chart of Account [COA] Codes Allowed |
COA element, sub element, and rollup codes marked as inactive on their respective reference tables result in an overrideable error message on documents when used. Only those users with appropriate override authority can apply overrides and use the code when this Inactive COA Codes Allowed flag is set to No. If set to Yes, then no error message will be issued. The default for the flag is No. |
Component Specific Application Resource Allowed |
This flag indicates whether a component-specific application resource should be used for component security for the specified document code. The default for this flag is No (not selected), indicating that the document code is used for all security checks on the document, header, and component. If the flag is checked, the system performs security authorization at the document component level as the application resource rather than document code itself. When component security is to be used, the application has to be enabled to perform this type of security as well as setup within the Administration application. Please refer to documentation on security setup before checking this flag. |
Funding Profile/Priority/Line Allowed |
This flag indicates whether the Funding Profile, Funding Priority, and Funding Line fields are visible on the accounting lines of the RE/CR document codes that use the fRE/fCR HTML. The Cost Accounting Receivable (CARE) and Cost Accounting Cash Receipt (CACR) document codes are delivered with this flag checked. All other document codes are delivered with this flag cleared (not checked). By selecting this flag for RE/CR document codes that use the fRE/fCR HTML you can capture the funding source information for revenue or cash received, respectively. |
Future Tracking Date Allowed |
This control should be set to Yes if the users are allowed to enter a date that is greater than the current system date from APPCTRL. The default is No. If set to No, a future date is not allowed. |
Allow Miscellaneous Vendor |
A choice of three options: Required, Prohibited, and Optional. A miscellaneous vendor is a vendor/customer code that is marked as Miscellaneous Vendor on the Vendor/Customer (VCUST) table. When set to Required, a miscellaneous vendor is required on the respective document code. If set to Prohibited, then a miscellaneous vendor is not allowed to be entered on the respective document code. If Optional, then a miscellaneous vendor can be entered on the respective document code. |
New Action Allowed |
If new draft versions of a document code are allowed to be created, then this control should be set to Yes. If set to No, a new draft cannot be created. Only the document function of New is controlled by this flag in the creation of a new draft. Functions of Modification and Cancellation that create new modifications and new cancellations are not controlled by this flag. Other controls listed below govern those functions. The default for this flag is Yes. A user's security settings would be evaluated to see if creating the document code is allowed at the individual level as this DCTRL option is at the system level. |
Modify Action Allowed |
If a modification draft version of a document code is allowed to be created, then this control should be set to Yes. If set to No, a modification draft cannot be created. The default for this flag is Yes. Even if set to Yes, various document types will prevent a cancellation draft from being created with document-specific logic. The Journal Voucher and Fixed Asset document types are two such examples. A user's security settings would be evaluated to see if creating a modification draft of the document code is allowed at the individual level as this DCTRL option is at the system level. |
Submit Action Allowed |
If a document code should be allowed to be submitted online, this control should be set to Yes. If a batch job should only submit the document code, this control should be set to No. The default for this flag is Yes. A user's security settings would be evaluated to see if submitting the document code is allowed at the individual level as this DCTRL option is at the system level. |
Cancellations Allowed |
If cancellation draft version of a document code is allowed to be created, then this control should be set to Yes. If set to No, a cancellation draft cannot be created. The default for this flag is Yes. Even if set to Yes, various document types will prevent a cancellation draft from being created with document-specific logic. The Journal Voucher and Disbursement Reclassification document types are two such examples. A user's security settings would be evaluated to see if creating a cancellation draft of the document code is allowed at the individual level as this DCTRL option is at the system level. |
Online Catalog Creation Allowed |
When new, modification, or cancellation drafts of a document code should be allowed to be created online, this control should be set to Yes. If set to No, then new draft, modification, and cancellation versions of a document code can only be created by a batch program. The default for this flag is Yes. A user's security settings would be evaluated to see if the type of draft can be created at the individual level as this DCTRL option is at the system level. |
Allow Budget Control Reduction |
This control enables a document code the ability to have the Budget Control Reduction flag set to Yes on a document so that budget constraint errors issued will be reduced one level in severity (reject to override, override to warning, and warning remains warning). When set to Yes on the Document Control table, if the corresponding flag is set to Yes on a document then no error about the reduction ability will be issued. If set to No, which is the default, on the Document Control table but set to Yes on a document, an error will be issued that the ability is not allowed. The Journal Voucher (JV) and Payroll (PYRL) document types have the corresponding document flag. |
Allow Fund Balance Control Reduction |
This control enables a document code the ability to have the Fund Balance Control Reduction flag set to Yes on a document so that fund balance errors issued will be reduced one level in severity (reject to override, override to warning, and warning remains warning). When set to Yes on the Document Control table, if the corresponding flag is set to Yes on a document then no error about the reduction ability will be issued. If set to No, which is the default, on the Document Control table but set to Yes on a document, then an error will be issued that the ability is not allowed. The Journal Voucher (JV) and Payroll (PYRL) document types have the corresponding document flag. |
Allow Cash Balance Control Reduction |
This control enables a document code the ability to have the Cash Balance Control Reduction flag set to Yes on a document so that cash balance errors issued will be reduced one level in severity (reject to override, override to warning, and warning remains warning). When set to Yes on the Document Control table and if the corresponding flag is set to Yes on a document then no error about the reduction ability will be issued. If set to No, which is the default, on the Document Control table but set to Yes on a document, then an error will be issued that the ability is not allowed. The Journal Voucher (JV) and Payroll (PYRL) document types have the corresponding document flag. |
Override of BFY Staging Allowed |
If a Document Code should have the ability to override BFY Staging errors issued, then this control should be selected. When selected, the reject errors for document processing will be issued as overrideable so a user with the appropriate override authority can apply overrides and submit the document. If not selected, then the errors will be issued as rejected and the document will fail until it complies with BFY Staging. The default for the field is not selected. This control does not apply to any Journal Voucher Document Code that does not have an Event Type entered on the Line Group. In such a case, all BFY Staging edits are skipped. |
Change Closed Allowed |
If a document code should have the ability for a user to modify the chart of account values on an accounting line with a portion or all of that line closed, then this control should be set to Yes. If set to No, no chart of account element, sub element, or rollup values can be modified for an accounting line with a non-zero closed amount. The reason for this restriction is to prevent posting line generation for an accounting line where chart of account values are different on the posting line than on the current version of the accounting line. When restricted, the line amount must be modified down to the closed amount and a new accounting line entered. The default for the field is No. |
Recurring Transaction Allowed |
If a document code should have the ability to have Future Document Triggering records created, then this control should be set to Yes. If set to No, then a user will not be able to save a record on the Future Document Triggering table for the document code. The default for the field is No. |
Approval Override Allowed |
If a document code should have the ability to bypass approvals and workflow, then this control should be set to Yes, which is the default. If set to No, then the Bypass Approval action will not be allowed. A user's security settings would be evaluated to see if the action was allowed for the document code at the individual level as this DCTRL option is at the system level. |
TIN Number & Type for Miscellaneous Vendors |
A choice of three options: Not Required, Overrideable, Required, Required for Reportable Funding Only, and Overrideable for Reporting Funding Only exist to control taxpayer identification information entry on document types that request payments. The Payment Request (PR), Accounting Based Spending (ABS), and Manual Disbursement (MD) document types read this control. A miscellaneous vendor is a vendor/customer code that is marked as a Miscellaneous Account on the Vendor/Customer (VCUST) table. Reportable Funding is defined by a n Object, Sub Object, BSA, or Sub BSA on an accounting line having a value set in the 1099 Income Code field on the respective reference table. When set to Not Required, TIN Number and Type are not required, but allowed, for a miscellaneous vendor. If the Required, then the TIN information is required. If Overrideable, then the TIN information is required, but an override can be applied in order to leave the information blank. The two similar options for Reportable Funding Only work the same if a n Object, Sub Object, BSA, or Sub BSA is determined to be reportable. |
Update Vendor Document History Table |
When this checkbox is selected, the system records, on the Vendor History page, all Vendor Customer Creation (VCC) and Vendor Customer Modification (VCM) documents that have been created for a given vendor and its associated description of the change, if one is entered, on the corresponding document. |
Future Tracking Date Allowed |
This control should be set to Yes if the users are allowed to enter a date that is greater than the current system date from APPCTRL. The default is No. If set to No, a future date is not allowed. |
Disable Vendor Information Inference |
This control should be set to Yes if the Vendor Name, Alias, Contact, and Address Information should not override the user’s entry with values from the Vendor table. The default is No. If set to No, the Vendor Name, Alias, Contact, and Address Information will always be inferred from the Vendor table. |
Field Name |
Field Description |
Calculate MD Backup Withholding |
When this flag is checked, the system will calculate withholding for the MD accounting line and perform a soft inference of the Withholding Line Amount field on MD’s accounting line upon Validate/Submit action. A “soft inference” means that the Withholding Line Amount will be populated only if the field is blank. You will always able to specify a different value, which will not be overwritten by the “soft inference”. |
MD Backup Withholding Amount Error Severity |
Controls the severity of an error, which is issued if the system-calculated Withholding Line amount is different from amount specified in the Withholding Line Amount field. The logic associated with this field is activated only if the Calculated MD Backup Withholding flag is checked. Valid values for this CVL are Warning, Overridable, Error and No Error. |
Disable Payee Contact ID Inference on MD |
This check box indicates whether to infer the Payee Contact ID for the Payee Vendor. |
Use Soft Inference for Payee Contact Name on MD |
This check box indicates whether to overwrite the Payee Contact Name entered with the Contact Name associated with the Payee Contact ID. This field does not change the inference of the other Contact information (phone, e-mail, and so forth). A Yes value results in soft inference, a No value will use the powerful inference. Powerful inference will overlay any user entry. Soft inference will only infer a value when it is blank. |