KFS Customizations
This spec requests the creation of a maintenance document for the existing Procurement Cardholder business object. In addition, two extended attribute fields need to be created and added to the newly created maintenance document. This maintenance document also has validation and access requirements. See the functional spec for details.
Two vendor-related fields exist in FRS, but not in KFS. Two extended attributes will represent the AZ Sales Tax License Number and the Tucson Sales Tax License; they need to be added to the Vendor business object. These two attributes will need to be displayed on the Vendor inquiry screen.
An account-related field called "Sales Tax Code" exists in FRS, but not in KFS. An extended attribute called "Tax Region Code" will represent this sales tax code, and will apply to all accounts. It will link to the existing Tax Region Code in KFS and will need to be displayed on the Account Inquiry screen in the Extended Attributes tab.
This spec requests the addition of a new Account extended attribute field, FA Cost Subcategory and the creation of a maintenance document for the purpose of maintaining FA Cost Subcategory values. The new extended attribute field will be added to the Account document Extended Attributes tab, but will not be included in the Account Lookup or Results list. The FA Cost Subcategory Extended Attribute maintenance document is unremarkable and validation requires only that both code and descriptions fields are supplied. See the functional spec for details.
This spec requests the addition of a new Account extended attribute field, Assession Code. The new extended attribute field will be added to the Account document Additional Account Attributes (formerly Extended Attributes) tab, but will not be included in the Account Lookup or Results list. The Assession Code extended attribute field is freeform and does not require a lookup or validation against a table of valid values. See the functional spec for details.
There is currently a PCard transactional document (PCDO) in KFS. Sales Tax Amount and Tax Exempt Indicator both exist in the database for each transaction, and these now need to be displayed on the document level as editable fields for each transaction.
There is currently a PCard transactional document (PCDO) and a related inquiry screen for the PCDO in KFS. The inquiry screen needs to be modified to display Level 3 data from the bank, which needs to be added into the FP_PRCRMNT_TRN_DTL_T table.
Currently, several FP eDocs have a Line Description field on each accounting line. The Distribution of Income and Expense document (DI) doesn't have a Line Description on the accounting lines. This needs to be added.
A system parameter needs to be added so that users can restrict the use of specific object sub-types (i.e. codes) from being used with specific sub-fund groups on accounting documents. This involves modifying delivered/core code related to accounting validation and document data dictionary files.
The GEC needs to be modified to validate the reference number against the original document number both when an accounting line is added and the document is submitted. There will also be a new system parameter to turn this validation on and off.
FRS is currently able to route requisitions for approval based on a combination of object codes and account numbers. This functionality can be reproduced in KFS by using an Object Code's Object Sub-Type Code to determine requisition document routing. It requires an additional route node and a new role that is for reviewing and approving the Object Sub-Type Code routing.
This feature needs to be used in all financial processing e-docs.
The Disbursement Voucher Travel tab is currently required to be completed if the vendor is selected as the payee. This needs to be changed so that it is also required if there is an employee payee.
The Salary Expense Transfer (SET) is used to transfer salary expenses from one account to another. The SET needs to display an Error Certification tab to justify expenses.
Replace IU report links with links to GL Scrubber/Poster Reports and UAccess Analytics.
Batch Processing
This spec requests the creation of new batch process to calculate use tax on posted Procurement Card transactions and post the calculated use tax to the KFS general ledger. The new batch process will consist of two batch steps that will be added to the existing general ledger poster job after the poster reversal step and before the indirect cost recovery steps. This new batch process is part of the Procurement Card Reconciliation and Approval process and will be contributed back to the Kuali Foundation for use by other member Universities. See the functional spec for details.
The page Workflow Ingester Batch Process does not exist.
Data Dictionary
DataDictionary Tool
Workflow
Workflow Tool
Integration
KITT-91@Jira
Julie Wingate
Leo Przybylski