Warehouse_Requirements_2023_(1).xlsx

XLSX spreadsheet 52 KB Posted Mar 27, 2023

Attached to: Warehouse Supply & Inventory Management Solution
Solicitation number: 2023-RFP-031
Issued by: Cook County, Pennsylvania

About this file

Written by GovTribe AI · Jun 27, 2025

The document is a comprehensive Warehouse Requirements spreadsheet from the City of Pittsburgh Office of Management and Budget, detailing functional requirements for an enterprise-wide warehouse supply and inventory management solution. The project will initially involve the Department of Public Works, Finance, Fire, and EMS departments, with potential for future expansion. The requirements document outlines detailed system capabilities across multiple domains including ordering and purchasing, receiving/shipping, inventory management, reporting, security, integration, and technical specifications. The solution must support functions such as generating purchase orders, electronic catalog integration, inventory tracking, user access management, and robust reporting capabilities.

The technical requirements emphasize stringent data security, with mandates for encryption, breach notification, continuous system availability (99.99% uptime), and comprehensive security protocols. The system must be cloud-based, preferably hosted by the provider, with all cloud-hosted data remaining in the continental United States. Key technical specifications include support for multiple Windows platforms, remote administration, export capabilities in standard formats, built-in backup and restore functionality, and integration with existing city applications. The City requires full data ownership, API access, and the ability to export data to regional data centers. While no specific budget is mentioned, the detailed requirements suggest a complex, enterprise-level solution with significant technical and operational expectations for potential vendors.

View the file

Other files

File	Type	Posted
Warehouse_Supply_&_Inventory_Management_Solution_(Addendum_#1_Revision).pdf	PDF	Jun 5, 2024
21.01.11_Water_Order_(1).docx	DOCX document	Apr 18, 2023
20.10.16_Filling_An_Order_(1).docx	DOCX document	Apr 18, 2023
EMS_Warehouse_Operations_Process_2023-02-02_17-12-10_(1).pdf	PDF	Apr 18, 2023
PGH_Supply_Instructions_(1).pdf	PDF	Apr 18, 2023
20.10.16_Filling_An_Order__Office_(1).docx	DOCX document	Apr 18, 2023
22.12.15_DPW_Warehouse_-_MaterialsExport_(2).xlsx	XLSX spreadsheet	Apr 18, 2023
DPW&PARKS_Approval_Process_(WHS_ORDERS)_(1).PDF	PDF	Apr 18, 2023
PGH_Supply_Video_(1).mp4	MP4 file	Apr 18, 2023
DPW_WHS_Applications_and_Functions_(1).PDF	PDF	Apr 18, 2023
DPW_WHS_Order_Overview_(1).PDF	PDF	Apr 18, 2023
MaterialsExport_Fire.csv	CSV file	Apr 18, 2023
Standard_SLA_with_Remedy.doc	DOC document	Mar 27, 2023

Show all 13

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

DPW_Functional Requirements

	Requirement ID	Requirements
(All of the items apply to any subcontractors that work on the solution. )	System Capability
(select from dropdown)	Comments: R= Required Functionality

W = Wish List

Ordering and Purchasing:
1.1	generate/modify/suspend/delete orders from system suggested order (based on loaded inventory parameters)	R
1.2	generate purchase order from set inventory parameters	R
1.3	add, delete, suspend purchase order	R
1.4	access and integration of electronic catalogs from suppliers	R
1.5	submit/receive orders electronically	R
1.6	process orders/purchase order requests electronically	R
1.7	add custom note field to order e.g.: ship with next order, pick up, urgent…, changes in inventory items, etc.	R
1.8	link warehouse inventory item number to supplier number	R
1.9	ability to classify items on purchase order as regular order or special order	R
1.10	integrate purchase orders from external sources outside of warehouse to warehouse system	R
1.11	flags for inventory item supersedes, obsoletes, etc.	W
Receiving/Shipping:
2.1	current order status i.e. - open, closed, held, delivered, picked-up	R
2.2	receive orders by purchase order electronically	R
2.3	item prices changes/updates at time of receiving	R
2.4	electronic signature/scanning of deliveries (e.g.: like UPS, FedEx)	R
2.5	classify orders electronically as pick-up, delivery or other	R
2.6	receive and process external orders i.e. items not ordered by warehouse but received at warehouse	R
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
Inventory Management:
3.1	set warehouse item re-order points to produce suggested orders	R
3.2	import suggested order to generate purchase order	R
3.3	delete line items on orders	R
3.4	warehouse order editing	R
3.5	cost of inventory items and ability to update	R
3.6	delete or ability to archive item numbers	R
3.7	change item information e.g.: ea., pk., rl., box, case, etc.	R
3.8	inventory count and cycle count generation	R
3.9	ability to change location, set master location	R
3.10	committed inventory display with on hand quantity	R
3.11	inventory search by number and text	R
3.12	classification of inventory item as stock, non-stock, special order, obsolete, superseded	R
3.13	attach item information: manufacturer number, picture (jpeg), etc.	R
3.14	item supersession ability	R
3.15	show on hand quantity when making inventory adjustments	R
3.16	ability to integrate warehouse loan items into inventory	R
3.17	system of inventory classification i.e.: use categories that match contract commodities	W
3.18	use of scanners/mobile devices for receiving, order processing, inventory counts	R
Reporting:
4.1	current on hand inventory valuation, physical and ledger values	R
4.2	inventory delivered history by item, delivery location, date, volume	R
4.3	inventory changes, deletions, supersedes, obsolete for time period	R
4.4	reports by purchase order numbers	R
4.5	non moving inventory by time	R
4.6	item movement lists, i.e. by number frequency	W
4.7	item returns, cancels	R
4.8	purchase order status, searchable by open, closed, partial, etc.	R
Security:
5.1	user security access by function, and have this customizable	R
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Integration:
6.1	integration of inventory to move, transfer, share from other locations	W
6.2	access to inventories/reports at multiple locations	W
6.3	employee timecard clock sign in / sign out	W
6.4
6.5
6.6
6.7
Miscellaneous:
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21

EMS_Functional Requirements

	Requirement ID	Requirements
(All of the items apply to any subcontractors that work on the solution. )	System Capability
(select from dropdown)	Comments: R= Required Functionality

W = Wish List

Ordering and Purchasing:
1.1	Request supplies from a dropdown	R
1.2	Additional Comment section when making a request	R
1.3	Categorized items (House, Drugs, Equipment, Forms, Medical)	R
1.4	Ability to select multiple items in a single order	R
1.5	Ability to alert when item threshold is reached	R
1.6
1.7
1.8
1.9
1.10
1.11
Receiving/Shipping:
2.1	Notification to administrator on new orders	W
2.2	Ability to identify the origin of an items and/or item
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
Inventory Management:
3.1	Built-in quantity limitation on requests of certain supplies	W
3.2	Ability to inventory disposable supplies	Optional
3.3	Ability to provide dispensary machines	Optional
3.4	Ability to track expiration, of medicines	Optional
3.5	Ability to alert related to medicine categories	Optional
3.6	Ability to pull a full drug audit	Optional
3.7	Ability to pull a full medicine audit that includes but is not limited to: medic unit assigned, individual that pulled the item (including medicine) for use, date, time	Optional
3.8	Ability to track all aspects of emergency medical supplies, medical equipment, pharmaceuticals, and narcotics	Optional
3.9	Ability to list levels and/or categories of item	R
3.10	Ability to set trigger(s) or alert(s) related to inventory threshold	R
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
Reporting:
4.1	Ability to generate report based on who orders are submitted to	R
4.2	Ability to generate report based on who requests an order	R
4.3	Ability to sort orders based on who, what, how many, etc.	W
4.4	Ability to pull a full medicine audit that includes but is not limited to: medic unit assigned, individual that pulled the item (including medicine) for use, date, time	R
4.5	Ability to export reports into commonly used formats such as: excel, word, PDF	R
4.6	Ability to limit report generation based on account permissions
4.7
4.8
Security:
5.1	Required login to access system and request supplies	R
5.2	Ability to restrict access to dispensary machines (RFID preferred)	R
5.3	Ability to secure controlled medications	R
5.4	Ability to set permissions for accounts including but not limited to: inventory management, account creation, audit reporting, general user	R
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Integration:
6.1	Ability to print a generated supply order form PDF	R
6.2	Send digital receipt to orderer after submission	W
6.3	Ability to send SMS	W
6.4	Ability to send email alerts	R
6.5
6.6
6.7
Miscellaneous:
7.1	Training on how to filll, clean, and use dispensing machines
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21

FIN_Functional Requirements

	Requirement ID	Requirements
(All of the items apply to any subcontractors that work on the solution. )	System Capability
(select from dropdown)	Comments: R= Required Functionality

W = Wish List

Ordering and Purchasing:
1.1	An optional explanatory area to explain why the Specialty/Professional services or items are needed	R
1.2	Unique profile numbers or names to identify employees making request.	R
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
Receiving/Shipping:
2.1	The ability to associate items requested with specific Purchase order numbers	R
2.2	Status bar (received, processing, complete etc.)	R
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
Inventory Management:
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
Reporting:
4.1	The ability to filter by requester, items, month date etc.	R
4.2	Dialog bar to communicate within the program	R
4.3
4.4
4.5
4.6
4.7
4.8
Security:
5.1	The ability to give special permissions to Directors, Managers, Supervisors.	R
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Integration:
6.1	The ability to generate a spreadsheet (via excel or within program) that shows all requested items Weekly, Monthly, and YTD.	R
6.2	The ability to upload screenshot or photos on both administrator and requestors side. (this will ensure the correct item is being purchased)	R
6.3
6.4
6.5
6.6
6.7
Miscellaneous:
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21

FIRE_Functional Requirements

	Requirement ID	Requirements
(All of the items apply to any subcontractors that work on the solution. )	System Capability
(select from dropdown)	Comments: R= Required Functionality

W = Wish List

Ordering and Purchasing:
1.1	Unified request submission	* right now some submit via the supply dashboard others are emailing
1.2	Response to request - Approve, Deny, partial approval, partial denial
1.3	Justification field for response type based on item type
1.4	Item justification field (with drop list for why item is needed)
1.5	Approval workflow (to include fire warehouse and admin)
1.6	Medicine descriptions - Expiration dates
1.7	Notice of last order (warning or double dare)
1.8
1.9
1.10
1.11
Receiving/Shipping:
2.1	Vendor management/pricing	* City has contracts that can change with different pricing - Joe has a spreadsheet of this information
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
Inventory Management:
3.1	Images of the items	*physical inventory of what is in the warehouse
3.2	Tracking of items with triggers for when to reorder	* Supplies - Office, medicial, house,
3.3	Vendor management/pricing	* City has contracts that can change with different pricing - Joe has a spreadsheet of this information
3.4	Item field type - medicial, office , house, equipment, PPE(maybe), medicine, COVID	* Other Bureaus order through Charles Showers (ps admin) and fire warehouse fullfilled
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
Reporting:
4.1	Medicine summary
4.2	The ability to pull reports via Firehouse, item type,
4.3	The ability to see what was ordered by person, by location
4.4
4.5
4.6
4.7
4.8
Security:
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Integration:
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Miscellaneous:
7.1	Replenishment of supplies between bureaus	* when fire uses AED pads or Narcan and EMS transports the patient, fire needs replenishment
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
Nice to have
	Tracking of turnout gear
	Tracking of SCBA

Technical Requirements Final

	Requirement ID	Requirements
(All of the items apply to any subcontractors that work on the solution. )	System Capability
(select from dropdown)	Comments:
	Outage and Breach Reporting:
	1.1	Provide your outage notication communication
	1.2	Provides fast detection and root cause diagnosis
	1.3	The City of Pittsburgh (referred to as City) must be notified in writing within 24 hours of the earliest indication or report of a potential breach or unintended disclosure of Confidential Information (CI) or a System that supports CI.
	1.4	Response actions to incidents that might affect CI or Systems must be conducted quickly and with ample resources. Vendor will hire a professional third-party incident response team if in-house resources do not have sufficient skill or availability. The Vendor is expected to distribute all incident response evidence, reports, communications and related materials to security@pittsburghpa.gov. The format of incident reports will be agreed upon with the City in advance.
	1.5	City shall have the right to view all incident response evidence, reports, communications and related materials upon request.
	1.6	If requested by the City, or if required by law, the Vendor shall notify in writing all persons affected by the incident, at its own cost and expense.
	1.7	Vendors shall have a comprehensive secure development system in place consistent with industry standard best practices, including policies, training, audits, testing, emergency updates, proactive management, and regular updates to the secure development lifecycle System itself.
	1.8	Vendors will make updates available to the City in a timely fashion at no additional cost.
	1.9	The system can provide the ability to track and log system uptime and transaction response times in order to provide information for SLA monitoring
	1.10	Provides for predictive failures and issue alerting functions
	1.11	Ability to allow for notification of blackouts
	Data and Security:
	2.1	All cloud-hosted data must remain in the continental United States.
	2.2	Ownership of all data remains with the City, at no additional cost.
	2.3	Data should be encrypted at rest and in transit.
	2.4	The City shall have the right to view all documentation containing the results of any security audits completed within the last twelve (12) months, including documentation regarding security practices and data classification.
	2.5	The Vendor shall use commercially reasonable efforts to secure and defend any System housing Confidential Information against third parties.
	2.6	Vendors that handle Confidential Information must respond to and resolve security-related bug reports, inquiries and incidents in a timely and professional manner. The Vendor must notify the City within 24 hours of when Vendor becomes aware of any such incident that poses a potential risk to City data. The Vendor shall send the notification to security@pittsburghpa.gov
	2.7	Must follow industry standard password requirements. (Passwords must be stored in non-reversible one-way cryptographic hash)
	2.8	Log all successful and failed authentication attempts, including date, time, IP address, and username.
	2.9	Offer a secure password reset feature, including verification of identity, email or text notification.
	2.10	Temporarily lock accounts with repeated failed login attempts and provide support to affected users.
	2.11	Ability to provide authentication via generally agreed upon SSO methodologies.
	2.12	Vendors managing City-owned CI must engage an independent third party annually to assess the practical security of Vendor's Systems. These reviews must include penetration tests from the perspective of an external attacker and an internal user with common privileges. The penetration tests must include all Systems exposed to the internet and any Systems, internal or external, that Handle Confidential Information. Such annual assessment shall be at Vendor’s sole expense.
	2.13	Audit logs must be implemented for all Systems including those that handle CI. All attempted violations of System security must generate an audit log. Audit logs must be secured against unauthorized access or modification. Electronic logs required
	2.14	In the event of adverse findings through a City or Vendor audit, the Vendor shall cooperate with the City in remediating any risks to CI, including complying with request to temporarily taking the system offline or otherwise limiting access to the system, and any other follow up actions reasonably necessary to secure the CI.
	2.15	For the life of the contract, all data should be retained and available upon request from the City, available via API calls.
	2.16	All metadata, logs, notifications of system outages, etc. should also be retained for the life of the contract.
	2.17	Vendor Systems that Handle Confidential Information shall be available and fully functional 24x7x365 with 99.99% uptime, unless otherwise agreed upon in writing with the City. Vendor shall make plans for colocation, backups and any other Systems necessary to ensure continuity.
	2.18	Vendor must notify and obtain agreement from the City for any planned interruptions in service, with the exception of emergency security updates. Vendor must notify the City immediately of any unintended service interruption.
	2.19	RFP responses should include a plan for content availability in the event of the need to migrate to a different platform. Remittance of content directly to the City of Pittsburgh is acceptable.
	2.20	Include online Help
	2.21	Comprehensive Security

o Local certificates, trusted certificates, and 128-bit SSL

2.22	System should be able to provide an unlimited number of different security groups that can be defined, each with their own security settings and group names that are appropriate.
2.23	ISO/IEC 27001 Certification or in pursiut of audit before working with the City
2.24	Storage needs to be capable of compliance with CJIS Security Policy storage requirements: https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center
Network:
3.1	The solution must adhere to latest best network industry practices.
3.2	The solution must assure that the integrity of the City's network is sustained by the implementation and utilization of modern firewall, VPN and other remote access technologies.
3.3	The soluton must provide network authentication and system user events logging.
3.4	The solution must assure that there will be no degradation in performance of City's network due to their system or design.
3.5	Proposers must include a list of web browsers and devices their system does/does not support
Solution Infrastructure:
4.1	Solutions are preferred to be cloud based solutions hosted with the provider. If solution needs to be customer hosted enviroment, Google Cloud Platform is preferred.
4.2	Respondent must detail all additional software licenses that would be required to utilize the product/solution.
4.3	Provider solution must not incur additional software licensing expense. Provider solution must be a complete package. Solutions utilizing industry standard component applications such as MS SQL are preferred .
4.4	If and when a City owned software license for a component in the solution stack is viable for utilization to avoid additional software licensing expense, it is to be utilized.
4.5	If the suggested solution is to be implemented on the City Infrastructure, requirements for component resources from a virtualized hardware perspective are required. vCPU, Memory, Storage per server with an overall summary.
Data and Reporting:
5.1	When geospatial information is needed, the Solution should have the ability to use City GIS layers hosted on ArcGIS online to create geocoding for locations and administrative geographies provided by the City
5.2	The system should allow for exporting of data through an open, REST API to the City's data ingestion system or the Western Pennsylvania Regional Data Center, as needed.
5.3	Vendor shall provide data dictionary for database fields, field types, number of characters, value ranges, relationship diagram(s) (database map) of the data model, and key fields used in relationships with database tables.
5.4	The API provided by the system should include documentation that contains: Sample requests, headers and other relevant metadata, Clear, comprehensive descriptions of the data represented in the API, such as its output format (e.g., JSON or CSV), understandable by someone with a basic to intermediate familiarity with the system, Generated code snippets in some of the most popular programming languages (e.g., Python). API documentation should include details of specific encodings, documentation, data types, requests, and objects for the API.
5.5	Supports a dashboard with a login

dependent views

5.6	Ability to provide trend analysis
5.7	Real-time Reporting

o At least 150 configurable reports, real-time, and historical graphs

5.8	City must have full ownership and free access to data captured by the System, both during and after the contract period
5.9	Full API Access - Access to our data through the use of an API must be provided.
5.10	A general site user must have the ability to embed third party code (ex. Google Calendar)
5.11	Geospatial data must be compatible with ESRI systems and common geospatial data storage formats (.geojson, .dbf, .shp)
Miscellaneous:
6.1	Companies from outside the United States are welcome to apply, provided they meet the standards as described above.
6.2	Remote meetings may be acceptable, with prior arrangement from the City.
6.3	The City's preference is that Adobe Flash not be part of this solution.
6.4	Role-based Management

o Access network maps, configuration, alerts, notifications, reporting, and management console

6.5	The system can accommodate separate instances of databases for testing, training, and quality assurance
6.6	The vendor shall provide customer service support during the City of Pittsburgh's normal business hours.
6.7	The vendor shall provide "As-Built" documentation to the City of Pittsburgh representing the state of the application service at the time of Go-Live.
Project-Specific Technical Requirements (Mandatory):
7.1	Solution to run on multiple Windows platforms
7.2	Ability to support remote administration
7.3	Ability to export reports in common formats (PDF, Word, Excel)
7.4	Solution shall have built-in backup and restore capability
7.5	If solution hosts or utilized a source of data, solution must have built-in database maintenance and reporting tools
7.6	Vendor shall include a description of the system’s basic architecture
7.7	Vendor shall describe how the system handles multiple users, data concurrency control, record locking, and conflict resolutions
7.8	Vendor shall describe the hosting models (customer enviroment or vender enviroment)
7.9	Vendor shall describe if the solution servers can be virtualized (and if so, describe the system)
7.10	Vendor shall describe hardware requirements or recommendations
7.11	If applicable, describe how the solution can perform database maintenance, including, but not limited to, backup and upgrades without requiring system downtime
7.12	If applicable, describe the solutions ability to auto-discover targets on the network
7.13	If applicable, describe the solutions ability to monitor an application and its performance with agentless configurations where possible.
7.14	If applicable, describe the solutions ability to monitor user response time and throughput by location or other logical grouping.
7.15	If applicable, describe the solutions ability to drill down into the full

technical details on how the server and the browser interact with one another.

7.16	If applicable, describe the solutions ability to assemble an e-mail, with one click, that includes a complete user session with replay to provide additional information when triaging an incident.
7.17	Must support alerting and notifications by email, SMS, pager message, and HTTP

request

7.18	Vender must provide a visual of the solutions network Mapping, Network topology, subnets, devices, applications, and systems.
7.19	If applicable, solution should have configurable monitoring that identifys performance, passive, active, real-time, custom (scripted), monitoring templates, and bulk changes
7.20	If applicable, solution should have have predictive Alerting that is customizable and identifies up, down, and threshold (min/max), maintenance mode, device dependency, and escalation.
7.21	If applicable, solution must support, SNMP (supports SNMP V1, V2c and V3), WMI (Windows Management Instrumentation), HTTP based services, TCP and UDP based services including PING, Port, SMTP, POP3, FTP
Integration or API Requirements (Project-Specific - I&P review this section for relevance to each project/solitication )
8.1	Ability to support two-way communication with Microsoft Outlook
8.2	Ability to integrate with payroll systems to include, but not limited to Ceridien TimePro version
8.3	Vendor shall describe if the system have built-in integration with other systems
8.4	Vendor shall describe if the system can import date from various formats (XML, CSV, TXT).
8.5	The vendor shall INTERACT with City specific applications (for example APRS, Firehouse, CYA, etc)
8.6	Solution allows for reading/writing of map services specifically created and published via ArcGIS for Server environment
8.7	Integrates with existing monitoring tools

Index

Core Capability

Configurable by Vendor

Configurable by City Staff

Requires Customization

Provided in Conjunction with a 3rd Party

Not Applicable

Sheet1

Data Validation

Core Capability

Configurable by Vendor

Configurable by City Staff

Requires Customization

Not Applicable

File details come from the government source that posted it. Updated Jun 27, 2025.