Get documents about "New York State Lease Agreements
Description
New York State Lease Agreements document sample
Document Sample
New York Financial Management System (NYFMS) Exhibit E.5
INSTRUCTIONS
To obtain an understanding of how the Contractor’s software can meet functional and technical requirements, Exhibit E-5 lists each requirement and a set of columns seeking precise information from the Contractor
concerning whether the solution would be a standard function for the software, or if it requires another means for compliance. Contractors must select a response code (defined below) to indicate the Mode of
Compliance (IV) for each requirement.
Contractors must provide a corresponding description in the Comment/Explanation (V) field for each requirement to explain the mode of compliance selected, and a description of how the requirement is met, and also
identify Where in Software (VII) the requested functionality would reside.
For a response code of M (Modification Required), the Contractor shall also include an Estimated Level of Effort (VI) necessary to meet the requirement.
In addition, where a code of S - Standard Function; or T - Third Party is entered, the Contractor must provide an appropriate Software Document Reference (VIII) or citation to the documentation that will accompany the
software product which addresses the functionality for each requirement.
Note: In instances where the explanation provided appears to be inadequate to support the Mode of Compliance code entered, the scoring for that requirement may be effected. The State, at its option, reserves the right
to request clarification from the Contractor to further explain their comments. The clarification will be in writing and follow the communication protocol under RFP Section 2.2.
The Contractor is to provide only one answer for each field in Exhibit E-5. Requirements for which a response has not been provided for fields IV through VIII (except for requirements identified as an N - cannot meet
requirement), or requirements which incorporate multiple answers, will not receive a score.
IV. Mode of Compliance Response
Code Response Description
The functionality is provided by the contractor’s core ERP software, or by
configuration of the core ERP that will not require rework during an
S Standard Function upgrade, or by third party software that is fully integrated with the core
ERP software and does not require rework during an upgrade, and is
included in the cost proposal.
The functionality is provided by a third-party application, which has
received certification as a third party solution that integrates with the core
T Third Party
ERP product and may require rework during an upgrade. The third party
products are included in the cost proposal.
The functionality is provided by a third-party application, included in the
B Third Party Non Certification cost proposal, which is not certified to work with the contractor's core ERP
product.
The requirement is met by customization or user exit to invoke the
necessary custom code, and/or a change to the basic architecture and/or
M Modification Required source code of the contractor’s software. These modifications are not
automatically carried forward during an upgrade, and will require
additional effort in order to satisfy the requirement.
N Cannot Meet Requirement The desired functionality is not available.
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 1 of 111
New York Financial Management System (NYFMS) Exhibit E.5
INSTRUCTIONS
V. Comment/Explanation - explain/justify how a requirement will be accommodated by the system, when a requirements is met through any of of the modes of compliance (except for requirements marked with N -
cannot meet requirement).
VI. Level of Effort - the estimated amount of effort required to complete a modification in order for the system to perform the detailed requirement in question. (enter LOE for responses identified as M - Modification
Required only)
Please use the following codes and definitions:
Level of Effort (LOE) Response
Code Effort in hours
A Less than 8 hours
B 9-40 hours
C 41-160 hours
D 161 or more hours
VII. Where in Software –identify the place (component/screen/report/module) within the software that will be used to implement the functionality of the detailed requirement.
VIII. Software Documentation Reference -- FOR MODE OF COMPLIANCE CODES S and T -- provide the appropriate section page/screen reference within your software product's documentation package, which
speaks to how the software provides the means to meet the requirement.
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 2 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1 The system shall provide functionality to receive electronic invoices from vendors AP-10
2 The system shall provide functionality to create standard/miscellaneous vouchers for AP-10
instances in which a purchase order/contract does not exist
3 The system shall provide functionality to default vendor bank information from the vendor AP-10
master file and record the information onto the voucher
4 The system shall provide functionality to default the vendor "remit to" address in the AP-10
voucher, based on data associated with the vendor master record, and allow changes to the
address as necessary
5 The system shall provide functionality to permit multiple payees to be assigned to a voucher AP-10
6 The system shall provide functionality to accommodate at least 950 payees per voucher AP-10
7 The system shall provide functionality to select the correct address when the payee has AP-10
multiple remit-to addresses through the use of a "favorite lists" by agency
8 The system shall provide functionality to code multiple invoices to a single voucher AP-10
9 The system shall provide functionality to automatically assign a voucher ID number at time AP-10
of entry
10 The system shall provide functionality for the following fields for voucher entry including, but AP-10
not limited to:
- Voucher type
- Invoice number
- Invoice date
- Period of service covered by invoice (if applicable)
- Account number
- Discount terms
- Total invoice amount
- Additional invoice charges (freight, etc.)
- Item quantity
- Item price
- Comments
- Payee FEIN/TIN
- Payee name and address
- Invoice receipt date
- Payment date (to take advantage of available discount)
- Interest eligible
- Multiple contract number
- Purchase order number
- 1099 number
- Payment route code
- Receipt date of item
- Liability date
11 The system shall provide functionality to save an incomplete voucher AP-10
12 The system shall provide functionality for users to create advances and prepayments and AP-10
update the general ledger and AP modules with advances and prepayment information
13 The system shall provide functionality to identify advance payments as "recoupable" in the AP-10
system
14 The system shall provide functionality to create credit memos against advance payments AP-10
15 The system shall provide functionality for the users to apply previous payments or advances AP-10
to a vendor invoice/contract payment
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 3 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
16 The system shall provide functionality to record expenses incurred through petty cash funds, AP-10
paid by both cash and check, for the following data elements including, but not limited to:
- Method of payment (check or cash)
- Check number (if appropriate)
- Payee name
- Invoice or source document reference
- Accounting distribution to be charged
- Amount for each distribution
- Check location (account ID)
- Description of advance
- Check date
17 The system shall provide functionality for users to create checks for petty cash AP-10
18 The system shall provide functionality to process a payment request to replenish the petty AP-10
cash account
19 The system shall provide functionality for users to place a petty cash payment on hold AP-10
20 The system shall provide functionality for users to void petty cash payments and attach an AP-10
associated reason code (e.g., lost, duplicate)
21 The system shall provide functionality for the user to change the scheduled payment date on AP-10
any voucher
22 The system shall provide functionality to calculate the payment due date based on vendor AP-10
terms and/or NYS rules and regulations
23 The system shall provide functionality for users to identify line items with a 1099 code as AP-10
part of voucher entry
24 The system shall provide functionality to validate certain data fields as part of the voucher AP-10
entry, including, but not limited to:
- Project number
- Asset number
- Account number
- URC Code
- Purchase Order number
- Contract number
25 The system shall provide functionality to notify the user when a duplicate vendor invoice AP-10
number is entered
26 The system shall provide functionality for users to set up voucher templates that can be AP-10
copied to facilitate the creation of vouchers
27 The system shall provide functionality for funds/budget checking at the time of voucher entry AP-10
28 The system shall provide functionality for users to enter retainage, which is a portion of the AP-10
payment that will be withheld until the final payment is processed, as a dollar amount or
percentage in the voucher
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 4 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
29 The system shall provide functionality to enable the voucher program to extract data AP-10
elements from the purchase order including, but not limited to:
- Payment terms
- Account code
- Purchase order number
- Item description
- Asset number
- Quantity ordered
- Vendor information
- Contract number
30 The system shall provide functionality for users to override data elements defaulted in the AP-10
voucher from the purchase order and/or contract
31 The system shall provide functionality to ensure that encumbered funds remain obligated AP-10
from the receipt of goods/services against a purchase order for a 2-way or 3-way match to
the approval of payment request
32 The system shall provide functionality for users to record non-financial data in a voucher AP-10
(e.g., kilowatt usage, water gallon usage, and gallons of gasoline used)
33 The system shall provide functionality for users to add comments on the voucher header or AP-10
individual line item level
34 The system shall provide functionality to establish the MIR date based on the latter of the AP-10
invoice received date or the merchandise received date
35 The system shall provide functionality for users to override the default merchandise or AP-10
invoice received (MIR) date in a voucher
36 The system shall provide functionality for the option to calculate discounts based on the MIR AP-10
date
37 The system shall provide functionality to accommodate voucher matching, including, but not AP-10
limited to the following:
- 3 way match - purchase order/contract, invoice, and receipt
- 2 way match - purchase order/contract and invoice
- No match - invoice only
38 The system shall provide functionality for users to override a match discrepancy between AP-10
the invoice and receipt if the discrepancy is within an allowable threshold
39 The system shall provide functionality to enable the voucher program to extract data AP-10
elements from the purchase order receipt, including, but not limited to:
- Amount
- Quantity received
- Items received
- Date received
40 The system shall provide functionality for alerts, when the purchase order and invoice AP-10
match, but the receiving document is missing
41 The system shall provide functionality to automatically generate a voucher once goods have AP-10
been received against the purchase order
42 The system shall provide functionality for users to create multiple vouchers against a single AP-10
purchase order or contract
43 The system shall provide functionality for users to create a voucher from multiple purchase AP-10
order and receipt transactions
44 The system shall provide functionality to verify expenditure refunds against current and prior AP-10
year disbursements
45 The system shall provide functionality to prevent users from creating vouchers against AP-10
closed purchase orders and/or contracts
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 5 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
46 The system shall provide functionality for users to edit a voucher after it has been saved AP-10
and/or posted
47 The system shall provide functionality for users to review, revise, and approve vouchers AP-10
online
48 The system shall provide functionality for approval levels for voucher transactions based on, AP-10
but not limited to:
- Vendor
- Dollar amount
- Account number
49 The system shall provide functionality for users to assign a priority code to vouchers AP-10
50 The system shall provide functionality for users to place vouchers on hold AP-10
51 The system shall provide functionality to post all vouchers (e.g., contract, purchase order, AP-10
miscellaneous) to the general ledger and AP modules
52 The system shall provide functionality to create and release recurring vouchers based on a AP-10
schedule
53 The system shall provide functionality for users to add, edit, or delete recurring payment AP-10
information based on changes to agreement terms, amounts, and frequencies
54 The system shall provide functionality to generate recurring transactions (e.g., building rent) AP-10
for a fixed or percentage allocation amount between multiple GL accounts
55 The system shall provide functionality for users to edit the dollar amount, GL account, or AP-10
payment terms on any recurring voucher
56 The system shall provide functionality for users to cancel or void multiple vouchers AP-10
57 The system shall provide functionality to automatically generate the appropriate accounting AP-10
entries upon the voiding of a voucher
58 The system shall provide functionality for users to apply credit memos against a single AP-10
voucher
59 The system shall provide functionality for users to apply a credit memo against multiple AP-10
vouchers
60 The system shall provide functionality for users to net payables and receivables for a vendor AP-10
that is also a customer of the state
61 The system shall provide functionality to notify agency staff when an invoice is approaching AP-10
the Prompt Payment deadline
62 The system shall provide functionality to generate standard reports for AP data AP-10
63 The system shall provide functionality for aging analysis, both onscreen and in reports, of AP-10
outstanding payables for less than 30, 30, 60, 90, 120, and greater than 120 days (e.g.,
invoice date, due date, MIR date)
64 The system shall provide functionality for the vendor to inquire on invoices and payments AP-10
via vendor self-service
65 The system shall provide functionality to create email notification to vendors when AP-10
incomplete or contested invoices are received by the agency
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 6 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
66 The system shall provide functionality to query, display, and report payables or payment AP-10
history by any data element including, but not limited to:
- Purchase order
- Encumbrance
- Invoice
- Vendor name
- Vendor ID number
- Vendor invoice number
- Check number
- Document/voucher number
- Purchase order number
- Contract number
- Life-to-date expenditures
- Fiscal year expenditures
- Quarterly, and month to date expenditures
67 The system shall provide functionality to generate a statistical sample of approved invoice(s) AP-10
and payment requests for post-audit review
68 The system shall provide functionality to capture the following tolerances from voucher data AP-10
including, but not limited to:
- Unit price invoiced versus unit price ordered
- Unit quantity invoiced versus unit quantity ordered
- Unit quantity invoiced versus unit quantity received
- Total invoice cost for goods received versus total cost of goods received against the
purchase order
69 The system shall provide functionality to enable the use of multiple banks and bank AP-20
accounts as part of the vendor master record
70 The system shall provide functionality for users to request that payment vouchers be placed AP-20
on hold
71 The system shall provide functionality to automatically update voucher and payment records AP-20
based on payment data from an external system (i.e. interface)
72 The system shall provide functionality for users to generate reports to track (e.g., identify, AP-20
record, inquire, and report) all cash disbursements by financial reporting categories required
by GAAP and GASB (e.g., other funds, component units, related governments, private
customers, and federal government)
73 The system shall provide functionality for users to view payment status and history online AP-20
74 The system shall provide functionality for users to inquire, display, and report on various AP-20
elements of the payment voucher including, but not limited to:
- Check number
- Check date
- Vendor number
- Purchase order number
- Contract number
- Grant Number
- Project Number
- Associated vouchers for payment information
75 The system shall provide functionality to notify users of aging or unpaid vouchers AP-20
76 The system shall provide functionality to identify cleared checks as part of payment AP-20
reconciliation including a date when the check cleared
77 The system shall provide functionality for users to change an encumbrance to a liability, AP-50
either at the time of receipt or at the time of invoice
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 7 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
78 The system shall provide functionality for partial or full liquidation of encumbrances as AP-50
specified by users during the vouchering process
79 The system shall provide functionality to identify encumbrances against reappropriated or AP-50
lapsing funds to be addressed at fiscal year end
80 The system shall provide functionality for users to roll encumbrances (e.g., purchase orders AP-50
and contracts) to the next fiscal year, liquidating lapsing funds and encumbering new year
funds as necessary
81 The system shall provide functionality to keep purchase orders open when encumbrances AP-50
have been liquidated so that purchase orders can cross fiscal years
82 The system shall provide functionality to automate the process of liquidating lapsing funds AP-50
and encumbering new year funds (roll-over) with specific selection criteria based on, but not
limited to:
- Document type
- Account attribute
- Account code
- Dollar amount
83 The system shall provide functionality for inquiry capability to track encumbrance detail from AP-50
initial encumbrance through final payment including, but not limited to:
- Original encumbrance amount
- Changes to the original encumbrance amount
- Released liability amounts
- Payment amounts
- Expenditure amounts
- Vendor name
- Purchase order/contract number
- Account number
84 The system shall provide functionality to maintain a travel profile on each traveler with AP-60
various information including, but not limited to:
- Name
- Default account information
- Spending limits
- Needed approvals for travel
- Social security number
- Traveler work location
- Traveler mailing address
- Email address/user ID
- Normal work hours
85 The system shall provide functionality to download Travel card expense information from the AP-60
credit card company
86 The system shall provide functionality for users to manually add travel vouchers AP-60
87 The system shall provide functionality for users to manually add travel card expenditures AP-60
88 The system shall provide functionality for users to identify personal incidental expenses on a AP-60
travel voucher
89 The system shall provide functionality for users to classify both taxable and non-taxable AP-60
travel expenses
90 The system shall provide functionality to pre-approve employee travel AP-60
91 The system shall provide functionality to approve employee travel vouchers prior to AP-60
submitting the voucher to the finance department
92 The system shall provide functionality to capture fractions of a cent in the mileage rate AP-60
calculation
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 8 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
93 The system shall provide functionality to automatically select the appropriate element in the AP-60
chart of accounts for each travel expense entered into the voucher
94 The system shall provide functionality for users to make line item changes and deletions to AP-60
travel vouchers
95 The system shall provide functionality for users to make changes to previously posted trips, AP-60
if necessary
96 The system shall provide functionality for a warning when an employee has multiple trips AP-60
with overlapping trip dates
97 The system shall provide functionality to identify expense items that fall outside of the AP-60
traveler’s travel dates (e.g., airline tickets purchased in advance)
98 The system shall provide functionality to copy lines from one travel expense report to AP-60
another
99 The system shall provide functionality for users to override default accounting/profile AP-60
information when funds are encumbered or expensed for a trip
100 The system shall provide functionality for users to charge multiple funding sources when AP-60
creating travel vouchers
101 The system shall provide functionality to calculate reimbursement amounts based on the AP-60
date of travel, not the date of entry
102 The system shall provide functionality to convert foreign currency data (rates) to U.S. dollars AP-60
for foreign travel
103 The system shall provide functionality to encumber against multiple funding sources for AP-60
employee travel expenses
104 The system shall provide functionality to distinguish between in-state travel and out-of-state AP-60
travel
105 The system shall provide functionality to notify the user of outstanding balances when a trip AP-60
or advance is requested and/or approved
106 The system shall provide functionality to edit and validate mileage, miles, and lodging AP-60
information for compliance against travel regulations
107 The system shall provide functionality to calculate meal "per diem" reimbursement amounts AP-60
based on departure and return dates, times, and locations
108 The system shall provide functionality to default certain accounting information for trip AP-60
requests based on default coding assigned to the traveler and allow override of default
values
109 The system shall provide functionality to edit and validate lodging costs against spending AP-60
limits and provide fields for comments related to exceeding the limits
110 The system shall provide functionality for travel classification codes to track the number of AP-60
employees traveling on a particular trip or conference
111 The system shall provide functionality for a mechanism to reconcile travel advances with an AP-60
employee’s travel voucher
112 The system shall provide functionality to enable the user to reconcile employee travel AP-60
vouchers to travel card expenditures from the credit card company
113 The system shall provide functionality for users to capture trip details that will be paid to a AP-60
third party for planned travel (e.g., direct bills for airplane tickets and hotels) and capture
additional expenses directly reimbursable to the employee
114 The system shall provide functionality for users to capture trip details that will be paid by a AP-60
third party for planned travel (e.g., direct bills for airplane tickets and hotels)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 9 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
115 The system shall provide functionality for a mechanism to report on cost component AP-60
information including, but not limited to:
- Lodging
- Meals
- Vehicle rental
- Mileage
- Registration fees
- Airfare
116 The system shall provide functionality to compare approved expenses per travel AP-60
authorization to actual expenses claimed for reimbursement
117 The system shall provide functionality to view and track the number of outstanding travel AP-60
advances and travel card expenditures that apply to one or more trips
118 The system shall provide functionality for users to inquire about employee travel history AP-60
(e.g., payment, supporting documents)
119 The system shall provide functionality to generate standard reports from travel-related data AP-60
120 The system shall provide functionality to support CONUS, IRS' high-low method of AP-60
reimbursements
121 The system shall provide functionality to create negative vouchers for travel expenses AP-60
122 The system shall provide functionality for users to upload and save IFB/RFP templates CO-10
123 The system shall provide functionality for users to search for IFB/RFP templates based on CO-10
search criteria including, but not limited to:
- Agency
- Bid type
- Dollar amount of bid
124 The system shall provide functionality for users to select sections and items from the CO-10
IFB/RFP templates to include or not include in the IFB/ RFP based on search criteria
including, but not limited to:
- Agency
- Bid type
- Dollar amount of bid
125 The system shall provide functionality for users to collaboratively develop IFB/RFP CO-10
126 The system shall provide functionality to copy an existing RFP/IFB to create a new RFP/IFB CO-10
127 The system shall provide functionality to "close" specific sections or items of the IFB/RFP CO-10
templates to prevent user modification
128 The system shall provide functionality to define which users are allowed to collaboratively CO-10
develop a specific IFB/RFP and grant them access to an online workspace for collaboration
129 The system shall provide functionality to grant read/write access to different sections of a CO-10
specific IFB/RFP draft
130 The system shall provide functionality to track versions of IFB/RFP drafts during CO-10
collaborative development
131 The system shall provide functionality to prevent multiple users from making updates to the CO-10
same section of the same IFB/RFP draft at the same time
132 The system shall provide functionality to notify users when edits or comments are made to CO-10
an IFB/RFP
133 The system shall provide functionality to establish, track, and monitor bid events and CO-10
milestones (e.g., IFB/RFP release, bidder conference, bid opening date)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 10 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
134 The system shall provide functionality to set up and edit a workflow for a bid event with a CO-10
variety of elements including, but not limited to:
- Key event dates
- Expected actions
- Required documents
- Appropriate approval levels
135 The system shall provide functionality to automatically send notifications to users regarding CO-10
each approaching key event in the bid event
136 The system shall provide functionality for users to "close" a bid event in the workflow upon CO-10
its completion
137 The system shall provide functionality to automatically send notifications to users if a bid CO-10
event ages past the date on which it should be "closed"
138 The system shall provide functionality to automate bid approval routing for users based on CO-10
business rules
139 The system shall provide functionality to automate bid approval routing for external parties CO-10
(i.e. outside agency) based on business rules
140 The system shall provide functionality for users to simultaneously approve bid documents CO-10
141 The system shall provide functionality for users to approve bid documents in sequence, with CO-10
one approval being contingent upon another
142 The system shall provide functionality for external users (i.e. outside agency) to CO-10
simultaneously approve bid documents
143 The system shall provide functionality for external users (i.e. outside agency) to approve bid CO-10
documents in sequence, with one approval being contingent upon another
144 The system shall provide functionality to prompt users for action if electronic request for CO-10
requisition approval ages past required action date
145 The system shall provide functionality to close key bid events if the required approvals have CO-10
not been received
146 The system shall provide functionality to automate bid notification routing for users based on CO-10
business rules
147 The system shall provide functionality to automate bid notification routing for external users CO-10
(i.e. outside agency) based on business rules
148 The system shall provide functionality for users to add comments and attachments to bid CO-10
approvals or rejections
149 The system shall provide functionality for external users (i.e. outside agency) to add CO-10
comments and attachments to bid approvals or rejections
150 The system shall provide functionality to track status of bid approvals CO-10
151 The system shall provide functionality to "close" an IFB/RFP when the draft content has CO-10
been completed and prevent the users from making additional edits
152 The system shall provide functionality to add, change, and delete IFB/RFPs CO-10
153 The system shall provide functionality to search for previous IFBs/RFPs based on user CO-10
defined criteria
154 The system shall provide functionality to post the IFB/RFP and supporting material to the CO-10
"bidder website"
155 The system shall provide functionality for vendors to register in a "bidder website" for CO-10
automatic notification of all IFBs/RFPs that fall in their self-selected, specific categories of
interest (e.g., furniture, office supplies, technology consulting)
156 The system shall provide functionality for vendors to register in "bidder website" for long- CO-10
term access rights to all IFBs/RFPs to which they wish to respond electronically
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 11 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
157 The system shall provide functionality to automatically prompt vendors via email to renew CO-10
"bidder website" registration at specific time intervals
158 The system shall provide functionality for vendors to search "bidder website" for relevant CO-10
IFBs/RFPs even if the vendors are not registered for automatic notification/long-term
electronic response access
159 The system shall provide functionality for users to search the bidder and vendor databases CO-10
in order to target specific organizations in the distribution of an IFB/RFP
160 The system shall provide functionality to restrict access to a specific IFB/RFP on "bidder CO-10
website" to a list of vendors
161 The system shall provide functionality to allow vendors to download IFBs/RFPs even if they CO-10
are not registered for automatic notification/long-term electronic response access
162 The system shall provide functionality to restrict vendors who are not registered for the CO-10
"bidder website" from submitting electronic responses
163 The system shall provide functionality to allow vendors not registered for automatic CO-10
notification/long-term electronic response access to complete "one-time" web registration so
that they can respond to a specific IFB/RFP electronically
164 The system shall provide functionality to track and enter the number of times each CO-10
document is downloaded from the "bidder website"
165 The system shall provide functionality to record and track web-registered vendor access to CO-10
specific IFBs/RFPs on the "bidder website"
166 The system shall provide functionality to automatically trigger the distribution of IFBs/RFPs CO-10
to vendors via mail
167 The system shall provide functionality to automatically alert users to bids received from out- CO-10
of-state or foreign vendors
168 The system shall provide functionality for vendors to submit responses to IFBs/RFPs CO-10
regardless of possible eligibility issues identified including, but not limited to:
- Federal identification numbers
- Performance history
- Location
169 The system shall provide functionality to create a bid tabulation summary sheet to enter bids CO-10
and/or responses
170 The system shall provide functionality to track and identify bid submissions that are pending CO-10
certification or other information so that internal reviewers are aware of the status
171 The system will provide functionality to allow users to set up evaluation criteria and/or CO-10
scoring models for IFBs/RFPs. Such evaluation criteria and/or scoring models shall include,
but not be limited to:
- Price per unit
- Award by line
- Award by lot
- Percent discount
- Grand total
- Cost plus
- Market basket price comparison analysis
- Formulas with variables
172 The system shall provide functionality to test the evaluation criteria/scoring model prior to CO-10
issuing IFB/RFP to verify that results are accurate
173 The system shall provide functionality for vendors to enter and submit responses to CO-10
IFBs/RFPs directly into fields set up by users on the "bidder website"
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 12 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
174 The system shall provide functionality for users to define certain fields in the IFB/RFP CO-10
templates as required, restricting submission until the fields are completed
175 The system shall provide functionality for vendors to enter and submit responses to CO-10
IFBs/RFPs as attachments/files on the "bidder website"
176 The system shall provide functionality for multiple vendors to access and respond to the CO-10
same IFB/RFP simultaneously
177 The system shall provide functionality for vendors to save their responses, so that they can CO-10
make multiple updates to them prior to submission
178 The system shall provide functionality to define disclaimer dialog box(es) that display prior to CO-10
vendors confirming their electronic submission
179 The system shall provide functionality for vendors to submit electronic amended versions of CO-10
IFB/RFP via the "bidder website" up to the submission date/time
180 The system shall provide functionality for vendors to save to their own systems a "print CO-10
version" copy of their electronic responses to an IFB/RFP
181 The system shall provide functionality to automatically time-stamp the submission of CO-10
electronic responses to an IFB/RFP
182 The system shall provide functionality for users to enter the receipt of paper bidder CO-10
responses
183 The system shall provide functionality for users to "post" scanned versions of paper bidder CO-10
responses to system
184 The system shall provide functionality to track means of notice (e.g., Contract Reporter) for CO-10
responding bidders
185 The system shall provide functionality to automatically restrict vendors from making changes CO-10
to their responses after submission date and time
186 The system shall provide functionality to automatically remove IFB/RFP from "bidder CO-10
website" after a period of time
187 The system shall provide functionality for users to extend deadline for submission on "bidder CO-10
website"
188 The system shall provide functionality to automatically assign a unique identification number CO-10
to each bidder response entered
189 The system shall provide functionality to automatically generate an "electronic receipt" when CO-10
vendors submit an electronic response for consideration
190 The system shall provide functionality to place submitted bids in a restricted work space that CO-10
can only be accessed by users at specific times
191 The system shall provide functionality to count the number of vendor responses received, CO-10
and save the result in restricted work space prior to the bid opening date
192 The system shall provide functionality to mark parts of bidder response as protected from CO-10
future FOIL requests
193 The system shall provide functionality for users to conduct "pre-screening" of bidder CO-10
responses prior to distributing them for evaluation
194 The system shall provide functionality for users to grant evaluators access to specific CO-10
electronic bidder responses, including technical and fiscal responses, and any additional
material for review and "scoring"
195 The system shall provide functionality for users to restrict evaluator from viewing parts of a CO-10
bidder response (e.g., evaluators typically do not have access to the cost proposal)
196 The system shall provide functionality for evaluators to review the bidder responses CO-10
electronically and to directly enter "scores" into system
197 The system shall provide functionality for evaluators to save their "scores" and update them CO-10
on multiple occasions prior to submitting them for calculation
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 13 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
198 The system shall provide functionality to restrict an evaluator from accessing other CO-10
evaluators' "scores"
199 The system shall allow users to define the steps and business rules used to calculate CO-10
scores for each vendor bid
200 The system shall provide functionality to automatically compile evaluations and scores CO-10
201 The system shall provide functionality to determine a short list of vendors based on eligibility CO-10
requirements or preliminary evaluation results
202 The system shall provide functionality to create user defined free text/supplement fields CO-10
associated with each vendors bid
203 The system shall provide functionality to track and enter a summary of bidder responses, CO-10
with information including users, bid amounts, evaluation results, etc.
204 The system shall provide functionality for users to award a bid to a selected vendor CO-10
205 The system shall provide functionality for users to award a bid to multiple selected vendors CO-10
206 The system shall provide functionality to deselect bidders awarded a bid CO-10
207 The system shall provide functionality to post the name of a selected vendor to the "bidder CO-10
website" after the award has been approved
208 The system shall provide functionality for users to email messages and documents to CO-10
individual vendors
209 The system shall provide functionality for users to email messages and documents to CO-10
multiple vendors simultaneously
210 The system shall provide functionality for users to select from email correspondence CO-10
templates (e.g., free standing text)
211 The system shall provide functionality to automatically save copies of all email CO-10
communications for an electronic audit trail
212 The system shall provide functionality to upload and save formal correspondence templates CO-10
(e.g., award letter)
213 The system shall provide functionality for bid coordinators to revise formal correspondence CO-10
templates
214 The system shall provide functionality to automatically alert users of bidder questions CO-10
received after the question-and-answer deadline
215 The system shall provide functionality to track and report the status of all bids CO-10
216 The system shall provide functionality to define bid reporting categories and run ad hoc CO-10
reporting
217 The system shall provide functionality to automatically save bid documents and results for a CO-10
defined period of time
218 The system shall provide functionality to automatically save bid documents and results for a CO-10
period of time on a case-by-case basis
219 The system will provide capability to accept proposals as "Continuous Solicitations" and CO-10
allow users to open bids regardless of when received
220 The system will provide capability to allow multiple contractors for a single award CO-10
221 The system will provide capability to allow additional or supplemental contracts to an CO-10
existing award or contract
222 The system shall provide functionality to upload and save contract templates CO-20
223 The system shall provide functionality to search for contract templates based on criteria CO-20
including, but not limited to:
- Agency
- Contract type
- Dollar amount of contract
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 14 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
224 The system shall provide functionality to select sections and items from the contract CO-20
templates to include or exclude in a first draft based on search criteria including, but not
limited to:
- Agency
- Contract type
- Dollar amount of contract
225 The system shall provide functionality to collaboratively create an electronic contract online CO-20
226 The system shall provide functionality to copy an existing contract to create a new contract CO-20
227 The system shall provide functionality to "close" specific sections and items of the contract CO-20
templates to restrict user modification
228 The system shall provide functionality to define participants for collaborative development of CO-20
a specific contract and to grant them access to an online "space" for collaboration
229 The system shall provide functionality to grant read/write access to different sections of a CO-20
specific contract draft
230 The system shall provide functionality to track versions of contract drafts during CO-20
collaborative online development
231 The system shall provide functionality to prevent multiple users from making updates to the CO-20
same section of the same contract draft at the same time
232 The system shall provide functionality to notify users when edits or comments are made to a CO-20
specific contract
233 The system shall provide functionality for users to “close” a contract when the draft has CO-20
been completed and prevent users from making additional edits
234 The system shall provide functionality to add, change, and delete a contract CO-20
235 The system shall provide functionality for users to assign a unique identification number to CO-20
each contract
236 The system shall provide functionality for users to link a contract file to its bid/procurement CO-20
history
237 The system shall provide functionality for users to link a contract file to its grant file(s) CO-20
238 The system shall provide functionality for users to link a contract file to the vendor file CO-20
239 The system shall provide functionality for users to link a contract file to projects CO-20
240 The system shall provide functionality to automatically populate key fields in a contract file CO-20
with data from the vendor file
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 15 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
241 The system shall provide functionality to maintain profile information on each contract, including, but not CO-20
limited to:
- Vendor
- Vendor contact information
- Contract amount
- Contract number
- Contract period (start/end date)
- Contract execution date
- Project ID(s)
- Program
- Activity
- Contract type
- Funding source(s) (e.g., federal, consent orders)
- Amendments/renewals
- Deliverables and/or items
- Sub-contractors (includes WBE/MBE compliance)
- Units of measures
- Minimum order
- Method of payment
- Award date
- Budget ceiling
- Performance bond/insurance information
- Liquidated damages
- Retainage
- Performance bonds/bid deposits
- Financial security
- Letter of credit
- Escrow agreements
242 The system shall provide functionality to automatically verify the following items against CO-20
existing State databases via interfaces including, but not limited to:
- Vendors' certifications
- Charity numbers
- Federal identification numbers.
The system will automatically alert the user if the verification check shows that a vendor
does not comply with State regulations
243 The system shall provide functionality for users to search previous contracts based on user CO-20
criteria
244 The system shall provide functionality to enter an encumbrance for a contract across CO-20
multiple fiscal years
245 The system shall provide functionality to enter the agency, agency sub-unit, or individual CO-20
who received services from a vendor and the date the services were received
246 The system shall provide functionality for users to inquiry about goods received by an CO-20
agency
247 The system shall provide functionality for users to directly enter bid evaluation "scores" into CO-20
the system
248 The system shall provide functionality for users to save their bid evaluation "scores" and CO-20
update them on multiple occasions prior to submitting them for calculation
249 The system shall provide functionality to restrict an evaluator from accessing other CO-20
evaluators' "scores"
250 The system shall provide functionality for users to query contract information between and CO-20
within state agencies
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 16 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
251 The system shall provide functionality to manage different contract types including, but not CO-20
limited to:
- Fixed fee
- Time and materials
- Retainage
- Price agreements
- Discounts from price lists
- Revenue-based
- Performance-based
252 The system shall provide functionality to establish, track, and report on cost-plus contracts CO-20
253 The system shall provide functionality to perform a global price adjustment to a price CO-20
contract, either through a specified change or by using vendor-supplied data
254 The system shall provide functionality to manage a contract with multiple funding sources CO-20
255 The system shall provide functionality to manage a contract with different "contract" and CO-20
"effective" dates
256 The system shall provide functionality to suspend a bid/contract prior to completion CO-20
257 The system shall provide functionality to access status of a contract CO-20
258 The system shall provide functionality to monitor expenditures against the contract amount CO-20
259 The system shall provide functionality to prevent the total expenditure and encumbrance CO-20
balance from exceeding the contract amount
260 The system shall provide functionality for a warning before processing contract-related CO-20
transactions if a contract's expiration date has passed or if a contract is on hold or pending
261 The system shall provide functionality to prevent the processing of contract-related CO-20
transactions if a contract's expiration date has passed or if a contract is on hold
262 The system shall provide functionality for users to query the status of expenditures against a CO-20
contract, and to provide summary amounts for different time periods including, but not
limited to:
- Period to Date
- Month to Date
- Quarterly to Date
- Year to Date
- Previous Month to Date
- Previous Quarter to Date
- Previous Year to Date
- Fiscal Year
- Life to Date
263 The system shall provide functionality to access the original contract amounts, as well as CO-20
the amended contract amounts
264 The system shall provide functionality to enter and track change orders CO-20
265 The system shall provide functionality to access contract budgetary controls by contract CO-20
(e.g., contract year if different from the fiscal year, contract cap, and the beginning/end date
of the contract)
266 The system shall provide functionality to track and report the status of all contracts CO-20
267 The system shall provide functionality to establish, track, and report on a contract's CO-20
contingency allowance (delivery of good or service is contingent upon need) or specified
allowance (delivery of good or service is known, but dollar amount is not)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 17 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
268 The system shall provide functionality to automatically save contract documents and results CO-20
for a period of time
269 The system shall provide functionality to automatically save contract documents and results CO-20
for a period of time on a case-by-case basis
270 The system shall provide functionality to deselect bidders awarded a contract CO-20
271 The system shall provide functionality to automate contract approval routing for users based CO-30
on business rules
272 The system shall provide functionality to automate contract approval routing for external CO-30
users (i.e. outside agency) based on business rules
273 The system shall provide functionality for users to approve contract documents CO-30
simultaneously
274 The system shall provide functionality for users to approve contract documents in sequence, CO-30
with one approval being contingent upon another
275 The system shall provide functionality for external users to approve contract documents CO-30
simultaneously
276 The system shall provide functionality for external users to approve contract documents in CO-30
sequence, with one approval being contingent upon another
277 The system shall provide functionality to close key contract events if the required approvals CO-30
have not been received
278 The system shall provide functionality to automate contract event notification routing for CO-30
users based on business rules
279 The system shall provide functionality to automate contract event notification routing for CO-30
external users based on business rules
280 The system shall provide functionality for users to add comments and attachments to CO-30
contract approvals or rejections
281 The system shall provide functionality for external users to add comments and attachments CO-30
to contract approvals or rejections
282 The system shall provide functionality to track status of contract approvals CO-30
283 The system shall provide functionality for users to create an online survey and electronically CO-40
distribute it to employees who received goods or services from a vendor
284 The system shall provide functionality for users to save their survey responses online so CO-40
that they can make multiple updates prior to submission
285 The system shall provide functionality to collect survey responses and evaluate vendor CO-40
performance based on "scores" entered into the system by survey respondents
286 The system shall provide functionality to define performance measures in a contract file CO-40
287 The system shall provide functionality to track vendor performance against performance CO-40
measures in the contract file
288 The system shall provide functionality to attach documents regarding vendor performance CO-40
(e.g., vendor reports) to the contract file
289 The system shall provide functionality to enter contract actions (e.g., key correspondence CO-40
dates, sanctions) in the contract file
290 The system shall provide functionality to track subcontracting activities against the contract CO-40
(e.g., subcontractor responsibilities, percentage of revenue, start and end dates)
291 The system shall provide functionality to upload and save amendment/renewal templates CO-40
292 The system shall provide functionality to select sections and items from the CO-40
amendment/renewal templates to include in the contract
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 18 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
293 The system shall provide functionality to save final amendment/renewal in system as part of CO-40
contract file
294 The system shall provide functionality to update contract file to reflect amended information CO-40
295 The system shall provide functionality to track the original contract amount and adjustments CO-40
to the amounts resulting from change orders and/or amendments
296 The system shall provide functionality to identify contracts that are eligible to be renewed CO-40
297 The system shall provide functionality to notify the user, after a certain number of days has CO-40
elapsed, to complete the execution of a recurring contract
298 The system shall provide functionality to notify the user, after a certain number of days has CO-40
elapsed, to initiate the process of renewing an existing contract
299 The system shall provide functionality to reopen closed contracts CO-40
300 The system shall provide functionality to maintain an audit trail of actions taken pertaining to CO-40
contract management (e.g., reports, sanctions, key communications)
301 The system shall provide functionality to allow users to access all previously approved CO-40
contracts and respective amendments
302 The system shall provide functionality to create a pre-encumbrance at point of requisition PO-10
303 The system shall provide functionality to create an encumbrance at the point of purchase PO-10
order and/or contract
304 The system shall provide functionality to liquidate the pre-encumbrance on a requisition PO-10
once a line or the entire requisition is cancelled
305 The system shall provide functionality to create an optional encumbrance with no specific PO-10
vendor reference to reserve funds in the system for future procurements
306 The system shall provide functionality for users to create an optional encumbrance for a PO-10
specific purpose or vendor and reference the optional encumbrance on a voucher
307 The system shall provide functionality for users to create and maintain blanket PO-10
encumbrances where the vendor and goods are known, but delivery needs change
periodically (e.g., milk for a youth facility)
308 The system shall provide functionality to select vendors alphabetically by name, by vendor PO-10
number, or by their correct Federal Employer Identification Number (FEIN) number for entry
into a requisition, solicitation/bid, and purchase order
309 The system shall provide functionality to perform the following requisitions and purchase PO-10
functions including, but not limited to:
- Inquiry
- Add
- Change
- Cancel
- Delete
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 19 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
310 The system shall include fields for the following information on a requisition and purchase order PO-10
including, but not limited to:
- Vendor Name
- Vendor Number
- Buyer Number
- Ship To Address
- Order From Address
- Commodity Code
- Description
- Unit of Measure
- Unit Price
- Quantity
- Total Amount
- Account Code Structure
- Recycled Content Indicator
- Project Code (Pin Number)
- Contract Number
- Discretionary Purchase Flag
- Method of Purchase
- Group Number
- FOB Field
- Payment Terms
- Item Master Reference or Description
- Discount Percent
- Asset ID Number
- MWBE Status
- Small Business
- MSDS
311 The system shall provide functionality to save incomplete requisitions and purchase orders PO-10
312 The system shall provide functionality for users to suggest multiple recommended vendors PO-10
and associated cost estimates on a requisition
313 The system shall provide functionality to access and select stock items from the item master PO-10
for requisitions and purchase orders
314 The system shall provide functionality to enter hazardous materials codes based on PO-10
standards
315 The system shall provide functionality to automatically create a requisition and/or purchase PO-10
order for inventoried supplies when supplies reach a specified order level
316 The system shall provide functionality to enter zero dollar requisitions and purchase orders PO-10
317 The system shall provide functionality to assign a buyer number or id to either an entire PO-10
requisition or specific line items of a requisition
318 The system shall provide functionality to automatically validate certain requisition and PO-10
purchase order fields, at the time of creation including, but not limited to:
- Commodity Code
- Object Account
- Account Code
- Pin/Project Number
319 The system shall fully support the UNSPSC (United Nations Standard Product and Service PO-10
Code) commodity code system
320 The system shall provide functionality to identify multiple delivery dates and ship-to locations PO-10
on a line item basis for requisitions and purchase orders
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 20 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
321 The system shall provide functionality to associate multiple account codes to a single line PO-10
item on a requisition or purchase order
322 The system shall provide functionality to pre-populate account code information into PO-10
transactions based on users defaults and allow for defaults to be changed
323 The system shall provide functionality to enable a percentage based distribution of costs for PO-10
a line item across multiple account codes on a requisition or purchase order
324 The system shall provide functionality to automatically populate a central ship-to address PO-10
with capabilities to override the address on an as-needed basis
325 The system shall provide functionality to assign unique document numbers for the following PO-10
including, but not limited to:
- Solicitations
- Requisitions
- Purchase orders
326 The system shall provide functionality for users to manually assign unique document PO-10
numbers for the following including, but not limited to:
- Solicitations
- Requisitions
- Purchase orders
327 The system shall provide functionality to enable no less than six decimal places for price per PO-10
units of measure
328 The system shall provide the ability for users to route certain requisitions through the PO-10
approval process (sequential or parallel) and not others
329 The system shall provide functionality to enter pre-encumbrance of a requisition at either the PO-10
time of creating the requisition or once all required approvals are received
330 The system shall provide functionality to perform an automated check of the budget for PO-10
funds availability at the time of pre-encumbrance and/or encumbrance
331 The system shall provide functionality to allow the user to modify the requisition amount PO-10
after it has initially been saved
332 The system shall provide functionality for budget checking capability to restrict users from PO-10
overspending the funds allotted to their department/cost center
333 The system shall provide functionality to allow users to choose whether or not to pre- PO-10
encumber a requisition at the time of creation
334 The system shall provide functionality to backdate purchase orders. PO-10
335 The system shall provide functionality for sequential approval routing of requisitions and PO-10
purchase orders based on item classifications and enter the appropriate date and time
stamps
336 The system shall provide functionality for sequential approval routing of requisitions and PO-10
purchase orders based on dollar thresholds and enter the appropriate date and time stamps
337 The system shall provide functionality for parallel approval routing of requisitions and PO-10
purchase orders, based on item classifications, and enter the appropriate date and time
stamps
338 The system shall provide functionality for parallel approval routing of requisitions and PO-10
purchase orders, based on dollar thresholds, and enter the appropriate date and time
stamps
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 21 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
339 The system shall provide functionality to determine the appropriate approval/workflow to PO-10
execute based on various information including but not limited to:
- Transaction type
- Agency
- Account code
- Dollar value
- Commodity
340 The system shall provide functionality to initiate an approval process if certain modifications PO-10
are made to fields to a requisition or purchase order after submission for approval (e.g.,
changes to quantity and/or price)
341 The system shall provide functionality to initiate an approval process if modifications are PO-10
made to a solicitation after submission for approval
342 The system shall provide functionality to pass change orders to a purchase order through an PO-10
approval routing process
343 The system shall provide functionality for approvers in the approval routing process to PO-10
approve, reject, or edit requisitions
344 The system shall provide functionality to create and track (e.g., identify, enter, inquire, PO-10
report) all orders, including orders for items that have graduated pricing (e.g., the first 25
items are $0.25, 26-50 items are $.20)
345 The system shall provide functionality to enter term conditions for %, net days, and/or date PO-10
of month if vendor offers prompt payment or any discount
346 The system shall provide functionality to aggregate multiple requisitions to a single purchase PO-10
order
347 The system shall provide functionality to add comments on documents including, but not PO-10
limited to:
- Requisition
- Purchase order
- Receiving report
- Return merchandise authorization (RMA)
- Contract
- Change order (line by line or by entire document)
348 The system shall provide functionality to edit specific purchase order fields after approval PO-10
has occurred
349 The system shall provide functionality to create a purchase order without entering the PO-10
associated account coding
350 The system shall provide functionality for fields to document justification for award of a PO-10
purchase order and/or contract
351 The system shall provide functionality to create change orders to existing purchase orders PO-10
352 The system shall provide functionality to fully liquidate the encumbrance on a purchase PO-10
order/contract once the entire purchase order/contract is cancelled
353 The system shall provide functionality to partially liquidate the encumbrance on a purchase PO-10
order/contract once a line on the purchase order/contract is cancelled
354 The system shall provide functionality to keep purchase orders open when encumbrances PO-10
have been liquidated so that purchase orders can cross fiscal years
355 The system shall provide functionality to create recurring purchase orders PO-10
356 The system shall provide functionality to route purchase orders to agencies outside of the PO-10
originating agency for approvals
357 The system shall provide functionality to require the tax ID number of a vendor before PO-10
awarding a purchase order or contract
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 22 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
358 The system shall provide functionality to automatically notify users via email about pending PO-10
approval action, pending items for review, and pending orders for receipt
359 The system shall provide functionality to automatically route purchase orders that are above PO-10
a threshold and for items not on an existing contract to an external agency for approval
360 The system shall provide functionality to award multiple contracts from one requisition PO-10
361 The system shall provide functionality to create multiple purchase orders from one PO-10
requisition
362 The system shall provide functionality to create requisition and purchase order documents PO-10
that include multiple accounting and commodity lines (up to 1,000 lines)
363 The system shall provide functionality to set price and quantity tolerances by line item on PO-10
purchase orders for over-runs
364 The system shall provide functionality to copy existing purchase order information into a new PO-10
or modified purchase order
365 The system shall provide functionality to transfer information from the bid response to a PO-10
contract or purchase order
366 The system shall provide functionality for the issuance of multiple purchase orders from a PO-10
single solicitation/bid
367 The system shall provide functionality to enable the creation of purchase orders without a PO-10
requisition
368 The system shall provide functionality to enable the inclusion of the value of trade-ins/credits PO-10
on a purchase order that reduces the total purchase order value
369 The system shall provide functionality to reverse the pre-encumbrance on a requisition and PO-10
encumber the purchase order at the time of purchase order creation
370 The system shall provide functionality to identify line items within a purchase which will PO-10
generate an asset record
371 The system shall provide functionality to place orders and/or change orders via internet, PO-10
EDI, fax, and paper form
372 The system shall provide a mechanism to send documents to vendors including, but not PO-10
limited to:
- Bid request
- Purchase orders
- Contracts
- Standard letters via multiple formats based on vendor profiles (email, EDI, XML, fax
server, hard copy, etc.)
373 The system shall provide functionality to alert all participants in a transaction (requestor, PO-10
initiator, receiver, AP clerk) upon the event of partial or complete purchase order
cancellation
374 The system shall provide functionality to alert the designated users when an asset has been PO-10
purchased, accepted, rejected, or returned by the receiver
375 The system shall provide functionality to establish required fields based on prompts such as PO-10
the cancellation of a purchase order/line item (e.g., if a purchase order is cancelled, require
users to populate a purchase order date cancelled field)
376 The system shall provide functionality to use a purchase order for goods and services PO-10
ordered from an internal department and/or external agencies
377 The system shall provide functionality to match receipts and vouchers (e.g., quantities, PO-10
receipt date, and prices) against purchase order line items and report discrepancies
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 23 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
378 The system shall provide functionality for users to run inquiries on line-item information from PO-10
purchase orders, requisitions, and/or solicitation/bid information for any combination of the
following fields:
- Commodity code/inventory item number
- Description
- Unit of measure
- Recommended vendor (For requisitions only)
- Previous vendor (For requisitions only)
- Previous price (For requisitions only)
- Account information
- Ship to/Bill to/Invoice to
- From Date
- To Data
379 The system shall provide functionality to create a blanket purchase order without a vendor, PO-10
for a specified dollar amount and later release purchase order against the blanket for
specific vendors
380 The system shall provide functionality to create a blanket purchase order and create PO-10
subsequent purchase orders against the blanket
381 The system shall provide functionality to enable orders with staggered delivery schedules on PO-10
a line item basis
382 The system shall provide functionality to automatically update requisitions and purchase PO-10
orders to reflect cumulative volume and/or quantity discounts specified within the contract
383 The system shall provide functionality to update posted encumbrances when changes to the PO-10
existing purchase order quantity and/or price are processed
384 The system shall provide functionality to update the purchase order with order PO-10
acknowledgements received electronically from the vendor
385 The system shall provide functionality for users to create templates for documents including, PO-10
but not limited to:
- Requisition
- Request for bid
- Purchase order
386 The system shall provide functionality for users to inquire on the status of requisitions, PO-10
purchase orders, and receipts
387 The system shall provide functionality to transfer information from the requisition to the PO-10
solicitation
388 The system shall provide functionality for users to extend opening date of established PO-10
solicitations
389 The system shall provide functionality to save individual components of a solicitation, PO-10
including, but not limited to:
- Solicitation
- Addenda
- Questions and answers
- Solicitation status
- Solicitation results
- Other information to a web-enabled front-end
390 The system shall provide functionality for users to add non-registered vendors to the system PO-10
for the purpose of accessing the bid document
391 The system shall provide functionality to set the release date of the bid subsequent to the PO-10
purchasing or contract addenda
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 24 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
392 The system shall provide functionality for users to determine which vendors will receive PO-10
solicitations
393 The system shall provide functionality to receive vendor solicitations and accept vendor PO-10
questions submitted electronically
394 The system shall provide functionality to post responses to questions to a web-enabled front PO-10
end when approved
395 The system shall provide functionality to alert invited vendors of any changes to a PO-10
solicitation
396 The system shall provide functionality to receive responses electronically and include an PO-10
electronic time and date stamp
397 The system shall provide functionality to reject responses submitted after the bid opening PO-10
date and time have passed
398 The system shall provide functionality to accept the receipt of bid responses via manual PO-10
entry (response received outside the system from phone, fax, email, etc.) or web interface
399 The system shall provide functionality for users to indicate the time/date stamp of manually PO-10
received responses
400 The system shall provide functionality to control access to the vendors’ responses to allow PO-10
only vendors to edit/view their own response
401 The system shall provide functionality to track all bidder responses against an open bid PO-10
(including "no responses")
402 The system shall provide functionality for users to delete a bid response at the vendor’s PO-10
request
403 The system shall provide functionality to track who received a solicitation, who responded, PO-10
and who did not respond
404 The system shall provide functionality for users to create ad hoc management reports for PO-10
solicitation/bid information
405 The system shall provide functionality for users to standardize comparable units of measure PO-10
406 The system shall provide functionality to enable the award of a solicitation by line item, by PO-10
groups of line items, or for all items
407 The system shall provide functionality for users to edit standard solicitation award letters PO-10
408 The system shall provide functionality to extract pricing and terms automatically from a PO-10
contract onto the purchase order
409 The system shall provide functionality to automatically validate the contract terms and PO-10
conditions in a purchase order that is created against a specific contract
410 The system shall provide functionality for users to create IFBs and RFQs using templates PO-10
411 The system shall provide functionality for freight and payment term fields as part of the PO-10
solicitation/bid
412 The system shall provide functionality to enable payment of invoices without a purchase PO-10
order
413 The system shall provide functionality for users to enter vendor responses against a PO-10
solicitation/bid
414 The system shall provide functionality to select multiple winning responses from the bid and PO-10
then create multiple purchase orders
415 The system shall provide functionality to maintain and report an audit trail of changes and PO-10
updates to purchase orders, requisitions, quotes/bids, and change orders
416 The system shall provide functionality to enable standard item classification codes PO-10
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 25 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
417 The system shall provide functionality for inquiries to display YTD orders, pending payables, PO-10
unmatched receivers, and unmatched vendor invoices by vendor
418 The system shall provide functionality for detailed purchasing history by vendor via inquiry PO-10
419 The system shall provide functionality for inquiries to summarize purchasing history by PO-10
vendor
420 The system shall provide functionality for inquiry tools to view the history of change PO-10
orders/amendments to a purchase order
421 The system shall provide functionality for inquiries to outstanding purchase orders by PO-10
department/agency
422 The system shall provide functionality for inquiries to receiving history regarding items and PO-10
quantities received and waiting receipt
423 The system shall provide a tool for automated tabulation of responses based on factors PO-10
such as price and percent discounts (IFBs only)
424 The system shall provide functionality to tabulate responses by grouping of line items or PO-10
single line items
425 The system shall provide functionality to enable the import of structured data from an PO-10
external web-enabled front end /source (e.g., NIGP for specifications)
426 The system shall provide functionality for searches of the vendor list from within the PO-20
requisition or solicitation development tool to identify vendors for a solicitation
427 The system shall provide functionality to accommodate the use of online vendor's catalog(s) PO-20
428 The system shall provide functionality for users to identify favorites or to bookmark specific PO-20
pages within the catalog to enable catalog browsing during subsequent sessions
429 The system shall provide functionality to automatically update pricing and product PO-20
information within a favorites list when the electronic catalog is updated
430 The system shall provide functionality to compare prices, descriptions, and specifications PO-20
across multiple vendors, contracts, and schedules of items within the system catalog (either
internal or external)
431 The system shall provide functionality to have an electronic catalog that must restrict certain PO-20
contracts and line items to be viewed and/or ordered only by users, user groups, agencies,
or groups of agencies
432 The system shall provide functionality to enable the automatic population of PO-20
requisition/purchase order line items with information transferred from a vendor-maintained
web catalog when an order is initiated
433 The system shall provide functionality to allow users to control the effective date of an PO-20
update to a certain catalog line item
434 The system shall provide functionality for users to create items catalogs with a PO-20
corresponding price list
435 The system shall provide functionality for users to add and maintain foreign vendors (without PO-20
a FEIN)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 26 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
436 The system shall provide functionality to add, delete, search, and edit vendor/payee PO-20
information including, but not limited to:
- Vendor Name
- Vendor ID Number
- Federal ID Number (e.g., FEIN)
- Dun & Bradstreet Number
- Payment Addresses
- Order from Addresses
- City/State/Zip Code
- Phone Numbers
- Contact Person(s)
- Vendor Email Address
- Commodity Code Grouping
- Method of Payment
- Geographic Location
- Vendor Fax Number
- Minority/Women Business Code
- EFT and EDI Information
- 1099 Reporting Code
- Default Account Information
- Small Business Code
- Employee (Yes/No)
- Interest Eligibility
437 The system shall provide functionality for users to add, delete, search, edit order form and PO-20
payment information related to vendor records including, but not limited to:
- Contract Name
- Address Line 1
- Address Line 2
- City
- State
- Zip
- Phone Number
438 The system shall provide functionality to alert users if multiple vendors have the same FEIN PO-20
439 The system shall provide functionality to automatically create a unique vendor identifier PO-20
440 The system shall provide functionality to allow vendor information to be updated at any point PO-20
in the procure-to-pay process and have those changes reflected on open documents related
to that vendor
441 The system shall provide functionality to place a spending threshold on a vendor by agency PO-20
so that notifications can be created, informing users when the spending limit is about to be
exceeded
442 The system shall provide functionality to create parent-child relationships based on various PO-20
data including, but not limited to:
- Tax ID number
- Owner/subsidiary relationship
- Merger/dissolution history
- Former name(s)
- Other criteria
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 27 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
443 The system shall provide functionality for an automatic notification to the vendor or users, PO-20
based on criteria including, but not limited to:
- Non-responsiveness over a period of time
- Vendor status change
444 The system shall provide functionality to capture contact information of agency PO-20
representative for 1099 reporting
445 The system shall provide functionality to maintain a log of vendor complaints across all PO-20
agencies through resolution
446 The system shall provide functionality to track vendor performance including, but not limited PO-20
to:
- Late Delivery
- Quantity/Quality
- Specification Issues
- Milestone Dates Achieved
- Invoicing Errors
- Non Responsibility Determination
- Suspended or Debarred Status
447 The system shall provide functionality for users to deactivate a vendor and simultaneously PO-20
track the history of transactions assigned to that vendor
448 The system shall provide functionality to identify any information as "confidential," restricting PO-20
access accordingly through security, in the vendor/payee file
449 The system shall provide functionality for users to edit vendor information on a procurement PO-20
or payment document until time of payment (e.g., vendor changes name, merges with
another company)
450 The system shall provide functionality to save templates of vendor management documents PO-20
and emails
451 The system shall provide functionality to automatically notify, via email or workflow, users of PO-20
changes to specific vendor fields, including, but not limited to:
- Address
- Location
- Tax ID number
452 The system shall provide functionality for at least 10 commodity codes for each vendor PO-20
master record
453 The system shall provide functionality to assign agency specific classifications and PO-20
characteristics to each vendor master record (e.g., Vendor X does business with both the
Department of Corrections and Department of Education; however, the vendor has different
Order-from address and reporting codes for each agency)
454 The system shall provide functionality to route vendor self-service updates for approval to a PO-20
purchasing entity prior to being accepted
455 The system shall provide functionality to merge duplicate vendor records into one vendor PO-20
record (e.g., if an organization has multiple records for vendor X, the ability to merge all of
those vendor records into one record for vendor X)
456 The system shall provide functionality to approve purchase card transactions before the PO-30
processing of the transaction
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 28 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
457 The system shall provide functionality to record and save card assignment information for a PO-30
cardholder including, but not limited to:
- Unique cardholder ID number
- Fund account coding close
- Merchant classification code (MCC) profile name
- Cardholder specific controls of transaction limits
- Dollar value limits
458 The system shall provide functionality to use drop-down menus to select specific pre-coded PO-30
data to complete the transaction including, but not limited to:
- Account numbers
- Commodity codes
459 The system shall provide functionality for users to link goods/services acquired with a PO-30
purchase card to an asset (e.g., relating the purchase of a copier with the office supplies
category in assets)
460 The system shall provide functionality to manage and record consumption dollars through PO-30
the purchase card interface
461 The system shall provide functionality to enable at least five purchase card providers (e.g., PO-30
purchase card and travel card)
462 The system shall provide functionality to distribute the purchase card transactions received PO-30
from the bank to users based on an established unique identifier
463 The system shall provide functionality to allow manual entry of purchase card transaction PO-30
information in a form or template
464 The system shall provide functionality to add fields to the transaction data including, but not PO-30
limited to:
- Detailed product description
- Merchant
- Set-aside purchase
- Receipt
- Term contract number
- Asset number
- Commodity code or object code
465 The system shall provide functionality to track returned purchases made using purchase PO-30
cards
466 The system shall provide functionality to handle automatic downloads of Level One, Two, PO-30
and Three purchase card transaction data into the system from a third party including, but
not limited to:
- Item Description
- Quantity
- Unit Price
- Cost
- Item Classification Code
- Transaction Date
- Vendor
- Tax ID
467 The system shall provide functionality for users to review, update, and submit their purchase PO-30
card expense data
468 The system shall provide functionality to have a status indicator which will identify PO-30
questionable transactions (e.g., transaction is on hold, transaction is not reconciled)
469 The system shall provide functionality to automatically notify users via email or workflow of PO-30
purchase card transactions that have not been acted on after a defined period of time
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 29 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
470 The system shall provide functionality to indicate open transactions made with a purchase PO-30
card that should be reviewed by specified users
471 The system shall provide functionality to perform ad hoc reporting against purchase card PO-30
transaction data
472 The system shall provide functionality to receive multiple transactions from multiple vendor PO-40
locations against a purchase order
473 The system shall provide functionality to save the date and time stamp of receipt for goods PO-40
and services
474 The system shall provide functionality to allow various types of transactions relating to the PO-40
receipt of goods/services including, but not limited to:
- Completes
- Back Order
- Rescheduled
- Balance Cancelled
- Partial receipts
- Material disposition
- Return goods for credit
- Return goods for damage
- Return goods for over-shipments
- Trade-ins (a line item rather than deducting from the actual cost)
475 The system shall provide functionality to perform blind receiving including, but not limited to: PO-40
- Close quantity with product description, item number, and unit of measure showing
- Provide verification mechanism of the quantity entered
476 The system shall provide functionality to record the receipt of no cost items PO-40
477 The system shall provide functionality to create a unique receiving number at time of receipt PO-40
478 The system shall provide functionality to enable the identification of commodities that require PO-40
a certificate, bond receipt, Material Safety Data Sheet (MSDS), or other documentation, and
alert the receiver to confirm valid status prior to approving receipt
479 The system shall provide functionality to enable the receipt of goods and services without a PO-40
purchase order
480 The system shall provide functionality to receive against purchase card transactions PO-40
481 The system shall provide functionality to conduct receiving on behalf of other agencies PO-40
482 The system shall provide functionality to process a return material authorization (either PO-40
electronic or hard copy, depending on vendor capabilities) for materials to be returned (e.g.,
rejected goods)
483 The system shall provide functionality to track (e.g., identify, save, inquire, report) the PO-40
reason for the rejection of goods by receiver (individual)
484 The system shall provide functionality to alert users of the planned date for return material to PO-40
be picked up by the vendor
485 The system shall provide functionality for the purchasing system and the inventory system to PO-40
share a common receiving function and item commodity file
486 The system shall provide functionality to automatically update inventory on-hand and on- PO-40
order when items are received into inventory from a purchase order
487 The system shall provide functionality for the receipt of goods, not the payment of goods, to PO-40
update inventory
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 30 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROCUREMENT REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
488 The system shall provide functionality to process three-way match transactions (purchase PO-40
order, receipt, and voucher)
489 The system shall provide functionality to transfer items between agencies/departments PO-40
using inter-department orders
490 The system shall provide functionality to authorize designated receivers (individuals) by PO-40
agency
491 The system shall provide functionality to automatically notify users via email or workflow of PO-40
purchase orders that are past its delivery dates and have not been fully received
492 The system shall provide functionality to automatically update purchase order status and PO-40
balances based on receipt of goods
493 The system shall provide functionality to reverse a receiving transaction against a purchase PO-40
order
494 The system shall provide functionality to create reminder notices to vendors for shipments PO-40
due based on defined thresholds
495 The system shall provide functionality for receiving transactions to create an AP liability in PO-40
the general ledger
496 The system shall provide functionality to process two-way matches (purchase order and PO-40
voucher)
497 The system shall provide functionality to enable inspection processing as a separate step in PO-40
the receiving process
498 The system shall provide functionality to establish receiving tolerances by commodity PO-40
classification code (e.g., computer hardware and software)
499 The system shall provide functionality to enable bar code scanners in the receiving process PO-40
500 The system shall provide functionality to automatically create vouchers upon the receipt of PO-40
goods against a purchase order
501 The system shall provide functionality for users to correct data entered into the receiving PO-40
system
502 The system shall provide functionality to receive against multiple ship-to addresses in a PO-40
purchase order
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 31 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
503 The system shall provide functionality for a fully integrated budget preparation and financial BU-10
system including the seamless exchange of budget and accounting information
504 The system shall provide functionality for budgeting and reporting by agency BU-10
505 The system shall provide functionality to accommodate a chart of accountsthat has at least BU-10
seven categories of data and associated sub-levels including, but not limited to:
- Agency
- Fund
- Sub-fund
- Program
- Account
- Sub-account
- Organization
- Department
- Division
- Location
- Grant
- Project
- Object
506 The system shall provide functionality to accommodate a multi-level appropriation structure BU-10
that satisfies the State's budgeting and statewide reporting requirements
507 The system shall provide functionality to accommodate a multi-level fund structure that BU-10
satisfies GAAP, GASB, statewide and agency reporting requirements
508 The system shall provide functionality to accommodate a fund structure that satisfies the BU-10
State's appropriation, agency, grant, contract, activity and capital project budgeting
requirements
509 The system shall provide functionality for users to identify fund classification at both the BU-10
agency and statewide levels according to Governmental Accounting, Auditing, and Financial
Reporting (GAAFR) or other external requirements
510 The system shall provide functionality for users to establish central appropriation control at BU-10
any level in the chart of accounts including, but not limited to:
- Fund
- Program
511 The system shall provide functionality to accommodate a hierarchical budget chart of BU-10
accounts, such that each level is a summary of the level directly beneath it
512 The system shall provide functionality for users to develop an agency budget at any level in BU-10
the chart of accounts and aggregate the results to the appropriation level
513 The system shall provide functionality for users to develop budget at a higher level in the BU-10
chart of accountst han expenditures and encumbrances are entered
514 The system shall provide functionality for users to control budget at a higher level in the BU-10
chart of accounts than expenditures and encumbrances are entered
515 The system shall provide functionality for different agencies to develop its budgets at BU-10
different levels in the chart of accounts (e.g., program level for Agency A vs. department
level for Agency B)
516 The system shall provide functionality for users to create new budget lines at any time BU-10
throughout the year
517 The system shall provide functionality for users to establish effective dates to activate or BU-10
deactivate budget lines at various times throughout the year
518 The system shall provide functionality for users to set budgetary controls at any level in the BU-10
chart of accounts
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 32 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
519 The system shall provide functionality for users in different agencies to set budgetary BU-10
controls at different levels in the chart of accounts (i.e. program level for Agency A vs. cost
level for Agency B)
520 The system shall provide functionality for users to process transactions that exceed budget BU-10
controls, if the transactions are approved by a specified user
521 The system shall provide functionality for users to develop a budget at any level in the chart BU-10
of accounts while controlling budgets at a different level
522 The system shall provide functionality to monitor budget at any level in the data BU-10
classification structure
523 The system shall provide functionality to accommodate a holding account at the lowest level BU-10
in the chart of accountsto ensure that the budget remains in balance. When the budget is
adjusted at any level in the chart of accountshigher than the holding account, the holding
account shall be populated with the adjusted amount or the total of accumulated
adjustments
524 The system shall provide functionality for the holding account to contain negative numbers BU-10
525 The system shall provide functionality for users to develop the budget at a higher level or BU-10
lower level in the chart of accounts, than controlled at in the previous year
526 The system shall provide functionality for users to develop the budget at a higher or lower BU-10
level in the chart of accounts than developed in the previous year
527 The system shall provide functionality for users to lock lower levels in the chart of BU-10
accountsduring the budget preparation process so it can not be altered, while retaining
functionality to alter higher levels in the chart of accounts
528 The system shall provide functionality for users to assign responsibility to specific individuals BU-10
to identify who is responsible for developing certain levels in the chart of accounts including,
but not limited to: differing levels of the organization structure
529 The system shall provide functionality to automatically duplicate a version of the previous BU-10
year's budget and establish it as the starting budget for the current year's budget
530 The system shall provide functionality for users to identify and manually exclude proposals, BU-10
which were labeled as one-time in the previous year's budget, when duplicating the budget
531 The system shall provide functionality for users to set caps on the budget request at any BU-10
level in the chart of accounts
532 The system shall provide functionality for users to set caps on the budget request that are BU-10
either specific dollar amounts or percentages of a specific amount
533 The system shall provide functionality for users to selectively set caps on the budget request BU-10
at any level in the chart of accounts
534 The system shall provide functionality for users to set controls to prevent a budget request BU-10
that exceeds the cap
535 The system shall provide functionality for users to set controls to selectively prevent a BU-10
budget request that exceeds the cap
536 The system shall provide functionality to automatically identify a budget request that BU-10
exceeds the agency cap
537 The system shall provide functionality for users to save budget requests that exceed the cap BU-10
in order to edit them later
539 The system shall provide functionality for users to set limits on positions and/or FTEs at any BU-10
level in the chart of accounts
540 The system shall provide functionality for users to selectively set position and/or FTE caps BU-10
at any level in the chart of accounts
541 The system shall provide functionality for users to set controls to prevent a budget request BU-10
that exceeds the position and/or FTE cap
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 33 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
542 The system shall provide functionality for users to set controls to selectively prevent a BU-10
budget request that exceeds the position and/or FTE cap
543 The system shall provide functionality to automatically identify a budget requests that BU-10
exceeds the position and/or FTE cap
544 The system shall provide functionality for users to save budget requests that exceed the BU-10
position and/or FTE cap in order to edit them later
545 The system shall provide functionality for users to invoke the position and/or FTE caps on BU-10
individual versions of the budget
546 The system shall provide functionality for users to save budget documents (e.g., Call Letter, BU-10
instructions, budget request manual, targets, goals, submission forms) in a system-wide
document library
547 The system shall provide functionality for users to define and create budget documents BU-10
including instructions and linking data fields to specific elements in the coding structure
548 The system shall provide functionality for users to access and download budget request BU-10
documents that are saved (e.g., Call Letter, instructions, budget request manual, targets,
goals, submission forms)
549 The system shall provide functionality for users to develop performance based budgets BU-10
550 The system shall provide functionality to track performance-based budgets BU-10
551 The system shall provide functionality to report on performance measures BU-10
552 The system shall provide functionality for users to save budgeted and actual non-financial, BU-10
performance measures, and associated data at any level in the chart of accounts
553 The system shall provide functionality for users to establish relationships between BU-10
performance statistics and budget amounts
554 The system shall provide functionality for users to selectively use performance measures for BU-10
budgeting purposes
555 The system shall provide functionality for users to develop performance budgeting tools BU-10
556 The system shall provide functionality for users to realign actual and budgeted financial BU-10
information based on reorganizations to enable budget preparation
557 The system shall provide functionality to save historical financial information after a BU-10
reorganization in both the original structure and the revised structure at all levels in the chart
of accounts
558 The system shall provide functionality to display historical financial information after a BU-10
reorganization in both the original structure and the revised structure at all levels in the chart
of accounts
559 The system shall provide the ability to save historical coding information after a BU-10
reorganization in both the original structure and the revised structure at all levels in the chart
of accounts
560 The system shall provide the ability to display historical coding information after a BU-10
reorganization in both the original structure and the revised structure at all levels in the chart
of accounts
561 The system shall provide functionality for users to create requests for additions to the BU-10
starting budget, henceforth referred to as proposals
562 The system shall provide functionality for users to edit and track proposals while retaining BU-10
the initial value of the starting budget
563 The system shall provide functionality for users to create proposals that simultaneously BU-10
impact multiple levels in the chart of accounts
564 The system shall provide functionality for users to enter revenue estimates for each BU-10
proposal
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 34 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
565 The system shall provide functionality for users to enter expenditure estimates for each BU-10
proposal
566 The system shall provide functionality for users to create proposals that transfer budget BU-10
amounts between different levels in the chart of accounts (e.g., transferring budget between
different programs)
567 The system shall provide functionality for users to create multi-agency proposals that BU-10
simultaneously impact a number of agencies' budgets
568 The system shall provide functionality for users to view a summary of the proposal and its BU-10
the cumulative effect when the proposal impacts multiple levels in the chart of accounts
569 The system shall provide functionality to save at least 50 different iterations of a proposal BU-10
570 The system shall provide functionality for users to establish controls regarding who can BU-10
access the history or detail of the proposal
571 The system shall provide functionality for users to create at least 50 different categories to BU-10
label or classify proposals including, but not limited to:
- One-time vs. Recurring
- Core vs. Supplemental
- Administrative vs. Legislative
572 The system shall provide functionality for users to edit the values in each category when a BU-10
new version of a proposal is created
573 The system shall provide functionality to automatically pre-populate proposal categories with BU-10
the value assigned in the previous version of the proposal
574 The system shall provide functionality to create reports based on proposal categories BU-10
575 The system shall provide functionality to automatically prevent proposals from being entered BU-10
into invalid levels in the chart of accounts
576 The system shall provide functionality for users to create an unlimited number of proposals BU-10
each year
577 The system shall provide functionality for users to create mass adjustment proposals that BU-10
simultaneously impact a specific element in the chart of accounts throughout the entire
agency (e.g., 5% increase to utility costs in every program within the agency)
578 The system shall provide functionality for multiple users to simultaneously enter different BU-10
proposals that impact the same level in the chart of accounts
579 The system shall provide functionality to automatically prevent more than one user from BU-10
editing a proposal at the same time
580 The system shall provide functionality for users to "turn on" and "turn off" proposals as a BU-10
means to determine which proposals are used to create a version of the budget
581 The system shall provide functionality for users to link proposals together in a group so they BU-10
can be "turned on" or "turned off" simultaneously
582 The system shall provide functionality for users to simultaneously update categories on BU-10
proposals that are linked together
583 The system shall provide functionality to automatically combine the activated proposals with BU-10
the starting budget to create a new version of the budget
584 The system shall provide functionality to exclude proposals that are "turned off" when BU-10
copying one version of a budget to another
585 The system shall provide functionality for agency and control agency (DOB) users to BU-10
independently turn the same set of proposals "on" and "off" to create multiple different
versions of the budget
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 35 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
586 The system shall provide functionality to automatically display the status of the proposal BU-10
(e.g., turned on, turned off) and allow it to be viewed by users
587 The system shall provide functionality to save proposals that are not included in the final BU-10
enacted budget and make them available in the subsequent year's budget preparation
process
588 The system shall provide functionality for users to save proposals that are not included in BU-10
the final budget
589 The system shall provide functionality for users to delete proposals that are not included in BU-10
the final budget
590 The system shall provide functionality for users to reopen deactivated proposals BU-10
591 The system shall provide functionality for users to create and save at least 25 versions of BU-10
each agency's budget (e.g., multiple agency submission versions, multiple DOB versions,
multiple executive recommendation versions, multiple legislative versions, multiple
appropriation versions and multiple agency operating budget versions)
592 The system shall provide functionality to simultaneously display at least 5 different versions BU-10
of an agency's budget on one screen
593 The system shall provide functionality to apply access controls to each version of the BU-10
budget, including, but not limited to:
- Marking as complete
- Freezing
- Unfreezing
- Copying
- Editing
594 The system shall provide functionality to automatically save the original version of a budget BU-10
when a new version of the budget is created
595 The system shall provide functionality to compare different versions of the budget and BU-10
calculate the difference between two versions
596 The system shall provide functionality to identify the status of each version of the budget BU-10
(e.g., open, closed, submitted, under review, approved)
597 The system shall provide functionality for users to define formulas, steps, and rules so that BU-10
the system can perform automatic data calculations
598 The system shall provide functionality for users in different agencies to define different BU-10
formulas, steps, and rules to perform data calculations
599 The system shall provide functionality for users to define steps and rules to calculate BU-10
projections including, but not limited to:
- Fixed rate adjustments
- Absolute dollar adjustments
- Prior year expenditures
- Grant match rates
600 The system shall provide functionality for users to make calculations based on various BU-10
items, including, but not limited to:
- Actual balances
- Budgeted balances within a budget version
- Non-financial/statistical information that is captured
601 The system shall provide functionality for users to define and apply business rules to budget BU-10
documents or forms (e.g., amount in column x cannot exceed $100)
602 The system shall provide functionality for users to calculate and post budget projections BU-10
using robust modeling tools including, but not limited to:
- Multivariate analysis
- What-if simulation
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 36 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
603 The system shall provide functionality for users in different agencies to define different BU-10
criteria to allocate budget overhead costs
604 The system shall provide functionality for users to notify another user via email or workflow if BU-10
a resubmission of the budget request is necessary
605 The system shall provide functionality for users to reopen submitted budget request BU-10
documents for revision purposes
606 The system shall provide functionality for users to update or revise and resubmit budget BU-10
request documents
607 The system shall provide functionality for users to establish create, edit and view access BU-10
rights to a variety of budget data and related documentation including, but not limited to:
- Proposals
- Budget requests
- Versions of the budgets
- Establishment of appropriations
- Establishment of reappropriations
- Close out/save proposals
- Release mechanism
- Individual releases
- Budget transfer requests
- Spending plans
- Spending limits
- Budget reports
608 The system shall provide functionality for users to undo and/or redo actions when BU-10
creating/editing budget data
609 The system shall provide functionality for users to open and close budget documents BU-10
610 The system shall provide functionality to automatically notify users via email or a workflow BU-10
when a version of the budget is available to be edited
611 The system shall provide functionality for users to close and lock budget documents BU-10
612 The system shall provide functionality to automatically notify users via email or workflow BU-10
when a budget document is locked and can no longer be edited
613 The system shall provide functionality to display an error message and restrict edits if a user BU-10
tries to edit a locked version of the budget
614 The system shall provide functionality for users to open, close, and lock a variety of budget BU-10
documents and related functionality including, but not limited to:
- Proposals
- Budget requests
- Versions of the budgets
- Establishment of appropriations
- Establishment of reappropriations
- Close out/save proposals
- Release mechanism
- Individual releases
- Budget transfer requests
- Spending plans
- Spending limits
- Budget reports
615 The system shall provide functionality for a restricted workspace for users to conduct BU-10
informal budget analysis. This informal analysis shall not be included in any formal budget
development documents
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 37 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
616 The system shall provide functionality for users to create a calendar for the budget process BU-10
and link tasks to the calendar
617 The system shall provide functionality for users in different agencies to create different BU-10
budget calendars and link different tasks to the calendar
618 The system shall provide functionality to automatically notify users via email or workflow BU-10
when a budget calendar is established
619 The system shall provide functionality for users to edit the budget calendar throughout the BU-10
year
620 The system shall provide functionality to automatically notify users via email or workflow BU-10
when a budget calendar is modified
621 The system shall provide functionality for users to apply calendar functionality to a variety of BU-10
tasks including, but not limited to:
- Proposals
- Budget requests
- Versions of the budgets
- Establishment of appropriations
- Establishment of reappropriations
- Close out/save proposals
- Release mechanism
- Individual releases
- Budget transfer requests
- Spending plans
- Spending limits
- Budget reports
622 The system shall provide functionality for users to establish a budget cycle and events BU-10
within a budget cycle
623 The system shall provide functionality for users to make changes to a budget cycle and BU-10
events including, at a minimum, names, length, adding or deleting events, and activating or
inactivating events.
624 The system shall provide functionality for users to enter and track financial plan estimates BU-10
for a minimum of 6 state fiscal years
625 The system shall provide functionality for users to add fiscal years for each event within a BU-10
budget cycle
626 The system shall provide functionality for users to reorganize the hierarchy of the previous BU-30
year’s actual and budgeted financial information
627 The system shall provide functionality for users to download detailed financial data to BU-30
external systems
628 The system shall provide functionality for users to enter the fiscal year of the initial BU-40
appropriation and track that designation when the appropriation is extended for additional
fiscal years
629 The system shall provide functionality for users to set the effective date for each BU-40
appropriation (i.e. start and end dates)
630 The system shall provide functionality to establish each appropriation as a separate item BU-40
631 The system shall provide functionality for users to indicate that a version of the budget was BU-40
enacted
632 The system shall provide functionality for users to indicate which appropriations in the BU-40
enacted budget are finalized and which are not finalized (e.g., subject to line-item veto)
633 The system shall provide functionality to automatically transfer individual, finalized BU-40
appropriations from a budget preparation module into a budget control module
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 38 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
634 The system shall provide functionality for users to manually transfer individual BU-40
appropriations from a budget preparation module into a budget control module
635 The system shall provide functionality for users to identify calendar functionality to all non- BU-40
finalized appropriations. If, after a period of time (e.g., 10 day limit for appropriations subject
to line item veto) no action has been taken, the appropriation will automatically be
transferred from the budget preparation module to the budget control module
636 The system shall provide functionality to make appropriations remain available for two or BU-40
more fiscal years
637 The system shall provide functionality for users to create and identify interim appropriations BU-40
(i.e. emergency appropriations)
638 The system shall provide functionality for users to reallocate spending entered against an BU-40
interim appropriation and apply it to a final enacted appropriation
639 The system shall provide functionality to extend the effective period of an appropriation BU-50
beyond one fiscal year. The months beyond the original fiscal year, during which the
appropriation is still effective, are henceforth referred to as the carryover period. Users are
allowed to continue to post the previous year's expenditures and current year's
disbursements during the carryover period and enter them against the appropriation
640 The system shall provide functionality for users to define different carryover periods for each BU-50
appropriation
641 The system shall provide functionality to keep appropriations that remain open during the BU-50
carryover period to be saved as separate items and not be combined with new
appropriations
642 The system shall provide functionality to automatically lapse available budget at the end of BU-50
the carryover period
643 The system shall provide functionality to automatically close an appropriation at the end of a BU-50
carryover period and prevent any additional transactions from being posted against the
appropriation
644 The system shall provide functionality to display the final lapsed balance after an BU-50
appropriation expires
645 The system shall provide functionality for users to reopen expired appropriations BU-50
646 The system shall provide functionality for users to identify appropriations that shall be BU-50
extended for an additional fiscal year
647 The system shall provide functionality for users to edit the expiration date associated with BU-50
each appropriation in order to extend it for an additional fiscal year
648 The system shall provide functionality for users to simultaneously edit the expiration dates BU-50
on a number of appropriations
649 The system shall provide functionality to save appropriations that are extended for an BU-50
additional fiscal year as a separate item and not be combined with new appropriations
650 The system shall provide functionality to use the same hierarchical coding structure for BU-50
appropriations that are extended for an additional fiscal year as was used in the previous
fiscal year
651 The system shall provide functionality to reorganize and use a new hierarchical coding BU-50
structure for appropriations that are extended for an additional fiscal year
652 The system shall provide functionality for users to enter current year encumbrances, BU-50
expenditures and disbursements against appropriations that have been extended for
additional fiscal years
653 The system shall provide functionality to display all budget and transaction history over the BU-50
course of all fiscal years when an appropriation is extended for additional fiscal years
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 39 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
654 The system shall provide functionality for users to access all budget and transaction history BU-50
over the course of all fiscal years when an appropriation is extended for additional fiscal
years
655 The system shall provide functionality for users to approve individual portions of an BU-50
appropriation and make that amount available to spend, henceforth referred to as an
allotment
656 The system shall provide functionality to control spending against an appropriation through a BU-50
structured allotment of available funds, referred to henceforth as a release mechanism
657 The system shall provide functionality for users to define the number of structured BU-50
allotments used to allocate each appropriation
658 The system shall provide functionality to populate the amount included in each allotment BU-50
based on a percentage of the appropriation's total value
659 The system shall provide functionality for users to link the release of individual appropriation BU-50
allotments to specific calendar dates, henceforth referred to as an allotment schedule
660 The system shall provide functionality for users to create multiple types of release BU-50
mechanisms, including allowing users to establish mechanisms with different numbers of
structured allotments throughout the year (e.g., one appropriation is allocated in three
allotments while another is allocated in four allotments)
661 The system shall provide functionality for users to create multiple types of release BU-50
mechanisms, including allowing users to establish mechanisms that use different
percentages to populate the amounts included in each allotment (e.g., an appropriation with
three allotments is divided up 33%-33%-33% while another is divided up 50%-25%-25%)
662 The system shall provide functionality for users to save multiple types or templates of BU-50
release mechanisms
663 The system shall provide functionality for users to simultaneously use multiple types of BU-50
release mechanisms in one agency
664 The system shall provide functionality for users to simultaneously use multiple types of BU-50
release mechanisms in different agencies
665 The system shall provide functionality for users to link specific appropriations with a specific BU-50
type or template of release mechanism
666 The system shall provide functionality to automatically confirm that the sum of the individual BU-50
allotments in the release mechanism equals the total value of the appropriation
667 The system shall provide functionality for users to define the percentages used to populate BU-50
the allotments in the release mechanism
668 The system shall provide functionality for users in different agencies to use different BU-50
percentages to populate the allotments in the release mechanism
669 The system shall provide functionality for users to prompt the system to duplicate the BU-50
percentages used in the previous year's release mechanism and apply those percentages to
the current year's release mechanism
670 The system shall provide functionality for users to manually edit the amount in each BU-50
individual allotment
671 The system shall provide functionality for users to approve individual allotments at any time BU-50
throughout the year
672 The system shall provide functionality to automatically add, upon approval, the amount of BU-50
the allotment to the available spending balance (i.e. uncommitted balance) for the individual
appropriation
673 The system shall provide functionality to automatically notify users via email or workflow BU-50
when an allotment has been approved and released
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 40 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
674 The system shall provide functionality to automatically notify users via email or workflow BU-50
when the amount of the appropriation in each individual allotment is altered
675 The system shall provide functionality for users to turn off the release mechanism when it is BU-50
not necessary
676 The system shall provide functionality for users to adjust the budget within an individual BU-50
appropriation in a single agency
677 The system shall provide functionality for users to adjust the budget within an individual BU-50
appropriation at any level in the chart of accounts
678 The system shall provide functionality for users to transfer appropriation authority from one BU-50
appropriation to another within the same agency
679 The system shall provide functionality for users to transfer appropriation authority from one BU-50
appropriation to another within the same agency at any level in the chart of accounts
680 The system shall provide functionality for users to transfer appropriation authority from one BU-50
appropriation to another appropriation in a different agency
681 The system shall provide functionality for users to transfer appropriation authority from one BU-50
appropriation to another in a different agency at any level in the chart of accounts
682 The system shall provide functionality for users to establish a new appropriation when BU-50
appropriation authority is transferred
683 The system shall provide functionality for users to combine a transferred appropriation with BU-50
an existing appropriation when appropriation authority is transferred
684 The system shall provide functionality for users to establish a threshold, based on the total BU-50
value of the appropriation, for the amount of the appropriation that can be transferred from
one appropriation to another
685 The system shall provide functionality for users to define approval criteria when BU-50
appropriation authority is transferred between agencies
686 The system shall provide functionality to enter the key information when appropriation BU-50
authority is transferred including, but not limited to:
- Appropriation amount
- Agency(s)/program(s) involved
- Comments/narrative description
687 The system shall provide functionality to automatically complete an "availability check" to BU-50
ensure that appropriation, allotments, and spending limits are available at the necessary
levels in the chart of accounts before allowing a financial transaction to occur, and alert the
user if the transaction fails any of the availability checks
688 The system shall provide functionality to automatically alert users when a transaction cannot BU-50
be processed because the liability and/or transaction dates do not correspond with an
appropriation's effective date (the period between when an appropriation is available and
when it expires)
689 The system shall provide functionality for users to set "hard" spending limits that create a BU-60
threshold of allowable spending. If a financial transaction or resulting balance exceeds the
amount of the threshold, the system does not allow the transaction to be processed
690 The system shall provide functionality for users to set "warnings" for allowable spending. If BU-60
a financial transaction or resulting balance exceeds the amount of a threshold, the system
alerts the user that the transaction exceeds the threshold, but allows the transaction to be
processed
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 41 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
691 The system shall provide functionality for users to set "tolerance" spending limits. These BU-60
limits set a threshold and a lenience of allowable spending (e.g., $500 ±10%). If a financial
transaction or resulting balance exceeds the amount of the threshold, but is less than the
amount of the lenience (e.g., $525), the system alerts the user, but allows the transaction to
be processed. If the transaction or resulting balance exceeds the threshold and the
lenience (e.g.,$575), the system does not allow the transaction to be processed
692 The system shall provide functionality for users to establish spending limits (e.g., hard BU-60
control, tolerance, warning) to control the amount of expenditures (e.g., pre-encumbrances,
encumbrances, and expenditures) that can be spent
693 The system shall provide functionality for users to establish spending limits (e.g., hard BU-60
control, tolerance, warning) to control the amount of disbursements that can be spent
694 The system shall provide functionality for users to simultaneously establish both expenditure- BU-60
based and disbursement-based spending limits (e.g., hard control, tolerance, warning)
695 The system shall provide functionality for users in different agencies to create different types BU-60
of spending limits (e.g., hard, tolerance, warning) at any level in the chart of accounts
696 The system shall provide functionality for users to establish periodic (e.g., annual, quarterly, BU-60
monthly) spending limits (e.g., hard control, tolerance, warning)
697 The system shall provide functionality for users to set access controls so specified users BU-60
can override spending limits (e.g., hard control, tolerance, warning)
698 The system shall provide functionality for users to edit spending limits (e.g., hard control, BU-60
tolerance, warning) throughout the fiscal year
699 The system shall provide functionality to automatically notify users via email or workflow BU-60
when the spending limits (e.g., hard control, tolerance, warning) have been altered
700 The system shall provide functionality for users to load and save expenditure-based BU-60
spending projections at any level in the chart of accounts
701 The system shall provide functionality for users to load and save expenditure-based BU-60
spending projections for different time periods including, but not limited to:
- Annually
- Quarterly
- Monthly
702 The system shall provide functionality for users to load and save multiple versions of the BU-60
expenditure-based spending projections
703 The system shall provide functionality for users in different agencies to create and save BU-60
expenditure-based spending projections at different levels in the chart of accounts
704 The system shall provide functionality for users to load and save disbursement-based BU-60
spending projections at any level in the chart of accounts
705 The system shall provide functionality for users to load and save disbursement-based BU-60
spending projections for different time periods including, but not limited to:
- Annually
- Quarterly
- Monthly
706 The system shall provide functionality for users to load and save multiple versions of the BU-60
disbursement-based spending projections
707 The system shall provide functionality for users in different agencies to create and save BU-60
disbursement-based spending projections at different levels in the chart of accounts
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 42 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
708 The system shall provide functionality for users to simultaneously load and save both BU-60
expenditure-based and disbursement-based spending projections
709 The system shall provide functionality for users to create disbursement-based spending BU-60
projections based on the expenditure-based spending projections using customized
business rules
710 The system shall provide functionality to display the total value of each appropriation BU-80
711 The system shall provide functionality to display the amount of appropriation that is BU-80
available, based on summation of authorized allotments, henceforth referred to as the
available funds balance
712 The system shall provide functionality to display the life-to-date, year-to-date and period-to- BU-80
date available funds balance
713 The system shall provide functionality to display the remaining spending authority for each BU-80
appropriation, henceforth referred to as the uncommitted funds balance. This balance is the
available funds balance less expenditures, encumbrances and pre-encumbrances
714 The system shall provide functionality to display the amount of outstanding year-to-date BU-80
encumbrances recorded at each level in the data classification structure
715 The system shall provide functionality to display the amount of year-to-date expenditures BU-80
recorded at each level in the chart of accounts
716 The system shall provide functionality to display the amount of year-to-date disbursements BU-80
recorded at each level in the chart of accounts
717 The system shall display the amount of outstanding life-to-date encumbrances recorded at BU-80
each level in the chart of accounts when appropriations span multiple fiscal years
718 The system shall provide functionality to display the amount of life-to-date expenditures BU-80
recorded at each level in the chart of accounts when appropriations span multiple fiscal
years
719 The system shall provide functionality to display the amount of life-to-date disbursements BU-80
recorded at each level in the chart of accounts when appropriations span multiple fiscal
years
720 The system shall provide functionality for users to "drill down" to the lowest level to identify BU-80
the transactions that comprise the encumbrance balance
721 The system shall provide functionality for users to "drill down" to the lowest level to identify BU-80
all the transactions that comprise the expenditure balance
722 The system shall provide functionality for users to "drill down" to the lowest level to identify BU-80
all the transactions that comprise the disbursement balance
723 The system shall provide functionality for users to set a calendar function that automatically BU-80
notifies the user, via email or workflow at a pre-determined time before the end of the fiscal
year, of the amount of uncommitted funds available
724 The system shall provide functionality to automatically notify users when the uncommitted BU-80
funds balance is less than a specified percent of the spending limit
725 The system shall provide functionality to automatically notify users when the expenditure BU-80
balance is more than a specified percent of the spending limit
726 The system shall provide functionality to automatically notify users when the disbursement BU-80
balance is more than a specified percent of the spending limit
727 The system shall provide functionality for users to create reports using budgeted amounts BU-80
as the basis for reporting
728 The system shall provide functionality for users to create reports using spending projections, BU-80
expenditure-based and disbursement-based, as the basis for reporting
729 The system shall provide functionality for users to create reports using performance BU-80
measures and performance data as the basis for reporting
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 43 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
730 The system shall provide functionality for users to archive financial data (i.e. actual, BU-80
statistical, budget, etc.), without irrevocably condensing or summarizing any level of detail
for a specified period of time
731 The system shall provide functionality for users to condense or summarize budget data BU-80
732 The system shall provide functionality for users to condense or summarize budget data BU-80
including, but not limited to:
- Proposals
- Version of the budget
- Close out/retention of proposals
- Release mechanisms
- Budget transfers
- Spending plans
733 The system shall provide functionality for users to selectively condense or summarize BU-80
financial data (i.e. actual, statistical, budget, etc.)
734 The system shall provide functionality for users to access archived financial data (i.e. actual, BU-80
statistical, budget, etc.)
735 The system shall provide functionality for users to save electronic copies of all budget BU-80
documents and attachments for audit purposes
736 The system shall provide functionality to track adjustments to budget data including, but not BU-80
limited to:
- Time stamp indicating when the change was made
- User ID of the person who made the change
- Field altered
- Value in the field before it was altered
- Value in the field after it was altered
737 The system shall provide functionality for users to configure additional fields of at least 500 BU-80
characters to capture comments/narrative for each of the following, including but not limited
to:
- Proposals
- Budget requests
- Versions of the budgets
- Establishment of appropriations
- Establishment of reappropriations
- Close out/save proposals
- Release mechanism
- Individual releases
- Budget transfer requests
- Spending plans
- Spending limits
- Budget reports
738 The system shall provide functionality for users to define the budgetary control period at a BU-80
global level including, but not limited to:
- Annual
- Quarterly
- Monthly
739 The system shall provide functionality for users to globally close and open periods BU-80
740 The system shall provide functionality for users to permanently close the period BU-80
741 The system shall provide functionality to support a statewide chart of accounts to replace COA
the charts of accounts currently in place in existing New York State agency financial
systems
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 44 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
742 The system shall provide functionality to accommodate a statewide chart of accounts that is COA
in alignment between NYFMS and the Office of the State Comptroller's new Central
Accounting System (new CAS) (i.e. the NYFMS COA "rolls up" to the new CAS COA such
that there is one statewide chart of accounts, with NYFMS carrying a greater level of detail
than the new CAS)
743 The system shall provide functionality to accommodate agency-level needs in the chart of COA
accounts by providing several data elements for use at the agency level, including
accommodating the ability for agencies to assign and define data elements. These data
elements will "roll-up" to the statewide chart of accounts
744 The system shall provide functionality to accommodate statewide definitions for data COA
elements in the chart of accounts (i.e., Program should have a single, statewide definition)
745 The system shall provide functionality to implement and monitor statewide governance rules COA
related to the chart of accounts
746 The system shall provide functionality to accommodate a hierarchical chart of accounts, COA
such that each level is a summary of the level directly beneath it
747 The system shall provide functionality to accommodate a scalable chart of accounts, COA
allowing for future expansion
748 The system shall provide the following functionality for chart of accounts data elements, at a COA
minimum:
- Required/non-required
- Add data elements in active and non-active state
- Delete data elements
- Activate/non-activate/re-activate based on effective dating
- Re-label
- Re-name
- Change length
- Change display length
749 The system shall provide functionality to accommodate making changes to the chart of COA
accounts
750 The system shall provide functionality to accommodate tracking changes made to the chart COA
of accounts
751 The system shall provide functionality for sorting of the chart of accounts COA
752 The system shall provide functionality to accommodate a chart of accounts that supports COA
Federal laws and regulations (e.g. Federal Drawdown and Reimbursement regulations)
753 The system shall provide functionality to accommodate changes to the chart of accounts COA
due to changes in State Law
754 The system shall provide functionality to accommodate changes to the chart of accounts COA
due to changes in Federal Law
755 The system shall provide functionality to accommodate changes to the chart of accounts COA
due to regulatory changes
756 The system shall provide functionality to accommodate the mapping of historical chart of COA
accounts data
757 The system shall provide functionality to accommodate the mapping of active chart of COA
accounts data
758 The system shall provide the ability for users to group chart of accounts data elements COA
through user-defined categories to support agency-specific and statewide requirements
759 The system shall provide functionality to accommodate the grouping of data elements in the COA
chart of accounts into multiple reporting hierarchies
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 45 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
760 The system shall provide functionality for the users to perform inquiries of the chart of COA
accounts on screen that is specific to their own agency
761 The system shall provide functionality to access, track, and report on any level of detail COA
within the chart of accounts, including, but not limited to, the following data elements:
- Organization
- Fund
- Program
- Project
- Object
762 The system shall provide functionality to accommodate statewide numbering of chart of COA
accounts data elements
763 The system shall provide functionality to accommodate dynamic organization structures at COA
the State agency level, including tracking organization changes for a specified period of time
764 The system shall provide functionality to accommodate changes in organization structures COA
without recasting historical financial information, while providing a clear cross-walk from
history to active data
765 The system shall provide functionality to recast historical financial data relating to COA
organization structure changes
766 The system shall provide functionality to copy accounts from one organization unit to COA
another to facilitate chart of accounts maintenance
767 The system shall provide functionality to accommodate at least twenty levels of structure for COA
each chart of accounts data element
768 The system shall provide functionality for filtering of the chart of accounts COA
769 The system shall provide functionality to accommodate a chart of accounts that satisfies COA
GAAP, GASB, statewide and agency reporting requirements and Governmental Accounting,
Auditing, and Financial Reporting (GAAFR) or other external requirements, at both the
agency and statewide levels
770 The system shall provide functionality to accommodate a chart of accounts that satisfies the COA
State's appropriation, agency, grant, contract, activity and capital project budgeting
requirements
771 The system shall provide functionality to accommodate filtering the chart of accounts to COA
display chart of accounts data elements appropriate by agency
772 The system shall provide functionality to accommodate a chart of accounts that supports COA
New York State laws and regulations (e.g. State Finance law)
773 The system shall provide functionality to give system users an option to indicate whether to COA
recast historical data after an organization change
774 The system shall provide functionality to accommodate groupings of chart of accounts data COA
elements based on pre-defined characteristics inherent to the chart of accounts data
elements, such that these groupings are performed automatically, without user intervention
(i.e. funds belong to a certain fund-group based on the fund number)
775 The system shall provide functionality to allow comparable levels in any element in the chart COA
of accounts structure to have different names across agencies
776 The system shall provide functionality to accommodate entering a short description for each COA
chart of accounts data element
777 The system shall provide functionality to accommodate entering a long description (at least COA
30 characters) for each chart of accounts data element
778 The system shall provide functionality to accommodate notifying users when a requested COA
update has been made to the chart of accounts
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 46 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
779 The system shall provide functionality to accommodate limiting visibility of selected chart of COA
accounts data elements by a user's role or responsibility throughout the application
780 The system shall provide functionality to accommodate permitting segments of the chart of COA
accounts to be grouped on a user-defined basis into multiple reporting hierarchies
781 The system shall provide functionality to maintain a history of statistical balances across the COA
chart of accounts
782 The system shall provide functionality to permit cross-validation rules across all elements of COA
the chart of accounts
783 The system shall provide functionality to automatically reconcile and adjust reports to reflect COA
modifications to the COA structure
784 The system shall provide functionality to automatically reconcile and adjust hierarchical or COA
roll-up structures when changes are made to COA elements at different levels
785 The system shall provide functionality to automatically reconcile bank activity entered in the GL-10
system with bank transactions received from the State’s bank accounts
786 The system shall provide functionality to accommodate multiple banks and bank accounts in GL-10
the automated bank reconciliation processes
787 The system shall provide functionality for a manual and automatic reconciliation process of GL-10
bank activity that can be used at the user’s discretion
788 The system shall provide functionality for users to make corrections during the reconciliation GL-10
process
789 The system shall provide functionality to automatically receive and store electronic deposit GL-10
information in various formats
790 The system shall provide functionality for users to manually enter deposit transactions GL-10
originating from, but not limited to:
- Wire transfers
- ACH deposits
- Over-the-counter deposits by agencies
791 The system shall provide functionality for users to manually input, adjust, or reverse the GL-10
applicable transactions including, but not limited to:
- Bank deposits
- Bank debit memorandums
- Credit adjustments
- Debit adjustments
- Interest earned
792 The system shall provide functionality to automatically adjust cash held in an agency's fund GL-10
ledger and the associated revenue for each returned check
793 The system shall provide functionality to automatically update the general ledger with GL-10
contract transactions/information
794 The system shall provide functionality for users to manually and/or automatically enter GL-10
encumbrances and pre-encumbrances
795 The system shall provide functionality to alert agencies that funds encumbered have not GL-10
been disbursed by a pre-determined date
796 The system shall provide functionality to support fund accounting and accounting standards GL-10
that meet GAAP and GASB standards
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 47 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
797 The system shall provide functionality to define accounting rules such that both full accrual GL-10
and modified accrual postings are captured for Governmental Funds (in support of GAAP
and GASB fund and entity financial reporting), as well as a cash basis (for budgetary
reporting) for the following items including, but not limited to:
- Fixed assets
- Capital leases
- Loans receivable and payable
- Investments
- Long term debt
- Advances
- AR and AP
- Compensated absences out of human resources/accounting
798 The system shall provide functionality to support an unlimited number of subsidiary ledgers GL-10
including statistical and financial ledgers
799 The system shall provide functionality that supports a centralized ledger for each fund GL-10
800 The system shall provide functionality to simultaneously support the following bases of GL-10
accounting for appropriate fund types including, but not limited to:
- Cash basis
- Accrual basis
- Modified accrual basis
801 The system shall provide functionality to support multi-fund accounting with the capacity to GL-10
segregate funds by type and by regulatory requirements
802 The system shall provide functionality to ensure that each fund is always in balance by GL-10
automatically treating funds as a self-balancing sets of accounts
803 The system shall provide functionality to automatically create due to/due from entries to GL-10
balance transaction entries by fund based on pre-defined rules
804 The system shall provide functionality to create a journal entry GL-10
805 The system shall provide functionality for the user to set-up standard journal entry templates GL-10
that can be recycled to enable the creation of like kind entries
806 The system shall provide functionality to generate a unique journal ID for each journal entry GL-10
transaction and transaction line entered
807 The system shall provide functionality to define multiple types of journal entries to handle GL-10
multiple transaction types including, but not limited to:
- Manual
- Recurring
- Interfaced
808 The system shall provide functionality to reverse manual, recurring, and interfaced journal GL-10
entries
809 The system shall provide functionality to create unique journal entry types to be identified GL-10
with each journal entry created within the system. Unique journal entry types will be used as
a means to easily identify the purpose of the entry, the originating source, and its contents
810 The system shall provide functionality to store valid journal types in a repository GL-10
811 The system shall provide functionality for a user to edit the accounting distribution from the GL-10
default distribution for interfaced journal entries
812 The system shall provide functionality to post transactions from integrated functional GL-10
processes to the general ledger interactively (near-real time)
813 The system shall provide functionality for users to enter audit adjustments GL-10
814 The system shall provide functionality for users to enter adjustments that automatically GL-10
generate subsequent general ledger postings, such as a reversal of a journal entry in a
future period
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 48 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
815 The system shall provide functionality to generate recurring journal entries on a schedule GL-10
(e.g., monthly, quarterly, annually) so users may edit or approve journal entries prior to
posting
816 The system shall provide functionality to process standard/recurring journal entries of fixed GL-10
and variable amounts that are posted at scheduled intervals
817 The system shall provide functionality for users to modify a recurring journal entry at the GL-10
header and line levels
818 The system shall provide functionality to reverse journal entries with user control over the GL-10
period in which the reversal occurs
819 The system shall provide functionality to establish accruals (e.g., payroll) on a monthly basis GL-10
820 The system shall provide functionality to automatically reverse accrual transactions in either GL-10
the period immediately following the fiscal month to which the transactions are posted or the
current period
821 The system shall provide functionality for users to add comments to pending transactions or GL-10
documents
822 The system shall provide functionality to automate reconciliation controls between general GL-10
ledger and sub-ledger balances
823 The system shall provide functionality to post to multiple state fiscal years GL-10
824 The system shall provide functionality to generate a set of comprehensive annual financial GL-10
reports compliant with GAAP and GASB requirements
825 The system shall provide functionality to identify goods or services received in the prior year GL-10
that were paid for in the current year
826 The system shall provide functionality for the user to create and use separate concentration GL-10
funds to document cash receipts, cash holdings, and cash disbursements within a single
checking/banking account
827 The system shall provide functionality for the user to retrieve data in order to reverse or GL-10
make adjustments, based on search criteria (e.g., batch number, batch and group identifier,
receipt, debit memo identifier)
828 The system shall provide functionality to assign approval routes to journal entry transactions GL-10
829 The system shall provide functionality for users to review saved journal entries prior to GL-10
posting
830 The system shall provide functionality for users to account for inter-fund transfers of cash GL-10
properly in accordance with GAAP and GASB standards
831 The system shall provide functionality for sending or receiving users to enter transactions on GL-10
behalf of other agency users
832 The system shall provide functionality to create approval routes for inter-fund or inter- GL-10
agency
833 The system shall provide functionality for users to enter transfers between funds (operating GL-10
transfer, expenditure to expenditure, and revenue to revenue), both within an agency (intra-
agency transfers) and between agencies (inter-agency transfers)
834 The system shall provide functionality for users to suspend intra-agency transfers that allow GL-10
the receiving agency to review and approve the transaction/document/business event prior
to posting
835 The system shall provide functionality to automatically enter due to and offset due from GL-10
entries in both funds (using appropriate compatible budget category and general ledger
codes) when an intra-fund journal transfer is processed (including expenditure corrections)
836 The system shall provide functionality to automatically balance inter-fund and inter-agency GL-10
transactions
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 49 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
837 The system shall provide functionality to track due to and due from balances by both GL-10
financial fund and agency and the participating fund and agency
838 The system shall provide functionality to flag inter-agency transactions awaiting completion GL-10
839 The system shall provide functionality for users to manually flag disputed inter-agency GL-10
transactions
840 The system shall provide functionality for users to provide a description of inter-agency GL-10
transaction disputes
841 The system shall provide functionality for users to reference an encumbrance on an inter- GL-10
agency transaction
842 The system shall provide functionality to accommodate the partial completion of an inter- GL-10
agency transaction (e.g., post/save an unbalanced journal entry transaction)
843 The system shall provide functionality to prevent the receiving agency from changing the GL-10
sending agency's coding and dollar amount on an inter-agency or inter-fund transaction
844 The system shall provide a template with multiple lines to enter journal entry data on inter- GL-10
agency transactions per agency for spending and receiving agencies
845 The system shall provide functionality for users to manually and the system to automatically GL-10
eliminate inter-fund or inter-agency transactions
846 The system shall provide functionality for users to create current journal entries during the GL-10
period closing cycle until the period is closed
847 The system shall provide functionality for users to run multiple, preliminary, period-end GL-10
(including year-end) closing reports, and review the results
848 The system shall provide functionality to prevent transactions/documents from posting into a GL-10
closed period (e.g month or year)
849 The system shall provide functionality to post transactions into a past or future period (e.g GL-10
month or year), as long as the period is open
850 The system shall provide functionality to process transactions/documents according to a GL-10
specified date, not the actual current date or computer date
851 The system shall provide functionality to permit prior year adjustments to be entered in the GL-10
current fiscal year and reported as a prior year adjustment for financial reporting and
entered as a current year adjustment for budgetary purposes
852 The system shall provide functionality for users to access the current period information GL-10
during the previous period's close (e.g., no restrictions on January while December is being
closed)
853 The system shall provide functionality to run multiple periods and fiscal years concurrently, GL-10
and allow users to enter transactions, based on effective dates, in any periods that have not
been closed
854 The system shall provide functionality to automate fiscal year-end close processes (e.g., GL-10
close nominal accounts to fund balance or fund equity, roll real accounts forward)
855 The system shall provide functionality to "soft close" a fiscal year end to prevent State GL-10
agencies from posting in the prior fiscal year after a designated date
856 The system shall provide functionality to re-open a prior fiscal year after a "soft close" to GL-10
adjust entries made by State agencies before the fiscal year hard close. (i.e. agencies
typically make adjusting entries at a high level and then need to break those entries down to
the most detailed level of the chart of accounts structure before a hard close is performed
for the fiscal year)
857 The system shall provide functionality to maintain open and closed periods for other GL-10
modules (e.g., AR, AP, fixed assets, project, grants) independent from the general ledger
module
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 50 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
858 The system shall provide functionality to accommodate special periods (outside the normal GL-10
fiscal periods) for year-end processing and other audit adjustments
859 The system shall provide functionality to allow flexible controls for posting transactions GL-10
during the period closing cycle (e.g., date, functional area, and users)
860 The system shall provide functionality to impose posting controls over each integrated GL-10
functional area, prohibiting the posting of additional entries during a "soft" close
861 The system shall provide functionality to allow multiple preliminary year-end closings to GL-10
occur while maintaining the ability to post data to current and prior periods
862 The system shall provide functionality to perform an automated year-end rollover of selected GL-10
financial information into the new fiscal year
863 The system shall provide functionality to prevent interferences with the processing of current GL-10
year transactions during the year-end closing process
864 The system shall provide functionality to report revenue and expenditure activity on a cash GL-10
basis (budgetary compliance and reporting) and accrual basis within the same fund, and
shall provide reconciling transaction reports as needed, including the transactions that may
end up in different fiscal years based on the method of reporting
865 The system shall provide functionality for users to trace summarized transactions in the GL-10
general ledger back to detail source documents in other system modules or subsystems. If
the information must be retrieved from these modules or subsystems, it should be
transparent to users
866 The system shall provide functionality for users to define standard general ledger inquiries GL-10
with parameter options
867 The system shall provide functionality for users to perform drill-downs within the system GL-10
from the general ledger summary balance to the original source document(s)
868 The system shall provide functionality to include statistical data as well as financial data GL-10
(e.g., gallons of fuel, square footage) on standard inquiry reports
869 The system shall provide functionality to generate monthly bank statements based upon GL-10
individual agency account activity
870 The system shall provide functionality to edit or validate transactions/documents against GL-10
available cash balance
871 The system shall provide functionality to identify lapse dates by appropriation GL-10
872 The system shall provide functionality for users to identify specific transactions that are GL-10
exempt from appropriation budget and/or cash edits/validation
873 The system shall provide functionality for users to suspend or hold transactions GL-10
874 The system shall provide functionality to validate the account number field in general entry GL-10
transactions prior to posting
875 The system shall provide functionality for users to edit transactions in order to ensure that GL-10
each entry to a fund is complete based on specified fields
876 The system shall provide functionality to ensure that journal entries are in balance prior to GL-10
posting
877 The system shall provide functionality for users to define and maintain standard rules that GL-10
control general ledger account postings for all accounting events across integrated
functional areas (e.g., AP and Purchasing)
878 The system shall provide functionality to develop routines, reports, and inquiries that GL-10
compare subsidiary ledger balances (e.g., any integrated functional area) with the
respective general ledger balance for integrity controls
879 The system shall provide functionality to prevent the creation or processing of all duplicate GL-10
transactions with system controls
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 51 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
880 The system shall provide the ability to produce a trial balance by fund to obtain a running GL-10
total of debits and credits
881 The system shall provide functionality for subsidiary ledgers for balance sheet accounts. GL-10
The subsidiary ledgers must generate reports of open transactions that accumulate to the
balance sheet account totals
882 The system shall provide functionality to support a centralized ledger for each fund GL-10
883 The system shall provide functionality to support multiple ledgers that are updated GL-10
simultaneously
884 The system shall provide functionality to support Generally Accepted Accounting Principles GL-10
(GAAP) and standards of the Governmental Accounting Standards Board (GASB)
885 The system shall provide functionality to access historical financial information (i.e., GL-10
information for grants and appropriations covering multiple years must be accessible)
886 The system shall provide functionality to set a cash and/or modified accrual indicator GL-10
depending on the transaction type
887 The system shall provide functionality to enter and store descriptions for journal entries GL-10
888 The system shall provide functionality to automatically generate information to identify and GL-10
approve the deposits
889 The system shall provide functionality to create journal entries automatically as a result of GL-20
cost allocations
890 The system shall provide functionality to summarize cost allocations or detail cost GL-20
allocations using the original expenditure object
891 The system shall provide functionality to record allocations down to any element of the chart GL-20
of accounts
892 The system shall allow for users to be able to define a default allocation method for a project GL-20
or grant that will be applied to all transactions that are charged to that project or grant
893 The system shall provide functionality to perform cost allocations based on the organization GL-20
structure and data elements existing during the period in which the allocation takes place
894 The system shall provide functionality to allocate financial balances from any account coding GL-20
distribution to any other account coding distribution (e.g., split the financial balances in one
organization to two new organizations)
895 The system shall provide functionality for user agencies to determine which indirect costs GL-20
are to be allocated, including the time period in which those costs occurred (e.g., effective
start and end dates)
896 The system shall provide functionality to execute/simulate cost allocations in "test mode." GL-20
This will allow agency personnel to perform "what-if" scenarios and review allocation results
prior to the creation of financial postings within the system
897 The system shall provide functionality to generate all warning messages, error messages, GL-20
and summary reports during the execution of a cost allocation in "test mode"
898 The system shall provide functionality to carry decimal places to an unlimited degree for GL-20
allocations and distributions
899 The system shall provide functionality to enable stepped allocations usually performed GL-20
during the execution of the State-wide cost allocation plan
900 The system shall provide functionality to accumulate lower-level allocations and redistribute GL-20
them with another allocation using intermediate pools (e.g., step down clearing distributions)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 52 of 111
New York Financial Management System (NYFMS) Exhibit E.5
FINANCIAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
901 The system shall provide functionality to allocate indirect financial balances based on pre- GL-20
determined rates, ratios, or statistics
902 The system shall provide functionality for users to edit and apply new allocation rates during GL-20
the fiscal year
903 The system shall provide functionality to allocate costs based on fixed amounts GL-20
904 The system shall provide functionality to allocate costs based on fixed percentages GL-20
905 The system shall provide functionality to allocate costs based on a fixed amount per statistic GL-20
906 The system shall provide functionality to allocate costs based on relative statistics within the GL-20
cost receiver(s)
907 The system shall provide functionality to allocate costs based on relative spending within the GL-20
cost receiver(s)
908 The system shall provide functionality to capture statistics based on any element of chart of GL-20
accounts (e.g., number of disbursements)
909 The system shall provide functionality to support Generally Accepted Accounting Principles GL-20
(GAAP) reporting standards for State-wide cost allocation plan reporting as designated by
current GASB requirements
910 The system shall provide functionality to define the beginning and end dates for all cost GL-20
allocations
911 The system shall provide functionality to identify allocable and non-allocable cost GL-20
components
912 The system shall provide functionality to capture definitions of a cost pool across any GL-20
element of the chart of accounts
913 The system shall provide functionality for cost drivers to include both statistical and financial GL-20
activity across any level of the chart of accounts
914 The system shall provide functionality to capture offset accounts for allocation transactions GL-20
posted to the general ledger in support of either an immediate cash transfer or an inter-
agency/inter-fund due to/due from if the allocations cross agencies or funds
915 The system shall provide functionality to schedule and automatically execute a cost GL-20
allocation on specified dates
916 The system shall provide functionality for users to determine frequency of allocation GL-20
processing
917 The system shall provide functionality to reverse all postings generated during the execution GL-20
of a cost allocation
918 The system shall provide functionality for users to back out, reverse, or edit cost allocation GL-20
methodologies over multiple periods
919 The system shall provide functionality for a user to create a cost allocation summary report GL-20
which details the allocated costs, the cost pools from which the costs were allocated, and
the amount of costs that were allocated to each cost receiver
920 The system shall provide functionality for a user to create a cost allocation summary report GL-20
which details a “before” and “after” view of the allocated costs
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 53 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
921 The system shall provide functionality for the following fields for customer master entry AR-10
including, but not limited to:
- Customer name
- Customer number
- Billing address
- Contact name/address/phone number/email
- Doing Business As (DBA) reference
- Security deposit required (Y/N)
- Credit and collection manager
- Late fees (Y/N)
- Tax codes and information
- One time customer (Y/N)
- Payment method
- Customer type
- Customer status
- Bank account
- Classifications codes
- Agency-specific customer number
922 The system shall provide functionality to store multiple bill-to addresses per customer AR-10
923 The system shall provide functionality for users to select the correct address when AR-10
customers have multiple bill-to addresses through the use of a "favorite lists" by agency
924 The system shall provide functionality for users to create parent/child relationships between AR-10
customer master records
925 The system shall provide functionality for users to attach electronic documents to a AR-10
customer master record
926 The system shall provide functionality to automatically assign a unique invoice ID number at AR-10
time of invoice creation
927 The system shall provide functionality for users to manually enter an invoice number at time AR-10
of invoice creation
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 54 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
928 The system shall provide functionality for the following fields for invoice entry including, but AR-10
not limited to:
- Customer name
- Customer number
- Invoice type
- Invoice number
- Invoice date
- GL/posting date
- List of services
- Account number
- Discount terms
- Total invoice amount
- Additional invoice charges (freight, etc.)
- Item quantity
- Item price
- Comments
- Due date
- Sales tax
- Bank account information
- Fields (e.g., location)
929 The system shall provide functionality for users to set up and record the appropriate AR-10
receivable accounting entry to offset based on the type of transaction
930 The system shall provide functionality to notify users when a duplicate customer invoice AR-10
number is entered
931 The system shall provide functionality for users to code an invoice against multiple General AR-10
Ledger account numbers
932 The system shall provide functionality to enable users to override any information in the AR-10
invoice that defaults from the customer master (e.g., sales tax information)
933 The system shall provide functionality for the capability to attach supporting documentation AR-10
and emails to invoices
934 The system shall provide functionality to validate certain data fields as part of the invoice AR-10
entry including, but not limited to:
- Customer number
- Account number
- Contract number
935 The system shall provide functionality for users to identify different types of deposit AR-10
transactions
936 The system shall provide functionality for users to create invoices with a zero dollar amount AR-10
937 The system shall provide functionality for users to create invoices with a minimum/maximum AR-10
billing amount
938 The system shall provide functionality for users to create an invoice that cross-references AR-10
against a voucher number (e.g., payment of fees to third party)
939 The system shall provide functionality for users to set up invoice templates that can be AR-10
copied to facilitate the creation of new invoices
940 The system shall provide functionality for users to create recurring invoices based on a AR-10
schedule
941 The system shall provide functionality to automatically release recurring invoices based on a AR-10
schedule
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 55 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
942 The system shall provide functionality for users to add, edit, or delete recurring invoice AR-10
information based on changes to agreement terms, amounts, or frequencies
943 The system shall provide functionality for users to create recurring invoice transactions for a AR-10
fixed or percentage allocation amount between multiple accounts
944 The system shall provide functionality for users to save an incomplete invoice AR-10
945 The system shall provide functionality to notify users, after a set number of days has AR-10
elapsed, to take action on any incomplete invoices
946 The system shall provide functionality for users to review, revise, and approve invoices AR-10
947 The system shall provide functionality for approval levels for invoice transactions based on, AR-10
but not limited to:
- Customer
- Dollar amount
- Account number
948 The system shall provide functionality to post all invoices to the general ledger and AR AR-10
modules
949 The system shall provide functionality for users to edit an invoice after it has been saved AR-10
and/or posted
950 The system shall provide functionality for users to make edits to any fields in an invoice after AR-10
saving it, but prior to posting it to the General Ledger
951 The system shall provide functionality for users to identify and hold disputed invoices AR-10
952 The system shall provide functionality for users to cancel or void multiple invoices AR-10
953 The system shall provide functionality to automatically generate the appropriate accounting AR-10
entries upon the voiding of an invoice
954 The system shall provide functionality to generate a paper version of the invoice AR-10
955 The system shall provide functionality to regenerate an existing paper invoice AR-10
956 The system shall provide functionality to not generate an invoice for a customer billing AR-10
957 The system shall provide functionality to distribute invoices electronically (e.g., EDI, HTML, AR-10
email)
958 The system shall provide functionality for users to customize the layout of the invoice print AR-10
959 The system shall provide functionality for users to purge invoices from the system AR-10
960 The system shall provide functionality for the following fields for receipt entry including, but AR-10
not limited to:
- Customer name (may not apply where a receipt is matched against an invoice)
- Customer number (may not apply where a receipt is matched against an invoice)
- Invoice number (may not apply where a receipt is matched against an invoice)
- Receipt date
- Amount
- Payment type
- Item quantity
- Comment fields
- Check number
- Alternative payer
- Tax classification codes
- Account number
961 The system shall provide functionality for users to enter a receipt without a corresponding AR-10
invoice (miscellaneous receipts)
962 The system shall provide functionality for users to apply multiple receipts against a single AR-10
invoice
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 56 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
963 The system shall provide functionality for users to apply a single receipt against multiple AR-10
invoices
964 The system shall provide functionality for users to code multiple revenue classifications on a AR-10
receipt
965 The system shall provide functionality for users to record a partial receipt against an invoice AR-10
966 The system shall provide functionality for automatic cash receipt functionality AR-10
967 The system shall provide functionality for users to create rules to automatically apply AR-10
receipts against existing invoices
968 The system shall provide functionality for users to manually match open invoices against AR-10
receipts that cannot be processed using an automatic cash receipts program
969 The system shall provide functionality to post receipt transactions to the General Ledger AR-10
970 The system shall provide functionality for users to post a receipt that exceeds the dollar AR-10
amount of the invoice
971 The system shall provide functionality to automatically post the excess amount of a receipt AR-10
to the appropriate element in the chart of accounts
972 The system shall provide functionality for users to void a miscellaneous receipt AR-10
973 The system shall provide functionality for users to void a receipt posted against an invoice AR-10
974 The system shall provide functionality for users to purge receipts from the system AR-10
975 The system shall provide functionality to receive, merge, and match daily account AR-10
information electronically from banking institutions
976 The system shall provide functionality to automatically receive and store electronic deposit AR-10
information in various electronic file formats
977 The system shall provide functionality for users to deposit transactions originating from, AR-10
including but not limited to the following:
- Wire transfers
- ACH deposits
- Over-the-counter deposits
- Credit card accounts
978 The system shall provide functionality to electronically receive and identify alpha-numeric AR-10
deposit numbers from inbound ACH transactions
979 The system shall provide functionality to automatically reconcile bank statement data to AR-10
receipt and withdrawal transactions in the AR and GL modules
980 The system shall provide functionality for users to manually adjust data that is interfaced AR-10
from the banking institution
981 The system shall provide functionality to generate a deposit slip report based on receipts AR-10
recorded during a period of time, with the ability to remove any selected receipt
982 The system shall provide functionality for users to link revenue transactions to deposits AR-10
983 The system shall provide functionality to record a credit card receipt (e.g., miscellaneous AR-10
receipt)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 57 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
984 The system shall provide functionality to generate AR reports with various data elements AR-10
including, but not limited to:
- Customer account aging
- Customer open receivables
- Customer types and balances (by payment method)
- Partial payments or overpayments
- Interest charges
- Payment history
- Customer data
- Invoice detail
- Miscellaneous receipts
- Checks returned by banks for non-sufficient funds
- Invoice date
- Due date
- Account number
- Invoice type
- Revenue type
985 The system shall provide functionality for users to combine multiple invoices on a single AR-20
customer statement
986 The system shall provide functionality for users to customize the layout of the customer AR-20
statement
987 The system shall provide functionality to automatically generate recurring customer AR-20
statements based on user specified criteria
988 The system shall provide functionality for users to reprint existing customer statements AR-20
989 The system shall provide functionality for users to purge customer statements from the AR-20
system
990 The system shall provide functionality for users to assign a credit and collections manager to AR-20
each customer
991 The system shall provide functionality to automatically notify the credit manager when a AR-20
customer’s account is deemed delinquent
992 The system shall provide functionality for users to add and delete delinquency business AR-20
rules (i.e. the parameters by which an account will be deemed delinquent)
993 The system shall provide functionality to generate delinquency/dunning notices based on AR-20
business rules
994 The system shall provide functionality for users to alter the language printed on dunning AR-20
notices (e.g., a dunning notice for a payment 30 days past due would have different
language than a dunning notice for a payment 90 days past due)
995 The system shall provide functionality to maintain multiple versions of delinquency/dunning AR-20
notices
996 The system shall provide functionality for users to reprint an existing delinquency/dunning AR-20
notice for a customer
997 The system shall provide functionality for users to purge dunning/delinquency notices from AR-20
the system
998 The system shall provide functionality for users to calculate late fees based on multiple fee AR-20
structures (e.g., flat fee, percentage of overdue balance)
999 The system shall provide functionality for users to set up effective dates for each late fee AR-20
structure
1000 The system shall provide functionality for users to determine which customers or group of AR-20
customers will be charged late fees
1001 The system shall provide functionality to calculate interest on overdue invoices AR-20
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 58 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1002 The system shall provide functionality for users to charge interest on either principal only or AR-20
on principal and accumulated interest
1003 The system shall provide functionality for users to override the system calculated interest AR-20
against an invoice or account
1004 The system shall provide functionality for users to retroactively apply late fees to past due AR-20
invoices
1005 The system shall provide functionality to generate an invoice for the late fees charged AR-20
against a customer's account
1006 The system shall provide functionality for aging analysis, both onscreen and in reports, of AR-20
outstanding accounts receivable for 30, 60, 90, 120, and greater than 120 days
1007 The system shall provide functionality for users with the option to determine which date AR-20
initiates the aging cycle (e.g., due date, invoice date)
1008 The system shall provide functionality for users to inquire about outstanding balances by AR-20
customer
1009 The system shall provide functionality for standard collections reporting AR-20
1010 The system shall provide functionality to track the status of overdue accounts including, but AR-20
not limited to:
- Comments
- Contact discussions
- Collection attempts
- Amount in dispute
1011 The system shall provide functionality to route aged invoices to different users based on AR-20
certain parameters
1012 The system shall provide functionality for users to add and delete credit memos AR-20
1013 The system shall provide functionality for users to apply credit memos against a single AR-20
invoice
1014 The system shall provide functionality for users to apply a credit memo against multiple AR-20
invoices
1015 The system shall provide functionality for users to review, revise, and approve of invoices AR-20
that will be written off
1016 The system shall provide functionality for users to identify invoices deemed as uncollectible AR-20
1017 The system shall provide functionality for multiple write-off codes (e.g., for bad debt and AR-20
discharge settlements)
1018 The system shall provide functionality for users to net a customer’s outstanding receivables AR-20
to his/her outstanding payables
1019 The system shall provide functionality to track refunds against miscellaneous receipts by AR-20
customer
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 59 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1020 The system shall provide functionality to identify each grant with at least 100 data fields including, but not GE-10
limited to:
- Award date
- Grantor's name (awarding entity)
- Grantor contact person's name, position, fax number(s), phone number(s), email address(es), and mailing
address(es)
- Grantor's website(s)
- Grantee contact person’s name and position
- Budget, fiscal, and other staff person(s)
- Title and description of grant
- Grant status, project start/end date, funding period start/end date, and award amount
- GAD (Grant Award Document) action number and type
- Award type
- CFDA (Catalogue of Federal Domestic Assistance) number
- Federal account code
- Agency award number
- Amendment number
- Type of funding source(s) (e.g., public, private)
- Funding source(s)
- Indirect rate type (restricted, unrestricted, etc.)
- Fringe benefit rate
- Federal program year
- Report type due and frequency
- Match requirement
- Administrative retainage requirement
- Maintenance-of-effort state and local requirements
- Liquidation date
- Amount of previous grant
- Increase/decrease in grant amount compared to previous grant
- Federal administering office, contact's name, contact's title, and address
- Pending litigation flag and purge flag
- Sub-grant number
1021 The system shall provide functionality to save award information for each grant in at least GE-10
100 data fields including, but not limited to:
- Award amount
- Award date
- Amended/Supplemental amount(s)
- Amended/Supplemental date(s)
- Allowable advances - Payment basis (e.g., deliverables, reimbursement of expenditures)
- PMS (Federal payment management system) type
- PMS number
- Non-cash award(s) (e.g., equipment, land, inventory supplies)
- Estimated value for non-cash award(s)
- Terms and conditions
- Funding technique(s) for drawdown (e.g., percent based on a class of expenditures:
payroll, administrative, direct, indirect)
- Y/N identifier to indicate whether subject to CMIA requirements
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 60 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1022 The system shall provide functionality to save federal requirements for a grant including, but GE-10
not limited to:
- Maintenance of effort requirements
- Expenditure types/levels that are eligible for reimbursement
- Federal appropriation number(s) and years
- Reporting requirements (schedule and frequency)
- Audit requirements
1023 The system shall provide functionality to save multiple matching requirements for a grant GE-10
including, but not limited to:
- Match type (e.g., cash, in-kind services, donated equipment, donated land)
- Match rate(s) and basis (e.g., expenditure type)
- Match restrictions on non-cash items (e.g., use/sale of land, equipment, buildings)
- Match source(s)
- State and local cost sharing
1024 The system shall provide functionality for users to define the status of a grant by categories GE-10
including, but not limited to:
- Application/state plan in progress
- Application/state plan submitted
- Application/state plan withdrawn
- Application/state plan not applicable
- Awarded
- Denied
- Suspended
- Closed
1025 The system shall provide functionality to automatically create a unique grant number and GE-10
sub-grant number, if necessary, for each grant
1026 The system shall provide functionality for users to manually enter an agency-defined unique GE-10
grant number and sub-grant number, if necessary, for each grant
1027 The system shall provide functionality for users to edit and update the grant record and GE-10
capture all edits and updates in an electronic audit trail
1028 The system shall provide functionality for users to copy key information from a previous GE-10
grant record and include it in a new grant record
1029 The system shall provide functionality for users to configure additional fields of at least 500 GE-10
characters to capture comments/narrative
1030 The system shall provide functionality for users to define the data in the grant record that GE-10
are required before the grant record can be saved
1031 The system shall provide functionality for users to translate electronic grant applications GE-10
(e.g., applications in PDF format) into grant templates/forms
1032 The system shall provide functionality to view transactions made against a sub-allocated GE-10
grant
1033 The system shall provide functionality for users to establish grant budgetary controls in GE-20
multiple formats including, but not limited to:
- Grant year
- Grant award amount
- Beginning and end date
1034 The system shall provide functionality for users to establish grant budgetary control periods GE-20
different from appropriation control periods
1035 The system shall provide functionality for users to link multiple grants to a project GE-20
1036 The system shall provide functionality for users to link multiple projects to a grant GE-20
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 61 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1037 The system shall provide functionality for users to link multiple grants to an appropriation GE-20
1038 The system shall provide functionality for users to link multiple appropriations to a grant GE-20
1039 The system shall provide functionality for the effective date for a grant to span multiple state GE-20
fiscal years
1040 The system shall provide functionality for users to change the effective date associated with GE-20
a grant
1041 The system shall provide functionality for users to view awards made to sub-recipients GE-20
1042 The system shall provide functionality for users to view funds expended and disbursed by GE-20
the sub-allocation recipient agency
1043 The system shall provide functionality for users to establish the beginning date and the end GE-20
date of a sub-allocation
1044 The system shall provide functionality for users to establish budget categories as defined by GE-20
the grant and/or sub-allocation contract
1045 The system shall provide functionality to restrict users from establishing beginning and end GE-20
dates, for the sub-allocated portions of grants, that extend beyond the beginning and end
date for the original grant
1046 The system shall provide functionality for budgeting and reporting by grant GE-20
1047 The system shall provide functionality for users to create a grant's budget at any level in the GE-20
data hierarchy (including the Chart of Accounts)
1048 The system shall provide functionality for users to control a grant's budget at any level in the GE-20
data hierarchy (including the Chart of Accounts)
1049 The system shall provide functionality for users to create and save expenditure-based GE-20
spending projections for each grant at any level in the chart of accounts
1050 The system shall provide functionality for users to create and save expenditure-based GE-20
spending projections for each grant for different time periods including, but not limited to:
- Annually
- Quarterly
- Monthly
- Weekly
1051 The system shall provide functionality for users to create and save multiple versions of the GE-20
expenditure-based spending projections for each grant
1052 The system shall provide functionality for users to create and save expenditure-based GE-20
spending projections for each grant at different levels in the chart of accounts
1053 The system shall provide functionality for users to create and save disbursement-based GE-20
spending projections for each grant at any level in the chart of accounts
1054 The system shall provide functionality for users to create and save disbursement-based GE-20
spending projections [spending plan] for each grant for different time periods including, but
not limited to:
- Annually
- Quarterly
- Monthly
- Weekly
1055 The system shall provide functionality for users to create and save multiple versions of the GE-20
disbursement-based spending projections for a grant
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 62 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1056 The system shall provide functionality for users in different agencies to create and save GE-20
disbursement-based spending projections for a grant at different levels in the chart of
accounts
1057 The system shall provide functionality for users to simultaneously create and save both GE-20
expenditure-based and disbursement-based spending projections for a grant
1058 The system shall provide functionality for users to create disbursement-based spending GE-20
projections for a grant based on the expenditure-based spending projections using
customized business rules
1059 The system shall provide functionality for users to edit the spending projections over the GE-20
course of the grant term
1060 The system shall provide functionality to link all relevant transactions to a grant GE-20
1061 The system shall provide functionality to prevent a transaction from occurring when the GE-20
transaction will result in the grant award amount being exceeded
1062 The system shall provide functionality to post encumbrances against a grant GE-20
1063 The system shall provide functionality for users to obligate portions of a grant and reserve it GE-20
so it cannot be spent (e.g encumbrances and accruals to grants)
1064 The system shall provide functionality to post expenditures to a grant GE-20
1065 The system shall provide functionality to restrict grant-related expenditure transactions that GE-20
are outside of the specified grant period
1066 The system shall provide functionality for auhorized users to override the grant expenditure GE-20
transaction controls
1067 The system shall provide functionality to record Personal Service (e.g., payroll) transactions GE-20
to the grant regardless of availability of grant, but alert users if the grant amount is exceeded
1068 The system shall provide functionality for users to enter refunds of an expenditure against a GE-20
grant
1069 The system shall provide functionality to alert specified users of a refund of expenditure GE-20
against a grant
1070 The system shall provide functionality for users to save planned and actual non-financial, GE-20
performance measures and associated data at any level in the data hierarchy
1071 The system shall provide functionality to display the total value of a grant's appropriation(s) GE-20
1072 The system shall provide functionality to display a dashboard for each grant that GE-20
summarizes the financial balances associated with the grant including, but not limited to:
- Total value of the award
- Encumbrances/obligations
- Expenditures
- Disbursements
- Uncommitted funds
1073 The system shall display the amount of outstanding encumbrances posted to the grant as of GE-20
a specified time
1074 The system shall display the amount of expenditures posted to the grant life-to-date GE-20
1075 The system shall display the amount of disbursements posted to the grant life-to-date GE-20
1076 The system shall provide functionality for users to drilldown to the lowest level of the chart of GE-20
accounts to identify the transactions that comprise the encumbrance balance posted to a
grant
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 63 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1077 The system shall provide functionality for users to drilldown to the lowest level of the chart of GE-20
accounts to identify all the transactions that comprise the expenditure balance recorded
against a grant
1078 The system shall provide functionality for users to drilldown to the lowest level of the chart of GE-20
accounts to identify all the transactions that comprise the disbursement balance posted to a
grant
1079 The system shall provide functionality for users to generate reports detailing all transactions GE-20
posted to the grant including those posted to the sub-allocated portions of the grant
1080 The system shall provide functionality for users to close a grant upon completion of a grant GE-20
cycle
1081 The system shall provide functionality for users to reopen closed grants GE-20
1082 The system shall provide functionality to alert and/or notify users when a decrease in the GE-20
grant amount results in a grant award amount that is lower than the committed balance
1083 The system shall provide functionality to alert and/or notify users when the committed GE-20
balance exceeds the grant award amount
1084 The system shall provide functionality for users to suspend a grant prior to completion and GE-20
"hold" all additional financial transactions
1085 The system shall provide functionality for users to view closed grants GE-20
1086 The system shall provide functionality for users to liquidate encumbrances after a grant GE-20
period’s end date has passed but before its liquidation period end date has passed
1087 The system shall provide functionality to save grant data, without irrevocably condensing or GE-20
summarizing any level of detail for a period of time or if a status code (i.e Pending Litigation
Flag) indicates that the grant must remain open
1088 The system shall provide functionality to save electronic copies of all grant documents and GE-20
attachments for audit purposes
1089 The system shall prevent grant records from being purged until the grant is closed GE-20
1090 The system shall provide functionality for users to search and view closed grant records and GE-20
related attachments
1091 The system shall provide functionality for users to create a calendar for the grant process GE-20
and link tasks to the calendar
1092 The system shall provide functionality for users in different agencies to create different grant GE-20
calendars and link different tasks to the calendar
1093 The system shall provide functionality to automatically notify users via email or workflow GE-20
when a grant calendar is established
1094 The system shall provide functionality for users to edit the grant calendar throughout the GE-20
year
1095 The system shall provide functionality to automatically notify users via email or workflow GE-20
when a grant calendar is modified
1096 The system shall provide functionality for users to apply calendar functionality to a variety of GE-20
tasks, including, but not limited to:
- Grant application
- Reconciliation reports
- Drawdown requests
- Other state/federal reports
- Close out process
1097 The system shall provide functionality to notify users when a grant award notice has been GE-20
received
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 64 of 111
New York Financial Management System (NYFMS) Exhibit E.5
REVENUE REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1098 The system shall provide functionality to enable daily draw downs from federal agencies GE-30
1099 The system shall provide functionality to identify each financial transaction posted to the GE-30
grant to signify whether the transaction has been included in a drawdown request and the
date of the drawdown
1100 The system shall provide functionality to calculate the drawdown amount by off-setting GE-30
expenditures with revenues and receivables that have been posted to the grant and have
not been previously posted to a drawdown
1101 The system shall provide functionality to calculate the drawdown amount by off-setting GE-30
disbursements with revenues and receivables that have been posted to the grant and have
not been previously posted to a drawdown
1102 The system shall provide functionality to create a drawdown request report that includes any GE-30
new or modified transactions that have been posted to the grant since the last drawdown
request report
1103 The system shall provide functionality to apply for reimbursement to the federal government GE-30
for expenditures/disbursements based on CMIA compliance options including, but not
limited to:
- Grant number
- CFDA number
- Fund number
- Account number
- Activity number
- Cost sharing requirements
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 65 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1104 The system shall provide functionality for users to modify assets by overriding information AS-10
received from other modules or subsystems (e.g., Project Accounting, Purchasing, or AP)
1105 The system shall provide functionality to maintain computer software inventory in the assets AS-20
module. Additional data fields would include, but are not limited to the following:
- Product name
- Product version
- Manufacturer (i.e. licensor)
- Order number (e.g., contract, purchase order, or purchase card)
- Order date
- Quantity
- Supplier
- License term
- License type
- Product category (e.g., PC, mainframe, or server)
- Memo field
1106 The system shall provide functionality to identify an asset acquisition at time of requisition AS-20
1107 The system shall provide functionality to track assets associated with a purchase through AS-20
the Purchasing Module that have not been received
1108 The system shall provide functionality to update the asset master record if the amount paid AS-20
(i.e. invoice amount) for the asset is different than the price stated on the purchase order
from which the asset was generated
1109 The system shall provide functionality for users to use multiple purchase orders to acquire a AS-20
single asset
1110 The system shall provide functionality for users to directly enter asset information when the AS-20
asset is acquired outside of integrated system modules (e.g., contractor procures
commercial oven on behalf of the State, gift, donation)
1111 The system shall provide functionality to maintain pertinent data on controlled assets as AS-20
follows. Controlled assets are non-capitalized equipment that are not to be capitalized per
State policy, but have been deemed to be items requiring security and control by State or
agency policy
1112 The system shall provide functionality for users to distinguish between capitalized and AS-20
controlled assets
1113 The system shall provide functionality to assign unique inventory control or property AS-20
numbers to all assets
1114 The system shall provide functionality to integrate the Purchasing, Project Accounting, and AS-20
Asset Management modules to identify expenditure transactions against an asset
1115 The system shall provide functionality for a free-form narrative description field for an asset AS-20
item
1116 The system shall provide functionality to track different types of assets including, but not AS-20
limited to:
- Equipment
- Buildings
- Infrastructure
- Land
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 66 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1117 The system shall provide functionality for users to record the funding source used to acquire AS-20
the asset including, but not limited to:
- Certificates of participation
- Bonds proceeds
- Federal funds
- Installment purchase agreement
- State operating funds
1118 The system shall provide functionality for users to copy asset record entries for identical AS-20
items and then assign separate asset tag/inventory control numbers (e.g., purchase of 20
identical personal computers)
1119 The system shall provide functionality to maintain detailed real estate information required to AS-20
identify and account for State lands including, but not limited to:
- Legal description per survey
- County
- Acquisition information
- Number of acres
- Value per acre
- Fair market value
- Deed information
- Structure/Building Number(s)
- Betterments
- Special Improvement District tax information
- Options to purchase property
- Geographic Information System technology location (latitude and longitude)
- Memo Field
1120 The system shall provide functionality to calculate acquisition cost automatically based on AS-20
total unit cost including shipping and other ancillary costs captured on a purchase order or
AP voucher
1121 The system shall provide functionality to record all capitalizable costs associated with the AS-20
construction or purchase/acquisition of an asset and when applicable, link the asset to the
project, sub-project or grant that resulted in acquisition of the asset
1122 The system shall provide functionality for users to record and maintain information on AS-20
construction work-in-progress and provide a mechanism to transfer accumulated work-in-
progress costs to an asset record
1123 The system shall provide functionality for users to identify expenditures as fixed assets AS-20
based on useful life, dollar amount, general ledger account, etc.
1124 The system shall provide functionality for users to create, edit, or delete parent/child AS-20
relationships between assets
1125 The system shall provide functionality for users to change an asset's useful life, salvage AS-20
value, and depreciation method when necessary
1126 The system shall provide functionality to fully integrate bar code technology for asset AS-20
tagging upon acquisition/purchase and annual inventory certification(s)
1127 The system shall provide functionality to track (e.g., identify, record, inquire, report) AS-20
regular/preventative maintenance performed on selected assets
1128 The system shall provide functionality for user inquiries by any element of the asset master AS-20
record (e.g., asset number, asset description)
1129 The system shall provide functionality for users to record the priority assigned to critical and AS-20
non-critical maintenance for assets
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 67 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1130 The system shall provide functionality to maintain information on building assets pertinent to AS-20
insurance underwriting, including but not limited to the following:
- Location (regions, zones, cost centers)
- Building age or date constructed
- Number of stories
- Construction type
- Foundation
- Air handling system
- Square footage
- Roof type
- Condition
- Maintenance requirements and actual maintenance performed
- Inspection requirements and actual inspections performed
- Fire protection systems
- Building fuel information
- Usage
- Valuation
- Insurance information (company, policy, coverage amount, etc.)
- Geographic Information System technology location (Latitude and Longitude)
- Loss history
1131 The system shall provide functionality to accommodate multiple depreciation schedules that AS-20
could be applied to an asset
1132 The system shall provide functionality for users to maintain detailed asset information AS-20
required to identify and properly account for all assets including, but not limited to:
- Asset ID
- Description
- Condition rating
- Acquisition date
- In service date
- Asset category
- Asset class
- Agency
- Division
- Responsible organization
- Model number
- Serial number
- Location
- Procurement method - a reference to the method of the acquisition such as purchase
order, petty cash, purchase card, project or other
- Procurement document(s) – a reference or link to the source document
- Payment document(s)
- Object code
- Cost
- Surplus reference (if necessary)
- Disposal date
- Disposal reference
- Disposal method - must be selected from a list of valid values
- Disposal costs
- Amount collected (to be required if the method of disposition is sale)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 68 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1133 The system shall provide functionality for users to modify or remove the link between a child AS-20
asset and a parent asset
1134 The system shall provide functionality to automatically update the general ledger to AS-20
capitalize any asset acquired through the purchasing module that meets the capital
threshold
1135 The system shall provide functionality to automatically update the general ledger to AS-20
capitalize any completed project that is added to fixed assets that meets the capital
threshold
1136 The system shall provide functionality to automatically update the general ledger to AS-20
capitalize any assets entered directly into the fixed asset module that meets the capital
threshold
1137 The system shall provide functionality to post accounting entries to the general ledger when AS-20
additions, deletions, and changes to the asset values occurs
1138 The system shall provide functionality for users to drill down from asset summary reports to AS-20
any source document stored in the system (e.g., Purchasing, AP, or Project Accounting)
1139 The system shall provide functionality to track the usage of a child asset independently of AS-20
the parent asset to which it is linked so that if the child moves from one parent asset to
another parent asset, all data is maintained and transferred
1140 The system shall provide functionality to accommodate a transaction for non-State agencies AS-20
(e.g., not-for-profit organizations and local municipalities) to access and update asset
records for assets charged to its stewardship
1141 The system shall provide functionality for users to identify assets that have been purchased AS-20
or leased by methods including, but not limited to:
- Contracts
- Request for quote
- Option to buy
- Lease purchase
- Direct agency lease
1142 The system shall provide functionality for users to record and track the physical location of AS-20
an asset
1143 The system shall provide functionality for users to retain the original fund source, but identify AS-20
current fund source and report on history
1144 The system shall provide functionality to track initial tag number and subsequent tag number AS-20
changes as of an effective date (time dependent data with history)
1145 The system shall provide functionality for users to record and track updates to historical cost AS-20
(e.g., a separate shipping invoice is received for a specific asset)
1146 The system shall provide functionality to allow multiple asset master record assignments by AS-20
purchase order line item. (e.g., one line item on a purchase order for 20 computers for $20K
is eventually displayed in Assets as 20 individual computers at $1K)
1147 The system shall provide functionality to default an asset master record by asset class when AS-20
creating a master record based on the commodity or other criteria chosen during the
acquisition transaction within procurement
1148 The system shall provide functionality to identify the one-time procurement of infrastructure AS-20
assets (e.g., park system and network purchase) and on-going infrastructure assets (e.g.,
sewage structure)
1149 The system shall provide functionality for an equipment type to pre-populate useful life for AS-20
an asset
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 69 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1150 The system shall provide functionality for each agency to define the useful live of each AS-20
equipment type (e.g., Agency A has a useful live of 5 years for asset type copiers and
Agency B has a useful life of 7 years for copiers)
1151 The system shall provide functionality for tracking an alternate replacement date and useful AS-20
life expiration date
1152 The system shall provide functionality for users to capture easement information including, AS-20
but not limited to:
- Type of easement
- Address
- Legal description
1153 The system shall provide functionality to track asset ownership information (e.g., AS-20
communications equipment on top of a tower owned by another entity)
1154 The system shall provide functionality to link assets (e.g) buildings and associated building AS-20
improvements
1155 The system shall provide functionality to identify assets as potential liabilities (e.g., AS-20
contaminated land)
1156 The system shall provide functionality to procure and receive a number of similar assets on AS-20
one purchasing transaction, then distribute individually from a central location. This
requirement is similar to the ability to warehouse assets for use as needed and to assign
them individually. Upon assignment, agencies would update the asset master shell record
for in-service date, responsibility, and location information
1157 The system shall provide functionality to accommodate a tag number that is independent of AS-20
the system generated asset number identifier
1158 The system shall provide functionality to capture whether an environmental assessment has AS-20
been completed
1159 The system shall provide functionality to create an asset record for a leased asset (State as AS-20
lessee)
1160 The system shall provide functionality for users to identify assets as leased by the State AS-20
(State as lessor)
1161 The system shall provide functionality to adjust (write-up and write-down) value of land and AS-20
track changes of the value adjustment
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 70 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1162 The system shall provide entry of equipment units and maintain up-to-date information about AS-20
each unit. Data elements for the units are including, but not limited to:
- Basic information
- Meter information (e.g., mileage)
- Classes
- Locations
- Assignments
- Status
- Class preventative maintenance program
- Individual preventative maintenance program
- Comments
- Inspections
- Recurring costs
- Acquisition
- Ownership and depreciation
- Warranty
- Replacement and disposition
- Link to external files
- Lease agreements
1163 The system shall provide functionality to support the definition of any number of equipment AS-20
classes. Users must be able to assign each equipment unit to at least six functional classes
including, but not limited to:
- Maintenance (for cost and cost analysis purposes)
- Preventative maintenance (for preventative maintenance program)
- Standards (for cost, consumption, and labor standards)
- Rental rates (for fixed and variable chargeback rates)
- Shop scheduling (for bay, labor, parts, and tool requirements)
1164 The system shall provide functionality to track repairs made under warranty for all assets AS-20
1165 The system shall provide functionality to display a message after opening a work order if an AS-20
equipment unit is:
- Late, due, or soon due for a scheduled preventative maintenance
- Under warranty
- Flagged for disposition
- Subject of other open work orders
- Subject to department approval prior to work
1166 The system shall provide functionality to track equipment costs and provide reporting AS-20
including, but not limited to:
- Cost per mile or engine hour
- Current year-to-date total cost
- Life-to-date total cost
1167 The system shall provide functionality to maintain repair and preventative maintenance AS-20
history data for each equipment unit, including online access to both summary information
1168 The system shall provide functionality to support the automatic renewal of component-level AS-20
warranty coverage periods based on type of repair performed
1169 The system shall provide functionality to define the triggers that define when preventative AS-20
maintenance services become due (e.g., elapsed time, meter usage, odometer, hour meter,
or flow meter)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 71 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1170 The system shall provide functionality to support any number of certain preventative AS-20
maintenance checklist items detailing individual checkpoints for the preventative
maintenance service
1171 The system shall provide functionality for online tracking of completed preventative AS-20
maintenance items
1172 The system shall provide functionality for notification of preventative maintenance AS-20
automatically for all equipment units by data elements including, but not limited to:
- Location
- Department
- Preventative maintenance type
- Elapsed time
- Meter usage
- Fuel consumption since the last maintenance was performed
1173 The system shall provide functionality to support an unlimited number of inspections for AS-20
each equipment unit separate from preventative maintenance program, including but not
limited to:
- A periodic inspection, which a user can define to occur every month, two months, three
months, four months, six months, or annually. When due, this inspection appears on a
system generated report of equipment units due for inspection
- A statutory inspection, which a user can define to occur on any desired monthly interval.
When due, this inspection appears on a system generated report of equipment units due for
inspection
1174 The system shall provide functionality to track the complete history of meter rollovers (and AS-20
replacements) for each equipment unit and track the total life usage for each unit
1175 The system shall provide online entry and maintenance account number information for all AS-20
asset records
1176 The system shall provide functionality to generate reports detailing the cost of new assets AS-20
acquired to replace an asset lost, missing, stolen, or destroyed
1177 The system shall provide functionality to produce capital asset activity reports by agency, AS-20
asset class and fund source (per the CAFR) for governmental activities, discretely
presented component units, and business-type activities including, but not limited to:
- Beginning balance
- Beginning balance adjustments
- Additions
- Deletions and net transfers
- Ending balance
1178 The system shall provide functionality to record capital assets that were originally captured AS-20
as construction in progress in another module (e.g., Project Accounting)
1179 The system shall provide functionality to create reports to be used for physical counts that AS-20
are organized and sorted by physical asset location and by sub-location codes specified by
the agency
1180 The system shall provide functionality to track and report each asset record by the AS-20
equipment custodian, (assigned responsible employee) another State employee or someone
else that has taken an asset offsite from a State facility. The information to be tracked is
including, but not limited to:
- Date the asset was taken from the State facility
- Expected return date
- Actual return date
- Who checked the asset out and in the system
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 72 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1181 The system shall provide functionality to track and report by each asset record if the AS-20
equipment custodian (assigned responsible employee) is authorized to take his or her
assigned assets offsite from the State facility and identify the person who authorized the
State employee the privileges or right to take his or her assets offsite
1182 The system shall provide functionality to record corrections to the previous fiscal year and AS-20
retroactively adjust the beginning balance of accumulated depreciation or original cost for an
asset
1183 The system shall provide functionality to create asset master records with no corresponding AS-20
cost for manual transactions (e.g., donated, gifts)
1184 The system shall provide functionality to maintain information on loaned assets including, AS-20
but not limited to the following:
- Date loaned
- Description of action taken
- Repairs/modifications, if necessary
- Location changes
1185 The system shall provide functionality to transfer asset maintenance jurisdiction within or AS-30
between independently operating entities at the individual asset level or group level (for
mass changes and individual items)
1186 The system shall provide functionality to transfer assets between departments, divisions, AS-30
and responsible organizations or work units
1187 The system shall provide functionality for the receiving agency to confirm the receipt of the AS-30
item after a transfer
1188 The system shall provide functionality for users to identify assets that are not subject to a AS-30
transfer (e.g., an asset purchased through federal funds)
1189 The system shall provide functionality, after an asset transfer, for a quick "fill" of an AS-30
electronic form with information defaulted from the asset record in order to update
responsible organization and location data
1190 The system shall provide functionality to automatically generate any general ledger entries AS-30
that may result from a transfer of a capital asset
1191 The system shall provide functionality to record the date when an asset is transferred AS-30
1192 The system shall provide an asset transfer transaction for collaborative data entry. This AS-30
shall include the capability to enter and save partially completed asset transfers. This could
include allowing the transferring agency to complete its portion of a transfer and to allow the
document to be saved. At a later date, the receiving agency could access the transaction
for completion and posting of the final transfer
1193 The system shall provide transactions (workflow enabled) for asset transfers. This AS-30
functionality shall include review, release, and authorization for intra-agency or inter-agency
transfers
1194 The system shall provide functionality to handle transfers of partial assets AS-30
1195 The system shall provide functionality to conduct mass transfers of assets AS-30
1196 The system shall provide functionality to identify and track intra-agency transfers that AS-30
involve a change to the fund source
1197 The system shall provide functionality to track the parent and child relationship history of a AS-30
component (chain of custody) when the component is transferred from one asset to another
1198 The system shall provide functionality to transfer assets within or between independently AS-30
operating entities at the individual asset level or group level (for mass changes and
individual items)
1199 The system shall provide functionality to initiate an asset disposition request through AS-40
automated workflow processing
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 73 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1200 The system shall provide functionality to dispose of a parent asset and child asset in the AS-40
same transaction
1201 The system shall provide functionality to generate the appropriate accounting entries for the AS-40
disposition of both a parent and child asset
1202 The system shall provide functionality to automatically generate the general ledger entries to AS-40
dispose of a capital asset including the removal of the cost (book value) from the asset, the
elimination of the accumulated depreciation, the amount collected (if sold), and any gain or
loss on the disposal
1203 The system shall provide functionality to allow a transaction for approval of retirements. AS-40
Currently the State uses a Declaration of Surplus form for approval by OGS Surplus
1204 The system shall provide functionality to retire an asset based on the disposition status of AS-40
the asset (e.g., if disposition is approved by OGS Surplus Property)
1205 The system shall provide functionality for partial retirement based on, but not limited to, the AS-40
following:
- Percentage
- Value
- Quantity
- Unit of measure
1206 The system shall provide functionality for reporting of assets by retirement reason, AS-40
retirement transaction code, and retirement method
1207 The system shall provide functionality to conduct mass disposals of assets AS-40
1208 The system shall provide functionality for exceptions to be made to the surplus document AS-40
prior to approval (e.g., add items to the retirement transaction that are being retired but not
part of asset management system)
1209 The system shall provide functionality for users to modify an asset's condition code to be AS-40
changed during the retirement process
1210 The system shall provide functionality to track asset statuses within the disposition process. AS-40
Potential status categories include, but are not limited to:
- Agency approved
- Disposal review
- State surplus reviewed
1211 The system shall provide functionality to record and store various methods of asset AS-40
disposition including, but not limited:
- Sold
- Traded
- Discarded
- Cannibalized
- Lost or stolen
- Donated
- Deleted
- Transferred
- Casualty loss
- Assigned to outside source
- Control purposes only
1212 The system shall provide functionality, upon disposition of an asset, to store data elements AS-40
including, but not limited to:
- Disposition date
- Disposition method
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 74 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1213 The system shall provide functionality to update asset location information and "last AS-50
inventoried date" for each scanned asset based on scanned data
1214 The system shall provide functionality to record and store the following information related to AS-50
missing, lost, or stolen assets, including but not limited to:
- Property tag/inventory control number
- Reporting individual
- Last inventoried date
- Last location
- Date of occurrence or date first noticed missing
- Police report number, if applicable
- A text area for applicable narrative comments
1215 The system shall provide functionality for users to scan bar coded asset tags and AS-50
automatically upload the physical inventory for review, reconciliation, and approval
1216 The system shall provide functionality for users to modify an asset's condition during AS-50
physical inventory. Examples of an asset's condition include, but are not limited to:
- New
- Good
- Poor
- Broken
- Missing
- Lost
- Stolen
- Destroyed
- Marked for disposition
1217 The system shall provide functionality for agencies to provide mass updates to a physical AS-50
inventory date field
1218 The system shall provide functionality to identify any missing physical inventory and produce AS-50
exception reports for tracking purposes including, but not limited to:
- Assets scanned, but not found in system inventory
- Assets found but retired within the system
- Assets not found but in system inventory
1219 The system shall provide functionality to support the download of physical inventory data to AS-50
bar code scanners for physical inventory counts
1220 The system shall provide functionality to support the update of user-defined asset fields via AS-50
a bar code scanner at the time of physical inventory count
1221 The system shall provide functionality to process physical inventory counts at any time, AS-50
including a report comparing the physical inventory count to the system count and showing
inventory discrepancy
1222 The system shall provide a list of all building components to facilitate a mass retirement from AS-50
the State's fixed asset records (e.g., a building is damaged from a fire)
1223 The system shall provide functionality to generate depreciation on specific assets above a AS-60
certain dollar threshold
1224 The system shall provide functionality to generate depreciation and update assets records AS-60
without sending a depreciation journal entry to the general ledger
1225 The system shall provide functionality to perform a simulated depreciation analysis prior to AS-60
actual posting of depreciation
1226 The system shall provide functionality to fully integrate the Asset Management module with AS-60
the general ledger to allow for the recording of depreciation expense
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 75 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1227 The system shall provide functionality to accommodate various depreciation tools including, AS-60
but not limited to:
- Calculate depreciation on all fixed assets
- Provide depreciation schedules on fixed assets
- Generate monthly depreciation by asset for any element in the classification structure (e.g.,
appropriation, fund, organization, program, activity, grant, project)
1228 The system shall provide functionality to capitalize and depreciate composite assets when AS-60
the capitalization threshold has been met. It is not necessary for each individual component
to meet the threshold (e.g., children of a parent asset)
1229 The system shall provide functionality to support GAAP and GASB for the automatic AS-60
calculation of depreciation
1230 The system shall provide functionality to support the selective disabling of depreciation AS-60
calculations by, including but not limited to:
- Asset record
- Child
- Parent
- Agency
1231 The system shall provide functionality to display the amount of depreciation tied to a specific AS-60
fixed asset
1232 The system shall provide functionality to project depreciation for up to 10 years on monthly, AS-60
quarterly, semi-annually and yearly basis at a summary and detailed level
1233 The system shall provide functionality to project annual depreciation for all assets at a AS-60
consolidated and individual asset level
1234 The system shall provide functionality to not exclude certain assets from being depreciated AS-60
(e.g., land)
1235 The system shall provide functionality to identify an asset as fully depreciated when it AS-60
reaches the end of its depreciable life
1236 The system shall provide functionality to adjust the depreciation manually at year-end under AS-60
special circumstances
1237 The system shall provide functionality to report cumulative depreciation AS-60
1238 The system shall provide functionality to generate period end financial reports that are in AS-60
compliance with GAAP and GASB requirements
1239 The system shall provide functionality to generate a report of deleted (archived) asset AS-60
master shell records in the current fiscal year, either by mass maintenance or initiated by a
user
1240 The system shall provide functionality for users to transfer inventories, goods, or supplies IN-10
within or between agencies
1241 The system shall provide functionality to issue items for a repair order IN-10
1242 The system shall provide functionality to identify stock items by commodity number or other IN-10
designated item identifier
1243 The system shall provide functionality for a variable length free-form character field or IN-10
notepad, to describe special handling requirements, including but not limited to:
- Hazardous material classification
- Storage requirements
- Special clothing requirements
- Special instructions for handling and disposal
- Spill response
- Notification requirements
1244 The system provide functionality for users to record, maintain, and report Material Safety IN-10
Data Sheet information
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 76 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1245 The system shall provide functionality to define and support the relationships between IN-10
division inventory or main storage location and sub-inventory locations
1246 The system shall provide functionality to accommodate a minimum of three levels of IN-10
parent/child relationships between inventory locations
1247 The system shall provide functionality to update inventory quantities and the general ledger IN-10
in near-real time when the following transactions are executed including, but not limited to:
- Receipts
- Issues
- Transfers
- Returns
- Quantity adjustments
- Price adjustments
- Disposal of items
- Making items obsolete
1248 The system shall provide functionality to apply an adjustment to the weighted average unit IN-10
price of an inventory item
1249 The system shall provide functionality for users to apply price adjustments to the weighted IN-10
average unit price of all inventory items in any inventory location
1250 The system shall provide functionality for separate adjustment pools to capture purchase IN-10
variance, inventory variance, and price adjustments of each division
1251 The system shall provide functionality for users to issue transactions and create pick lists for IN-10
the backorders using a combination of First In First Out (FIFO) and priority basis
1252 The system shall provide functionality to generate “shadow” transactions to record the IN-10
receipt of the items in inventory and issuance of the items from inventory at the same time
(this requirement should be accomplished in one step)
1253 The system shall provide functionality for users to place an inventory item on backorder IN-10
1254 The system shall provide functionality for users to cancel any backorder IN-10
1255 The system shall provide functionality for users to for set a backorder priority level on each IN-10
backorder when backorders are created at a warehouse location
1256 The system shall provide functionality to generate a pick list when an inventory unit receives IN-10
a requisition
1257 The system shall provide functionality to generate a receipt document when items are IN-10
issued from inventory
1258 The system shall provide functionality to generate inventory transfer documents IN-10
1259 The system shall provide functionality to flag inventory items as “in-transit” until items are IN-10
received by the receiving location
1260 The system shall provide functionality to not allow the cost and quantity of inventory items to IN-10
be transferred to another inventory location for items “in-transit” without the receiving unit
accepting the items
1261 The system shall provide functionality to return stock at the same cost it was issued IN-10
1262 The system shall provide functionality to alert the user if material being transferred is short IN-10
or over
1263 The system shall provide functionality for a user to assign a part number and manufacturer IN-10
reference to a specific inventory location
1264 The system shall provide functionality for users to schedule inventory assessment reports IN-10
on demand and on a predefined schedule by location
1265 The system shall provide functionality to update the on-hand quantity at the time of receipt IN-10
for the receiving location
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 77 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1266 The system shall provide functionality to track serial numbers for inventory items (e.g., tools IN-10
and warranty items
1267 The system shall provide functionality to require the user to enter serial numbers as part of IN-10
the issue, receipt, returns, and transfer transactions for those inventory item types identified
as requiring serial numbers
1268 The system shall provide functionality for a user to assign an effective date for inventory IN-10
class/type/groupings
1269 The system shall provide functionality for users to receive, maintain, and issue IN-10
inventory/stock items from multiple locations
1270 The system shall provide functionality to allow for the partial receipt of an inventory delivery IN-10
1271 The system shall provide functionality to automatically add approved requisitions to a list of IN-10
requisitions awaiting fulfillment
1272 The system shall provide functionality to maintain a list of all approved requisitions awaiting IN-10
fulfillment with information including, but not limited to the following:
- Date requisition was received
- Expected date of fulfillment
- Requesting agency/location
1273 The system shall provide functionality to suggest alternates to inventory stock items when IN-10
requested inventory items are insufficient to fulfill the requisition
1274 The system shall provide functionality to allow for partial fulfillment of inventory requisitions IN-10
1275 The system shall provide functionality to prioritize partially fulfilled requisitions to the top of IN-10
the requisitions awaiting fulfillment list
1276 The system shall provide functionality to automatically close a requisition upon the receipt of IN-10
an inventory delivery
1277 The system shall provide functionality for users to control and reconcile inventory by: IN-20
- Establishing inventory levels and reorder points
- Maintaining designated critical levels of stock
- Monitoring stock levels
1278 The system shall provide functionality for users to obtain and report stock levels on demand IN-20
1279 The system shall provide functionality to calculate, record, store, and report price averaging IN-20
for stock on hand
1280 The system shall provide functionality for users to track consumption of fuel, gas, etc. IN-20
1281 The system shall provide functionality for users to track pharmaceuticals at the unit dose IN-20
level
1282 The system shall provide functionality to track physical location of inventoried items within IN-20
the warehouse, by bin numbers, aisle numbers, etc.
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 78 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1283 The system shall provide functionality to record and store inventory to an Item Master File IN-20
including, but not limited to:
- Supply center identifier
- Organization code
- Stock number
- Item description
- Unit of issue or measurement
- Unit price
- Inventory stock levels
- Storage standards (e.g., climate controlled, secured)
- Expiration date
- Hazardous material codes
- Location codes
- Reorder point and quantity
1284 The system shall provide functionality for users to determine when and where the count IN-20
sheets are printed
1285 The system shall provide functionality to produce count sheets that include the following IN-20
data elements including, but not limited to:
- Agency part number
- Manufacturer part number
- Bin number
- Description
1286 The system shall provide functionality to generate count sheets sorted by any data element IN-20
captured by the count sheets
1287 The system shall provide functionality to control whether or not the balances of the IN-20
inventoried items are reported on the count sheets
1288 The system shall provide functionality for users to enter physical count totals for inventory IN-20
items
1289 The system shall provide functionality to automatically adjust any discrepancies between the IN-20
physical count and the actual on-hand quantity
1290 The system shall provide functionality for users to record against a variance account for IN-20
Inventory adjustments
1291 The system shall provide functionality for users to suspend all inventory transactions during IN-20
the physical count period
1292 The system shall provide functionality for users to indicate the reason for an inventory IN-20
adjustment
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 79 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ASSET INVENTORY REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1293 The system shall provide an online inquiry that will list, for a specific item and location, the IN-20
history of the transaction details for that item including, but not limited to:
- The document/purchase order (or other transaction) number
- The accounting distribution information
- The type of transaction (receipt, issue, transfer, price adjustment, requisition, direct
delivery to a job site, etc.)
- Total cost
- Issuers
- Receivers
- Location
- Part number
- Location number
- Manufacturer(s) product number(s)
- Description
- Inventory unit of measure
- Weighted unit price
- Inventory replenishment lead days
- Bin number(s)
- Maximum/minimum levels
- Quantity on hand
- Quantity in-transit
- Quantity on order
- Quantity on backorder
- Quantity reserved
- Quantity available
1294 The system shall provide functionality to automatically calculate the following elements for IN-30
each item in each location including, but not limited to:
- Maximum inventory level
- Inventory replenishment lead days
1295 The system shall provide functionality to support rules, including seasonal factors, to IN-30
calculate for the following including, but not limited to:
- Maximum inventory level
- Inventory replenishment lead days
1296 The system shall provide functionality for users to create a single requisition for all items IN-30
that are less than or equal to the reorder point
1297 The system shall provide functionality to calculate the suggested order quantity based on IN-30
the difference between on hand quantity and maximum inventory level
1298 The system shall provide functionality to automatically generate a requisition for review IN-30
based on agency defined reorder level
1299 The system shall provide functionality for users to place limits on quantities issued based on IN-30
set criteria
1300 The system shall provide functionality to record backorders and generate notifications when IN-30
an item is restocked
1301 The system shall provide functionality to maintain retirement or replacement dates or IN-40
periods by inventory item (e.g., expiration dates, shelf-life)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 80 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1302 The system shall provide functionality to accommodate a primary grant record that provides GR-10
information for the grant overall
1303 The system shall provide functionality to identify each grant and maintain a primary grant GR-10
profile with at least 100 data fields, including, but not limited to:
- Grantor contact person’s name
- Grantor contact person's position
- Budget staff person(s)
- Fiscal staff person(s)
- Other staff person(s)
- Title of grant
- Grant number
- Description of grant
- Grant status
- Grant procurement record subject to OSC review
- Amount
- Funding source
- CFDA number
1304 The system shall provide functionality to accommodate at least 100 data fields in the GR-10
primary grant record to enter and save award information for each grant including, but not
limited to:
- Award amount
- Award date
- Award type (e.g., member item, M contract)
- Amended/Supplemental amount(s)
- Amended/Supplemental date(s)
- Allowable advances
- Payment basis (e.g., deliverables, reimbursement of expenditures)
- Non-cash award(s) (e.g., equipment, land, inventory supplies)
- Estimated value for non-cash award(s)
- Federal award number
- Indirect cap amount
- Terms and conditions
- Grant requirements
- Funding technique(s) for drawdown (e.g., percent based on a class of expenditures:
payroll, administrative, direct, indirect)
- Subject to CMIA (Cash Management Improvement Act) requirements signifier (Y/N)
- Identifier that the grant award is greater than $50,000
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 81 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1305 The system shall provide functionality to identify each prospective grantee and maintain a GR-10
secondary grant record with at least 100 data fields, including, but not limited:
- Grantee/sub-grantee organization name
- Grantee/sub-grantee contact person's name
- Grantee/sub-grantee contact person's position
- Grantee/sub-grantee contact person's fax number(s)
- Grantee/sub-grantee contact person's phone number(s)
- Grantee/sub-grantee contact person's email address(s)
- Grantee/sub-grantee contact person's address(s)
- DUNS number
- Grantee's/sub-grantee's website(s)
- Grant status
- Grant project start and end date
- Grant funding period start date
- Grant funding period end date
- Liquidation date
- Fiscal year
- Amount of previous grant
- Report type due
- Report frequency
- Report due date(s)
- Funding source(s)
- Amount from each funding source
- FEID number (federal employer identification number)
- Statewide grant award number
- Agency -specific grant award number
- Women/Minority Business Enterprise code
- Grant subject to prompt contracting requirements
- Grant procurement record subject to OSC review
1306 The system shall provide functionality for users to configure at least 100 data fields in the GR-10
secondary grant record to enter and save award information for each grant including, but not
limited to:
- Award amount
- Award date
- Award type (e.g., member item, M contract)
- Amended/Supplemental amount(s)
- Amended/Supplemental date(s)
- Allowable advances
- Payment basis (e.g., deliverables, reimbursement of expenditures)
- Non-cash award(s) (e.g., equipment, land, inventory supplies)
- Estimated value for non-cash award(s)
- Federal award number
- Indirect cap amount
- Terms and conditions
- Grant requirements
- Funding technique(s) for drawdown (e.g. percent based on a class of expenditures: payroll,
administrative, direct, indirect)
- Subject to CMIA requirements signifier (Y/N)
- Identifier that the grant award is greater than $50,000
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 82 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1307 The system shall provide functionality to define the status and sub-status of a grant in the GR-10
primary grant record by categories including, but not limited to:
- Application under development
- Under development
- Level 1 review
- Level 2 review
- Application posted/provided to grantee
- Closed
1308 The system shall provide functionality to define the status of a grant in the secondary grant GR-10
record by categories including, but not limited to:
- Application under development
- Application posted/provided to grantee
- Application received
- Application under review
- Application approved
- Contract under development
- Awarded
- Denied
- Suspended (e.g., pending litigation)
- Closed
1309 The system shall provide functionality to automatically update the status of a grant record GR-10
based on business rules and/or events
1310 The system shall provide functionality to create a unique grant number and sub-grant GR-10
number, if necessary, for each grant
1311 The system shall provide functionality for users to manually enter a unique grant number GR-10
and sub-grant number, if necessary, for each grant
1312 The system shall provide functionality for users to edit and update the grant record and GR-10
capture all edits and updates in an electronic audit trail including, but not limited to:
- Time stamp indicating when the change was made
- User ID of the person who made the change
- Field altered
- Value in the field before it was altered
- Value in the field after it was altered
1313 The system shall provide functionality to save a grant record for a specified period of time GR-10
1314 The system shall provide functionality for users to copy key information from a previous GR-10
grant record and include it in a new grant record
1315 The system shall provide functionality for users to configure additional fields of at least 500 GR-10
characters to capture comments/narrative on all grant-related documents and fields
1316 The system shall provide functionality for users to identify which categories in the grant GR-10
record are required and which are optional
1317 The system shall provide functionality for users to establish business rules to indicate when GR-10
a field in the grant record is required and/or optional
1318 The system shall provide functionality to automatically update an identifier in the primary GR-10
grant record if a data field in a secondary grant record exceeds or meets a value
1319 The system shall provide functionality to allow the effective date for a grant to span multiple GR-10
fiscal years
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 83 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1320 The system shall provide functionality for users to edit the effective date associated with a GR-10
grant
1321 The system shall provide functionality for users to upload grant-related document templates GR-10
1322 The system shall provide functionality for users to create grant-related document templates GR-10
1323 The system shall provide functionality for users to edit and save grant-related document GR-10
templates
1324 The system shall provide functionality for users to categorize templates (e.g., Approved by GR-10
OSC, member-item template)
1325 The system shall provide functionality for users to search for templates based on criteria GR-10
1326 The system shall provide functionality for users to select sections and items from the grant- GR-10
related templates to include or not include in the user’s document
1327 The system shall provide functionality to restrict users from accessing competitive grant GR-10
applications that have been submitted by the grantee until a specified date
1328 The system shall provide functionality for users to collaboratively create grant-related GR-10
documents
1329 The system shall provide functionality for users to close specific sections of grant-related GR-10
documents to prevent user modification during the collaboration process
1330 The system shall provide functionality for users to define participants for collaborative GR-10
creation of grant-related documents
1331 The system shall provide functionality for users to define participants for collaborative GR-10
creation that are internal to the agency and external to the agency
1332 The system shall provide functionality to save versions of grant-related documents during GR-10
collaborative online creation
1333 The system shall provide functionality to restrict multiple users from making updates to the GR-10
same section of a grant-related document at the same time
1334 The system shall provide functionality to track the edits made to a grant-related document GR-10
1335 The system shall provide functionality to notify users when other users make edits to a grant- GR-10
related document under creation
1336 The system shall provide functionality for users to create multiple types of applications GR-10
based upon the applicant type
1337 The system shall provide functionality to identify grant-related documents that are submitted GR-10
after a deadline
1338 The system shall provide functionality for a countdown clock, henceforth referred to as a GR-10
prompt contracting clock, that displays the number of days left before a contract must be
completed and signed
1339 The system shall provide functionality for users to define the circumstances that warrant the GR-10
use of the prompt contracting clock and the circumstances that do not require it
1340 The system shall provide functionality for users to define the number of days included in the GR-10
prompt contracting clock countdown
1341 The system shall provide functionality for users to repeatedly suspend and reactivate a GR-10
prompt contracting clock in the secondary grant record
1342 The system shall provide functionality for users to turn on a clock based on specific events GR-10
1343 The system shall provide functionality for users to turn off a clock based on specific events GR-10
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 84 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1344 The system shall provide functionality to track the number of days on the prompt contracting GR-10
clock
1345 The system shall provide functionality to track the number of days a clock has been turned GR-10
off
1346 The system shall provide functionality to create electronic notifications at specific periods GR-10
before the grant award end dates
1347 The system shall provide functionality for users to create a calendar for the grant process GR-10
and link tasks to the calendar
1348 The system shall provide functionality for users in different agencies to create different grant GR-10
calendars and link different tasks to the calendar including, but not limited to:
- Deliverable due from the grantee
- Audit to be performed at the grantee site
- State and federal reporting dates
1349 The system shall provide functionality to notify users via email or workflow when a grant GR-10
calendar is established
1350 The system shall provide functionality for users to edit the grant calendar throughout the GR-10
year
1351 The system shall provide functionality to notify users via email or workflow when a grant GR-10
calendar is modified
1352 The system shall provide functionality to accommodate secondary level grant records GR-20
associated with each organization that submits an application for the grant
1353 The system shall provide functionality to accommodate an unlimited number of secondary GR-20
grant records for each primary grant record
1354 The system shall provide functionality for users to set up a unique analysis and scoring GR-20
approach for each grant
1355 The system shall provide functionality for users to define the steps and rules used to GR-20
calculate scores for each grant application
1356 The system shall provide functionality for users to save a description of how evaluators GR-20
should evaluate a particular section/item of an application and attach it to each section
1357 The system shall provide functionality for users to enter, edit, and save scores for GR-20
competitive grants
1358 The system shall provide functionality for users to save one score for each evaluation GR-20
section
1359 The system shall provide functionality for users to save multiple scores for each evaluation GR-20
section
1360 The system shall provide functionality to calculate the sum or average of all scores in each GR-20
section of the grant based on specified rules
1361 The system shall provide functionality for users to develop separate scoring rules for each GR-20
round of scoring when multiple scores are entered for an individual evaluation section
1362 The system shall provide functionality for users to define access rules to restrict certain GR-20
users from viewing other users' scores
1363 The system shall provide functionality to assign a unique ID number to each evaluator GR-20
1364 The system shall provide functionality to identify evaluators by their evaluator ID rather than GR-20
name to protect the evaluator's identity
1365 The system shall provide functionality for users to attach scoring documents to a grant GR-20
record for competitive grants
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 85 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1366 The system shall provide functionality for users to create business rules in order for the GR-20
system to automatically calculate "scores" for information contained in the application
1367 The system shall provide functionality to create a summary report of the scores based on GR-20
users’ specified needs
1368 The system shall provide functionality for multiple agencies to make awards from a primary GR-20
grant record
1369 The system shall provide functionality for multiple agencies to approve an award before it is GR-20
awarded to a recipient
1370 The system shall provide functionality for users to categorize each grant record's GR-20
attachments (e.g., application documents, grant application package document)
1371 The system shall provide functionality for users to link multiple grants to a project GR-40
1372 The system shall provide functionality for users to link multiple projects to a grant GR-40
1373 The system shall provide functionality for users to link multiple grants to an appropriation GR-40
1374 The system shall provide functionality for users to link multiple appropriations to a grant GR-40
1375 The system shall provide functionality for users to establish grant-specific budget control in GR-40
multiple formats including, but not limited to the following:
- Grant year
- Grant award amount
- Beginning and end date
1376 The system shall provide functionality for users to establish grant-specific budget control GR-40
periods that are different from the appropriation control period
1377 The system shall provide functionality to budget and report by grant GR-40
1378 The system shall provide functionality for users to create a grant's budget at a higher level in GR-40
the data structure than expenditures and encumbrances are recorded
1379 The system shall provide functionality for users to control a grant's budget at a higher level GR-40
in the data structure than expenditures and encumbrances are recorded
1380 The system shall provide functionality for users to enter and save expenditure-based GR-40
spending projections for each grant at any level in the data hierarchy (including the chart of
accounts)
1381 The system shall provide functionality for users to enter and save expenditure-based GR-40
spending projections for each grant for different time periods (e.g., annually, quarterly,
monthly)
1382 The system shall provide functionality for users to enter and save disbursement-based GR-40
spending projections for each grant at any level in the chart of accounts
1383 The system shall provide functionality for users to enter and save disbursement-based GR-40
spending projections for each grant for different time periods (e.g., annually, quarterly,
monthly)
1384 The system shall provide functionality for users in different agencies to create and save GR-40
disbursement-based spending projections for a grant at different levels in the chart of
accounts
1385 The system shall provide functionality for users to simultaneously load and save both GR-40
expenditure-based and disbursement-based spending projections for a grant
1386 The system shall provide functionality to create disbursement-based spending projections GR-40
for a grant based on the expenditure-based spending projections using customized business
rules
1387 The system shall provide functionality for users to edit the spending projections over the GR-40
course of the grant cycle
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 86 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1388 The system shall provide functionality for users to link and track all financial transactions to GR-40
a grant
1389 The system shall provide functionality to restrict a grant transaction from being processed if GR-40
the transaction exceeds the grant award amount
1390 The system shall provide functionality to record encumbrances against a grant GR-40
1391 The system shall provide functionality to record expenditures against a grant GR-40
1392 The system shall provide functionality to restrict grant-related expenditure transactions that GR-40
took place outside of the specified grant period
1393 The system shall provide functionality for users to override the grant expenditure transaction GR-40
controls
1394 The system shall provide functionality to record refunds of an expenditure against a grant GR-40
1395 The system shall provide functionality to alert specified users of a refund of expenditure GR-40
against a grant
1396 The system shall provide functionality for users to suspend a grant prior to completion and GR-40
hold all additional financial transactions against the grant
1397 The system shall provide functionality to save projected and actual non-financial, GR-40
performance measures and associated data at any level of the data structure
1398 The system shall provide functionality to display the total value of a grant's appropriation(s) GR-40
1399 The system shall provide functionality to display a financial dashboard that summarizes the GR-40
financial balances associated with each grant including, but not limited to:
- Award amount
- Encumbrances/obligations
- Expenditures
- Disbursements
- Uncommitted funds
1400 The system shall provide functionality to display the amount of current outstanding GR-40
encumbrances recorded against the grant
1401 The system shall provide functionality to display the amount of life-to-date expenditures GR-40
recorded against the grant
1402 The system shall provide functionality to display the amount of life-to-date disbursements GR-40
recorded against the grant
1403 The system shall provide functionality for users to close a grant upon completion of a grant GR-50
cycle
1404 The system shall provide functionality for users to reopen closed grants GR-50
1405 The system shall provide functionality for users to view closed grants GR-50
1406 The system shall provide functionality for users to generate reports for closed grants GR-50
1407 The system shall provide functionality for users to liquidate encumbrances after a grant GR-50
period’s end date has passed but before its liquidation period end date passes
1408 The system shall provide functionality to alert users when they decrease the grant award to GR-50
an amount lower than the committed balance
1409 The system shall provide functionality to save grant data, without irrevocably condensing or GR-50
summarizing any level of detail for a agency-defined or state-defined period of time
1410 The system shall provide functionality for users to condense or summarize grant-related GR-50
documents
1411 The system shall provide functionality for users to selectively condense or summarize grant- GR-50
related documents
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 87 of 111
New York Financial Management System (NYFMS) Exhibit E.5
GRANTOR REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1412 The system shall provide functionality to save electronic copies of all grant documents and GR-50
attachments for audit purposes
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 88 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1413 The system shall provide functionality to create a unique project ID number and/or WBS PA-10
element for each project
1414 The system shall provide functionality to automatically create project ID numbers PA-10
1415 The system shall provide functionality for users to create projects via a batch PA-10
upload/interface
1416 The system shall provide functionality for users to create sub-projects and/or phases at the PA-10
detailed level required by an agency to manage its project
1417 The system shall provide functionality for users to create a project profile for each project PA-10
including, but not limited to:
- Project status (e.g., pending, active, completed, cancelled)
- Project name
- Project description
- Project summary
- Location
- Location description
- County code
- Project start and end dates
- Other project identifier (e.g., federal project ID number)
- Restrictions on assets acquired from the project
- Default allocation method
- Default billing method
1418 The system shall provide functionality for users to record and save multiple contacts and PA-10
associated information for a project including, but are not be limited to:
- Contact type
- Contact’s name
- Contact’s office name
- Contact’s address
- Contact’s phone number
- Contact’s fax number
- Contact’s web address
- Contact's email address
- Comment field
1419 The system shall provide functionality to accommodate a project structure that supports PA-10
agency requirements for federal and state funding including, but not limited to:
- Project ID
- Project type
- Project category
- Sub-project/phase
- Project task identifier (used to segregate transactions/documents for a project, sub-project,
or phase)
- Bondable or non-bondable
- Taxable or tax-exepmt bonds
- State vs. Federal match
1420 The system shall provide functionality for users to enter and save the project ID, sub-project, PA-10
phase, task and/or activity on any transaction
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 89 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1421 The system shall provide functionality for users to enter and save a schedule for the phases, PA-10
tasks and activities to occur within each project or sub-project
1422 The system shall provide functionality for users to define their own geographic definitions PA-10
associated with a project or sub-project
1423 The system shall provide functionality for users to identify all projects with a status PA-10
1424 The system shall provide functionality for users to identify one or more funding source for PA-10
each project, sub-project, or phase
1425 The system shall provide functionality to manually override or edit system generated project PA-10
IDs
1426 The system shall provide functionality to associate a project, phase, or sub-project to a grant PA-10
1427 The system shall provide functionality to associate a project, phase, or sub-project to one or PA-10
more funding sources
1428 The system shall provide functionality for users to create and save project templates that PA-10
can be used to expedite the creation of a project
1429 The system shall provide functionality for users to establish a funding record subsequent to PA-10
the commencement of a project
1430 The system shall provide functionality for users to edit project information after the project PA-20
begins
1431 The system shall provide functionality for users to identify project funding source(s) PA-20
throughout the life of the project including, but not limited to:
- Fund/Subfund
- Program
- Appropriation
- Appropriation year
- Fund amount
- Bonded or non-bonded
- Taxable or tax-exempt bonds
- Date funds will be available
- Agency
- State vs. Federal funding
1432 The system shall provide functionality for users to enter, save, and track data associated PA-20
with the project, sub-project, or phase. This data includes, but is not limited to:
- Deliverable/milestone
- Date for deliverable/milestone
- Value for the deliverable/milestone
1433 The system shall provide functionality for users to create a detailed project budget at the PA-20
sub-project and/or phase level(s)
1434 The system shall provide functionality for users to enter project budget detail for a specific PA-20
time period, fund, etc.
1435 The system shall provide functionality to control project spending at the lowest level of detail PA-20
provided in the project budget
1436 The system shall provide functionality for users to establish hard budgetary spending PA-20
controls which will prevent unapproved transactions from being processed against the
project
1437 The system shall provide functionality for users to establish tolerance budgetary spending PA-20
controls that will generate system warning messages when transactions are processed
against a project
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 90 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1438 The system shall provide functionality for users to remove project budgetary controls which PA-20
allows all transactions to be processed against a project without any warning messages
1439 The system shall provide functionality to ensure that all monies budgeted for a specific PA-20
project cannot be utilized for other capital projects
1440 The system shall provide functionality for the ability for separate line item contingencies to PA-20
be included in the project budget
1441 The system shall provide functionality for users to enter project creation date PA-20
1442 The system shall provide functionality to identify and track earmarks (specified use of funds PA-20
within a capital appropriation) within the line item project detail
1443 The system shall provide functionality to automatically update a project’s status based upon PA-20
agency approval or denial
1444 The system shall provide functionality to restrict spending activity on a project until PA-20
appropriate funds have been allocated and its status has been changed to "approved"
1445 The system shall provide the ability for users to create a project budget to match the total PA-20
amount of funding sources that have been allocated for that project
1446 The system shall provide functionality for users to edit the detailed project structure PA-20
including the addition or deletion of sub-projects and/or phases of work at any time
1447 The system shall provide functionality to generate a list of approved projects, their PA-20
respective budgets, and funding sources
1448 The system shall provide functionality to transfer all related historical data within NYFMS PA-20
when a project is restructured
1449 The system shall provide functionality to capture various dates associated with a project PA-20
including, but not limited to:
- Approval date(s)
- Effective date(s)
- Overall authorization period with start date and end date that can span multiple years
- Authorization date for a project and phase
- Agreement date that indicates when funding is committed and eligible costs can be billed
(This date should be validated in the context of the authorization date above.)
1450 The system shall provide functionality for users to enter and report budget information by PA-30
project, phase, or sub-project
1451 The system shall provide functionality for users to enter and report actual costs by project, PA-30
phase, or sub-project
1452 The system shall provide functionality for users to enter and report actual versus budget PA-30
variance by project, phase, or sub-project
1453 The system shall provide functionality for users to enter and save statistical information that PA-30
may be used to measure a project including, but not limited to:
- Unit of measure (e.g., number of full time equivalents, acres, square feet)
- Unit of measure value
- Percentage of completion at a specific date
- FTEs
-Work hours to date
1454 The system shall provide functionality for users to enter and save federal matching PA-30
requirements for a project including, but not limited to:
- Match type (e.g., cash, in-kind services, donated equipment, donated land)
- Match rate and basis (e.g., expenditure type)
- Comment/summary field
- Match restrictions on non-cash items (e.g., use/sale of land, equipment, buildings)
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 91 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1455 The system shall provide functionality to link an asset and the project(s) for which the asset PA-30
was acquired
1456 The system shall provide functionality to identify all transactions and documents that have PA-30
been billed for a project
1457 The system shall provide functionality to validate that project billings do not exceed the PA-30
reimbursable budget and release amounts
1458 The system shall provide functionality to generate an invoice based upon the reimbursement PA-30
of costs for a project or group of projects
1459 The system shall provide functionality for users to create and save a default billing method PA-30
for a project, phase, or sub-project
1460 The system shall provide functionality to generate a project invoice based upon PA-30
expenditures entered against a project
1461 The system shall provide functionality to generate a project invoice based upon PA-30
disbursements entered against a project
1462 The system shall provide functionality to create a receivables transaction upon the PA-30
generation of a project invoice
1463 The system shall provide functionality for users to correct transactions that were PA-30
inappropriately charged to the project
1464 The system shall provide functionality for users to enter project revenues, encumbrances, PA-30
expenditures, reimbursable budget, remaining balance, and amount billed for various time
periods including, but not limited to:
- Period to date
- Month to date
- Quarter to date
- Year to date
- Previous month to date
- Previous quarter to date
- Previous year to date
- Life to date
- Fiscal year
1465 The system shall provide functionality to drilldown on summary reports to the transaction PA-30
detail
1466 The system shall provide functionality for users to perform a system inquiry based upon data PA-30
elements within the project structure (e.g., list projects for a specific category or class)
1467 The system shall provide functionality for users to query and report all transactions and PA-30
documents entered against a project that are linked to a federal funding source (e.g., grant,
contract) for any time period specified by the users (e.g., federal fiscal year, state fiscal
year, life to date)
1468 The system shall provide functionality to perform system inquiries across multiple projects PA-30
for analysis and planning purposes
1469 The system shall provide functionality to track and report on amount of expenditures by PA-30
geography (e.g., county, legislative district, school district)
1470 The system shall provide functionality to track and report on amount of expenditures by PA-30
contractor type (e.g., prime vs. sub-contractors/suppliers, M/WBE)
1471 The system shall provide functionality to generate reports by project type (e.g., feasibility PA-30
studies, programs, buildings, infrastructure)
1472 The system shall provide functionality for users to track feasibility studies and other non- PA-30
capital project costs independently of a project
1473 The system shall provide functionality to track and report project budget and funding at each PA-30
milestone or deliverable, by funding source
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 92 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1474 The system shall provide functionality to report projected project costs over time to assist in PA-30
forecasting bond sale requirements
1475 The system shall provide functionality to report amounts or percentages complete by major PA-30
project component, phase or by Work Breakdown Structure (WBS) element
1476 The system shall provide functionality for users to enter costs and revenues (e.g., federal PA-30
reimbursement) at the project phase level and/or overall project level
1477 The system shall provide functionality to capture pre-encumbrances against a project upon PA-30
the creation of a requisition
1478 The system shall provide functionality to capture encumbrances against a project upon the PA-30
creation of a purchase order
1479 The system shall provide functionality to capture actual costs against the project associated PA-30
with the payment of vendor invoices
1480 The system shall provide functionality to report on pre-encumbrances entered against a PA-30
project
1481 The system shall provide functionality to report on encumbrances entered against a project PA-30
1482 The system shall provide functionality to report costs that have been entered against a PA-30
project including those entered via settlement, reposting, or allocation
1483 The system shall provide functionality for users to allocate overhead and other PA-30
miscellaneous charges to a project, sub-project, or phase through a journal entry or
allocation
1484 The system shall provide functionality to track all costs allocated or transferred to and from a PA-30
project, sub-project, or phase
1485 The system shall provide functionality to automatically update the General Ledger with PA-30
project transactions
1486 The system shall provide functionality to identify only new or modified transactions and PA-30
documents to be included in the next billing for a project
1487 The system shall provide functionality for users to define valid data combinations for posting PA-30
to the project, sub-project, or phase (e.g., define which organizations have authorization to
post to a particular fund)
1488 The system shall provide functionality to integrate project and cost accounting with other PA-30
functional areas including, but not limited to:
- Purchasing
- AP
- Inventory
- Fixed assets
- Fleet management
- General ledger
- Grantee
- Grantor
1489 The system shall provide functionality to charge a project for materials released from PA-30
inventory and capture information including, but not limited to:
- Material identifier
- Description
- Quantity
- Unit of measure
- Rate per unit
1490 The system shall provide functionality for users to identify equipment and formulate usage PA-30
charges to the project
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 93 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1491 The system shall provide functionality for users to formulate funding priorities when there PA-30
are multiple sources of reimbursement including: - 100% of one source is expended before
another source is expended - Sources are expended simultaneously based on percentage
allocations provided
1492 The system shall provide functionality for users to create a change order as a result of a PA-40
change in project scope and/or costs
1493 The system shall provide functionality to track the change orders processed against a PA-40
project for each contractor
1494 The system shall provide functionality to include change orders when reporting the PA-40
percentage complete by the contractor and/or project (e.g., cost and time)
1495 The system shall provide functionality to create and control a project budget at any level PA-40
within the data hierarchy
1496 The system shall provide functionality to automatically route change orders upon submission PA-40
to the appropriate level of agency management user for intra-agency approval
1497 The system shall provide functionality to automatically route change orders to different PA-40
and/or multiple levels of agency management based upon dollar thresholds
1498 The system shall provide functionality to automatically route change orders to the PA-40
appropriate control agency for approval once change orders have been approved by the
appropriate level(s) of agency management
1499 The system shall provide functionality for users to approve and release a change order PA-40
1500 The system shall provide functionality for users to reject a change order PA-40
1501 The system shall provide functionality to automatically update a project budget upon the PA-40
approval and release of one or more change orders
1502 The system shall provide functionality to send a system notification when a change order PA-40
has been approved
1503 The system shall provide functionality to send a system notification when a change order PA-40
has been denied
1504 The system shall provide functionality for users to edit the project budget after it has been PA-40
automatically updated (e.g. to reflect the approved change order)
1505 The system shall provide functionality for users to edit and resubmit a change order that has PA-40
been rejected by a control agency
1506 The system shall provide functionality to track and generate reports about change orders PA-40
that include various elements including, but not limited to:
- Type of change order
- Project
- Contractor
- Associate
- Price/amount of change order
- Impact on schedule
- Reason code
- Funding source
1507 The system shall provide functionality for users to monitor the status of project change PA-40
orders
1508 The system shall provide functionality for users to transfer budgeted funds between projects PA-40
or project categories according to user defined thresholds
1509 The system shall provide functionality to update the contract completion date based upon PA-40
any changes to the effective date on the change order
1510 The system shall provide functionality to track all projects associated with lapsing funds PA-40
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 94 of 111
New York Financial Management System (NYFMS) Exhibit E.5
PROJECT ACCOUNTING REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1511 The system shall provide functionality to automatically convert work in progress costs, PA-50
including labor, into a capitalized asset. This action will appropriately adjust general ledger
accounts and update the asset management module
1512 The system shall provide functionality for users to close a project at a specific level so that PA-50
all lower levels of the project will also be closed
1513 The system shall provide functionality for users to suspend a project or sub-project prior to PA-50
completion
1514 The system shall provide functionality for users to capitalize a portion of a project or project PA-50
asset prior to closing the project
1515 The system shall provide functionality to automatically alert users of unused funds upon PA-50
project completion and closing
1516 The system shall provide functionality to automatically generate notifications of open PA-50
contracts, requisitions, and/or purchase orders against a project prior to project closing
1517 The system shall provide functionality to send a notification to appropriate users when the PA-50
project status changes to "closed"
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 95 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1518 The system shall provide functionality to integrate with third party archiving solutions
Data Archiving
1519 The system shall provide functionality to archive transaction and non-transaction data within
Data Archiving
the application
1520 The system shall provide functionality to archive data to external media such as Serial ATA
Data Archiving
or optical disk systems
1521 The system shall provide functionality to interoperate with the EMC Centera content storage
Data Archiving
solution
1522 The system shall provide functionality to access archived data
Data Archiving
1523 The system shall provide functionality that preserves the original business context for
Data Archiving
archived data
1524 The system shall provide functionality to define multiple types of official electronic records
Data Archiving
1525 The system shall provide functionality to define multiple record retention policies
Data Archiving
1526 The system shall provide functionality to apply retention policies based upon record type
Data Archiving
1527 The system shall provide functionality to ensure that archived data will retain the security
Data Archiving
protections of the original data
1528 The system shall provide functionality to ensure that archived data will preserve e-
signatures and supporting transaction documentation (such as e-procurement Data Archiving
documentation)
1529 The system shall provide functionality to define disposition rules for archived information
Data Archiving
1530 The system shall provide functionality to optimize the use of different archival storage media
Data Archiving
based on the information retained
1531 The system shall provide functionality for archived data to be accessed and applied to
Data Archiving
transactional data as well as reporting data.
1532 The system shall include the ability to provide or integrate with data modeling tools to Data
facilitate data warehouse design Warehouse
1533 The system shall include the ability to provide or integrate with modeling tools to assess the Data
impact of prospective changes to the data warehouse design Warehouse
1534 The data warehouse software shall provide functionality to perform data transformations
Data
Warehouse
such as cleansing, validation, auditing, and semantic, structural, or format reconciliation
1535 The data warehouse software shall provide functionality to trace the lineage of transformed Data
data Warehouse
1536 The data warehouse software shall provide functionality to implement metadata
Data
Warehouse
management features such as semantic integration, metadata sharing, and synchronization
1537 The data warehouse software shall provide functionality to move data in batch or real-time Data
mode between various source and target systems Warehouse
1538 The data warehouse software shall provide functionality to deploy performance and capacity
Data
scaling strategies such as parallel processing, distributed processing, partitioning, and
Warehouse
caching
1539 The system shall provide functionality to seamlessly integrate with third party business Data
intelligence & reporting tools such as Business Objects, Cognos, or SAS Warehouse
1540 The system shall provide functionality to deploy multi-dimensional data structures Data
Warehouse
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 96 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1541 The system shall provide functionality to accept data from a variety of sources, formats, and Data
system platforms Warehouse
1542 The system shall provide functionality to integrate and capitalize on extraction and Data
transformation features offered by the vendor’s proposed EAI solution Warehouse
1543 The ETL software shall provide pre-built integration with the proposed solutions database Data
objects to extract, transform and load data Warehouse
1544 The ETL software shall contain pre-built connectors/adaptors to extract, transform and load Data
data from other systems including the CAS PeopleSoft system Warehouse
1545 The ETL software shall use open standards and utilize XML metadata interchange (XMI)to Data
exchange metadata from various heterogeneous systems Warehouse
1546 The ETL software shall provide features to create new routines to transform data Data
Warehouse
1547 The ETL software shall provide functionality to use scripting or other object-oriented Data
structured languages to define advanced transformation routines/procedures Warehouse
1548 The ETL software shall provide for the ability to validate and handle exceptions during Data
transformation Warehouse
1549 The ETL software shall provide a graphical environment to model the logical ETL process Data
Warehouse
1550 The ETL software shall allow allows users to specify chained transformations on the data Data
flow and apply complex scripted transformations to the data Warehouse
1551 The ETL software shall provide the ability to override the default source mapping and use Data
specific SQL statements Warehouse
1552 The ETL software shall provide for the ability to map data from multiple source systems (i.e.
Data
Warehouse
Oracle, DB2, Sybase, SQL Server) into multiple target source systems
1553 The ETL software shall include for the ability to change transformation output data in debug Data
mode Warehouse
1554 The ETL software shall provide for the ability to define and alter data refresh frequency and Data
methodology according to business needs Warehouse
1555 The ETL software shall provide for the ability to schedule and monitor the extraction, Data
cleansing, transformation, and loading processes Warehouse
1556 The ETL software shall provide for the ability to perform incremental loads, or take Data
advantage of pipelined and partitioned parallelism to meet acceptable timeframes Warehouse
1557 The system shall provide standard training courses that instruct in all major areas of
E Learning
functionality proposed
1558 The system shall provide training that has the same look and feel of the software proposed
E Learning
1559 The system shall provide for the ability to customize content to include New York State
E Learning
terminology
1560 The system shall provide for the ability to customize content to include New York State
E Learning
business practices
1561 The system shall provide for the ability to tailor content to include customization and
E Learning
configuration options used by New York State
1562 The system shall provide end-user personalization capabilities to define course curriculum
E Learning
and track progress
1563 The system shall provide for the ability to tailor and centrally manage course curricula by
E Learning
role and track progress
1564 The system shall provide for the ability to align courses with on-the-job practices E Learning
1565 The system shall provide for the ability to print course materials E Learning
1566 The system shall provide for the ability to perform post evaluation and assessments of
E Learning
participant knowledge
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 97 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1567 The system shall provide self-guided and self-paced training E Learning
1568 The system shall provide a simulation environment (one dedicated to training) that guides
E Learning
users through tasks
1569 The system shall provide a simulation environment that allows users to control the task
E Learning
1570 The system shall provide a simulation environment that allows users to selectively repeat
E Learning
sections of training
1571 The system shall provide a simulation environment that gives context specific help E Learning
1572 The system shall provide a simulation environment that organizes content by subject matter
E Learning
1573 The system shall provide a simulation environment that allows self testing E Learning
1574 The system shall provide a simulation environment that gives access to on demand step by
E Learning
step instructions and how-to guides
1575 The system shall provide a simulation environment that allows users to complete practice
E Learning
exercises
1576 The system shall provide context specific help E Learning
1577 The system shall provide step by step instructions and how-to guides E Learning
1578 The system shall provide for the ability to attach/include related documents such as work
E Learning
instructions or reference documents
1579 The system shall provide functionality to implement data interfaces between NYFMS and Enterprise
Application
other agency and non-agency systems, including data mapping and transformation Integration
1580 The system shall provide functionality to interface with industry standard document imaging Enterprise
technology, including functionality to view those documents as attachments within the Application
system, and to define where the link to the document is triggered Integration
1581 The system shall provide functionality to integrate with third-party EAI tools Enterprise
Application
Integration
1582 The system shall provide functionality to consolidate master records from multiple data Enterprise
Application
sources into a single copy of clean and harmonized master data Integration
1583 The system shall provide functionality to distribute master data records of appropriate type Enterprise
Application
and format based on characteristics of the destination systems Integration
1584 The EAI software shall provide functionality to implement metadata management features Enterprise
Application
such as semantic integration, metadata sharing, and synchronization Integration
1585 The EAI software shall provide functionality to synchronize data between systems in real Enterprise
Application
time, batch mode, or in near time (such that the latency experienced by users is minimal) Integration
1586 The system shall provide functionality to define business rules that drive the data Enterprise
Application
synchronization process Integration
1587 The EAI software shall provide functionality to perform data transformation functions such Enterprise
Application
as cleansing, validation, auditing, and semantic, structural, or format reconciliation Integration
1588 The system shall provide functionality to implement transaction management strategy Enterprise
between NYFMS and the new CAS to not only ensure transaction integrity and logical Application
completion and consistency, but also to provide transaction roll-back Integration
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 98 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1589 The system shall provide functionality to orchestrate fully formed business process flows Enterprise
Application
between NYFMS and the NEW CAS Integration
1590 The system shall provide pre-configured connectors, APIs, and wrappers to provide Enterprise
Application
connectivity to external systems Integration
1591 The system shall provide functionality to centrally manage the EAI components Enterprise
Application
Integration
1592 The system shall provide the ability to be independent of connecting platform and language Enterprise
Application
implementations Integration
1593 The system shall provide functionality to synchronize master data in near real-time Enterprise
Application
Integration
1594 The system shall provide functionality to register and administer master data Enterprise
Application
Integration
1595 The system shall provide functionality to manage chart of accounts, business partner Enterprise
Application
(vendors, bidders), and personnel data as master data Integration
1596 The system shall provide functionality to allow multiple data owners to contribute their data Enterprise
Application
to a single authoritative master data source Integration
1597 The system shall provide functionality to handle errors and exceptions that may occur as Enterprise
Application
part of integration and interface operations Integration
1598 The system shall provide functionality to define and implement standardized interfaces to Enterprise
Application
external systems Integration
1599 The system shall provide functionality to track the status of transaction processing that Enterprise
Application
occurs over an interface Integration
1600 The system shall provide functionality for scheduling and monitoring integration and Enterprise
Application
interface processing Integration
1601 The system shall provide functionality to automatically reconcile data between all proposed Enterprise
Application
solution components Integration
1602 The system shall provide functionality to prevent transactions that would introduce a data Enterprise
Application
discrepancy between application components Integration
1603 The system shall provide functionality to incorporate the use of common business logic in Enterprise
Application
transaction exchanges with the CAS PeopleSoft system Integration
1604 The system shall provide functionality to ensure that accounting transactions (and other Enterprise
general ledger transactions) are accurately reflected in both NYFMS and the CAS Application
PeopleSoft system to keep the systems synchronized and in balance Integration
1605 The system shall provide functionality to preserve the lowest level of transaction detail in the Enterprise
event that the proposed software and the CAS PeopleSoft systems use the same chart of Application
accounts model but at different levels of detail Integration
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 99 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1606 The system shall provide functionality to provide specific controls (e.g. header and trailer Enterprise
records with total number of transactions and total dollar amounts, hash totals, check digits) Application
to ensure accurate data transfers Integration
1607 The system shall provide functionality to use master data to validate inbound and outbound Enterprise
Application
interface transactions Integration
1608 The system shall provide functionality for the proposed EAI solution to track the propagation Enterprise
Application
of errors with complete audit trails Integration
1609 The system shall provide functionality for EAI transaction errors to be uniquely numbered Enterprise
Application
and to include a clear definition of the error Integration
1610 The system shall provide functionality for EAI error notifications to be sent based on user Enterprise
Application
defined criteria Integration
1611 The system shall provide functionality for EAI exception data to be automatically routed to a Enterprise
Application
logging utility Integration
1612 The system shall provide functionality to handle EAI errors differently based on high level Enterprise
Application
classifications of error categories (such as programming errors or resource errors) Integration
1613 The system shall provide functionality to generate electronic responses to source agency Enterprise
systems regarding the number and dollar amount of EAI transactions successfully Application
processed Integration
1614 The system shall provide functionality to generate electronic responses to source agency
Enterprise
systems regarding the number and dollar amount of EAI transactions rejected, and detail of Application
Integration
rejected transactions including a clear and succinct description of the reason for rejection
1615 The system shall provide EAI functionality that does not rely on proprietary protocols Enterprise
Application
Integration
1616 The system shall provide EAI functionality to support a number of standards, data formats, Enterprise
Application
and transaction protocols Integration
1617 The system shall provide EAI functionality that is based on a service-oriented architecture Enterprise
Application
Integration
1618 The system shall provide functionality for application exit points for integration with external Enterprise
Application
systems Integration
1619 The system shall provide EAI functionality that provides a choice of batch, real-time, or near Enterprise
Application
real-time modes of operation Integration
1620 The system shall provide EAI functionality that leverages network level protocols to ensure Enterprise
Application
secure and reliable delivery of data Integration
1621 The system shall provide functionality that ensures the identity of cross-system workflow Enterprise
Application
process actors may be validated without repudiation Integration
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 100 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1622 The system shall provide EAI functionality to ensure that application messages are Enterprise
Application
acknowledged and sequenced Integration
1623 The system shall provide EAI functionality to automatically recover from infrastructure or Enterprise
Application
application failures Integration
1624 The system shall provide EAI functionality to automatically correct common errors Enterprise
Application
Integration
1625 The system shall provide EAI functionality to enable application services that perform Enterprise
Application
specific functions, do not overlap in functionality, and only operate on specific data Integration
1626 The EAI architecture shall ensure that modifications to underlying system applications do Enterprise
Application
not necessitate revisions to EAI services Integration
1627 The system shall provide EAI functionality to allow application services to be reused by a Enterprise
Application
number of business processes Integration
1628 The system shall provide EAI functionality to combine application services to form new Enterprise
Application
business processes Integration
1629 The system shall provide EAI functionality for applications to register and locate services Enterprise
Application
Integration
1630 The system shall provide EAI functionality that allows application services to be Enterprise
implemented with predefined quality of service levels that may vary depending on the Application
function or process involved Integration
1631 The system shall provide the ability to integrate MDM functions with NYFMS as well as the Enterprise
Application
CAS PeopleSoft system Integration
1632 The MDM software shall provide functionality to perform master data cleansing and Enterprise
Application
validation Integration
1633 The MDM software shall provide functionality to perform transformation and semantic Enterprise
Application
reconciliation of master data Integration
1634 The MDM software shall provide functionality for master data profiling and change impact Enterprise
Application
analysis Integration
1635 The MDM software shall provide functionality to implement master data management roles Enterprise
Application
Integration
1636 The MDM software shall provide functionality to support master data lifecycle processes Enterprise
Application
(create, modify, delete) Integration
1637 The MDM software shall provide the ability for approvals in master data lifecycle processes Enterprise
Application
to be workflow driven Integration
1638 The system shall provide functionality to perform master data status and inventory reporting Enterprise
Application
Integration
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 101 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1639 The system shall provide functionality to manage and administer the MDM infrastructure Enterprise
Application
Integration
1640 The system shall provide functionality to synchronize master data with agency systems in a Enterprise
Application
mode consistent with the agency system capabilities Integration
1641 The system shall provide functionality to synchronize master data based on a pre-defined Enterprise
Application
schedule Integration
1642 The system shall provide the ability to run under the following operating systems: UNIX,
Infrastructure
LINUX (Suse), or a combination of the two
1643 The system shall provide the ability to operate in a three-tiered architecture environment
Infrastructure
1644 The system shall provide the ability to operate in a clustered computer environment Infrastructure
1645 The system shall provide the ability to use Oracle database management system software
Infrastructure
1646 The system shall provide functionality to integrate with a tool for estimating or calculating
Infrastructure
network bandwidth requirements
1647 The system shall support the ability to implement long-term storage and archival of historical
Infrastructure
information
1648 The system shall support the ability to implement a secondary instance of the software in a
Infrastructure
split mirrored environment
1649 The system shall provide functionality to generate performance information on the data
Infrastructure
storage at the volume level
1650 The system shall support open integration with leading storage vendors such as EMC, HP,
Infrastructure
IBM, SUN
1651 The system shall support the ability to operate with any type of storage mirroring (e.g., triple
Infrastructure
mirroring)
1652 The system shall support the ability to use a SAN for data storage Infrastructure
1653 The system shall provide functionality to store digital information assets such as images,
Infrastructure
recorded audio/video, streaming audio/video, PC- and Mac-based files
1654 The system shall support the ability to segregate data among storage repositories to meet
Infrastructure
performance demands or retention requirements
1655 The system shall support the ability to backup remote databases at a second data center or
Infrastructure
a disaster recovery site
1656 The system shall support the ability to perform database roll-back and roll-forward
Infrastructure
operations
1657 The system shall provide functionality to store data in a compressed format Infrastructure
1658 The system shall provide functionality to perform automated database problem diagnosis
Infrastructure
and status reporting
1659 The system shall provide functionality to perform automated database space tuning Infrastructure
1660 The system shall provide functionality to define an automated backup schedule Infrastructure
1661 The system shall provide functionality to perform a manual backup in the event a scheduled
Infrastructure
backup fails
1662 The system shall support the ability to perform incremental data backups Infrastructure
1663 The system shall support the ability to perform offline (cold) backups Infrastructure
1664 The system shall support the ability to perform online (hot) backups Infrastructure
1665 The system shall provide functionality for full recovery using backup data Infrastructure
1666 The system shall provide functionality to restore data from the point of failure Infrastructure
1667 The system shall provide functionality to select from multiple recovery points that are within
Infrastructure
a 12 hour period
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 102 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1668 The system shall support the ability to make copies of backup data Infrastructure
1669 The system shall support the ability to backup data from a split mirror of the database
Infrastructure
1670 The system shall provide functionality to set thresholds which generate event notifications or
alarms based on real time performance data. Thresholds may be manually or automatically Infrastructure
set based on historical trends
1671 The system shall support the ability to scale across all layers (presentation, application, and
Infrastructure
data) of the NYFMS three tier architecture to meet demand
1672 The system shall provide functionality to monitor file system performance through statistics
such as number of files created, file size, file checksum, compare files, available file Infrastructure
handles, and percent used file handles
1673 The system shall provide functionality to use monitoring tools to diagnose performance
problems, determine when database reorganization is required, increase the speed of
Infrastructure
reorganization, unload files and temporary indexes, and report statistical data such as
percent of migrated rows or perform pre-run analysis to check for data file space
1674 The system shall provide functionality to view free disk space and used disk space on a
Infrastructure
total and percent basis
1675 The system shall provide functionality to integrate with IBM Tivoli management software
Infrastructure
including the Tivoli Enterprise Console and Tivoli Workload Scheduler modules
1676 The system shall provide functionality for automatic notification via email and pager of
Infrastructure
system events or alerts that may require action
1677 The system shall provide functionality to schedule jobs to run automatically Infrastructure
1678 The system shall provide functionality to use a browser-based tool for system administration
Infrastructure
1679 The system shall include the functionality to provide or integrate with library (or program)
management software used to produce audit trails of program changes and maintain Infrastructure
program version numbers, creation date information, and copies of previous versions
1680 The system shall provide the ability for users in remote locations to access the system
Infrastructure
1681 The system shall support the ability to replicate system data and databases Infrastructure
1682 The system shall support the ability to perform synchronous and asynchronous data
Infrastructure
replication
1683 The system shall provide the ability to minimize the number of screen refreshes required to
Infrastructure
complete a transaction
1684 The system shall support the ability to implement multiple environments in the configuration
Infrastructure
and migration landscape
1685 The system shall provide functionality to manage the configuration & migration landscape
Infrastructure
1686 The system shall provide functionality to implement system change controls Infrastructure
1687 The system shall provide functionality to use a standard browser interface, (such as top tier
browsers like Netscape, Explorer, likely to already be deployed on agency desktops) with no Infrastructure
add-on software or plug-in necessary for a standard browser
1688 The system shall provide functionality for administrators to perform data recovery at the
Infrastructure
transaction, table, or system level
1689 The system shall provide functionality to ensure that data are logically consistent following
Infrastructure
system crash recovery
1690 The system shall provide functionality to link to multiple external systems such as those
Portal
based on Oracle, Peoplesoft, and SAP products
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 103 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1691 The system shall provide functionality to comply with open standards for portal
Portal
implementations such as JSR168 and WSRP
1692 The system shall provide functionality to support multiple languages/locals (e.g. double byte,
Portal
Cyrillic, etc.) in the interface
1693 The system shall provide functionality to integrate email with portal functions Portal
1694 The system shall provide functionality to implement search functions Portal
1695 The system shall provide functionality to support browsers of different versions and from
Portal
different vendors
1696 The system shall provide functionality to render data from a variety of source formats such
Portal
as PDF, HTML, XML, and XHTML
1697 The system shall provide functionality to allow personalization of individual portal
Portal
configurations/work environments
1698 The system shall provide functionality to support an interface with business intelligence
Portal
software
1699 The system shall provide functionality to support a modular framework of portal components
Portal
1700 The system shall provide a library of pre-build portal components Portal
1701 The system shall provide functionality for portal users to navigate within the application
Portal
without additional signons
1702 The system shall provide the ability for the portal to integrate with external systems without
Portal
compromising security controls
1703 The system shall provide functionality for users to generate reports by any element in the
Reporting
chart of accounts
1704 The system shall provide functionality for user-defined date ranges in all reports Reporting
1705 The system shall provide functionality for users to report on financial data in ad-hoc reports
Reporting
1706 The system shall provide functionality to create reports that can be converted to other
formats including but not limited to:
- PDF
Reporting
- HTML
- RTF
- XML
1707 The system shall provide functionality to create reports that can be exported to MS Office
Reporting
(e.g., Excel and Word) format
1708 The system shall provide functionality to save selected report views for future use by
Reporting
individual users or multiple users and by a single agency or multiple agencies
1709 The system shall provide functionality to distribute reports by a variety of methods such as
Reporting
email, web, fax, or PDA
1710 The system shall provide functionality to generate user-defined reports using an ad-hoc
Reporting
querying and reporting tool
1711 The system shall provide functionality to allow any inquiry available online to be printed
Reporting
1712 The system shall provide functionality to view reports as charts or in tabular format Reporting
1713 The system shall provide functionality to drill-in/drill-out amongst levels of detail in reports of
Reporting
tabular or chart format
1714 The system shall provide functionality for the user to incorporate formulas, functions, and
Reporting
mathematical calculations into reports
1715 The system shall provide functionality for the user to modify report formatting and
Reporting
presentation
1716 The system shall provide functionality to audit exports of report data or modifications to
Reporting
report definitions
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 104 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1717 The system shall provide functionality for the user to define calculations that incorporate
Reporting
values from multiple reporting dimensions
1718 The system shall provide functionality to generate and distribute reports based on events,
Reporting
process milestones, or predefined data thresholds
1719 The system shall provide functionality for users to generate ad-hoc reports using a standard
Reporting
querying and reporting tool
1720 The system shall provide functionality for users to modify the parameters, layout, and
Reporting
structure of reports
1721 The system shall provide functionality to "drill down" on a report to the transaction level
Reporting
detail
1722 The hardware or operating system that is required for the business intelligence/data
Reporting
warehouse/reporting tool must be the same as the ERP platform
1723 The business intelligence/data warehouse/reporting tool shall utilize the Oracle database
Reporting
platform proposed and not require its own proprietary database structures
1724 The business intelligence/data warehouse/reporting end user interface shall integrate with
Reporting
the proposed portal product without the loss of functionality
1725 The business intelligence/data warehouse/reporting end user interface shall not require a
Reporting
client installation
1726 The business intelligence/data warehouse/reporting toolset shall not require knowledge and
Reporting
training on its own proprietary language for normal usage by end-users
1727 The business intelligence/data warehouse/reporting toolset shall leverage standard based
Reporting
syntax to configure and customize objects
1728 The business intelligence/data warehouse/reporting toolset will provide strong monitoring
Reporting
and high control of resource utilization
1729 The security architecture of the business intelligence/data warehouse/reporting shall
Reporting
integrate with the NYSDS
1730 The business intelligence/data warehouse/reporting product shall leverage roles and
Reporting
security definitions that will be deployed for the main ERP product
1731 The business intelligence/data warehouse/reporting product provides robust security to
Reporting
control access at a data, cube, report or other data warehouse object level
1732 The business intelligence/data warehouse/reporting product shall leverage metadata in the
Reporting
end user experience to assist in the development of ad hoc queries/reports
1733 The business intelligence/data warehouse/reporting product architecture shall leverage
Reporting
open standards to enable the exchange of metadata with other systems
1734 The system shall provide functionality to integrate with the New York State Directory Service
Security
(NYSDS)
1735 The system shall provide functionality to operate in an environment consisting of a single or
Security
multiple LDAP directories
1736 The system shall include functionality to provide or integrate with technologies which allow
Security
for two factor authentication
1737 The system shall provide functionality for all security administration functions to be
Security
performed centrally
1738 The system shall provide functionality for selected security administration functions to be
Security
distributed to participating organizations
1739 The system shall provide functionality to limit access to security administration functions
Security
1740 The system shall provide functionality to add, change, and delete users, and designate
Security
users as inactive
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 105 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1741 The system shall provide functionality to determine, identify, and report inactive user
Security
accounts
1742 The system shall provide functionality to implement multiple security authorization levels
Security
1743 The system shall provide functionality to implement security controls at the application level
Security
1744 The system shall provide functionality to setup multiple user profiles Security
1745 The system shall provide functionality to implement standard “user profiles” from which
Security
individual user IDs may inherit privileges
1746 The system shall provide functionality to activate or deactivate user profiles Security
1747 The system shall provide functionality to assign users to groups and roles Security
1748 The system shall provide functionality to assign users appropriate access rights to the
application, sub-functions, menus, and data elements based upon their associated agency, Security
business unit, class, group, profile, or role
1749 The system shall provide functionality to allow or disallow the use of specific reporting
Security
capabilities
1750 The system shall provide functionality to implement security controls at these levels:
- Menu
- Transaction Security
- Row
- Field
1751 The system shall provide functionality to implement rule-based security by application
Security
function
1752 The system shall provide functionality to separately allow or disallow a user to schedule 'off-
Security
peak' processing
1753 The system shall provide functionality to set log-on attempts limits Security
1754 The system shall provide functionality to prescribe rules regarding acceptable passwords.
These rules shall include functionality to control:
- Password length
Security
- Allowable character combinations
- Reuse of passwords
- Password expiration
1755 The system shall provide functionality to record successful and unsuccessful attempts to
Security
obtain access to the system and data
1756 The system shall provide functionality to restrict the number of active sessions allowed for a
Security
single user
1757 The system shall provide functionality to display, upon log-on, the date and time the user
Security
last logged on to the system
1758 The system shall provide functionality to display a system banner message when a user
Security
logs on
1759 The system shall provide functionality to generate reports on user access to the application,
Security
server, and other system components
1760 The system shall provide functionality to maintain an audit trail of events, transactions, and
Security
data modifications
1761 The system shall provide functionality to log all transactions with external interfaces Security
1762 The system shall provide functionality to generate and view audit trails by selection criteria
Security
such as office, site, facility, and agency levels
1763 The system shall provide functionality to automatically generate alerts when security
Security
controls are violated
1764 The system shall provide functionality to run ALSEM (Audit Logging and Security Event
Security
Management) agents to allow security events to be harvested and monitored
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 106 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1765 The system shall provide functionality to encrypt data in conformance with Federal
Security
Information Processing Standard 140-2
1766 The system shall provide functionality for encryption of all data during the electronic
Security
transmission to non-NYFMS systems
1767 The system shall provide functionality to encrypt specific data at rest Security
1768 The system shall comply with SAML standards Security
1769 The system shall provide functionality to allow cross validation of sub-allocated funds
between two agencies without exposing data to an external agency that is not related to the Security
sub-allocaion
1770 The system shall provide functionality to align security controls with the organizational
Security
structure defined in the software chart of accounts
1771 The system shall provide functionality for users to view authorized summary data but not
Security
restricted detailed data
1772 The system shall provide functionality to save all incomplete transactions or records, at any
Usability
stage, for completion at a later time
1773 The system shall provide functionality for users to attach to any transaction, multiple
electronic files (documents and images), without restriction to size, including, but not limited
to:
- Scanned receipts Usability
- Supporting documentation
- Scanned image (e.g., drawings, bulletins)
- Amendment to a contract
1774 The system shall provide a common graphical user interface including, but not limited to:
- Pull-down menus
- Spell checking
- Ability to find, replace, and go-to within a transaction
- Keyboard equivalent for all menu options
- Use of a mouse for all commands
- Scrollable list boxes
Usability
- Cursor selection of items in scrollable list boxes
- Multiple windows that may be open at the same time
- Windows that can be minimized and maximized
- Built-in charting on all standard inquiries
- Drop-down menu list of open windows
- Ability to print windows or entire screens in a “user friendly” print format
- Print preview of each transaction
1775 The system shall provide an online help facility with capabilities including, but not limited to:
- Window level help
- Field level help
- Error message help
Usability
- Context sensitive help
- Windows hypertext help
- Indexed help
- Definable coaches, wizards, or tutors
1776 The system shall provide functionality for users to establish a descriptive profile for the
State's organization hierarchy containing information including, but not limited to:
- Organization addresses Usability
- Contact information
- User-defined fields for supplemental information
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 107 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1777 The system shall provide functionality to integrate (exchange data) with MS-Office software
including, but not limited to:
- Excel Usability
- Word
- Access
1778 The system shall provide functionality for users to view attachments in multiple formats of
common software programs including, but not limited to:
- Excel files
- Word files
- PowerPoint files
- Visio files Usability
- PDF files
- Notepad files
- Jpeg files
- HTML files
- Lotus 1-2-3 files
1779 The system shall provide functionality for users to both upload data and export data from
Usability
integrated project management software
1780 The system shall provide functionality for users to customize aspects of their screen layout
including, but not limited to:
- Establish custom menus
- Establish custom “go-to” buttons
Usability
- Color choices
- Fields displayed
- User specific default values
- Customizable toolbars
1781 The system shall provide functionality to clearly display the mandatory data entry fields
Usability
1782 The system shall provide functionality for users to view multiple screens simultaneously
Usability
while maintaining data and session integrity
1783 The system shall provide functionality to terminate a session after a pre-determined period
Usability
of inactivity
1784 The system shall provide functionality to accommodate multiple delivery options for all
system generated documents (e.g., vouchers, invoices, purchase orders, contracts)
including, but not limited to:
- Letter (printed for mailing)
- Email- Web posting Usability
- Electronic Data Interchange (EDI)
- Fax
- Extensible Markup Language (XML)
- Email attachment (spreadsheet or word processing document)
1785 The system shall provide functionality to fully integrate with email software such as Microsoft
Usability
Outlook, Lotus Notes, and GroupWise
1786 The system shall provide functionality to support the creation and use of electronic
Usability
signatures
1787 The system shall provide functionality to apply multiple electronic signatures to a document
Usability
or transaction
1788 The system shall provide functionality to validate and revalidate electronic signatures Usability
1789 The system shall provide functionality to maintain a record of electronic signature validation
Usability
in combination with the associated electronic document or transaction
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 108 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1790 The system shall provide functionality for users to create transactions for a fixed or
Usability
percentage allocation amount among multiple account codes
1791 The system shall provide functionality for users to pull forward account distributions and
other information from referenced documents (i.e. accounting codes from purchase order Usability
are pulled forward to any voucher that references the original purchase order)
1792 The system shall provide functionality for users to edit saved and posted
Usability
transactions/documents
1793 The system shall provide functionality to accommodate standard validation on all input fields
including, but not limited to:
- Data type validation (including highlighting fields that are incorrectly input and not allowing
Usability
use of inactive data elements)
- Range validation
- Format validation (including requiring a field of a specific length to be entered)
1794 The system shall provide functionality for users to copy previously saved transactions to a
Usability
new transaction
1795 The system shall provide functionality for users to perform mass updates to create, change,
Usability
or delete selected fields across multiple records
1796 The system shall provide functionality for users to establish and use quick codes (i.e. a short
code pulls forward an associated accounting distribution) to add account number information Usability
to transactions
1797 The system shall provide non-mandatory user-defined fields for the purposes of entering
Usability
miscellaneous data into a transaction
1798 The system shall provide functionality for either a system-assigned unique number or a user-
defined unique number for each transaction or document created in the system including,
but not limited to the following:
- Journal entries
- Including cost allocations
- Vouchers
- Invoices Usability
- Purchase orders
- Grants
- Requisitions
- Assets
- System
- Projects
1799 The system shall provide functionality for users to print the entire contents of any screen
Usability
1800 The system shall provide functionality to comply with the accessibility requirements specified
in Section 508 of the Federal Rehabilitation Act, and NY State standard S04-001 regarding
Usability
accessibility of State agency web based applications (S04-001 is available at
www.oft.state.ny.us)
1801 The system shall provide functionality to accommodate entering a specific data element only
Usability
once per transaction
1802 The system shall provide functionality to define unique date periods encompassing any
Usability
combination of day increments
1803 The system shall provide functionality to display descriptive and intuitive error messages
Usability
1804 The system shall provide functionality to establish, support, and validate pre-defined
combinations of data elements (i.e. appropriation and fund combinations, contract and Usability
program combinations, etc.). Invalid combinations should not be processed
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 109 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1805 The system shall provide functionality to support dependent conditions on data elements
that require the input of other data elements (i.e. object value requires input of project Usability
number)
1806 The system shall provide functionality to prevent the posting of a transaction unless all
components of the transaction pass data edits and validations (e.g. fund edits and Usability
validations).
1807 The system shall provide functionality for end users to undo a transaction they initiated by
Usability
mistake
1808 The system shall provide the ability to change the names of application objects and
attributes to be consistent with standard NY State terminology, including, but not limited to:
- Labels for data entry fields
- Report names Usability
- Report column headings
- Chart of account fields
- Organizational entities
1809 The system shall provide functionality to launch the system from within a workflow message
Workflow
or notification email
1810 The system shall provide functionality to implement end to end business process workflows
Workflow
that extend to external systems
1811 The system shall provide functionality to route electronic documents through a workflow and
Workflow
allow or disallow document editing at each workflow stage
1812 The system shall provide functionality to define lead and lag times between activities Workflow
1813 The system shall provide functionality to define dependencies between activities in a
Workflow
workflow
1814 The system shall provide functionality to maintain an audit trail of the transaction review and
Workflow
approval that occurred during an automated workflow
1815 The system shall provide functionality to perform transactions and other workflow functions
Workflow
via a portal interface
1816 The system shall provide functionality to perform workflow functions via a PDA interface
Workflow
1817 The system shall provide functionality for configurable rules-based automated notifications
including, but not limited to:
Workflow
- System alerts (e.g., pop-up windows)
- Automatically generated emails with variable narrative or appropriate web links
1818 The system shall provide functionality to accommodate rules-based automatic notifications
on events including, but not limited to:
- Pending approvals on a system transaction
- Aging of open invoice status
Workflow
- New budget version availability or release
- Status of prompt contracting calendar
- Collection of overdue debts
- Key milestone dates in RFP/contract process
1819 The system shall provide functionality for business partners to access the system from a
remote location using web-based self-service functionality and search for information
including, but not limited to:
- Order status Workflow
- Payment status
- Grant information
- Transaction history
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 110 of 111
New York Financial Management System (NYFMS) Exhibit E.5
ENTERPRISE TECHNICAL REQUIREMENTS
III. Sub IV. Mode of VI. Level VIII. Software Documentation
I. Req ID II. Requirement Description V. Comment/Explanation VII. Where in Software
Process ID Compliance of Effort Reference
1820 The system shall provide functionality to support the establishment of workflow by
transaction type including, but not limited to:
- Requisitions
- Purchase orders
- Contracts
Workflow
- Contract change orders and amendments
- Lease renewals
- Vouchers
- Budget adjustments based on cross appropriation level of detail
- Inter-agency transactions
1821 The system shall provide a reporting and/or inquiry tool that can report on the status of the
Workflow
transaction moving through workflow
1822 The system shall provide functionality for users to define time thresholds or parameters for
Workflow
each activity in a workflow
1823 The system shall provide functionality to enable users to define the sequence of activities
Workflow
that constitute a workflow transaction
1824 The system shall provide functionality to enable users to define concurrent activities within a
Workflow
workflow transaction
1825 The system shall provide functionality to support both sequential and concurrent approval
Workflow
processing in each module, based on predefined user configuration
1826 The system shall provide functionality for users to delegate approval authority for a defined
Workflow
time-period (e.g., vacations)
1827 The system shall provide functionality to establish, track, and monitor events and
Workflow
milestones (e.g., negotiation meetings, review dates, expiration dates, pricing updates, etc.)
1828 The system shall provide functionality to automatically send notifications of approaching key
Workflow
contract events to users
1829 The system shall provide functionality for users to "close" an contract event in the workflow
Workflow
upon its completion
1830 The system shall provide functionality to automatically send notifications to users if a
Workflow
contract event ages past the date on which it should be "closed"
ed32d41f-8e21-49b9-a471-2edbe5abc6b1.xls Page 111 of 111
Other docs by oan38723
RENDERED JANUARY 29 2010 10 00 A M TO BE PUBLISHED Commonwealth of Kentucky Court of Appeals
Views: 69 | Downloads: 0
