Inventory management software RFP questions for partners

How to run an inventory management software RFP for self-hosted systems

The questions that separate partners who can deliver a stock-accurate go-live from those who can only install software are about data, devices and cutover. Ask every bidder how they will migrate item masters, opening stock balances, lots, serials and expiry dates, how they will reconcile migrated quantities to a physical count before go-live, and how they will handle scanning hardware, label formats and printers at each site. Issue your written scope first, covering locations and warehouses, traceability rules, valuation method, integrations with purchasing, ecommerce and accounting, and the reports you need. A partner who asks for that scope in writing before quoting is usually a partner who will hold you to it during delivery. DeployOpen does not publish prices, and quotes follow from the written scope, so a bid that is not tied to specific requirements cannot be compared fairly.

Compare every answer against the same requirements list, scored the same way for Odoo, ERPNext and OpenBoxes. Edition questions matter more than most buyers expect. Odoo's barcode and other mobile features depend on the Enterprise edition and its subscription, while ERPNext is free to self-host and its Data Import tool is documented for batches of only a few thousand records at a time, which changes how a large stock migration is staged. Ask each bidder which edition or add-on each requirement needs, who pays for it, and whether it is one-time or recurring. Ask also how the warehouse go-live will be sequenced: pilot warehouse first or all sites at once, how the system runs in parallel with the old tool, and what the stock count freeze looks like.

Finally, ask how training and support will work during stock counts and the first weeks of live transactions, when errors are most costly. Ask who is on site or on call, what the escalation path is, how user accounts and roles are set up for pickers, receivers and supervisors, and whether authentication will connect to your directory. Ask for a named list of deliverables, the acceptance criteria for stock accuracy, and the support model after go-live, including whether it is covered by a retainer. Confirm the version each bidder proposes and its support window with the vendor before you sign, because support periods differ by release and edition.

Which questions to ask about migration, edition, devices and go-live

Which Odoo edition do we need for barcode scanning and multi-warehouse stock control?

Odoo's barcode app is part of the Enterprise edition, so scanning on the warehouse floor is a licensing question before it is a technical one. Ask the partner to list each inventory feature your process needs (barcode scanning, mobile apps, multi-company, Studio, external API access, upgrades) and map each one to an edition in writing. A strong answer names the edition, the subscription type and the hosting model, and states which features are Community, which need Enterprise, and which need the Custom plan on the pricing page. A weak answer says Odoo "supports barcodes" without naming the edition, or quotes a per-user price without a scope. Ask who buys and renews the subscription, and whether that cost is in the proposal.

How will the partner migrate item masters and opening stock balances?

A credible migration plan separates item master data (SKUs, units of measure, categories, reorder rules), locations and opening stock, and it validates each one against a count. Ask how the partner cleans duplicate SKUs, maps lots, serials and expiry dates, and reconciles opening quantities and valuation to the old system before cutover. For ERPNext, ask how the Data Import tool will be used, since its documentation advises importing only a few thousand records at a time, so large item and stock files need to be split into batches with a log of each run. A weak answer is a single bulk import with no reconciliation report or rollback plan. Ask for a sample migration on a copy of your data before go-live.

Which barcode scanners, label printers and browsers does the setup support?

The partner should name the scanner models, label printers, handheld devices and browsers it has tested, and the network path between them and the server. Ask how labels are generated (item, bin, lot, pallet), what label format and printer language are used, and who owns the label templates after handover. Check how scanning works when the Wi-Fi drops, and whether the warehouse needs an offline or queued workflow. For Odoo, confirm which barcode features depend on the Enterprise edition before buying devices. A weak answer lists "any barcode scanner" with no test evidence, or leaves devices to be sourced later with no owner.

How does the partner plan the warehouse go-live and cutover window?

Ask for a written cutover plan that covers the freeze period for receipts and shipments, the final data extract, the reconciliation count, the sign-off criteria, and the rollback point if counts do not match. A good answer names which warehouses go live first, whether a pilot site runs in parallel, and how open purchase orders and in-transit stock move across. Ask how the partner tests the production configuration with real users and real scanners before the cutover. Timelines should come from the written scope, not from a generic duration. A weak answer treats go-live as a date with no freeze, no rollback and no named owner for the sign-off.

What training and support will staff get during the first stock counts?

Ask who runs the training, who attends, and how many sessions cover receiving, picking, transfers, adjustments and counts. The partner should describe a floor-level approach: role-based guides, short hands-on sessions on the actual devices, and a named support contact during the first full count cycle. Ask how adjustments are approved and logged, so that counts do not overwrite stock without a trail. A strong answer ties training to the sign-off criteria of the go-live plan. A weak answer offers a single recorded video and no coverage for night shifts or temporary staff. Ask for the training materials in writing so they stay with your organization.

How are upgrades and version support handled after go-live?

Odoo and ERPNext release on different schedules, so the answer depends on the version you choose. For Odoo, the partner should state the standard support end date for your version and how major upgrades will be tested before production, since Odoo Online and Odoo.sh require major version upgrades every two years according to its upgrade documentation. For ERPNext, ask which Frappe major version you will run and confirm that it is still listed as supported on the Frappe support-versions page. Ask who applies minor releases, who tests them against your custom scripts, and whether a support retainer covers that work. A weak answer names no version and no test environment.

Which parts of the rollout can our own team run without a partner?

Ask the partner to split the work into three parts: what your staff will do alone, what they will do with help, and what only the partner should do. Typical internal tasks include reviewing item data, running counts and approving adjustments. Partner tasks usually include configuration, integrations, custom scripts, data migration tooling and the cutover. Ask what skills your team needs to keep the system running, such as access to a database administrator or a Python developer for custom server logic. Note that ERPNext Server Scripts are disabled by default from version 15 and must be enabled, so ask who owns that decision. A weak answer assumes the whole project lands on your team or on the partner without a written split.

What does the fixed-scope proposal include, and what does it leave out?

DeployOpen works from a written scope, with deliverables and timelines agreed before work starts, so ask any bidder to list included items in the same format. Your list should cover edition and licensing advice, data migration runs and reconciliation reports, device and label setup, training, cutover support, and the first count cycle. Then ask what is excluded: device purchases, Odoo or Frappe subscriptions, hosting, data cleanup done by your staff, and retainers for ongoing support. Ask how changes to scope are priced and approved. A weak proposal uses "and more" in the deliverables or gives a total with no list of exclusions.

Partner answers that should worry you

A partner's answer to a few specific questions tells you more than its proposal deck. The red flags below cover dates, editions, data migration, upgrades and training, which are the places where inventory rollouts usually fail. Treat any of these answers as a reason to ask follow-up questions in writing before you score the bid.

A go-live date before a stock count

A partner that commits to a warehouse go-live date before it has counted the physical stock, agreed the locations and tested the scanning flow is guessing. The go-live date should follow a reconciled opening balance, not come before it. Ask how the partner will freeze stock movements during the count, who signs off the variance, and what the rollback looks like if the counted quantities do not match the system.

Features listed as included in Community

Odoo's Community edition is open source under LGPL-3.0, but the Enterprise source code is not publicly available and requires a subscription. Barcode scanning, mobile apps and some warehouse features are tied to Enterprise, so a bid that lists them as included in Community is either misinformed or hiding a license line item. Ask the partner to map every inventory feature in the bid to a specific edition, and to show the subscription cost next to it.

No reconciliation step after migration

Moving items and stock from a spreadsheet or legacy system is only complete when the stock value and quantities in the new system match the source for each location, lot and item. A partner that loads the data and moves on has skipped the reconciliation. Ask for the reconciliation report, the named owner who approves it, and how duplicate item codes and unit mismatches are caught before the import, not after.

No plan for units of measure or lot conversion

Stock often arrives in cases while it is picked in single units, or uses old lot codes that the new system must map. If the bid does not describe how units of measure and lot numbers will be converted, quantities and expiry dates will drift from the first receipt. Ask how conversion factors are set and approved, how existing lot codes are mapped to the new lot structure, and who tests a sample of each unit type before the import.

No test environment for upgrades

Odoo's upgrade service moves a database to a newer version through an upgraded test database that should be tested before production, and major versions on Odoo Online and Odoo.sh are mandatory every two years. A partner that has no test environment, no upgrade rehearsal and no plan for the regression tests on barcode flows is leaving you to find breakage during a live shift. Ask who maintains the test copy, how often it is refreshed, and who signs off the upgrade.

No named trainer for floor staff

Stock counts and goods receipt depend on people who use handhelds on the warehouse floor, often with limited time for classroom training. A partner that describes training only as a generic workshop, or will not name the person who trains floor staff on each shift, is not planning for adoption. Ask who will deliver the training, in which language and on which devices, and who supports the counters during the first stock count.

How edition, hosting and upgrade paths change the bid

Odoo Community is the open source core of Odoo, licensed under LGPL-3.0, and it covers the inventory application without a subscription. The trade-off is that several inventory-adjacent capabilities sit in the paid edition or in custom work, and the upgrade service is not available to Community databases. A partner bid therefore has to say which features are built, which are bought, and who maintains them after go-live.

Feature gaps: Confirm in writing which barcode, mobile and label functions are included, since Odoo's barcode app is documented as Enterprise-only in the related scanning topic.
Upgrade path: The Community edition has no access to Odoo's upgrade service, so the partner must state how a major version change would be tested and executed.
Custom code ownership: Ask who owns any custom modules and whether they are maintained against each new Odoo release.
Support boundary: Odoo's standard support and security patches apply to its supported editions, so confirm what the partner provides in their place and at what cost.
Hosting: Confirm where the Community instance runs, who patches the operating system and database, and how backups are restored.

Ask the partner to list each inventory feature as included, custom-built or unavailable, and to price the upgrade path as a separate line item.

What stock migration and count support should include

Opening stock balances are only as good as the item master, units of measure and locations they sit on. Before go-live, every item, unit conversion (for example, a case of 12 eaches), bin or location and opening quantity needs a reconciliation step against a physical count in the warehouse. Without it, a migrated system will show confident balances that do not match shelves, and the errors will surface later as failed picks, negative stock and valuation problems in accounting. Ask each bidder to describe how the reconciliation is run, who prepares the extract, and what evidence is kept for each opening balance.

In the migration deliverables, ask the partner to specify the source extract for each object (items, units of measure, locations, opening balances, open purchase and sales orders), the transformation rules applied, and the load tool used. In Odoo, ERPNext and OpenBoxes this usually means structured imports with validation and an error log, which ERPNext's Data Import tool supports for CSV or Excel files with downloadable templates. The bid should state how many trial loads into a non-production copy are planned, what each trial must prove (record counts, quantity totals, sample bin checks), and how the partner handles rejected rows. Ask for the count of trial cycles in writing rather than accepting a general statement about testing.

Decide before the first trial who signs off variances. A reasonable structure is the warehouse manager accepting quantity differences, finance accepting valuation differences, and the project lead logging any unexplained gap as an open defect with an owner. Ask the partner to provide a variance template, a cut-over count plan that freezes receipts and shipments during the count, and support during the stock count itself, including who is on site and who answers questions on the day. Confirm whether the partner's support covers the post-go-live period and how stock corrections made after cut-over are audited.

How a warehouse go-live sequence should be agreed in the bid

The sequence turns an inventory rollout into a set of gated phases, so each stage proves its data, devices and staff are ready before the next one begins. Agreeing it in the bid lets the buyer compare partners on evidence instead of promises.

Sign off requirements and data scope
The partner documents locations, warehouses, bin structure, units of measure, lot, serial and expiry rules, valuation method and the integrations in scope, then the buyer's operations, finance and IT leads sign the document. The partner should also state which items and stock balances will migrate, in what format and who owns the source data. The step closes when the signed requirements and a data scope register exist, and any change after sign-off goes through a written change request.
Build a test environment with migrated data
The partner loads a copy of the item master and opening stock into a non-production environment, using the import tooling of the chosen platform, and reconciles counts against the source system. Ask for the reconciliation report showing item counts, quantities by location and value totals, with every exception listed and assigned. The step is done when the buyer's warehouse lead confirms that sample pallets and bins match the physical location in the test copy.
Validate devices and labels on site
Engineers test the actual handheld scanners, mobile browsers, label printers and label templates in the warehouse, not on a lab bench, including scanning under real lighting, print speed and label durability. They also check the wireless coverage at the dock, racking and cold areas where the devices will work. The evidence to request is a signed test log listing each device model, firmware, label symbology and failure found, with the fix and retest result. Confirm the platform's barcode features and edition requirements in writing before the test.
Run a pilot at one location
The rollout goes live at one warehouse or site with a defined set of users, item families and transaction types, while the legacy process remains available as a fallback. The partner runs daily reconciliation between system stock and physical stock during the pilot and reports every variance by root cause. The step closes when the pilot exit criteria the buyer approved in advance are met, such as an agreed variance threshold, and the partner records the open defects with owners.
Cut over with a full physical count
Before the remaining sites switch, the partner and the buyer run a full physical count at each location and load the counted quantities as the opening balance, with a freeze on stock movements during the count window. The partner provides a cutover runbook with roles, rollback criteria and the decision owner for go or no-go. The evidence to request is the signed count sheets, the variance report between counted and expected stock, and the approval record for cutover.
Provide hypercare and handover
For an agreed period after cutover, the partner provides on-site or remote support, daily defect triage and floor-level help during the first counting cycles. The bid should state the support hours, escalation path and response expectations in writing, and whether support is fixed-scope or a retainer. The step ends with a handover pack covering configuration, runbooks, training records and open issues, accepted by the buyer's operations owner.

How to score partner responses

This table lists the criteria to score partner bids for an Odoo, ERPNext or OpenBoxes inventory rollout, with what a strong answer shows and where weak bids usually fall short. Score each criterion on a scale of 0 to 5 and set the weights yourself, based on which risks matter most in your warehouses. The main takeaway is that migration, device setup and stock count support usually decide go-live success more than the software choice itself.

Criterion	What a strong answer shows	Where weak bids usually fall short
Data migration method	Item and stock migration plan with field mapping, opening balance reconciliation, a trial load and sign-off by the warehouse team	Generic import promise with no reconciliation step or reference to the tool's batch limits
Device and label plan	Named scanner models, browser or app support, label templates and print test results for each location	Scanning described only as a feature, with no device list or label test
Edition and feature fit	Clear mapping of required features to the edition, with licensing cost per user or app confirmed in writing	Edition choice made without checking whether barcode or mobile apps need a paid tier
Upgrade and support path	Stated version policy, upgrade test plan and named support window for the chosen release	Upgrades treated as optional, or support dates not confirmed for the target version
Go-live approach	Phased cutover by warehouse with a rollback point, parallel running period and written go/no-go criteria	Single big-bang cutover with no rollback plan
Stock count support	On-site or remote support during cycle and full counts, with a variance review process and escalation path	Training delivered once before go-live and no support during the first counts
Training and handover	Role-based training for pickers, receivers and supervisors, with materials the client can reuse	Admin-only training with no floor staff sessions
Verifiable references	Named contacts willing to confirm scope, timeline and results, or documented projects the buyer can review	Anonymous logos or claims that cannot be checked

What buyers ask before hiring an inventory implementation partner

Buyers should ask for a fixed-scope quote built from a written list of what is included, and they should expect that quote to separate one-time work from recurring charges. For a self-hosted Odoo, ERPNext or OpenBoxes rollout, the cost components are the partner's implementation and data work, the software edition or subscription, hosting, barcode devices and label printers, training, and ongoing support. The software itself is not the largest unknown. Odoo's scanning and warehouse apps sit in the Enterprise edition, and the Odoo pricing page reports that only the Custom plan can be hosted on Odoo.sh or on-premise, so the edition decision changes the bill before any services work begins. ERPNext is free to self-host according to its pricing page, but the page also states that Frappe Cloud hosting and support plans carry monthly costs, and implementation is sold separately through certified partners. Ask the partner to show each of these lines separately, and to state which ones recur every year.

Timing and client effort are where stock-control projects most often slip. Ask the partner to name the data cleanup tasks it will own and the ones your staff must sign off, such as item master records, unit of measure rules, opening stock counts and locations. The ERPNext Data Import documentation advises importing only a few thousand records at a time, so ask how the partner plans batch sizes and reconciliation checks against your count sheets. Ask who will attend training, how many people will be trained, and whether training is delivered before or during the first physical count. Confirm the partner's plan for a parallel run or cutover window, and ask what your warehouse staff must stop doing while the cutover happens. The partner should be able to tell you in writing which decisions must be made by your side and by when.

Finally, ask whether your team can run the rollout without the partner after go-live, and what the partner will leave behind. A capable internal lead can own requirements, configuration sign-off and user support, but the partner should document the setup, the upgrade path and the rollback steps. For Odoo, confirm which version your quote covers and how long standard support runs for that version, since the Odoo support documentation sets different end dates for each release. For ERPNext, confirm that the version you choose appears on Frappe's supported versions page and whether your hosting plan matches it. Ask for a named handover list and a plan for stock count support during the first months, and treat a partner who cannot describe these items in writing as a risk to your project.

How DeployOpen scopes and delivers inventory evaluations and rollouts

DeployOpen plans, implements, customizes, integrates and documents self-hosted inventory platforms inside your own cloud accounts, data centers or air-gapped networks. For RFP questions, we start with a written scope that states which platform, edition, data sets, devices and sites are covered before any work begins.

How we scope

Written scope fixes the platform, edition, warehouses, item and stock data sets, and scanning devices in one document.
Stock count support, go-live approach and training audiences are listed as named deliverables with agreed acceptance criteria.
Engagements are fixed-scope, and ongoing support can be added later as a retainer.

How we build

Item and stock migration is tested on copies of your data, with reconciliation reports signed off before any cutover.
Label formats, printer setup and handheld browser configuration are tested against your actual warehouse hardware.
Odoo edition needs, such as barcode and mobile features, are confirmed against the vendor's current edition page before scope is signed.

How we hand over

Handover includes configuration records, data mapping files, device and label setup notes, and an operator runbook for your team.
Go-live steps, rollback points and stock count procedures are documented in a form your warehouse leads can follow.
Training sessions are delivered to warehouse staff, supervisors and administrators, with materials kept for later onboarding.

How we support

Support during stock counts and the first operating weeks is scoped in advance, with named contacts and escalation steps.
Platform upgrades are planned as separate work, with a test database checked before any production change.
Ongoing support, upgrades and continuous testing can be provided under a retainer agreed in writing.

Inventory management software RFP questions