The file's text, extracted by GovTribe without its formatting.
APPENDIX A – BASIC FUNCTIONAL REQUIREMENTS
The primary modules or functions AHEC is interested in are:
1. General
2. Accounts Receivable
3. Accounts Payable
4. Budget Preparation/Control
5. Capital & Fixed Assets Management
6. Cash Receipting
7. Financial Reporting
8. General Ledger
9. Grants Management
10. Human Resources
11. Management Reporting and Analysis
12. Payroll
13. Project Accounting (including Capital Projects budgeting and costing)
14. Purchasing
15. Cost Accounting/Cost Allocation
16. Time and Attendance
Following are descriptions of the basic needs for each module. Please indicate in the columns below the appropriate response relating to your software. For the items asterisked below, please provide a more detailed explanation/description of functionality in the comments or in an attachment.
| Req. # 1 |
| Requirement: General |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 1. a. |
| Ability to maintain a consistent and logical look and feel with a modern and intuitive user interface. |
| 1. b. |
| *Ability to provide controlled and secure interfaces to allow for electronic updates to the various modules as well as electronic retrieval of information. |
| 1. c. |
| Ability to have high system availability and up-time, meaning >98% up time during M-F 6 AM - 8 PM. |
| 1 d. |
| Ability to have an average end-to-end user response time of one second or less during M-F 8 AM – 5PM. |
| 1. e. |
| Ability to have seamless two-way integration between modules. |
| 1. f. |
| Ability to include strong identity management with directory server integration. |
| 1. g. |
| *Ability to ensure proper user authorization both for application functions and application data and authorize users by one or more roles, organizational units or individually. |
| 1. h. |
| Ability for system licenses to allow for the set-up and use of a test system and a development environment. |
| 1. i. |
| Ability to sort and filter inquiries and reports on all relevant data fields for each screen and module and ability to drill-down on all data with hierarchical relationships. |
| 1. j. |
| *Ability for all modules to have extensive and user friendly reporting capabilities. |
| 1. k. |
| Ability to enforce business rules at the point of entry. |
| 1. l. |
| Ability to have web self-service functionality wherever applicable such as for job applicants, employees, and vendors. |
| 1. m. |
| Ability for new functionality to be developed efficiently in a modern application environment. |
| 1. n. |
| Ability to archive extensive and reliable historical information. |
| 1. o. |
| Ability to modify archive and purge criteria options that can be easily changed by an authorized administrator while maintaining file synchronization and referential table integrity. |
| 1. p. |
| Ability to extract a user defined or random data subset from the production to the test system for testing purposes while still maintaining file synchronization and referential table integrity. |
| 1. q. |
| Ability to be Generally Accepted Accounting Principle (GAAP) compliant, including adherence to Governmental Accounting Standards Board (GASB) statement 34, et al. |
| 1. r. |
| Ability to audit individual transactions and changes made into the system. |
| 1. s. |
| Ability to easily import and export data to and from the system, throughout various modules, electronically either through fixed interface and reporting activity or on an ad hoc basis as needed. |
| 1. t. |
| Ability to convert and input data needed from old systems into new system at implementation. |
The remainder of this page intentionally left blank.
| Req. # 2 |
| Requirement: Accounts Receivable |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 2. a. |
| Ability for Accounts Receivable to fully integrate with other financial modules such as General Ledger, Cash Receipting, Project Accounting, and grants. |
| 2. b. |
| Ability to setup and utilize various miscellaneous accounts receivable types such as interdepartmental, employee and external receivables. |
| 2. c. |
| Ability to maintain and produce various invoice templates, each potentially utilizing differing fields, needed to support our multiple lines of business and varying customer needs. |
| 2. d. |
| Ability to manage customer aging and status (e.g. current, sent to Collections, Uncollectable) through the use of integrated aging and status reports and query options. Allowing for the creation of reports that sort aging using different requirement parameters and varying spans of time. |
| 2. e. |
| Ability to have Customer records that can accommodate various searchable field parameters and are flexible to change if needed, including; unique customer numbers, various customer names available per customer, multiple customer addresses available per customer (while utilizing the same customer code/number), customer type, additional internally generated fields to help manage customers internally (i.e. Department, other system customer information) |
| 2. f. |
| Maintain detailed transaction activity for each customer account including invoicing amount detail by specific charge, date, credit and debit memos, penalties, interest, administrative charges, past due or collections details, write-downs or write-offs. |
| 2. g. |
| Ability to settle an invoice through multiple scenarios; full payment, partial payment, discount applied, credit, outstanding credit memos, write-off, etc. |
| 2. h. |
| Ability to apply various credit terms or payment options (in full, installments, etc.) on a customer or type of customer basis. |
| 2. i. |
| Ability to create and apply credits to vendor accounts and allow that these credits be reflected through the vendor record. |
| 2. j. |
| Report on invoices in varying statuses referencing account coding affected (pending, posted, settled, outstanding, etc.) |
| 2. k. |
| Allow payments to be applied to multiple invoices, and/or multiple accounting codes as needed |
2. l.
Be able to accumulate cash receipts by customer for various time frames (i.e. calendar year, fiscal year, period)
| 2. m. |
| Ability to help manage collections process. |
| 2. n. |
| Ability to integrate with other operational business systems used at AHEC to import revenue/daily sales and invoicing information (T2, Sidewalk - Bookstore system, Event Mgmt System). |
| 2. o. |
| *Please provide an overview of your A/R module with the focus on uses outside standard customer billing and receipting. |
| 2. p. |
| Ability to allow flexibility in account type classification applied to an invoice or cash receipt in order to ensure proper classification on the GL for the type of item received, include various revenues, liabilities (unearned revenues, payables, customer credits), expense (expense reimbursements), or assets. |
| 2. q. |
| One time data transfer of customer master file from Fundware to new ERP. |
| Req. # 3 |
| Requirement: Accounts Payable |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 3. a. |
| Ability for Accounts Payable to fully integrate with other financial modules such as General Ledger, Capital & Fixed Assets, Purchasing, Project Accounting, Cost Accounting/Cost Allocation, and Grants Management. |
| 3. b. |
| Ability to track and adjust 1099 information for vendors and produce 1099 reports, forms and files for transmission according to current IRS requirements and security specifications and standards. |
| 3. c. |
| *Ability to provide a single system-wide vendor file with appropriate separation of vendor maintenance duties between the purchasing and the accounts payable users. |
| 3. d. |
| Ability to establish and maintain (add, edit, delete) vendor records through a flexible vendor record system allowing for multiple fields and/or optional fields of input. |
| 3. e. |
| Ability to view vendor history (encumbrances, payments, credits, etc.) on a per vendor basis directly through the vendor record, or by report or query. |
| 3. f. |
| Ability to implement 2 way (PO/Payment Voucher) and/or 3 way (PO/Receiving docs/Payment Voucher) system match processes with associated controls available in the system to manage and enforce. |
| 3. g. |
| Provide system mechanisms that will enhance internal controls during the vendor payment process, including; prevent payment of duplicate invoice numbers; prevent duplication of voucher numbers, batch and check numbers; payment amount must fall into a current encumbered amount or be within established thresholds, budgetary restrictions/control if any exist, etc. |
| 3. h. |
| *Ability to process electronic invoices as well as electronic approval routing of invoices based on user defined business rules. |
| 3. i. |
| Ability for payment processing functionality to include a wide range of selection criteria for payment generation such as by vendor, due date, discount date, and ability to flag invoices to prevent them from being paid. |
| 3. j. |
| Ability to distribute and apply vendor payment to various account codes through the vendor payment process. |
| 3. k. |
| Ability to reduce vendor disbursement by a portion that is withheld to a liability account (retainage) while still recording the total expense on the GL. Be able to release the remaining retainage to the vendor when remaining terms and conditions are met. |
| 3. l. |
| Ability to flag vendors and or vendor payments based on, and to help enforce business rules. |
| 3. m. |
| Allow payments to batched on a scheduled or process determined basis. |
| 3. n. |
| Ability to allow for electronic automated bank reconciliation and positive pay formatting and processing. |
| 3. o. |
| Ability to offer multiple modes of payment when settling vendor invoices. Allow for vendor payments as EFT transactions, or through manually generated laser printed checks with unique check numbering on invoice by invoice basis. |
| 3. p. |
| Ability to upload Accounts Payable information processed in subsidiary systems (Sidewalk, Energycap) but to be paid through, and records maintained in, the main agency ERP system. |
| 3. q. |
| Ability to support current volume of 5,000+ invoices per year and 2,500 payments, plus annual growth of at least 3%. |
| 3. r. |
| Ability to track payments made internally within the agency and within other State Agencies and Institutions through the use of customer classification, special transaction type, coding, etc. |
| 3. s. |
| Ability to track and apply vendor credit memos |
| 3. t. |
| Ability to allow flexibility in account type classification applied to vendor payment in order to ensure proper classification on the GL for the type of item paid, include various expenses, assets (prepaid expenses), ,liabilities (retainage, various payables, vendor credits), or revenues (refund). |
| 3. u. |
| Ability to track payment detail (account distribution, $amt) within an encumbrance through direct system screens, reporting or query options. |
| 3. v. |
| Ability to import payment card purchase transaction detail from our credit card vendor (Citibank – software is Citidirect) to populate various GL accounts on a periodic basis (currently weekly). |
| 3. w. |
| Ability to identify from various funding sources to use for different types of payments made. |
| 3. x. |
| One time data transfer of vendor master file from Fundware to new ERP. |
| Req. # 4 |
| Requirement: Budget Preparation/Control |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 4. a. |
| Ability for Budget Preparation/Control to integrate with the General Ledger, Human Resource Management, Payroll, Purchasing, and Project Accounting modules and allow budget tracking at the account code level. |
| 4. b. |
| Ability to create electronic approval routings of budget adjustments based on user defined business rules. |
| 4. c. |
| Ability to link budgets to performance measures and provide an interface for regular data entry to update performance measures. |
| 4. d. |
| *Ability to provide the option to ignore, issue warnings or stop the processing of a transaction when the budget for an account code is exceeded. Ability to define business rules that determine which option applies. |
| 4. e. |
| *Ability to provide what-if analysis for both revenue and expenditure budgets with emphasis on personnel budget based on variable factors. |
| 4. f. |
| Ability to budget for activities or projects that do not currently exist but will be established during the upcoming fiscal year. |
| 4. g. |
| Ability to forecast and budget for items that meet varying time line criteria such as; fiscal year, project, or strategic planning interval. |
| 4. h. |
| Ability to create line item budget data by personnel slots authorized in human resources module, including the ability to calculate benefit cost increases. |
| Req. #5 |
| Requirement: Capital & Fixed Assets Management |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 5. a. |
| Ability for Capital & Fixed Assets to fully integrate with General Ledger, Accounts Payable, and Project Accounting. |
| 5. b. |
| Ability to transfer, dispose, reassign and make adjustments to assets. |
| 5. c. |
| Ability to have a dynamic fixed asset listing that can track by multiple searchable fields (such as department, owner, notes), tie asset to individual transaction history (including associated depreciation), and be able to pull reports on these items in various ways (i.e. additions and deletions for a certain period of time such as fiscal year or accounting period) |
| 5. d. |
| *Ability for flexible depreciation to accommodate asset adjustments and provide a variety of depreciation methods by group or individual asset. Ability to manually override depreciation or reverse if necessary and affects to post to asset and flow to GL. |
| 5. e. |
| Ability to allow assets to be categorized as either capital or non-capital (including $0)\ assets) and allow users to define different business rules for each. |
| 5. f. |
| Ability to support, at a minimum, tracking of current asset volume of 1,000 assets, of which 650 are capital assets (>$5,000), With the ability to increase volume based on current additions and agency policy changes. |
| 5. g. |
| Import of existing fixed asset master file (including historical cost and depreciation elements) into new ERP system. |
| Req. #6 |
| Requirement: Cash Receipting |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 6. a. |
| Ability for Cash Receipts to fully integrate with the General Ledger (GL), Accounts Receivable, and Grants modules and be able to post summary and detail level transactions to the GL. |
| 6. b. |
| Ability to upload cash receipt transactions rather than enter transactions manually. |
| 6. c. |
| *Ability to customize transaction codes and categories. |
| 6. d. |
| Ability to choose from various bank accounts when selecting a place for the cash receipt to be deposited. |
| 6. e. |
| Ability to select multiple invoices/credits per one deposit or batch. |
| Req. #7 |
| Requirement: Financial Reporting |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 7. a. |
| Ability to create customized formal, ad hoc and drill-down reports. |
| 7. b. |
| *Ability to provide flexible options for setting report security (i.e., based on General Ledger account authority for ad-hoc reports, based on user group for formal reports). |
| 7. c. |
| *Ability to meet GAAP reporting requirements. This includes, at a minimum, generating reports for fund level reporting on either a modified or full accrual basis (determined by fund) and for government-wide reporting on full accrual basis. |
| 7. d. |
| Ability to allow for flexible grouping of account segments and drill-downs to support the Consolidated Annual Financial Report (CAFR) creation and verification process. |
| 7. e. |
| Ability to assign various subsidiary labels/attributes to certain account codes (could be many to one or one to many relationship) in order to prepare required annual special reporting at various levels. These relationships could be established (inferred) in the system without having to explicitly key-in this portion of the code upon data entry or system entry. |
| 7. f. |
| Ability to prepare reports using cross referenced chart of account elements to other financial systems chart of accounts in order to upload financial data to other systems and be able to efficiently reconcile the data in the two (2) systems. |
| 7. g. |
| Ability to extract trial balance level information organized in a systematic order defined by our financial reporting categories into an external reporting tool or database in order to aid in combined financial statement preparation and maintenance. The method should be easy enough to be able to perform multiple times a day if needed during financial preparation time frames (i.e. quarterly, fiscal year-end). Additionally the organization of the data should be flexible enough to allow for changes in elements (accounts) that make up each category. |
| Req. #8 |
| Requirement: General Ledger |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 8. a. |
| *Ability to create a flexible chart of accounts using user-defined segments and lengths. Must allow for a minimum of 35 characters (alpha/numeric) with at least 12 segments of 1-8 characters each. |
| 8. b. |
| Ability to create and maintain a table based chart of accounts that can tie specific account field elements to each other in order to create meaningful reporting relationships as needed. |
| 8. c. |
| Ability to provide two-way integration with all other modules. |
| 8. d. |
| *Ability to comply with Generally Accepted Accounting Principles (GAAP), support multiple basis’s of accounting and record data properly to produce financial statements and schedules in accordance with GASB statement 34 and other GASB pronouncements. |
| 8. e. |
| Ability to allow multiple years and allow posting to two open years; no posting should be allowed to a closed period. |
| 8. f. |
| Ability to roll-forward ending balances to the beginning of the next financial period. Ability to do this multiple times or in phases in order to start operations of a new fiscal before the previous fiscal year is closed out. |
| 8. g. |
| Ability to support various posting options such as recurring journal entries, saved templates and automatic reversals. |
| 8. h. |
| Ability to allow for multiple pooled cash functionality. |
| 8. i. |
| Ability to maintain various attributes associated with each account coding string in order to meet other reporting and interfacing needs. |
| 8. j. |
| Ability to crosswalk to a different chart of accounts outside the entities direct control in order to provide summary financial transaction data to an authoritative entities financial system (in which we partially operate) through periodic and consistent data uploads. Ability to reconcile the 2 systems through the use of automated procedures and reports. |
| 8. k. |
| Ability to assign required elements of the chart of account needed for certain account code strings, determined by various combinations of codes used (i.e. fund chosen and account classification). |
| 8. l. |
| Ability to assign account classification (Asset, Liability, Revenue, Expense) to specific account code elements system-wide, and the ability to pull reports based on these classifications. |
| 8. m. |
| Ability to view/display the chart of accounts in various ways (referencing various relationships) through the system itself (preferably view would be user driven in order to best suit the task performed). |
| 8. n. |
| Aid in Chart of Account creation to help ensure that all data aspects are included in order to utilize system capabilities to best meet our needs. |
| 8. o. |
| Ability to ensure debits equal to credits by fund. Reflect debits as positive numbers and credits as negative numbers in the general ledger. |
| 8. p. |
| Allow for on-line real time setup of chart of accounts, including; allowing for mid fiscal year changes, ability to change at fiscal year-end while still maintaining 2 fiscal years open at the same time, etc. |
| 8. q. |
| Support on-line account validation |
| 8. r. |
| Provide for automatic reversals of month-end and year-end accrual entries, and ability to reverse entries spanning between fiscal years. |
| 8. s. |
| Ability to copy general ledger transactions that are reoccurring. |
| 8. t. |
| For journal entries, support automatic journal numbering, ability differentiate by purpose or type, ability to delete unposted journals, ability to edit or change online, and ability to approve on-line. |
| 8. u. |
| One time data transfer or setup of chart of account elements in new system. |
| 8. v. |
| Data transfer of account balances from old system into new system in a systematic fashion dependant on phases or time frame of implementation. (i.e. beg FY balances versus, period end balances if implementation occurs mid-year). |
| 8. u. |
| Ability to import journal entries from Xcel or flat file into G/L |
| Req. #9 |
| Requirement: Grants Management |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 9. a. |
| Ability for Grants Management to fully integrate with Accounts Payable, General Ledger, Accounts Receivable, Cash Receipts, Payroll and Time and Attendance. |
| 9. b. |
| *Ability to track grant specific information such as grantor, funding agencies, CFDA #’s, match requirements, grant amounts and actual expenditures, revenues, unearned revenues, accounts receivable, and associated liabilities |
| 9. c. |
| Ability to track various grant and financing relationships (e.g. multiple grants funding a single project, multiple projects for a single grant, co-mingled grant and non-grant monies, and grants across funds/departments). |
| 9. d. |
| Ability to use the Grant Management module to track external grant funds received and funds awarded through internal grant programs managed. |
| 9. e. |
| *Ability to support multi-year grants for budgeting, accounting and reporting purposes. |
| Req. #10.1 |
| Requirement: Human Resources - Human Resources Management |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 10.1 a. |
| Ability for Human Resource Management to fully integrate with Payroll, Budget Preparation/Control, Time and Attendance, Benefits Administration and Employee Self Service. |
| 10.1 b. |
| Ability to maintain various information about each employee such as demographic information, historical employment and salary information and provide extensive reports on demand (both standard and custom). |
| 10.1 c. |
| Ability to setup, classify and track position information for each position. |
| 10.1 d. |
| Ability to assist in the administration and analysis of job classifications. |
| 10.1 e. |
| *Ability to support compensation management and analysis. |
| 10.1 f. |
| Ability to support the tracking and monitoring of performance evaluations as well as renewals and requirements for training and certifications. |
| 10.1 g. |
| Ability to efficiently manage staffing, recruitment, and grievance/risk processes. |
| Req. #10.2 |
| Requirement: Human Resources/Benefits Administration |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 10.2 a. |
| Ability to comply with privacy and security regulations of FMLA, ADA and HIPAA. |
| 10.2 b. |
| Ability to track benefit enrollment information and costs for both employees, retirees, and family members in a variety of benefit programs, including medical, dental, vision and disability insurance. |
| Req. #11 |
| Requirement: Management Reporting and Analysis |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 11. a. |
| Ability to provide users with an intuitive interface to create user-defined reports (including charts, graphs, spreadsheets, etc). |
| 11. b. |
| Ability to accumulate and distribute reports (preferably via e-mail) on a periodic basis to specific individuals assigned to receive specific reports. Ability to easily manage and adjust report distribution tool to keep up with employee assignment changes. |
| 11. c. |
| *Ability to provide for interactive dashboards and standardized reports for various management levels, from process level monitoring to senior management, and allow drill down from reports to source transactions. |
| Req. #12.1 |
| Requirement: Payroll - Processing and Administration |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 12.1 a. |
| Ability for Payroll to integrate with the General Ledger, Budget, Human Resource Management, Time and Attendance Reporting, Employee Self Service, Grants Management, Project Accounting and Benefits Administration modules. |
| 12.1 b. |
| Use time entry data, payroll adjustment data, personnel salary profile data to calculate payroll based on user-defined business rules |
| 12.1 c. |
| Ability to support multiple payroll cycles, employee types, schedules, and over-time cycles as well as one-time payroll checks. |
| 12.1 d. |
| Ability to run payroll distribution for a variety of employee profiles (e.g., Full-time Employees, Temporary Employees, Permanent Part-time Employees, Retired Employees, etc). |
| 12.1 e. |
| Allow for employees to be paid Monthly or Biweekly. |
| 12.1 f. |
| Ability to support standard Federal, State, Local and retirement reporting requirements, including W-2, various monthly, quarterly and year-end reports and XIRE (State Benefits Payments) monthly reports. Including reconciliation process to ensure correct reporting and payment of all withholdings, benefits and liabilities. |
| 12.1 g. |
| Provide month end and year-end reports that contain data on various pay statistics (i.e. average wage, hours used of sick leave, hours used of annual leave, FMA, hours for worker comp and LWOP, Military Leave along with Short Term Disability). |
| 12.1 h. |
| Ability to process a variety of earnings including but not limited to; one-time special pay, shift pay, supplemental pay, longevity pay, overtime and compensatory time entitlements. |
| 12.1 i. |
| Ability to calculate payroll based on various employee types and profession requirements; i.e. Calculate overtime for essential / emergency versus non-essential / non-emergency positions. Essential positions get paid time for hours over 40 hours and when calculated 40 hours of leave time is included. Non-essential must actually work 40 hours excluding leave and additional hours paid at regular rate. |
| 12.1 j. |
| Provide data entry point for various payroll data elements including; work hours, actual hours worked, current salary, effective date, last pay, comments, was paid flag, Shift Differential, Overtime and On call work, referral bonus and signing bonus. |
| 12.1 k. |
| Ability to calculate various pay adjustments including; Leave Without Pay (and capture LWOP fields such as LWOP effective date and handle a refund of LWOP), based on call status, adjusted hours for previous months, actual hours worked, time-reporting revisions, exempt and non-exempt status, eligibility for shift and on-call, retroactive pay for new employees and current employees. |
| 12.1 l. |
| Ability to calculate employee promotions, which entails calculating actual hours and pay prior promotion and actual hours and pay after promotion or position change. |
| 12.1 m. |
| Ability to support a variety of deductions including but not limited to deferred compensation, insurance, garnishments, flexible spending accounts, and union/association dues. These may have a fixed rate, percentage or a combination. Ability to refund deductions without a salary base and calculate taxes on the refund. |
| 12.1 n. |
| Ability to maintain various non-worked banks such as vacation, sick leave, holidays, compensatory time and personal days. Ability to calculate ANR (annual leave conversion) for retiring employees and ANL (annual leave) for terminating employees. |
Ability to calculate SKF (sick leave conversion) for retiring employees.
| 12.1 o. |
| Ability to create multiple workflows and approvals for employee action forms based upon factors such as the action code, department, and other criteria. |
| 12.1 p. |
| Provide ability to determine exempt & non-exempt status with ability to override in situation where employee changes status. Audit report before confirming payroll. |
| 12.1 q. |
| Ability to allow for electronic automated bank reconciliation and positive pay formatting and processing. Produce bi-weekly and monthly payrolls with files sent electronically for payment by direct deposit with the capability to also produce manual checks. Ability to pay returned ACH direct deposits. Ability to void a payroll check. |
| 12.1 r. |
| Ability to track payroll changes to employee records. Provide search capability on employee information such as organization, last name and SSN. |
| 12.1 s. |
| Ability to process multiple payrolls and/or one-time payroll checks at the same time. |
| 12.1 t. |
| Ability to write reports and pull detailed payroll data as needed for reports, uploads for payments or requests, by earnings or deduction type. |
| 12.1 u. |
| One time data transfer of employee master file. |
| Req. #12.2 |
| Requirement: Payroll - Employee Self Service |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 12.2 a. |
| *Ability for Employee Self Service to fully integrate with Human Resource Management, Benefits Administration, Time and Attendance and Payroll. |
| 12.2 b. |
| Ability to allow employees to view information such as their current and historical paycheck and salary information, current benefit elections, leave activity and balances and W-2s. |
| 12.2 c. |
| Ability to provide a secure online process by which employees can update their personal information such as change of name, address and direct deposit institution and provide notice that such change has been made. |
| 12.2 d. |
| Ability to allow for an extensive user defined area in which links to manuals, paper forms, instructions and other websites can be maintained. |
| 12.2 e. |
| *Ability to add workflows such as submitting/approving travel expenditures. |
| Req. #13 |
| Requirement: Project Accounting |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 13. a. |
| Ability for Project Accounting to fully integrate with Accounts Payable, Purchasing, Budget Preparation/Control, Capital Assets, General Ledger, Payroll, and Time and Attendance. |
| 13. b. |
| Ability for users to define an active project period; periods may span fiscal years. |
| 13. c. |
| *Ability to support multi-year grants for budgeting, accounting and reporting purposes. |
| 13. d. |
| *Ability to capture expenditure and revenue information at a user-defined level including by department or groups of departments; ability to define, for each project, the level of detail needed and inquire and generate reports at these same levels. |
| 13. e. |
| Ability to assign, utilize and track multiple funding sources for each specific project. |
| 13. f. |
| Ability to link documents & information to specific projects. |
| 13. g. |
| Ability to separate and define projects by a unique identifier to allow for budget, commitment and actual cost tracking and reconciliation. |
| 13. h. |
| Ability to roll-up project reporting by various data elements including; buildings, institutions, funding source, clients, etc. |
| 13. i. |
| Ability to track budget, committed costs, actual cost, forecast and schedule. |
| 13. j. |
| Ability to import essential project data from external work order system (TMA) to populate financial and nonfinancial data related to projects. Financial data includes labor dollars spent on specific projects and project budget information. Nonfinancial includes; dates, project manager assignment, customer assignment, etc. If this need cannot be fully met (i.e. non-financial data elements can’t be imported) ability to meet this need through another mechanism. |
| 13. k. |
| Ability to export project data to a tool that could easily reconcile similar project financial balance elements from the financial ERP system to similar elements in the Center Work Order system (TMA) to ensure consistency in Center system data, and to be used for management reporting purposes. Assist in creation of this tool (currently F9 is used for this purpose). |
| 13. l. |
| Transfer of project balances from Fundware into new system at start-up. |
| Req. #14 |
| Requirement: Purchasing |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 14. a. |
| Ability for Purchasing to fully integrate with Accounts Payable, Project Accounting, Budget Preparation/Control, General Ledger, Inventory, Work Orders and Capital & Fixed Assets. |
| 14. b. |
| *Ability to have electronic purchase requisitions with approval routings and budget controls (note: approvals should include Human Resources and could include other approvals for some purchases). |
| 14. b. |
| *Ability to cancel or reject requisitions at Purchasing level with explanation. |
| 14. c. |
| *Ability to attach electronic backup documentation to the purchase requisitions prior to approval routings. |
| 14. d. |
| *Ability to attach electronic documents to Purchase Orders allowing both the Purchase Order and the electronic documents to be sent to the vendor. |
| 14. e. |
| Ability to encumber funds and issue Purchase Orders either by line item or total project with the ability to liquidate partial or full amounts. |
| 14. f. |
| Ability to pre-encumber funds and issue requisitions either by line item or total project with the ability to receive partial or full amounts. |
14. g.
Ability to issue an open Purchase Order with multiple draws.
| 14. h. |
| *Ability to have different types of Purchase Orders, e.g., additional signature lines on one type, but only one signature line on others, etc. |
| 14. i. |
| *Ability to allow for approval controls of purchase requisitions at multiple security levels with the levels being user defined. Examples of drivers would be dollar amount, individual or department/office. |
| 14. j. |
| Ability to support current annual volume of 2,000 requisitions, resulting in 2,000 purchase orders, plus annual growth of at least 3%. |
| 14. k. |
| *Ability to have predefined “standard text” that can be inserted into various Purchase Orders when necessary. |
| 14. l. |
| Ability for unlimited description text on Purchase Orders. |
| 14. m. |
| *Ability to encumber funds for other types of acquisitions, e.g., contracts. |
| 14. n. |
| Ability to load vendor file information from current system. |
| 14. o. |
| Ability for both Purchasing and Accounting staff to create and change vendor records. |
| 14. p. |
| *Ability to easily create uniquely identifiable Change Orders to Purchase Orders and other commitment documents (e.g., contracts) including increasing/decreasing quantities, unit prices, change unit of measure, change descriptions, account number, etc. |
| 14. q. |
| *Ability to issue a Purchase Order without encumbering funds. |
| 14. r. |
| *Ability to copy Purchase Orders to create a new Purchase Order. |
| 14. s. |
| *Ability to work in more than one fiscal year at a time, e.g., issuing new fiscal year POs before the close of the previous fiscal year. |
| 14. t. |
| *Ability for Purchasing staff to make status comments or notes in a requisition that would not be printed on a Purchase Order, or other commitment document (e.g. contract), but would be viewable to Purchasing staff. |
| 14. u. |
| Ability for Purchasing staff to have full system inquiry permissions and custom or AD HOC reports. |
| 14. v. |
| Ability to create different requisition types depending on what is being purchased. |
| 14. w. |
| *Ability for Purchasing and Accounts Payable to store electronic copies of documents such as W-9s. |
| 14. x. |
| Ability to search in various ways for Purchase Orders by vendor, by requisition number, by Purchase Order number, etc. |
| Req. #15 |
| Requirement: Cost Accounting/Cost Allocation |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 15. a. |
| Ability to create various cost allocation methodologies in the system in order to maintain and apply various costing and financing models and to aid in posting redundant and periodic accrual entries. |
| 15. b. |
| Ability for Accounting staff to be able to create and maintain various cost allocation models in the system. |
| 15. c. |
| Ability to apply cost allocation entries on an on demand basis. |
| 15. d. |
| Ability to preview/review effects of cost allocation entries before actual posting takes place. |
| 15. e. |
| Ability to apply multiple cost allocation entries to the same account and maintain a hierarchical systematic application of the different allocations applied. |
| 15. f. |
| Ability to use cost allocation processes to program reoccurring entries that are based on specific account balances (i.e. CIP additions, cash transfers, fund balance classification). |
| Req. #16 |
| Requirement: Time & Attendance |
| In Base |
| Requires Customization |
| Third Party |
| Comments/Explanation |
| 16. a. |
| Ability for Time and Attendance to fully integrate with Human Resource Management, Payroll, Project Accounting, Employee Self Service, Grants Management and Projects on a detailed or summary basis, as AHEC chooses. |
| 16. b. |
| Be able to provide labor reports outlining type of time worked (i.e. regular hours, overtime, shift differential, on-call, etc.) and tie to specific accounting code string elements (i.e. fund, cost center, object, project, grant) for grants, projects and specifically defined organizational units. |
| 16. c. |
| Ability to allow for exception based or leave based only time reporting for exempt employees as well as accommodate daily hours entry for hourly or non-exempt employees. It should also provide for time and attendance tracking or support the import of time and attendance data from external systems. Allow for different work schedules, work days or work times and lunches/breaks. |
| 16. d. |
| Ability to require and enforce authorized approval over timesheets, and provide functionality for various approval levels for time reporting based on business rules. (i.e., supervisor assigned, alternate approve when supervisor is not available.) |
Allow for updates and changes to a timesheet by assigned approvers for the timesheets they are responsible for.
| 16. e. |
| Ability for all AHEC employees to enter in time sheets to track hours worked if hourly, or to track exceptions for salaried employees (leave, OT, shift, etc.). |
| 16. f. |
| Ability for an employee to be assigned to various organizations which include |
various distribution of earnings setups, and be able to track time individually for approval routing purposes at each of the organizational levels.
| 16. g. |
| Ability to integrate leave requests and time reporting (timesheets) with approval routings for both. |
| 16. h. |
| Ability to accumulate leave balances with a variety of leave types with associated specific employee pay record in order to calculate and determine agency leave balance liability. |
| 16. i. |
| Provide the ability for all employees to view their own- time-reporting history for a defined period of time (i.e., 3 years plus current year). |