Attachment J-3 Functional Requirements 11-18-19.xls
XLS spreadsheet 320 KB Posted
- Attached to
- DHS Enterprise Financial Management Systems (EFiMS) Federal contract opportunity
- Solicitation number
- DHS-70RTAC18RFI000004
View the file
Other files for this federal contract opportunity
Show all 38
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
General
| # | Functional Requirements | Meets Requirement (Yes/No) | Answer if Meets Requirement = Yes | |||
| Meets Out of the Box (Yes/No) | Meets with Configuration (Yes/No) | Meets with Extension | ||||
| (Yes/No) | Meets with Future Enhancement (Yes/No) | |||||
| SOW 5.1.4. | The software shall provide the ability to import and export data in an open, standard-based nonproprietary format. The product shall be able to interface with external systems and other products using open application programming interfaces (APIs) and open documented standard data exchanges. The product shall be capable of supporting modern web-based data services. | |||||
| SOW 5.2.1 | The software proposed must meet all of the security requirements under Section 5.2.1 of the SOW. | |||||
| SOW 5.2.2 | Vendors must either (i) demonstrate that they have a documented plan to migrate existing software to SaaS or (ii) meet one of the following three FedRAMP requirements: (a) Provisional Authority to Operate (P-ATO), (b) Agency Authority to Operate (ATO), or (c) FedRamp Ready. | |||||
| SOW 5.2.3 | The software proposed must support IAM requirements. The following requirements shall be met for IAM: | |||||
| · Role-based access control (RBAC) | ||||||
| · Support DHS Single Sign-on/Personal Identity Verification (SSO/PIV) card access. | ||||||
| · User authentication and authorization of access to function components of the software suite | ||||||
| · Security incident identification, recording, and alerts | ||||||
| · Audit and accountability: track user access to software suite and its functional components | ||||||
| SOW 5.2.4 | All software proposed for EFiMS shall have the capability for internal verification and audit procedures to ensure that the data, including financial and inventory data, is complete and correct. The software suite shall support the six demotions of data quality: | |||||
| · COMPLETENESS - The proportion of stored data against the potential of "100% complete" | ||||||
| · UNIQUENESS - An event or entity will be not be recorded more than once based upon exclusivity identified. | ||||||
| · TIMELINESS -The degree to which data represent temporal event | ||||||
| · VALIDITY/CONFORMITY - Data must conform to the syntax (format, type, range) of its definition. | ||||||
| · ACCURACY - Data must correctly represent the event or entity being captured | ||||||
| · CONSISTENCY - Standardization when comparing two or more similar categorizations of an event or entity thing against standard system definition. | ||||||
| · CURRENCY - The degree to which data represents reality from the required point in time. | ||||||
| The EFiMS COTS software and services shall meet DHS Enterprise Architecture policies, standards, and procedures. | ||||||
| SOW 5.2.4 | The software must provide the capability to mask or obfuscate data on production and non-production environments. | |||||
| SOW 5.2.4 | The software must provide the capability to encrypt data at the row, column, table, and file level of the database. | |||||
| SOW 5.2.5 | The software proposed must meet all of the Enterprise Architecture requirements under Section 5.2.5 of the SOW. | |||||
| SOW 5.2.6 | The software must comply with the Electronic and Information Technology Accessibility Standards. | |||||
| SOW 5.3 | The software must comply with the Technical Specification requirements under Section 5.3 of the SOW. | |||||
| SOW 5.4 | The software must comply with the software configuration and capability requirements under Section 5.4 of the SOW. | |||||
| · Support DHS/Component financial management, asset management and procurement management business processes using configurable options. | ||||||
| · To be widely supported by market leaders/vendors such that DHS can acquire contract support for integration(s) and operations and maintenance. | ||||||
| · Integrated financial, procurement, and asset management software | ||||||
| · Integrated with Business Intelligence | ||||||
| · Logging/audit tracking including tracking user action | ||||||
| · Industry standards based open interfaces and data exchange | ||||||
| · Compliant with NIST and DHS Chief Information Security Officer (CISO) Standards | ||||||
| · Software with end-user configurability that eliminates or minimizes the need for custom software development | ||||||
| · Provide capabilities that simplify and automate migration to the cloud. | ||||||
| · Secure and scalable software suite | ||||||
| · Role based Access Control and Segregation of Duties Capability | ||||||
| · Single Sign On functionality | ||||||
| · Support User Access Management Capability | ||||||
| · Interfaced with internal and external systems using open API standards to exchange information with external systems | ||||||
| · Ability to export/import data in industry standard formats using service-oriented architect methodologies | ||||||
| · Allow data to be loaded from external sources and ensure data integrity, validation, and ability to transact using loaded data. | ||||||
| · The vendor shall coordinate with system support team on issues reported. If there is a system failure and the root-cause analysis traces it back to the vendor, then the Government would require the vendor to provide a patch to the software. | ||||||
| SOW 5.5 | The software must meet the license and subscription requirements under Section 5.5 of the SOW. | |||||
| SOW 5.5.1 | The COTS software vendor/SaaS provider shall support the following transfer requirements at no additional cost to the Government | |||||
| · The ability to transfer licenses between users | ||||||
| · Unlimited user license agreements | ||||||
| · Allow perpetual per current user licenses | ||||||
| · Upgrade current licenses to the latest version | ||||||
| · Allow usage of licenses for software testing and development | ||||||
| · Transfer of purchased licenses toward a subscription-based model | ||||||
| · Licenses purchased by any DHS Component shall be transferable to DHS HQ and other DHS Components | ||||||
| · Flexibility to transfer software between data centers at no additional cost to support disaster recovery and other activities | ||||||
| · Flexibility to transfer licenses from DHS to a cloud environment | ||||||
| · Flexibility to transfer licenses from DHS to the Quality Service Management Office (QSMO) for financial management. | ||||||
| SOW 5.5.2 | The software must be able to support a large user load (at least 6,500 users or more). | |||||
| SOW 5.5.3 | The software must comply with the license audit and compliance review requirements in Section 5.5.3 of the SOW. | |||||
| SOW 5.6 | The software must comply with the technical support and software maintenance requirements under Section 5.6 of the SOW. | |||||
| SOW 5.7 | The software product must support the transition requirements in Section 5.7 of the SOW. | |||||
| SOW 5.8 | The vendor must meet the professional services requirements under Section 5.8 of the SOW. | |||||
| SOW 5.9 | The vendor must meet the deliverable requirements under Section 5.9 of the SOW. | |||||
| · Software configuration recommendations and installation instructions for DHS HQ and Components | ||||||
| · COTS software product or SaaS logical and physical data models for the master and transaction data, considered Government owned data, for the software | ||||||
| · Software documentation (User guide, software installation guide, API guide) | ||||||
| · Technical documentation required for configuration/implementation of the software | ||||||
| · Other documentation not specifically outlined here that would be required by the Government or a Government Contractor to support or implement the application for a DHS Component | ||||||
| SOW 5.10 | The COTS software or SaaS must comply with the outlined policies, standards, guidance and regulations covered under section 5.10. | |||||
| · Federal Laws | ||||||
| · Federal Standards and Guidance | ||||||
| · OMB Memoranda and Circulars | ||||||
| · DHS Directives, Policies and Guidance | ||||||
| · DHS FSM Guidance | ||||||
| · Federal Standards and Guidance |
FINAL DRAFT
Budget Formulation to Execution
| # | FMSS Level 3 Process Title | FMSS Level 4 Process Title | Functional Requirements | Meets Requirement (Yes/No) | Answer if Meets Requirement = Yes | |||
| Meets Out of the Box (Yes/No) | Meets with Configuration (Yes/No) | Meets with Extension | ||||||
| (Yes/No) | Meets with Future Enhancement (Yes/No) | |||||||
| 1 | General - BF2E | General - BF2E | The software shall have the capability to configure automated approval workflows to ensure proper segregation of duties. | |||||
| 2 | General - BF2E | General - BF2E | The software shall have the capability to define and execute workflows. | |||||
| 3 | General - BF2E | General - BF2E | The software shall have the capability to keep an audit trail for all changes. | |||||
| 4 | 1.1.1 Prior Year Data Collection | 1.1.1.1 Report obligations by program activity | The Level 2/3 process is non-FFM. See Supporting Requirements below: |
The software shall have the capability to provide prior year financial data reports, for example SF 133 and standard status of funds report.
The software shall have the capability to make at least five prior years and current-year budget information available to guide development of out-year budgets.
The software shall have the capability to develop, store and revise program financial requirements, spending plans, procurement planning, and program justifications as part of budget activities for both budgetary and proprietary accounts.
| 5 | 1.1.1 Prior Year Data Collection | 1.1.1.2 Report budgetary resources available for obligation | Please see FMSS Level 4 Process Title: 1.1.1.1 Report obligations by program activity. |
| 6 | 1.1.1 Prior Year Data Collection | 1.1.1.3 Report change in obligated balances | Please see FMSS Level 4 Process Title: 1.1.1.1 Report obligations by program activity. |
| 7 | 1.1.1 Prior Year Data Collection | 1.1.1.4 Report net budget authority and outlays | The software shall have the capability to provide prior year financial data reports, for example SF 133 and standard status of funds report. |
| 8 | 1.1.1 Prior Year Data Collection | 1.1.1.5 Provide required memorandum information | The software shall have the capability to make at least five prior years and current-year budget information available to guide development of out-year budgets. |
| 9 | 1.1.1 Prior Year Data Collection | 1.1.1.6 Report unfunded deficiencies that have not been liquidated | The software shall have the capability to develop, store and revise program financial requirements, spending plans, procurement planning, and program justifications as part of budget activities for both budgetary and proprietary accounts |
| 10 | 1.1.2 Budget Review and Coordination | 1.1.2.1 Conduct internal base budget review | The software shall have the capability to create a spending plan template for the effective budget year and provide the tools to prepare that budget per approved agency-defined business rules for each program office. |
| 11 | 1.1.2 Budget Review and Coordination | 1.1.2.1 Conduct internal base budget review | The software shall have the capability to maintain spending plans for future budget years by PPA with the ability to roll up to highest level by appropriation. |
| 12 | 1.1.2 Budget Review and Coordination | 1.1.2.1 Conduct internal base budget review | The software shall have the capability to automate the loading of budget data and spending plan by importing budget data submitted in Excel and ASCII text delimited format. |
| 13 | 1.1.2 Budget Review and Coordination | 1.1.2.1 Conduct internal base budget review | The software shall have the capability to allow for changes in the spend plan. |
| 14 | 1.1.2 Budget Review and Coordination | 1.1.2.1 Conduct internal base budget review | The software shall have the capability to send formulation and execution data between the core accounting system and formulation system (2-way interface) |
| 15 | 1.1.3 Resource Allocation Planning | 1.1.3.1 Develop Component Resource Allocation Plan (RAP) | The software shall have the capability to send formulation and execution data between the core accounting system and formulation system (2-way interface) |
| 16 | 1.1.4 Performance Planning | 1.1.4.1 Manage performance measures | The software shall have the capability to send formulation and execution data between the core accounting system and formulation system (2-way interface) |
| 17 | 1.1.5 Component Budget Submission | 1.1.5.1 Submit Component budget estimates | The software shall have the capability to send formulation and execution data between the core accounting system and formulation system (2-way interface) |
| 18 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to process budget information and set up the funds control structure, levels, and accounting segments, including period of availability, TAFS/PPA/FY Quarter and organization. |
| 19 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to record spending authority and apportionment funding for reimbursable authority and allotted funding for organizations. |
| 20 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to provide budgetary resource reporting attributes (for example, Treasury Account Fund Symbol, expired, and unexpired) consistent with the budget execution activities as defined in OMB Circular No. A-11. |
| 21 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to provide comparison of spend plan data to budget execution data (commitments, obligations, expenditures) at any organization level or other level of the accounting classification structure. |
| 22 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to record reductions to available authority (both expired and unexpired) on demand. |
| 23 | 1.2.1 Budgetary Resource | 1.2.1.1 Record spending authority from offsetting collections | The software shall have the capability to maintain current year and historical versions of all spending plans up to five years. |
| 24 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to record transactions (entered by authorized users) against expired funds in the current year (upward and downward adjustments). |
| 25 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to provide an alert that will notify and allow approval/disapproval of transactions using expired funds. |
| 26 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to permit allocation of actual fees and recoveries to component identified line of accounting elements (e.g., PPA) based on anticipated authority. |
| 27 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to maintain the current year spend plan at multiple levels (below the PPA) that have been given spending authority with the ability to roll them up to the highest level by appropriation. |
| 28 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to upload the spend plan templates by DHS PPA for quarterly allotments and produce reports for tracking. . |
| 29 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to allow the development of managing and executing partner spend plans. (Example, Service Wide Costs). |
| 30 | 1.2.1 Budgetary Resource | 1.2.1.2 Record special authorities | The software shall have the capability to record transactions against unexpired (multi-year and no year funds) in the current year. |
| 31 | 1.2.1 Budgetary Resource | 1.2.1.3 Record a Continuing Resolution (CR) - Part 1 | The software shall have the capability to record a funding authority pro-rated for the period of the CR based on prior year funding levels. |
| 32 | 1.2.1 Budgetary Resource | 1.2.1.4 Record a Continuing Resolution (CR) - Part 2 | The software shall have the capability to record a funding authority pro-rated for the period of the CR based on prior year funding levels. |
| 33 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to record budget authority, Category B, and Reimbursables so that the funds flow to projects (top-down). |
| 34 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to allow updates and changes to budget authority allocation, distribution, and timing. |
| 35 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to record and permit updates to apportioned funds in accordance with the latest OMB approved SF 132 Apportionment and Reapportionment Schedule. |
| 36 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to provide budgetary authority and resource data required to post GL transactions consistent with USSGL transaction codes, transaction categories (e.g., funding) and transaction subcategories (e.g., budgetary resources other than collections) as defined in the TFM. |
| 37 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to support the entry of appropriations (with and without warrants and ones that do not have an apportionment) with applicable GL entries. |
| 38 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to determine appropriated fund subdivisions, apportionments, reapportionments, and allocations before any of the appropriated funds are expended consistent with the budget execution activities as defined in OMB Circular No. A-11. |
| 39 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to ensure budgetary resources are available for apportionment. |
| 40 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to check to see if the budgetary resource is exempt from Apportionment by fund type (e.g., Working capital) and exclude them from appropriation regulations. |
| 41 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to allow entry of approved apportionment amounts as indicated by a signed SF-132 and/or a Government-wide Accounting (GWA) System Treasury warrant, when applicable. Data can be input on a quarterly or annual basis. |
| 42 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to log and maintain approved apportionment documentation (e.g., signed SF-132). |
| 43 | 1.2.2 Apportionment (Record Budget Authority) | 1.2.2.1 Record budget authority | The software shall have the capability to generate the proper GL entries for anticipated resources (reimbursable transactions, user fees, offsetting collections, asset recycling, anticipated refunds, recovery, anticipated transfers). |
| 44 | 1.2.3 Funds Distribution | 1.2.3.1 Process budget allotments | The software shall have the capability to calculate available fund balances based on reimbursable agreement authority. |
| 45 | 1.2.3 Funds Distribution | 1.2.3.1 Process budget allotments | The software shall have the capability to allot funds by time period (e.g., month, quarter) and have the ability to allot for a future period (i.e., enter future start dates). |
| 46 | 1.2.3 Funds Distribution | 1.2.3.1 Process budget allotments | The software shall have the capability to classify and record budget data using accounting classification elements (e.g., appropriation, apportionment, authority, allotment, sub-allotment, allocation, allowances) in accordance with DHS accounting classification structure. |
| 47 | 1.2.3 Funds Distribution | 1.2.3.2 Process budget allocations and suballocations | The software shall have the capability to allocate and sub-allot funds to various levels, including the organization, PPA, object class, object class extension (i.e., SOC), Project/Task levels either individually or through a bulk process. |
| 48 | 1.2.3 Funds Distribution | 1.2.3.2 Process budget allocations and suballocations | The software shall have the capability to prevent the distribution of funds in excess of the amount of funds available. |
| 49 | 1.2.3 Funds Distribution | 1.2.3.2 Process budget allocations and suballocations | The software shall have the capability to record multiple levels of funds distribution including levels used for appropriation and apportionment of budget authority. |
| 50 | 1.2.3 Funds Distribution | 1.2.3.2 Process budget allocations and suballocations | The software shall have the capability to prevent recording program allocations in excess of the organizational allotment and provide notifications. |
| 51 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to execute administrative control of funds consistent with OMB Circular No. A-11 to restrict obligation and expenditure from each account to the lower of the amount apportioned by OMB or the amount available for obligation and/or expenditure. |
| 52 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | Execute statutory limitation controls restricting obligations and expenditures to amounts authorized by law consistent with OMB Circular No. A-11. |
| 53 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | Provide budget obligation and outlay data required to post GL transactions consistent with USSGL transaction codes, categories (for example, funding), and subcategories (for example, budgetary resources other than collections) as defined in the TFM. |
| 54 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to derive funds availability based on the budget fiscal year of the originating document (i.e., whether funds cited are unexpired, expired, or cancelled), and record prescribed GL entries when the de-obligation of expired funding occurs. |
| 55 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to process spending documents that affect the availability of funds, including commitments, obligations, advances, and expenditures. |
| 56 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to validate that funds availability balances used for funds control and funds status reporting agree with the GL. |
| 57 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to mass close commitments and obligations citing expiring funds or other parameters and report on what has been closed as a result of this action. |
| 58 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to update the spending plan with updates to budget authority allocation, distribution, and timing of fiscal periods. |
| 59 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to update the program spending plan with the budget authority allocations provided by LOA, PPAs, and programs and divisions. |
| 60 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to verify the budget authority of the spending plan against the budget authority allocations provided. |
| 61 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to not allow commitments, obligations or expenditures to be incurred until an allotment is made by the agency. |
| 62 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to prevent a deficiency condition that violates funds control in accordance with the appropriation language for that account for that component. |
| 63 | 1.2.4 Funds Control | 1.2.4.1 Establish funds control structure | The software shall have the capability to provide the option to exclude actual payroll expenditures from system funds control. |
| 64 | 1.2.5 Reprogramming and Transfer Authorization | 1.2.5.1 Process appropriation transfer | The system shall have the capability to process appropriation transfer. |
| 65 | 1.2.5 Reprogramming and Transfer Authorization | 1.2.5.2 Process reprogramming transaction | The system shall have the capability to process reprogramming transaction. |
| 66 | 1.2.6 Rescissions | 1.2.6.1 Process rescission | The system shall have the capability to process adjustments due to rescissions. |
| 67 | 1.2.7 Budget Monitoring | 1.2.7.1 Monitor status of program funding | The software shall have the capability to maintain open documents to show the status of commitments, obligations, advances, accruals, and disbursements by document line item. |
| 68 | 1.2.7 Budget Monitoring | 1.2.7.1 Monitor status of program funding | The software shall have the capability to track and monitor budgetary and proprietary activity to generate the SF133 report. |
| 69 | 1.2.7 Budget Monitoring | 1.2.7.1 Monitor status of program funding | The software shall have the capability to ensure that actual costs and updates for prior year activity including upward and downward adjustments for no year or multi-year funds properly post to the correct budget authority year and fund [e.g., for end of year accruals (when actual data received is after the close of the FY), funds should go against the prior year budget authority]. |
| 70 | 1.2.7 Budget Monitoring | 1.2.7.2 Conduct Mid-Year Reviews | The software shall have the capability to track, record, and produce reports. |
| 71 | 1.2.8 Budget Formulation and Execution Reporting | 1.2.8.1 Generate Monthly Execution Reports | The software shall have the capability to track, monitor, and report variances among commitments, obligations, expenditures in summary and detail against the spending plan and prior year data at the LOAs, PPAs, programs, and divisions. |
| 72 | 1.2.8 Budget Formulation and Execution Reporting | 1.2.8.2 Generate Quarterly Obligation and Personnel Plans | The software shall have the capability to track and report actual data to budgetary planned data, and calculate variances of dollar amounts and quantities. |
| 73 | 1.2.8 Budget Formulation and Execution Reporting | 1.2.8.3 Generate monthly reports on fee receipts | The software shall have the capability to report status of spending plans on a daily basis and by month, quarter, and year. |
| 74 | 1.2.8 Budget Formulation and Execution Reporting | NEW | The software shall have the capability to provide budgetary resource and budget execution data as specified in the TFM to support the budget reporting activities defined in OMB Circular No. A-11, OMB Circular No. A-136, and the FASAB Handbook. |
| 75 | 1.2.8 Budget Formulation and Execution Reporting | NEW | The software shall have the capability to verify that GL account balances can be traced to aggregated or discrete transactions in agency programmatic systems and that the aggregated or discrete transactions can be traced to the point of entry and source documents consistent with the TFM. |
| 76 | 1.2.8 Budget Formulation and Execution Reporting | NEW | The software shall have the capability to verify that financial statements and other required financial and budget reports can be traced to GL account balances as required by OMB Circular No. A-123 and as specified in the TFM. |
Record to Report
| # | FMSS Level 3 Process Title | FMSS Level 4 Process Title | Functional Requirements | Meets Requirement (Yes/No) | Answer if Meets Requirement = Yes | |||
| Meets Out of the Box (Yes/No) | Meets with Configuration (Yes/No) | Meets with Extension | ||||||
| (Yes/No) | Meets with Future Enhancement (Yes/No) | |||||||
| 1 | General - R2R | General - R2R | The software shall have the capability to include automated workflow notifications and verification notification. The software shall be compliant with Federal Financial Management Improvement Act (FFMIA). | |||||
| 2 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to add, change, or de-activate GL accounts in the chart of accounts without programming changes | |||||
| 3 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to automatically generate notifications of changes to the USSGL accounts. | |||||
| 4 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to generate reports of all additions to the G/L Account Inventory | |||||
| 5 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to generate reports on history, creation and changes, to individual SGL accounts and attributes. | |||||
| 6 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to require that when General Ledger accounts are created or modified the attributes field required by the USSGL are linked to the G/L Account. | |||||
| 7 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to allow for future modification to attributes linked to the G/L Accounts to include changes in allowed values and the addition of new attributes. | |||||
| 8 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to define specific GL accounts as control accounts for purposes of tracking activity in subsidiary ledgers | |||||
| 9 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to provide GL account classifications (e.g., budgetary, assets, liabilities, revenues and expenses), account categories (e.g., receivables), and account subcategories (e.g., accounts receivable) consistent with the USSGL accounts defined in the TFM | |||||
| 10 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to provide GL budgetary account attributes (e.g., Default Budget Enforcement Act Category, Apportionment Category B Program Code, Authority Type Code) consistent with the USSGL attributes defined in the TFM | |||||
| 11 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to provide revenue and other financing sources disclosure and supplementary information for agency and Government-wide reporting as specified in the FASAB Handbook | |||||
| 12 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.1 Create General Ledger accounts | The software shall have the capability to notify requestor about task completion | |||||
| 13 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.2 Modify existing General Ledger account | The software shall have the capability to generate report of all changes to the GL Account Inventory | |||||
| 14 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.2 Modify existing General Ledger account | The software shall have the capability to notify requestor about task completion | |||||
| 15 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.3 Deactivate existing General Ledger account | The software shall have the capability to generate report of all deletions to the Transaction Codes | |||||
| 16 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.3 Deactivate existing General Ledger account | The software shall have the capability to prevent transactions from posting to GL accounts that have been de-activated | |||||
| 17 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.3 Deactivate existing General Ledger account | The software shall have the capability to notify requestor about task completion | |||||
| 18 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to define standard transactions that derive GL postings based on accounting classification elements or other document data elements in accordance with Treasury USSGL guidance in the TFM | |||||
| 19 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to require transaction codes define both the USSGL account and account attributes. | |||||
| 20 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to be able to generate reports on active transaction codes and cross reference to the GL accounts and attributes posted. | |||||
| 21 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to generate reports of all additions to the Transaction Codes. | |||||
| 22 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to generate reports on history, creation and changes, to individual transaction codes including SGL accounts and attributes. | |||||
| 23 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to establish business rules that require, prohibit, or default accounting classification data elements for a particular GL account and limit what accounts can be used within a particular business event | |||||
| 24 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.4 Establish new Transaction code | The software shall have the capability to notify requestor about task completion. | |||||
| 25 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.5 Modify existing Transaction code | The software shall have the capability to report on all changes to the Transaction Codes. | |||||
| 26 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.5 Modify existing Transaction code | The software shall have the capability to notify requestor about task completion. | |||||
| 27 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.6 Deactivate existing Transaction code | The software shall have the capability to generate reports of all deletions to the Transaction Codes. | |||||
| 28 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.6 Deactivate existing Transaction code | The software shall have the capability to notify requestor about task completion. | |||||
| 29 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to provide Federal funding attributes (e.g., program, activity, and cost object) that align funding requests, funding allocations, fund obligations, fund expenditures, and costs with agency performance goals, as required by the Chief Financial Officer (CFO) Act, as well as the Government Performance and Results Act and consistent with the FASAB Handbook, OMB Circular No. A-11, OMB Circular No. A-136 and the DATA Act | |||||
| 30 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to comply with the DHS accounting classification structure elements and format requirements in accordance with the DHS ACS Guidebook. It must allow additions, changes, and deactivations of all ACS elements. In addition to standard Federal data required, the 15 DHS defined elements are as follows: |
• Internal Fund Code
• Allotment Code
• Strategic Code
• PPA Code
• Project Code
• Cost Center Code
• Task Code
• USSGL Account Extension Code
• Object Class Extension Code
• Revenue Source Code
• Mission Specific Field 1
• Mission Specific Field 2
• Mission Program
• Mission Sub-Program
• Mission Activity
| 31 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to add, change, or de-activate GL attribute domain values in order to accommodate changes in Treasury reporting (e.g., GTAS, GFRS) without programming changes |
| 32 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to limit the USSGL account attribute values entered by the user to those established as valid values for Treasury reporting |
| 33 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to be able to deactivate ACCS elements for future obligations but keep them open for payments on existing contracts |
| 34 | 2.1.1 General Ledger Set Up and Maintenance | 2.1.1.7 Maintenance of the Line of Accounting | The software shall have the capability to have the ability to define business rules for reorganization (e.g., project codes, organizations, ALC) |
| 35 | 2.1.2 Recurring Cost Accruals and Adjustments | 2.1.2.1 Create recurring entries for same accounts with different amounts | The software shall have the capability to allow users to establish and schedule accruals (e.g., Contingent Liability, Unfunded Leave Liabilities) based on business rules for known or planned payroll-related expenses that are not processed through NFC prior to the close of the fiscal year |
| 36 | 2.1.2 Recurring Cost Accruals and Adjustments | 2.1.2.2 Create recurring entries for same accounts with same amounts | The software shall have the capability to allow for the setup of recurring entries such as the accrual of monthly utilities or the allocation of pre-paid amounts over the period of performance. |
| 37 | 2.1.2 Recurring Cost Accruals and Adjustments | 2.1.2.3 Create recurring entries for same accounts and formula-based amounts | The software shall have the capability to allow users to schedule automatic generation and auto-reversal of payroll and benefits commitments and accruals using the last actual pay period payroll files |
| 38 | 2.1.2 Recurring Cost Accruals and Adjustments | 2.1.2.3 Create recurring entries for same accounts and formula-based amounts | The software shall have the capability to allow the agency to edit pay period maintenance information to allow for the population of payroll data and related GL dates. The software shall have the capability to also allow the agency to select parameters for automatic generation of accrual or commitment entries, including but not limited to the following: |
• Fiscal year (FY)
• Number of work hours
• Number of pay periods in FY
• Pay period number
• Status
• Number of holidays in the pay period
• Pay period beginning and end dates
• Pay dates
• GL end dates (by week)
• Calendar year
• Number of holiday hours and number of hours remaining
• Accrual flag
• Accrual factor
• Commitment flag
• Commitment factor
| 39 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to allow the user to enter manual GL journal entries for both current and prior year activities |
| 40 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to be able to prepare, approve, and post journal entries |
| 41 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to generate a unique identifier for each journal entry that is prepared and maintain the log of the journal entry identifier. |
| 42 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to maintain a recorded of any prepared journal entry that is not subsequently approved, for example an entry that is cancelled, rejected or disapproved. |
| 43 | 2.1.2 Recurring Cost Accruals and Adjustments | 2.1.2.3 Create recurring entries for same accounts and formula-based amounts | The software shall have the capability to allow reclassification of payroll transactions, individually or in bulk, at the detailed employee level |
| 44 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to support standard and free form-based journal entries, ensuring that debits and credits balance |
| 45 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to create journal entries to adjust balances in the current period and/or period(s) that are open |
| 46 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to automatically update all applicable GL account balances (budgetary, proprietary, and memorandum accounts) concurrently as part of a single input transaction event, allowing unlimited debit and credit pairs per single standard transaction |
| 47 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to prevent transactions from posting that would cause GL debits and credits to be out of balance within the proprietary, budgetary, or memorandum accounts. Proprietary, budgetary, and memorandum accounts must each be self-balancing. |
| 48 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to post GL proprietary, budgetary, and memorandum account transactions consistent with USSGL account attributes, account transaction codes, account transaction categories, and account transaction subcategories |
| 49 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to maintain ability to post transactions funded, obligated, or expended over multiple years to GL accounts that do not close (for example, undelivered orders–obligations, unpaid; delivered orders–obligations, unpaid; authority outlayed not yet disbursed). |
| 50 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to capture GL account transaction information provided by supporting financial management operations (for example, payments, receipts, liabilities, assets, and reimbursable/intra-governmentals) consistent with the USSGL account attributes, account transaction codes, account transaction categories, and account transaction subcategories defined in the TFM. |
| 51 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to determine if anticipated recoveries have been previously recorded in order to derive the USSGL prescribed entries to record upward/downward spending adjustments. The software shall have the capability to distinguish between upward/downward adjustments and corrections. |
| 52 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to update GL control accounts consistent with postings made to subsidiary ledgers and prevent transactions from posting that would cause the GL control accounts to be out-of-balance with the subsidiary ledgers |
| 53 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to make a mass allocation change that moves funding to alternate lines of accounting (e.g., Budget Fiscal Year rolled forward to a subsequent fiscal year) |
| 54 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to upload a journal entry template (flat file of both standard and free form-based entries) with the same edit checks (as applicable) as those journal entries entered in the software |
| 55 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to allow a user to create a new journal entry by copying from a similar approved journal entry |
| 56 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to create a template for standard journal entries |
| 57 | 2.1.3 General Ledger Module Posting | 2.1.3.1 Post appropriate entries to general ledger | The software shall have the capability to make a copy of a line item, within journal entries, as the basis for a new line item within the same entry |
| 58 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to provide for two levels of approval, posting and approval, by two distinct users with the appropriate level of authority before the transaction is posted to the G/L account balance. |
| 59 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to provide an approval indicator (e.g., status of approval) for journal entries |
| 60 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to provide the user with the ability to see the effect of the journal entry on the GL accounts prior to posting |
| 61 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to provide processing controls for journal entries by calendar date aligned with TIER submission requirements |
| 62 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability for the preparer to recall the journal entry transaction and for the approver to reject the entry prior to approval via workflow to correct journal entries |
| 63 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to upload and view back-up documentation in various formats for journal vouchers. |
| 64 | 2.1.3 General Ledger Module Posting | 2.1.3.2 Approve general ledger entries | The software shall have the capability to send notifications of entries approval |
| 65 | 2.1.3 General Ledger Module Posting | 2.1.3.3 Reverse general ledger entries | The software shall have the capability to create journal entries to adjust balances in the current period, which automatically reverses in the subsequent period specified in the journal entry |
| 66 | 2.2.1 Period Set Up/ Maintenance | 2.2.1.1 Define accounting calendar periods | The software shall have the capability to distinguish between single year and multiyear funds. |
| 67 | 2.2.1 Period Set Up/ Maintenance | 2.2.1.1 Define accounting calendar periods | The software shall have the capability to maintain accounting periods each fiscal year, with the option to facilitate the following, as needed: |
• A period for recording opening balances
• Twelve periods for recording monthly activity
• Additional periods for year-end pre-closing and closing entries
| 68 | 2.2.2 Period Open | 2.2.2.1 Open accounting period | The software shall have the capability to make fiscal year-dependent master data from a prior year available at the start of a new fiscal year for new accounting period/fiscal year transactions (e.g., rollover, roll forward, or update master data) |
| 69 | 2.2.2 Period Open | 2.2.2.1 Open accounting period | The software shall have the capability to derive an accounting period’s opening balances based on the prior accounting period’s closing balances at the USSGL attribute level. The opening of GL account balances must maintain the USSGL attribute information required to satisfy GTAS and GFRS reporting requirements. |
| 70 | 2.2.2 Period Open | 2.2.2.1 Open accounting period | The software shall have the capability to allow authorized users to record transactions to any open accounting period and provide the option to keep multiple accounting periods open simultaneously |
| 71 | 2.2.2 Period Open | 2.2.3.1 Close accounting period | The software shall have the capability to close proprietary. budgetary, non-fiduciary and fiduciary accounts consistent with USSGL account closing table rules as defined in the TFM. The software shall have the capability to have the ability to distinguish between accounts that maintain a balance at year end versus balances that need to be at zero at year end. |
| 72 | 2.2.2 Period Open | 2.2.3.1 Close accounting period | The software shall have the capability to distinguish between monthly and annual closing activities. The software shall have the capability to perform pre-closing, post-closing, and beginning balance for period closures, quarter end closures, and year end closures |
| 73 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to perform multiple preliminary closings in a trial/test mode so that users can review the closing results, clear the closing entries, and re-run the closing process. This functionality must be available for both "preliminary closing" entries and "final closing" entries. |
| 74 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to allow a user with special authorization to close accounting periods and prevent the posting of new transactions to any final closed period |
| 75 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to allow a user with special authorization to reopen closed accounting periods so that transactions can be recorded and posted to them |
| 76 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to allow for financial system preliminary soft (i.e., “soft close”) and final close (i.e., “hard close”) at defined points prior to the end of reporting period |
| 77 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to maintain account identity through year-end processes (e.g., sub-object, program code into beginning balance setup) |
| 78 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to require that any prepared but unapproved journal entries be resolved, either approved or deleted prior to the yearend closing. |
| 79 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to allow for the automatic closing of any unobligated requisitions (USSGL 4700 Commitments) prior to the yearend closing. |
| 80 | 2.2.3 Period Close | 2.2.3.1 Close accounting period | The software shall have the capability to close non-fiduciary and fiduciary accounts consistent with USSGL account closing table rules as defined in the TFM. |
| 81 | 2.3.1 Trading Partner Reconciliation and Elimination | 2.3.1.1 Reconcile difference(s) with a trading partner | The software shall have the capability to identify specific TP activity types (e.g., Incoming RAs, Transfers-In/Out, Benefits) for the TP transaction activity |
| 82 | 2.3.1 Trading Partner Reconciliation and Elimination | 2.3.1.1 Reconcile difference(s) with a trading partner | The software shall have the capability to prevent posting an IPAC record with a different TP than the obligation. IPAC records must match TP to TP and obligation to obligation |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .