Inventory management for low-resource and remote sites

Inventory management for low-resource and remote sites starts with the site, not the software

For a team running stock across sites with weak connectivity, intermittent power and no full-time IT staff, the choice turns on two questions: where the server runs, and how updates and data reach each site. OpenBoxes, Odoo and ERPNext each fit a different part of that answer, so the software decision should follow from the site model. Stock control at a remote clinic, depot or field office fails differently from a warehouse with a fixed link and an IT team. A dropped connection stops scanning, a power cut can lose an unsaved count, and nobody on site may be able to restart a failed service. DeployOpen plans and implements these systems inside the client's own infrastructure, so the hosting design and the update path are agreed before any product is selected.

Start with a site inventory. For each location, record the connection type and typical outage length, whether power comes from grid, generator or solar, how many users and handheld devices work there, and who will restart a server if it stops. These answers decide between one central server reached over a wide area link and a small server at each site that synchronizes when a link is available. Confirm with each vendor how its browser-based screens behave on a slow or interrupted connection, because a count screen that stalls mid-session is an operational failure, not a minor defect. Also check that the hosting you need is available under the edition you buy. The Odoo pricing page lists on-premise and Odoo.sh hosting only on its Custom plan, while ERPNext can run on Docker Compose or the bench tool on hardware you control.

Updates are the second constraint. Odoo's standard support covers the first three years after a major release, and the Odoo upgrade documentation describes major upgrades as mandatory every two years on Odoo Online and Odoo.sh, so a site that cannot take an upgrade in time can fall out of support. Odoo's upgrade service also requires an Enterprise subscription for on-premise use. ERPNext has its own cadence: it requires a listed version, and Frappe warranty coverage depends on a matching Frappe Cloud support plan. Frequent minor releases mean each site needs a defined update window. Before rollout, confirm how patches will reach sites without reliable links, test each release on a copy of the site database, and name the person who can run the upgrade when no one is on site.

Which requirements change when sites are remote

This table compares the requirements that shift when stock sites have weak connectivity, unreliable power or no local IT staff, and what each one asks of the build. Read each row as a question to answer in the design: where the control applies, what the assessor expects to see, and where remote deployments usually fail. The main takeaway is that remote sites add operational controls on top of the software choice, so the hosting model and administration path matter as much as the platform.

Requirement	What it means for the build	Evidence to keep	Where it usually fails
Offline or degraded-connectivity operation	Decide which stock movements must be recorded locally during an outage and how they sync back. Confirm whether the chosen platform and its browser or scanner clients tolerate intermittent links.	Documented outage behavior, sync test results, reconciliation reports after reconnection	Stock counts diverge between site and central records after a long outage with no reconciliation step
Local power resilience	Size UPS and backup power for the server, network equipment and any scanner charging point. Confirm graceful shutdown and restart behavior of the database and workers.	Power test records, shutdown runbook, restart checks on the database	Database corruption or stuck background jobs after unplanned power loss
Backup and restore at each site	Define where backups are stored, how often they run and who can restore without a vendor on site. Test restores on the remote hardware, not only in the central data center.	Backup logs, restore test reports, named restore owner per site	Backups exist but have never been restored, or they sit on the same device as the live data
Multi-factor authentication for remote administrators	Under 16 CFR 314.4, covered financial institutions must apply multi-factor authentication for any individual accessing an information system. Remote administrative paths, including vendor support sessions, need the same control.	MFA configuration for admin and vendor accounts, access review records	Local admin accounts or shared credentials used for emergency fixes at a site
Change management for remote updates	Under 16 CFR 314.4, change management procedures apply. Updates to distant servers need a tested package, a rollback path and a record of who approved each change.	Change tickets, staging test results, rollback steps, version inventory per site	Patches applied directly on a site server with no test copy and no record
Activity logging of authorized users	Under 16 CFR 314.4, the activity of authorized users must be logged. Logs from each site should reach a central store, or be kept locally and collected on a fixed schedule where links are unreliable.	Central or retained log exports, log retention settings, sample user activity reports	Logs stay on a single site server that is never collected, or log storage fills up unnoticed
Encryption in transit and at rest	Under 16 CFR 314.4, customer information must be encrypted in transit over external networks and at rest. Each site's disks, backups and sync links need encryption, including on portable media.	Encryption configuration per site, TLS certificate inventory, backup encryption settings	Unencrypted backup drives shipped between sites or sync traffic routed over an unmanaged link
Record retention for broker-dealer records	Under 17 CFR 240.17a-4, broker-dealers must keep certain records for at least three years, with the first two easily accessible. Confirm which inventory or transfer records count as covered and where copies live if a site is decommissioned.	Retention schedule, archive location, retrieval test	Archives kept on decommissioned hardware or in a format the current platform cannot read
Vulnerability testing across sites	Under 16 CFR 314.4, annual penetration testing and vulnerability assessments at least every six months apply absent effective continuous monitoring. Every remote site must be in scope, not only the central server.	Test scope listing each site, findings tracker, retest records	Remote sites excluded from scope because they are managed by a local contractor

Which platform fits which remote site pattern

OpenBoxes was developed around humanitarian supply chains, where stock moves between central warehouses, field stores and distribution points, and the people who maintain the system are often not full-time IT staff. Its focus on stock movement and tracking across locations makes it a natural first candidate when the main question is what is on hand at each site and how it got there. Confirm the current release details, supported database and hosting requirements, and how the software behaves on intermittent connections directly with the OpenBoxes project before you commit.

Field stock focus: Stock on hand, movements between locations and requisitions are central to the product, so site teams work in the same stock logic that headquarters uses.
Humanitarian origin: The project grew out of donated stock and distribution work, so its terms and workflows tend to match field operations.
Light administration: Fewer modules to configure means fewer settings for a small site team to maintain, although upgrades still need a named owner.
Accounting gaps: Sites that must keep their own general ledger or pay suppliers will need a separate system or an integration, so check this at the start.
Hosting decision: Choose between one central instance and per-site servers before buying hardware, since this decides backup, update and recovery effort.

Confirm how your device and label setup is documented for the sites you run, and who restores a site if its server fails.

Central server or per-site servers: how the deployment pattern changes

The number of servers and where they sit decides what happens when a link drops, a site loses power, or an update has to reach a facility with no IT staff. The four patterns below sit on a spectrum from full central control to fully local operation, and each one moves risk to a different place.

Central server with thin site connections

One hosted instance serves every site through browsers and handheld scanners. A typical ERPNext stack built from frappe_docker runs MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx on that server, and an Odoo deployment runs on PostgreSQL. Sites depend on a working link for every receipt, pick and transfer, so a dropped connection halts stock movement at that location. Check the bandwidth and latency each site really has, how scanners behave when the connection fails, and who operates the server and its backups. Plan the cost of one hosted server against the cost of many smaller ones.

Per-site servers synchronized to a hub

Each site runs its own server and pushes records to a central hub for consolidated stock and reporting. Sites keep working through a network outage, but the same item can be adjusted at two locations before the hub sees either change, which creates conflicts that someone must resolve. A hub outage delays consolidated reporting but not local work. Every site then needs its own patching, backups, and upgrade window, multiplying the staff time needed. Confirm with the vendor and in a tested build whether the chosen platform supports multi-site synchronization natively, because the supplied platform facts do not establish that capability.

Hybrid with local read-only caches

The central server holds the master item list, transactions and approvals, while each site keeps a read-only copy of item data and recent stock levels. Staff can look up items, check availability and print labels when the link is down, but they cannot post movements against the copy. The main risk is staleness: a cache refreshed once a day can show stock that has already left the building. Agree on the refresh interval, the size of the cached dataset, and what staff must do when the cache age exceeds an acceptable limit. Confirm how the chosen platform handles cached views and offline scanner data before scoping.

Local-only site servers reconciled by media

Each site runs a fully isolated server with no live connection to the hub. Stock counts and transactions travel to headquarters on controlled media and are reconciled on import. The ERPNext Data Import tool loads CSV or Excel files and updates existing records, but its documentation advises importing only a few thousand records at a time, so reconciliation batches need planning. Risks include reporting lag, duplicate counts from re-sent files, and version drift between sites. Define who signs off each reconciliation, how media is chain-of-custody tracked, and how a site recovers if its server fails before the last export.

Version support sets the update window

Every pattern needs a version plan because updates reach distant sites on a schedule, not on demand. Odoo 20.0 has standard support planned until September 2029, and Odoo's upgrade documentation makes major version upgrades mandatory every two years on Odoo Online and Odoo.sh. Frappe's supported versions policy lists version 15 through the end of 2027 and version 16 through the end of 2029. Plan one upgrade window per site for the central pattern and one per server for the distributed patterns. Ask the partner how many sites can be upgraded per window and how each site's update is tested before go-live.

Single-file demo setup is for evaluation only

frappe_docker publishes a single-file demo setup, and its documentation marks it for short-lived evaluation only. Teams sometimes promote a demo file into a site that runs stock movements for months, which skips the separate database, cache, worker, scheduler and proxy services that a production Compose stack provides. Use the demo to test scanner workflows and label formats, then build the production stack with backups, monitoring and a tested restore before any site depends on it. Ask the implementation partner to confirm which configuration each environment uses and to document the difference.

How a remote-site inventory rollout runs, phase by phase

The sequence moves a remote-site stock control system from a site survey to a tested, supported deployment, with a written output at each phase so that each decision is recorded before the next one begins. Each phase closes with a document or test result that the site and the implementation partner both sign off.

Survey connectivity, power and staffing
The implementation partner visits or interviews each site and records how it connects to the network, how stable power is, which equipment already exists, and who on site will run the system day to day. Site staff, local IT contacts and the partner's engineer complete the survey together. The output is an approved site profile that lists bandwidth and outage patterns, backup power, device inventory and named operators. Nothing else is decided until that profile is agreed.
Set requirements and choose the edition
Using the site profile, the client confirms the stock data it must hold, such as lot and expiry tracking, locations, units of measure and reporting needs, and decides whether the system runs centrally or on a server at each site. This is also where the team confirms which features the chosen platform needs and whether those features sit in a free edition or a paid one. The output is a signed requirements document and an architecture decision record that states where the servers sit and how updates will reach them.
Run a pilot at one site
The partner installs the platform at one representative site, configures the agreed locations and users, and runs real receiving, issuing and transfer transactions for a defined trial period. Staff use the actual network and devices the site has, so gaps in connectivity or scanning show up early. The pilot closes with a documented list of defects and workarounds, and a restore test that rebuilds the pilot database from a backup on separate hardware. The output is a tested restore and a go or no-go decision for wider rollout.
Count stock and import data in batches
Before go-live, each site performs a physical stock count, and the partner imports item masters, opening balances and supplier records in small batches. The ERPNext Data Import documentation advises importing only a few thousand records at a time, and the same caution applies to any platform used at remote sites with slow links. Each batch is reconciled against the count sheets and rejected rows are corrected before the next batch loads. The output is a signed count reconciliation for each site with variances explained.
Train staff on site
Trainers work in person or through a recorded, locally hosted session with the operators named in the site profile, using the site's own stock items, labels and devices. Training covers receiving, issuing, transfers, counts and the steps to take during an outage or failed sync. Each operator completes a short practical exercise on the live site copy, not on a demonstration database. The output is a training record per operator and a one-page local procedure card that stays at the site.
Cut over and set the update procedure
The partner switches each site to live use in an agreed window, freezes stock movements on the old method during the switch, and confirms the first day of transactions with the site lead. Before cutover, the update procedure is written and rehearsed, including how patches and version upgrades reach each site, whether by network or by media, and who approves them. The output is a cutover sign-off, a rehearsed update runbook, and a schedule for the first post-go-live review.

How training and updates reach distant facilities

Remote sites need training that a storekeeper can finish without a trainer on site. Write short role guides for receiving, issuing, stock transfers and counts, each tied to the exact screens, barcode steps and approval rules configured at that site. Keep copies on a local file share or a USB drive so the guides remain readable when the connection to the central server fails. Test them before go-live by having a person who has not been trained complete a receipt and a count using only the guide. Confirm with your implementation partner who writes the material, who owns it after handover, and how it is revised whenever the configuration changes.

The update cadence depends on the hosting model. Odoo SaaS versions are released every two to three months and cannot use extended support, so a site on Odoo Online must absorb those releases on the vendor's timetable. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. For self-hosted Odoo Enterprise, you choose the timing, but standard support covers the first three years after a major release, and security patches are provided only during standard support. Odoo 20.0 is supported under standard support until September 2029, so build a dated upgrade calendar from these windows and confirm the current terms in the Odoo support documentation.

For self-hosted systems, every update is a change management activity: a written request, an approval, a test on a copy, a rollback plan, and a dated rollout. Odoo documents duplicating a database with neutralization for test copies, and its upgrade service moves a database to a newer supported version through an upgraded test database that should be tested before production. On-premise use of that service requires an Enterprise subscription. Test the copy against the stock counts, transfers and barcode workflows that matter most to remote sites, then schedule production changes for a window when those sites can accept a short outage. Ask your partner to document the rollback steps and who can carry them out without a network connection to the central team.

Evidence auditors and regulators ask for from remote stock records

This table maps each piece of evidence an assessor or regulator is likely to request for remote stock records to the component that produces it. Read each row as a question to answer before go-live: which system generates the record, and who can show it for every site. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit reports or attestations.

Evidence item	Component that produces it	What an assessor typically checks	Where it usually fails at remote sites
Access logs for authorized users	Application audit log and the host's operating system logs	Who accessed stock and financial records, when, and from which account	Logs stay on a local server and are never collected centrally
MFA configuration for system access	Identity provider or the application's login settings	MFA is enforced for every user who can reach an information system	Local accounts or shared site logins bypass the central identity setup
Change records for software updates	Version control, deployment records and the upgrade test log	Each update was approved, tested on a copy and dated	Updates applied by hand at a site with no record of the version run
Backup and restore test results per site	Backup job logs and restore test reports from each site server	Restores were tested, not only backups scheduled	Backups exist but no site has restored one in recent memory
Penetration testing and vulnerability assessment records	Independent test reports and scan outputs covering every hosted site	Testing at least every six months where continuous monitoring is absent (16 CFR 314.4(d)(2))	Remote servers are left out of scope or scans are not run on them
Retained stock and financial records	Inventory ledger, stock movement history and accounting export archive	Records kept for the required period and readable on request	Archives sit on failing local disks or in formats no one can open
Encryption of data in transit and at rest	Site server disk encryption, TLS settings and sync links	Customer or financial data is encrypted over external networks and on disk	Sync traffic over satellite or mobile links falls back to unencrypted paths
Activity records for offline transactions	Queued transaction log and the sync reconciliation report	Stock changes made offline were replayed once and attributed to a user	Offline entries are merged without a trace of who made them

What do remote-site inventory projects cost and need from our team?

What drives the cost of a remote-site inventory project?

Cost is driven by the edition you choose, the number of sites, how each site is hosted, the devices and labels you need, the volume of data to clean up, and the training and support you buy. Open-source self-hosting has no license fee for the community editions. The Frappe documentation says self-hosting ERPNext is free, so the main costs are implementation, hosting, devices, and staff time. Odoo's pricing page lists Standard and Custom plans with per-user monthly prices, and only the Custom plan can be hosted on Odoo.sh or on-premise, which affects the edition decision. Ask any partner to itemize each cost separately in a written quote.

Can a small IT team run remote-site inventory on its own?

A small team can run a stable system if it has someone who can apply updates, back up the database, and manage user accounts. The harder part is covering several sites with little local IT. Odoo's standard support covers the first three years after a major release for on-premise use, and Frappe's supported versions policy requires you to be on a listed version and subscribed to a matching support plan to receive warranty coverage. Confirm who will handle patching, restores and off-hours incidents before you decide who owns the platform.

How long does a remote-site inventory rollout take?

The duration depends on the written scope, so there is no standard timeline to quote. A rollout usually depends on the number of sites, how many item and stock records need migrating, whether devices and labels must be configured, and how many training visits are included. Ask for a phased plan with a pilot site, a go-live for each later site, and a stock count milestone for each location. Treat any duration given without a written scope as an estimate, not a commitment.

What do site staff need to provide during the project?

Site staff need to confirm current stock counts, review item lists and locations, run a supervised count on go-live day, and attend training on the screens and devices they will use. Staff who work the receiving and issuing points should test scanning and label printing before cutover. Ask the partner to name the site contact for each location and to agree in writing how many staff hours and visits are expected from each site.

Does the inventory platform work offline at remote sites?

Self-hosted ERP systems are web applications that need a reachable server, so a site with an unreliable link needs a plan. Options include hosting a server at each site, running a central server that sites reach over a link with local caching, or using a mobile or offline mode if the chosen edition provides one. Odoo's barcode app is listed as an Enterprise feature, so confirm offline scanning support for the edition you select before relying on it. Test the failure case with the real link and power conditions.

Can DeployOpen deliver a remote-site inventory project on a fixed scope?

Yes, DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask for the list of sites, the item count, the device types and the training visits to be written into the scope document.

What should I ask for in a remote-site inventory quote?

Ask for a line-by-line quote covering the edition and license, hosting for the central server and any site servers, devices, label printers, data migration and cleanup, training, travel, and post-go-live support. Ask which costs recur each year and which are one-time. Also ask how updates reach distant sites, how backups are tested, and what happens when a site loses connectivity during a stock count. A quote that leaves these items out is incomplete.

What to ask an implementation partner before a remote-site rollout

Start by asking how the partner tests restores at each site, not only at the central data center. Ask for the restore test plan, who runs it, how often it is repeated, and whether a restore has been performed on a copy of a remote site's database over the same limited link and hardware that site will use in production. Ask how long the restore took in practice and what the partner does when it fails. A backup that has never been restored at the site it protects is an assumption, and remote sites are where that assumption breaks first. Ask the partner to show the written runbook for a full restore and the evidence from the last test.

Next, ask how updates reach a site with no IT staff. Ask who applies patches and minor releases, who pre-tests them, whether an updated copy of the database is checked before it goes live, and what happens if a update fails halfway through a power cut. Ask whether the partner will deliver updates by media or over a link, how the site confirms a successful update, and how a rollback works. Ask which edition and support window the partner recommends and how that aligns with vendor timelines. For Odoo, confirm that the chosen edition supports on-premise deployment and the planned support end date for the version you select. For ERPNext, confirm that the version is on the supported list and whether a Frappe Cloud support plan is required for warranty coverage. Finally, ask what the partner will hand over for training and runbooks: site-level quick guides, a stock count procedure that works offline, role-based training for the site storekeeper, and a written escalation path.

How DeployOpen scopes and supports remote-site inventory

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For remote-site inventory, that means fitting the stock system to the connectivity, power and staffing each site actually has, with the written scope agreed before work starts.

How we scope

Map every site's connectivity, power and on-site IT support before choosing a central or per-site server model
Define which stock movements must work offline and which can wait for a sync window
Record the update path for each facility, including how patches reach sites without reliable internet
Agree in writing which platform edition, devices and label printers the scope includes

How we build

Deploy the chosen platform on the client's own servers, cloud accounts or isolated networks
Configure locations, bins, units of measure and any lot or expiry tracking the site needs
Test stock transfers, receipts and counts against the agreed remote-site workflows before go-live
Harden access, backups and logging so each site's data is recoverable after a power or link failure

How we hand over

Deliver installation, configuration and integration documentation written for the client's own IT staff
Provide training materials for site storekeepers and central stock managers, adapted to each location
Document the backup, restore and update procedures, including the steps for media-based or delayed updates
Hand over the test results and configuration records needed for internal review or a compliance assessment

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers
Plan post-go-live support around stock counts, reporting cycles and site visits agreed in advance
Review platform release notes and support windows so upgrades are scheduled before versions reach end of support
Confirm with the client which support hours, response paths and escalation contacts apply to each site

Inventory management for low-resource and remote sites