Attachment 3 - Requirements Traceability Matrix.xlsx
XLSX spreadsheet 98 KB Posted
- Attached to
- EPROCUREMENT SOLUTION State and local contract opportunity
- Solicitation number
- 5400020744
- Issued by
- South Carolina
About this file
This is a Requirements Traceability Matrix (RTM) for South Carolina's eProcurement Solution RFP, detailing comprehensive functional requirements across critical, preferred, and optional categories that bidders must address in their proposals. The RTM is organized into multiple workstreams including Vendor Portal, Vendor Enablement, Buyer Portal, Need Identification, Request through Pay, Catalog Capability, Sourcing/Bid Management, Contract Management, Purchasing/Data Analytics, General Functionality, and Integration & Data Conversion. Critical requirements span 282 individual specifications covering vendor self-registration and account management, purchase request and order development with workflow automation, solicitation management with online response capabilities, contract creation and administration, receiving and invoice processing, catalog management, performance analytics and reporting, and system security controls. Preferred requirements add 98 specifications for enhanced functionality such as vendor performance tracking, advanced search capabilities, online collaboration tools, mobile responsiveness, and administrative fee management. Optional requirements include 40 additional specifications for features such as PCard management and reconciliation, advanced catalog organization, and multi-unit-of-measure support. All requirements specify availability codes (out-of-the-box, configuration, customization, integration, third-party, business process change, or not available) and level of complexity (low, medium, high, or extreme effort hours).
The RTM establishes detailed evaluation criteria for bidder responses, requiring specific identification of proposed tools and solutions, detailed approach descriptions including benefits and limitations, current functionality availability with implementation timelines for unavailable features, and estimated work effort for each requirement. Integration and data conversion requirements mandate seamless integration between eProcurement workstreams and with the state's existing financial systems, including support for batch and real-time interfaces, data migration from legacy systems, and compatibility with Microsoft Office and Adobe products. Bidders must provide comprehensive technical specifications for system integration standards, state personnel authentication mechanisms, budget verification and encumbrance capabilities, and historical data conversion services. The requirements establish that the solution must support the South Carolina Consolidated Procurement Code, accommodate multiple state agencies and organizations with role-based access controls, maintain full audit trails and document retention compliance, and provide both internal and public-facing portals with transparency for procurement activities and contract information.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| Attachment L.2 - Service Provider Security Assessment Questionna.docx | DOCX document | |
| Solicitation.pdf | ||
| Attachment 6 - Local Spend.xlsx | XLSX spreadsheet | |
| Amendment #2.pdf | ||
| Award Extension Notice.pdf | ||
| Amendment #1.pdf | ||
| Attachment E - Service Level Agreement.pdf | ||
| Attachment 8 - Response to Vendor Questions Amend 2.docx | DOCX document | |
| Attachment 9 - Response to Vendor Question #14.docx | DOCX document | |
| Attachment 1 - Higher Education ERP Systems.xlsx | XLSX spreadsheet | |
| Attachment 7 - Purchase Orders (2019).xlsx | XLSX spreadsheet | |
| Attachment 4 Amend 1 - Cost Proposal Workbook.xlsx | XLSX spreadsheet | |
| Award Final Extension Notice.docx | DOCX document | |
| Attachment K - Representations.pdf | ||
| Attachment 5 - Current Active Contracts.xlsm | XLSM spreadsheet | |
| Attachment 2 - Data Flow.pptx | PPTX presentation |
Show all 16
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| South Carolina eProcurement Solution RFP | |
| Functional Requirements RTM | |
| Instructions for completing the Requirements Traceability Matrix (RTM) | |
| This workbook contains the detailed Functional Requirements associated with this RFP and are provided in addition to the requirements identified in the RFP. |
The workbook is organized with separate Tabs (Worksheets) for each category of requirements. Each set of requirements is categorized by eProcurement Workstream (reference RFP Attachment C) for additional detail.
| Tabs/Worksheets in this Workbook |
| 1. Instructions |
| 2. Critical- Each requirement should be met by the proposed solution. |
| 3. Preferred- Requirements are preferred and will be evaluated as detailed in Attachment M of the RFP. |
| 4. Optional- Requirements on this tab are optional and will be evaluated as detailed in Attachment M of the RFP. |
| 5. Integration & Data Conversion- This tab lists the requirements for interfaces and integrations that are needed between the eProcurement Workstream tools and/or other State systems and tools. It also addresses any data loads or conversions into the eProcurement tools from State systems or tools. Responses to these requirements will be evaluated as detailed in Attachemnt M of the RFP. |
| General Instructions |
| 1. Offerors must provide a specific response for every requirement on each Tab in the RTM. Resposnes such as "will comply" or "in compliance" and similar responses arenot considered a specific response. |
| 2. Offerors must provide details in every Response Column listed below. |
| 3. Response Columns: |
| · Offeror Proposed Tools and Solution (Column D): provide the specific name of the software/system and component/module that will be used to |
meet the requirement.
· Offeror Approach/Comments (Column E): describe how the identified tools/solution will meet the requirement. Include benefits or limitations. Also include details that clarify the Availability and Level of Complexity.
· Availability (Column F): identify the current availability of the functionality/capability proposed using the appropriate code or codes described in Table 1 below.
· Level of Complexity (Column G): indicate the work effort that will be required to implement or provide the proposed functionality/capability using the level of effort codes described in Table 2 below.
| Table 1: Availability Codes (Column F) |
| Instructions: Enter appropriate codes (one or more) to reflect current availability of proposed functionality/capability |
Valid values: A, D, C, INT, TP, BP, N as defined below:
| Availability Codes | Description |
| A - Out of the Box | Available in the core (“out-of-the-box”) solution |
| D - Configuration Item | Currently under development or entails moderate to significant configuration or complexity is moderate to very high. Bidders must indicate anticipated date of availability in Column E. |
| C - Customization/Extension | Not available in the core solution, but will be provided as customization or extension. Bidders must indicate anticipated date of availability in Column E. |
| INT - Integration/Interface | Requires an integration/interface to meet the requirement. Bidders must provide full description in Column E. |
| TP - Third Party/Other | Requires Third Party/Other Solution Component(s). Bidders must provide details of the Component(s) in Column E. |
| BP - Business Process | Requires additional or a change in State business processes to fully meet requirement. Bidders must provide details in Column E. |
| N - Not Available | No functionality available to meet the requirement. |
| Table 2: Level of Complexity Codes (Column G) |
| Instructions: Enter appropriate code to reflect Level of Complexity required to implement or provide the proposed |
functionality/capability
Valid values: L, M, H, or E as defined below:
| Level of Complexity | Description |
| L - Low | Accomplish the requirement with less than 40 hours |
| M - Medium | Accomplish the requirement within 41- 180 hours |
| H - High | Accomplish the requirement within 181- 500 hours |
| E - Extreme | Accomplish the requirement with over 500 hours |
| Bidder Note: Multiple FTEs are permitted to perform responsibilities to complete the State’s requirements, all hours in the above table represent total estimated work effort of the Contractor, regardless of actual Contractor staffing model. |
SC Critical Critical eProcurement Functional Requirements
| No. | Requirement Area | Requirement | Offeror Proposed Tools and Solution | Offeror Approach/Comments | Availability | Level of Complexity |
| Vendor Portal | The Vendor eProcurement Portal functionality acts as a personalized single point of entry ‘front door’ that provides access to all Vendor facing functions for the eProcurement solution with the ability to also incorporate access to other applications or services such as banking, invoicing and online interactions with the State. | |||||
| EPROC-SPR-1 | Vendor Portal | The Vendor eProcurement Portal functionality should provide an integrated Portal that includes all Vendor facing functions for the eProcurement solution. | ||||
| EPROC-SPR-2 | Vendor Portal | The ability to self-register and self-maintain an account for the eProcurement system. | ||||
| EPROC-SPR-3 | Vendor Portal | The ability to retrieve and review awarded purchase orders. | ||||
| EPROC-SPR-5 | Vendor Portal | Allow Vendor access to solicitations, both invited and all others. | ||||
| EPROC-SPR-6 | Vendor Portal | Ability to submit responses/proposals online for any active Solicitation. | ||||
| EPROC-SPR-7 | Vendor Portal | Ability to retrieve and review awarded contracts. | ||||
| EPROC-SPR-13 | Vendor Portal | Ability to submit updated contract price lists and catalogs for review and approval by the State. | ||||
| Vendor Enablement Workstream | ||||||
| EPROC-VDR-1 | Vendor Enablement | The Vendor Enablement functionality should provide a self-managed eProcurement Vendor registration ability for those seeking to participate in the State solicitation process. The Vendor data required will include at a minimum the following: | ||||
| EPROC-VDR-2 | Vendor Enablement | IRS official name and 'doing business as' name. | ||||
| EPROC-VDR-3 | Vendor Enablement | Headquarters address (with validation preferred) | ||||
| EPROC-VDR-4 | Vendor Enablement | Main telephone number, fax number, and email address. | ||||
| EPROC-VDR-5 | Vendor Enablement | All business locations with associated addresses to support situations where a Vendor has multiple order fulfillment locations or separate lines of business. | ||||
| EPROC-VDR-7 | Vendor Enablement | Parent/child relationship between Headquarters and other business locations. | ||||
| EPROC-VDR-8 | Vendor Enablement | Federal tax identifier and associated 1099 data (with copy of 1099 attached). | ||||
| EPROC-VDR-9 | Vendor Enablement | Business type designation (Corporation, Sole Proprietor, etc.). | ||||
| EPROC-VDR-10 | Vendor Enablement | ACH payment information. | ||||
| EPROC-VDR-11 | Vendor Enablement | Commodity codes designating goods and/or services provided. The functionality provided to find/select a code should provide features to help ensure that Vendors pick an appropriate code by searching all levels of code hierarchy (Segment, Family, Class and Commodity). | ||||
| EPROC-VDR-13 | Vendor Enablement | Foreign vendors (not located in the United States) with appropriate address formats/edits and support situations where the Vendor does not have an IRS tax identification number. | ||||
| EPROC-VDR-14 | Vendor Enablement | The Vendor Enablement functionality should provide the ability for multiple user accounts to be associated with an eProcurement Vendor profile. Each user account should be roles-based and have unique user login (i.e. User ID and Password). | ||||
| EPROC-VDR-15 | Vendor Enablement | The Vendor Enablement functionality should prevent an eProcurement Vendor from setting up a duplicate account. | ||||
| EPROC-VDR-17 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should provide a means to require Vendors to accept/agree to State terms & conditions and any requirements to participate in the use of the solution (e.g. pricing commitments on bid/response submissions and catalogs). | ||||
| EPROC-VDR-29 | Vendor Enablement | The Vendor Enablement functionality should provide the ability to have a system generated or state assigned official/standard Vendor unique identifier for those registered only in the eProcurement Solution. The Vendor should have access to their identifier for reference. | ||||
| EPROC-VDR-30 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should provide the State the ability to designate specific Vendor fields as un-editable by the Vendor. The State will manage updates to these fields. | ||||
| EPROC-VDR-31 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should provide ability for state employees to enter/maintain Vendor accounts, as needed. | ||||
| EPROC-VDR-32 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should provide the ability to review and approve new and updated Vendor accounts to make them active and available for use in the system. | ||||
| EPROC-VDR-33 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should provide the ability to route Vendor registration through workflow to other state organizations for review and verification, as necessary (i.e., licensing, certification, finance pre-note, etc.). | ||||
| EPROC-VDR-34 | Vendor Enablement | The Vendor Enablement "eProcurement Vendor” registration functionality should provide an automated means for a registered Vendor to retrieve their User ID and Password with strong security verifications to prevent unauthorized access to the account. | ||||
| EPROC-VDR-35 | Vendor Enablement | The Vendor Enablement eProcurement Vendor registration functionality should send an email notification to the Vendor to confirm initial registration and confirmation/acknowledgement of any subsequent changes to the Vendor's registration account. | ||||
| EPROC-VDR-38 | Vendor Enablement | The Vendor Enablement registration functionality should provide an auditable history that documents all changes made to a Vendor account (e.g. Tax ID, Name, Contact information, Address, Email address, Phone Number, etc.) with a record of changes were made, when they were made, and who made them. | ||||
| Buyer Portal | The Buyer Portal component of the system should provide functionality that acts as a personalized single point of entry 'front door' to procurement activities within an Agency, within Central Procurement organizations and those that will be routed from Agencies to Central Procurement. | |||||
| EPROC-BPRT-1 | Buyer Portal | The eProcurement Buyer Portal components of the system should seamlessly integrate with the state's website and appear to users as a single, logically integrated solution despite the physical implementation of systems and system providers (i.e., State and Contractor) that comprise the eProcurement solution in full. | ||||
| EPROC-BPRT-2 | Buyer Portal | The eProcurement Buyer Portal should, for State employees, provide secure login capabilities. | ||||
| EPROC-BPRT-3 | Buyer Portal | The eProcurement Buyer Portal should provide dashboard access to procurements and procurement activities that is personalized based on organization, user, security role and applicable State/Agency data access rules. Information and functionality should include at a minimum: | ||||
| EPROC-BPRT-4 | Buyer Portal | Presentation of procurement transactions (Orders, Solicitations, Contracts) that the user has created with ability to monitor/track the transaction status and the ability to directly access a specific transaction to take action on it. | ||||
| EPROC-BPRT-6 | Buyer Portal | The eProcurement Buyer Portal should provide user access to system alerts and notifications including actions needed on specific procurements. The buyer should have the option to receive notifications via e-mail and/or on-screen in the portal. | ||||
| Identification of Need | The Need Identification component of the system provides functionality for a user to initiate any type of procurement action with configurable business rules to support both State Agencies/organization and State business needs. The user interface should be user-friendly, intuitive, flexible and adaptable to support users. | |||||
| EPROC-NEED-1 | Need Identification | The eProcurement Need Identification functionality should act as a single point of entry for a user to initiate any type of procurement action. | ||||
| EPROC-NEED-2 | Need Identification | |||||
| The eProcurement Need Identification functionality should be configurable to allow the State to define the available procurement actions. Initial available actions will be at a minimum: |
- initiate a Purchase Request
- initiate a Solicitation or request for a Solicitation
- initiate a Contract, or Request for Contract, or Contract Activities (e.g. Amendment, Renewal, Extensions, etc) The configuration of each procurement action should allow the definition of conditional fields that will display based on the values of a preceding field. Individual fields should allow for the definition of valid values which may be either enterprise or organization specific.
| EPROC-NEED-6 | Need Identification | The eProcurement Need Identification functionality should take the user into the appropriate eProcurement module for the selected procurement action without requiring an additional login action. |
| EPROC-NEED-7 | Need Identification | The eProcurement Need Identification functionality should allow users with the appropriate roles and authorities to by-pass the procurement action initiation functionality and directly access any of the eProcurement modules available to them. |
| Request through Pay Workstream | The purchase Request through Pay components of the system provides functionality to automate the ordering process from the end-user purchase request through authorizing payment for the resulting order. Key components include purchase request, catalog shopping to drive spend to existing contracts, access to retail/commercial market products, intelligent workflow engine to apply State Agencies/organization and Statewide business rules, on-line approvals, electronic order dispatch, receiving, integration with ERP, electronic invoicing, and 3-way match for payment authorization. | |
| EPROC-PRD-1 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should be seamlessly integrated with the Need Identification component of the system to create Purchase Requests. All information entered in the Need Identification module will automatically carry forward to the Purchase Request. |
| EPROC-PRD-2 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability for authorized users to create requests for the purchase of goods and/or services. |
| EPROC-PRD-3 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide role-based controls to identify users allowed to create purchase requests. |
| EPROC-PRD-4 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to give the State the option of either a system-assigned or state configurable purchase request number format with appropriate edits to ensure that number is unique and not duplicated. |
| EPROC-PRD-9 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to configure State standard and State Agency/organization specific template purchase requests for use by end users. |
| EPROC-PRD-11 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to include state standard and state agency/organization specific terms and conditions and any other language for participation in the Solution at the time of purchase request creation which will be carried forward to all resulting purchase orders and dispatched to the Vendor with the order. |
| EPROC-PRD-13 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to search (based on fields such as: commodity codes, title, description, keywords, Vendor, manufacturer) for similar purchase requests across the enterprise and copy the information to a new transaction with the option to copy any attachments (any size or type). Functionality should present the attachments available for copying and allow the user to select which to copy/include. |
| EPROC-PRD-14 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to attach documents of any type to the purchase request as a whole. |
| EPROC-PRD-15 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to attach documents of any type to individual line items of a purchase request. |
| EPROC-PRD-16 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to distinguish each individual attachment (any size or type) as internal or to be sent to Vendor. |
| EPROC-PRD-17 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to include comments at the header and line level with the ability to distinguish as internal, for State Agency use only (e.g. information regarding the purpose of the purchase and who signed off on the purchase) or to be sent to Vendor (e.g. information about available hours when delivery can be accepted). |
| EPROC-PRD-19 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to establish default values for all purchase request reference and accounting fields based on the user or the State Agencies/organization. |
| EPROC-PRD-20 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to specify ship to and bill to addresses at purchase request header level with the option to specify them at the line level if they need to be different. Addresses should default from the user profile and can be changed by the user. |
| EPROC-PRD-24 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to provide additional delivery instructions beyond the ship to address (e.g. specific delivery to person or special packaging requirements). |
| EPROC-PRD-25 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to select registered Vendors or internal organizations (government entities providing goods or services) and select a specific fulfillment location if the selected Vendor/organization has multiple locations available. |
| EPROC-PRD-26 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to have multiple Vendors on a purchase request and produce separate orders per Vendor. |
| EPROC-PRD-27 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to include trade-in line item values (i.e. negative) for equipment currently owned by the state, but used as a trade-in for new equipment. This would also apply to discounts. The system should have an edit to prohibit the Request total from being a negative value. |
| EPROC-PRD-28 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to include zero value line items. |
| EPROC-PRD-29 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to include shipping/freight/handling charges as a distinct value. This functionality should be configurable so it can be prohibited for specific Contracts. |
| EPROC-PRD-31 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should be able to cancel or process changes to approved purchase requests as revisions to the original purchase request with an auditable history that documents all changes made (including at a minimum, changes to price, product or account codes) to each version and who made the change. Changes are to be associated to the date they occurred (e.g. the amount of a decrease to a prior Fiscal Year order will be associated with the date the change order was issued). The system should provide notifications to reviewer and approvers that the purchase request was changed/cancelled. The State should have the ability to determine which field changes will re-trigger workflow. The ability to make changes should be role-based. |
| EPROC-PRD-32 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to process changes to purchase requests that are for internal purposes only (e.g. administrative changes, account code changes, etc.) which will not be transmitted to the Vendor as a change order. |
| EPROC-PRD-33 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should maintain the complete history of changes (including at a minimum, changes to price, product or account codes) to the purchase request that are accessible by the user creating the request, approvers of the request or any user provided a role allowing access to the request. |
| EPROC-PRD-34 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to create line items utilizing catalogs, punchouts, contracts, direct entry of non-catalog items or by obtaining/selecting quotes from contract Vendors (e.g. services, SOW work, and configurable products). Items selected from a catalog, punchout or referencing a contract will automatically populate line item fields. |
| EPROC-PRD-39 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide a configurable rules engine which will allow the State to automatically prioritize or limit search results to specific sources (contract catalogs/punchouts, contracts, etc.). |
| EPROC-PRD-41 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to support kitting, bundling and configured product situations. |
| EPROC-PRD-42 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to assign a commodity code to each line item with the standard code description presented as a read-only display and allow the user to enter/edit a separate item description. The functionality provided to find/select a code should provide features to help insure that users pick an appropriate code by searching all levels of the commodity code hierarchy (Segment, Family, Class and Commodity) and presenting search results in a manner that clearly displays the full hierarchy including the descriptions of the higher code levels |
| EPROC-PRD-43 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to establish a chart of accounts structure and code values that include fields standardized across all state government entities with the ability to also have State Agencies/organization specific fields. This capability should also allow political subdivisions to have their own unique chart of accounts structure and code values. |
| EPROC-PRD-45 | Request through Pay/ Purchase Request Development | The eProcurement Request Development chart of accounts functionality should be configurable to allow the State to stipulate by State Agencies/organization whether the fields will be available on a purchase request and/or whether entry of these fields is required or not. |
| EPROC-PRD-46 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to load valid chart of account code field values from the State’s finance system and provide a means through integration or interface to ensure that available code values are current and are available to all procurement activities. |
| EPROC-PRD-47 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to allow default chart of account code field values that is configurable at either the user or State Agencies/organization level. (e.g. Buyer/Analyst user id or agency identifier). |
| EPROC-PRD-48 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability to prevent or prohibit the selection of invalid chart of account code value combinations. |
| EPROC-PRD-49 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the ability for entry of chart of accounts values by line item or the purchase request as a whole, including split accounting by percentage, dollar amount or quantity. Chart of account value entity on the purchase request as a whole should allow a user to enter the values one time for all line items rather than enter the values at the line item level for each line item. Available field values should be filtered so only values valid to the user are available for selection. |
| EPROC-PRD-52 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should use the State time zone standard for current date and time for purchase request development. |
| EPROC-PRD-54 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should support definable/configurable request Types that will require different fields to be entered based on the Type selected. |
| EPROC-PRD-56 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the functionality to alert users when a date (e.g. Delivery date, bid open date) is selected that is a non-work day. To support this, include details of calendar functionality. |
| EPROC-PRD-57 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should provide the functionality to allow users to edit common fields across multiple request line items with single entry (e.g. accounting codes, ship to address). |
| EPROC-PRD-58 | Request through Pay/ Purchase Request Development | The eProcurement Request Development functionality should allow for the creation of a request from a blanket order that copies all item detail including accounting codes with the ability to modify accounting codes, ship to and bill to addresses. |
| EPROC-WRK-1 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide a robust, configurable rules engine and workflow management capability allowing for rules to be defined to support State Agencies/organization, Central Procurement authority, State-wide, oversight and governance requirements with the ability to define a hierarchy or order of precedence in situations where a rule exists at both the State Agencies/organization and State levels. Rules would be able to define either routing of work or required approvals. This rules capability will provide the ability to enforce Agency and State policies/statutory requirements (e.g. trigger management approval when annual Vendor spend limits have been exceeded) and the ability to capture an approval identifier that will carry forward with the transaction and any subsequent transaction. |
| EPROC-WRK-2 | Request through Pay/ Workflow Management | The eProcurement Workflow Management business rule functionality should provide the ability to define an unlimited number of separate rules for purchase requests, purchase orders and change orders. Definition of rules can be user, role, agency or state-wide specific and can be based on any one or combination of data elements of a request, purchase/change order, user profile, user's organization or Vendor. |
| EPROC-WRK-7 | Request through Pay/ Workflow Management | The eProcurement Workflow Management business rule functionality should include the ability to stipulate placement in the workflow with in-series or multiple-path (parallel) options. |
| EPROC-WRK-8 | Request through Pay/ Workflow Management | The eProcurement Workflow Management business rule functionality should allow routing to either specific users or to a Role assigned to a group of users (e.g. Budget Approver). |
| EPROC-WRK-13 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should record the specific user that provided the approval and if the approval rule was Role based, then remove the pending approval action from the accounts of all other users in the same approval group. |
| EPROC-WRK-14 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should allow approvers and reviewers to add comments and attachments (any size or type) when they are reviewing/approving/denying the transaction. |
| EPROC-WRK-17 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide visibility into purchase request and purchase order status and tracking within the individual transaction by the initiating user, user's manager and other individual users authorized to access the transaction. |
| EPROC-WRK-18 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide a display depicting the workflow generated for purchase requests and purchase orders that identifies each step, the users/roles assigned to approve each step, steps completed, and status with easy access to approval/denial details (e.g. comments, attachments (any size or type)). |
| EPROC-WRK-19 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide optional, user-specific email alerts and on-screen messages to notify individual workflow recipients when it is their turn to take action. The email/notification would include a link to access the associated purchase request/purchase order. |
| EPROC-WRK-20 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should include a system-based inbox of pending workflow and/or approval tasks. |
| EPROC-WRK-21 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should allow delegation of work or approval authority to at least one specific user for a limited timeframe. |
| EPROC-WRK-22 | Request through Pay/ Workflow Management | The eProcurement Workflow Management approvals functionality should include configurable controls to prevent a user from approving their own purchase requisition or purchase order. |
| EPROC-WRK-24 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should store a complete history of workflow actions executed regarding the purchase request, purchase order or change order including initial and re-initiated workflow actions. The details captured will include, at a minimum, the user, date/time and action taken and in those circumstances where the user edited the transaction, details of what was changed. |
| EPROC-WRK-25 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide initiating users the ability to withdraw purchase requests, purchase orders and change orders submitted for approval. The system should provide notifications to reviewers and approvers for any completed approvals that the purchase request was withdrawn. |
| EPROC-WRK-26 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide users with the ability to change and re-submit denied purchase requests, purchase orders and change orders. |
| EPROC-WRK-27 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide the ability to insert additional reviews/approvals (a.k.a. ad hoc approvers) at any point in the workflow as in-series or in parallel, to support situations such as manager review, product inspection/acceptance review or data entry review. |
| EPROC-WRK-29 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide an organization specific 'Super User' the ability to authorize users to edit/submit other users’ draft/in-process purchase requests and/or approve submitted purchase requests or orders. |
| EPROC-WRK-30 | Request through Pay/ Workflow Management | The eProcurement Workflow Management functionality should provide the ability to have different workflow/business rules based on Type of Purchase Request or Purchase Order that can be configured at State Agencies/organization and statewide levels. |
| EPROC-PO-1 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide automated purchase order or blanket order creation from approved purchase requests with capabilities that meet both procurement and finance business needs and upon approval provide for electronic delivery to Vendors. |
| EPROC-PO-3 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide role-based controls to authorize users to create, close, and cancel purchase orders, blanket orders and change orders. |
| EPROC-PO-4 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to configure state standard and state agencies/organization specific purchase order templates and types. |
| EPROC-PO-5 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should have the ability to give the state the option of either a system-assigned or state configurable purchase order number format with appropriate edits to ensure that number is unique and not duplicated. |
| EPROC-PO-6 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should carry forward all information to the Purchase Order from the initiating purchase request, solicitation award or contract. Data brought forward includes, at a minimum, line item fields, Vendor data, commodity codes, accounting codes, user-defined field values, ship to/bill to addresses, delivery schedules and terms/conditions, notes and attachments (any size or type). |
| EPROC-PO-7 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should have a means to attach or automatically include state standard and state Agencies/organization specific terms and conditions and any other language for participation in eProcurement brought forward either from the initiating purchase request unless the order is associated with an existing Contract or Blanket order in which case it will be governed by the terms and conditions specific to the contract/blanket order. |
| EPROC-PO-8 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to have statewide and state agencies/organization specific purchase order fields at the header, line and accounting line level including valid values and field attributes (e.g. required, optional, numeric format, date format) with appropriate field edits and configurable error/warning messages. |
| EPROC-PO-9 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to establish default values for all purchase order reference and accounting fields based on the user or the state agencies/organization. |
| EPROC-PO-10 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to attach documents of any type to the purchase order as a whole. |
| EPROC-PO-11 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to attach documents of any type to individual line items of a purchase order. |
| EPROC-PO-12 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to distinguish on each individual attachment (any size or type) as internal or to be sent to Vendor. |
| EPROC-PO-13 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to include comments at the header or line level with the ability to distinguish as internal, for State State Agencies/organization use only (e.g. information regarding the purpose of the purchase and who signed off on the purchase) or to be sent to Vendor (e.g. information about available hours when delivery can be accepted). |
| EPROC-PO-15 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability for electronic signature on approved orders based on State specified standards. |
| EPROC-PO-16 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should have the ability to transmit approved orders to Vendors electronically, including notes and attachments (any size or type), by Email, eFax, and transmission as an electronic record utilizing either EDI or cXML. The method of transmission will be determined by the Vendor in their registration account. EDI and cXML formats should include sufficient data identification elements (e.g. Agency Number, User identifier, Ship To Address identifier, Bill To Address identifier) for the Vendor to be able to automate account matching within their order fulfillment/processing system. |
| EPROC-PO-17 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should have the ability to print or email orders that have already been transmitted to the Vendor. |
| EPROC-PO-18 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should be able to create change orders either through revisions to the original purchase request or purchase order with an auditable history that documents all changes made to each version. Changes are to be associated to the date they occurred (e.g. the amount of a decrease to a prior Fiscal Year order will be associated with the date the change order was issued). Including at minimum the following: |
| EPROC-PO-19 | Request through Pay/ Purchase Order Generation & Management | a. The eProcurement Purchase Order functionality should retain original orders with version numbers to track changes. |
| EPROC-PO-20 | Request through Pay/ Purchase Order Generation & Management | b. The eProcurement Purchase Order functionality should maintain complete change order history and provide a means to communicate what was changed between versions to the Vendor. |
| EPROC-PO-21 | Request through Pay/ Purchase Order Generation & Management | c. The eProcurement Purchase Order functionality should provide change orders with the same workflow, approval, print and electronic transmission capabilities as the original purchase request and purchase order. |
| EPROC-PO-22 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should allow change orders to be created after partial receipts have been recorded against the order. |
| EPROC-PO-23 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide users with the ability to cancel purchase orders or blanket orders. The system should provide notifications (email or e-fax) to reviewers, approvers, and the Vendor that the purchase order was withdrawn/cancelled. |
| EPROC-PO-24 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability for authorized users to automatically close open purchase orders and blanket orders based on specific criteria (e.g. Order dates are in a prior Fiscal Year). |
| EPROC-PO-25 | Request through Pay/ Purchase Order Generation & Management | The eProcurement Purchase Order functionality should provide the ability to facilitate the fiscal year end close responsibilities: |
• Capital purchase order rollover,
• Operational mass order close,
• Current year requisitions in Open or Pending status
• Requisitions that have been denied
• Requisitions in sourcing error
• Requisitions that have been approved, but not sourced to PO
• POs in Open status
• Current year POs in budget error
• Change Requests pending approval
• Completed/Cancelled POs in budget error
| EPROC-PC-1 | Request through Pay/ Payment Card Integration | The eProcurement Payment Card (PCard) functionality should provide the ability for use of PCard for payment to Vendor for orders. |
| EPROC-PC-2 | Request through Pay/ Payment Card Integration | The eProcurement PCard functionality should provide for full compliance with PCI (Payment Card Industry) standards for use, transmission, storage and handling of PCard related data. PCard numbers cannot be included on printed or faxed documents including purchase orders and contracts. |
| EPROC-PC-4 | Request through Pay/ Payment Card Integration | The eProcurement PCard functionality should not require use of the PCard if the Vendor accepts PCard payments. Acceptance of PCard as a payment method will be captured in the Vendor registration account. |
| EPROC-RC-1 | Request through Pay/ Receiving | The eProcurement Receiving functionality should provide the ability to record receipt of both goods and services. |
| EPROC-RC-5 | Request through Pay/ Receiving | The eProcurement Receiving functionality should enforce role based controls to give users the ability to create/enter receipts. The role may allow the receiving person to either be the person who requested/ordered the goods/services or other individuals assigned the responsibility to manage receipts for a specific group of users or state agencies/organization. |
| EPROC-RC-7 | Request through Pay/ Receiving | The eProcurement Receiving functionality should have the ability to specify the amount received, amount rejected, and the ability to provide key information such as dates, comments, attachments (any size or type) and identify any hazardous material data. |
| EPROC-RC-8 | Request through Pay/ Receiving | The eProcurement Receiving functionality should have the ability to receive goods or services by either quantity or dollars. |
| EPROC-RC-11 | Request through Pay/ Receiving | The eProcurement Receiving functionality should have an auditable method to correct receiving entry errors. |
| EPROC-RC-13 | Request through Pay/ Receiving | The eProcurement Receiving functionality should have the ability to capture additional data for fixed assets (e.g. serial number on a microscope). |
| EPROC-RC-14 | Request through Pay/ Receiving | The eProcurement Receiving functionality should have the ability to capture the receiving users' assessment of quality or damage of delivered goods/services. |
| EPROC-RC-15 | Request through Pay/ Receiving | The eProcurement Receiving functionality should provide workflow/approval functionality to allow for review/approval of receipts before finalizing the receiving action. Receipt reviews/approvals will be defined through system Roles that are configured at the State Agencies/organization level and will provide email notification to reviewers and approvers. |
| Catalog Capability Workstream | The Catalog components of the system provide the functionality to maintain contract/non-contract catalogs in the shopping component of the system. Catalog content can be hosted within the system or made available by 'punching out' to the Vendor’s shopping website. Integration with the Sourcing or Contract Management component of the system should allow catalogs to be automatically generated as part of the Award process. Integration with the Contract Management component of the system should provide one method of maintaining catalog content throughout the life of the Contract/Agreement. Other key components include utilities for Vendors to setup, manage and maintain their catalogs. These utilities should be available for the Buyer/Analyst on an exception basis. Workflow functionality should also be available to automate review and approval of catalog content before it is made available to users. | |
| EPROC-CAT-1 | Catalog Capability | The eProcurement Catalog functionality should provide catalog abilities for state contracts, state and external cooperative agreements, in-state resources, and non-contract sources including: |
| EPROC-CAT-2 | Catalog Capability | a. Internally (State) managed catalogs: consistent process to create, maintain and load catalogs as needed regardless of number of items; |
| EPROC-CAT-3 | Catalog Capability | b. Vendor managed catalogs: create, update and loading into system; and |
| EPROC-CAT-4 | Catalog Capability | c. Third party catalogs hosted accessed through the system that navigate user to external Vendor shopping cart websites and return selections as Purchase Request line items (i.e. “Punchout” catalog). |
| EPROC-CAT-5 | Catalog Capability | The eProcurement Catalog functionality should support the following catalog characteristics/abilities: |
| EPROC-CAT-6 | Catalog Capability | a. Unlimited number of catalogs; |
| EPROC-CAT-7 | Catalog Capability | b. Unlimited number of items per catalog; |
| EPROC-CAT-8 | Catalog Capability | c. Catalog item without unit prices that allow authorized users to enter prices once added to the requisition (e.g. entering a services quote); |
| EPROC-CAT-9 | Catalog Capability | d. Catalog items have effective dating to control when they are available to users supporting future dating and making items unavailable when they expire; |
| EPROC-CAT-10 | Catalog Capability | e. Catalog items that are instructional without pricing to direct users on how to order (e.g. specify that the user should contact Vendor for pricing); |
| EPROC-CAT-11 | Catalog Capability | f. Catalogs should provide a means to obtain, review and accept quotes with the ability to retain the quotes received from multiple Vendors; |
| EPROC-CAT-12 | Catalog Capability | g. Configurable products or services based on specific contract prices or price ranges; |
| EPROC-CAT-13 | Catalog Capability | h. Pre-configured items with the ability to substitute optional components (e.g. Police car with ability to substitute type of radio) |
| EPROC-CAT-14 | Catalog Capability | i. Items with a zero-dollar value; |
| EPROC-CAT-15 | Catalog Capability | j. Items with tiered/multiple pricing based on the package size or quantity ordered (e.g. price break is given when buying larger quantities); |
| EPROC-CAT-16 | Catalog Capability | k. State definable/customizable catalog fields that can be used in searches and carried forward to the Purchase Request and/or purchase order; and |
| EPROC-CAT-17 | Catalog Capability | l. Inclusion of images, attached documents and links to external product information websites hosted by catalog Vendors; |
| EPROC-CAT-18 | Catalog Capability | m. Identification of items that are hazardous and have the ability to attach the associated MSDS sheets; |
| EPROC-CAT-19 | Catalog Capability | n. Items with a negative dollar value (e.g. deduct options for vehicles, pre-negotiated trade-in values, etc.); |
| EPROC-CAT-20 | Catalog Capability | o. Catalog punchouts should provide a means to obtain, review and accept quotes with the ability to retain quotes received from multiple Vendors. |
| EPROC-CAT-21 | Catalog Capability | p. Allow a single Contract to have catalog capability to support situations where the contract includes a combination of items with fixed priced, items requiring quote, and others may be instructional, such as “call for a quote”. |
| EPROC-CAT-22 | Catalog Capability | q. Contract catalog items will be automatically made unavailable in the system when the associated contract is expired. |
| EPROC-CAT-23 | Catalog Capability | The eProcurement Catalog functionality should provide functionality for the state catalog manager and contract officers to review/approve Vendor catalogs prior to loading into system. Approval functionality should provide the ability to assign specific catalogs to specific/different approvers. |
| EPROC-CAT-24 | Catalog Capability | The eProcurement Catalog approval functionality should have the ability to approve or deny individual items within a catalog prior to loading it into the system. |
| EPROC-CAT-25 | Catalog Capability | The eProcurement Catalog functionality should provide catalog maintenance functionality that will identify changes/differences between the new version of a catalog as compared to the currently active version. |
| EPROC-CAT-26 | Catalog Capability | The eProcurement Catalog functionality should have business rules to stipulate which catalogs are available to a user, group of users or entire State Agencies/organization. |
| EPROC-CAT-29 | Catalog Capability | The eProcurement Catalog functionality should provide intelligent searching across available catalogs based on keywords, contract number, Vendor, Manufacturer, part number (manufacturer and Vendor) and other catalog data elements to locate appropriate catalog(s). System will allow state to specify search result limits on records returned. |
| EPROC-CAT-32 | Catalog Capability | The eProcurement Catalog functionality should provide a means for the State to prioritize search results to promote specific contracts, Vendors, mandatory sources or items. The functionality should allow for prioritization to either be established across all users or for specific Agencies/organizations. Results will clearly identify why the items were prioritized (e.g. Mandatory Source item). |
| EPROC-CAT-33 | Catalog Capability | The eProcurement Catalog functionality should provide the ability to facilitate comparisons views of all search results including contract vs. punchout content. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .