Why Odoo for distributors and wholesalers starts with stock, purchasing and pricing
Odoo's Inventory, Purchase and Sales apps can run a distributor's core workload, with many SKUs, several warehouses, supplier terms, customer-specific prices and orders from more than one channel, in one database. Whether that works for your business depends on how you move stock and money, so the design starts with those flows rather than with the app list. Before any build, map where stock is held, who decides when to buy, how supplier terms are agreed and how a price is chosen for each customer.
For operations, the first decisions concern locations and replenishment. Confirm how many warehouses hold saleable stock, whether transfers between them need approval, and which team sets reorder points and minimum quantities for each SKU. Check how supplier lead times are recorded, because replenishment is only as reliable as those dates. Ask who will count stock, how often, and how adjustments are approved, since those rules determine whether the on-hand figures can be trusted by sales and purchasing.
For purchasing and finance, the key questions concern cost and valuation. Agree with finance which costing method and valuation approach will apply to each product category, and how freight, duties or other landed costs are allocated to received goods. Set up vendor pricelists and purchase agreements that match the terms your buyers negotiate, and decide how receipts are matched to supplier bills. Finance will also need a clear rule for when a received quantity becomes an accounting entry, because that timing affects month-end stock values.
For sales, customer-specific pricing is where most distribution projects gain or lose ground. Confirm how many price levels you need, whether they follow customer groups, contract terms or channels, and who may override a price on an order. Multi-channel orders need one stock position that every channel reads from, with a rule for which warehouse fulfills each order. Ask the sales lead to test a sample of negotiated prices end to end before go-live, using real customer contracts as the reference.
The Food distribution and Beverage Distributor packages are starting points, not finished solutions. Each package bundles settings and sample data for a sector, and your product structure, unit of measure rules, tax setup and excise or deposit handling still need to be confirmed against how your business operates. Note also that Odoo's pricing page places multi-company, custom modules and hosting on Odoo.sh or on-premise in the Custom plan, and that Odoo Online and Odoo.sh require major version upgrades every two years. Confirm these constraints with Odoo before you choose a hosting model.
Distribution requirements and what they mean for the build
This table maps the core requirements of a distribution business to the Odoo sources that set their limits and to the decisions each one forces on the build. Read each row as a question to answer in discovery: the source shows where Odoo's packaging, plans or documentation constrain the design, and the last column shows what your team must decide or test. Your own stock, tax, deposit and carrier rules determine the final configuration, so confirm them before any quote is agreed.
| Industry requirement | Source | What it means for the build |
|---|---|---|
| Multi-warehouse stock across distribution centers and branches | Odoo Inventory app; Odoo pricing page | Decide whether branches are warehouses within one company or separate legal entities. Separate entities bring in multi-company, which the pricing page places only on the Custom plan. Confirm warehouse and transit location structure in discovery. |
| Purchasing and replenishment rules by warehouse and supplier | Odoo Inventory and Purchase apps; confirm edition for replenishment features | Map your reorder points, supplier lead times, minimum order quantities and approval steps as configuration. Confirm which replenishment features in the version you select are Community or Enterprise only before scoping. |
| Dropshipping, where suppliers ship directly to customers | Odoo Sales and Purchase apps; Odoo pricing page for plan limits | Decide which orders route to suppliers and how supplier confirmations and invoices are matched to sales. Confirm the routing behavior in the target version and whether it depends on an Enterprise feature. |
| Shipping carrier and marketplace links | Odoo pricing page (external API access on Custom); Odoo and Odoo Community Association connector documentation | Choose between a published connector and a custom integration for each carrier and marketplace. External API access is available on the Custom plan, so confirm API needs and rate limits with each provider before planning the integration. |
| Excise and deposit handling for beverage distribution | Odoo Beverage Distributor package; your tax advisor's written rules | Confirm what the package configures out of the box, then define each excise and deposit rule as tested configuration in a test database. Rates and thresholds come from the jurisdiction and your advisor, not from this build plan. |
| Food distribution needs such as lot, expiry and recall lookups | Odoo Food distribution package; confirm feature edition | List the traceability, expiry and recall reports your customers and regulators require. Confirm which lot, serial and expiry features the package includes and whether each is available in your chosen edition. |
| Upgrades that must not break integrations or custom modules | Odoo standard and extended support docs; Odoo upgrade docs | On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so each connector and custom module needs a test upgrade plan. Confirm the support end date for your target version before setting the upgrade schedule. |
Which Odoo edition and hosting a distributor needs
The first decision is which edition the business runs. Odoo offers a fully open source Community edition, licensed under LGPL-3.0 and published on GitHub, and a paid Enterprise edition that adds features and support. The Enterprise source code is not publicly available and requires a subscription or partner access. For a distributor, the edition question comes down to the features that multi-warehouse Inventory, purchasing, dropshipping, shipping carrier links and the Food distribution or Beverage Distributor packages depend on. Confirm that list before any plan is chosen, because an edition decision made early is expensive to reverse later.
Odoo's pricing page lists three plans: One App Free, which covers one app with unlimited users on Odoo Online only, Standard, which covers all apps on Odoo Online only, and Custom. According to the pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise. Only Custom includes multi-company, Odoo Studio, external API access and custom modules. A distributor with several legal entities that share stock or invoicing, or with marketplace links that call Odoo through its external API, will usually need to look at Custom. Check each requirement against the current plan description, since feature placement is set by Odoo and can change.
Hosting follows from the plan. If the business must keep its data in its own cloud account, data center or a network with no internet access, Odoo Online is ruled out and the choice narrows to Odoo.sh or on-premise under Custom. On-premise Enterprise databases are activated with a subscription code, and Odoo documents both packaged installers and source installation. The Community edition has no access to Odoo's upgrade service, so a team that starts on Community will need a separate plan for version changes. Ask who will apply upgrades, where test copies will run, and how the business will move between hosting types if its needs change.
Before the quote, build a short written list. For each warehouse, marketplace, carrier, payment and bank connection, record the Odoo app or package it depends on, the edition it appears in, and whether it needs a Custom feature. Add the number of legal entities and the number of users in each group. Per-user monthly prices and the yearly discount are published on Odoo's pricing page and are not repeated here, so the quote should state which plan, user count and billing period it assumes. Ask the partner to show which requirements, if any, would force a higher plan, so the budget reflects the features the business actually uses.
Configuration that matters for distributors
Distribution businesses rarely struggle with the first screens of Odoo. They struggle where stock locations, purchasing terms, sales channels and tax rules meet. The cards below name the decisions to settle before configuration starts and the checks a partner should run in a test database before anything reaches production.
Multi-warehouse inventory and replenishment
Before configuration, decide how many warehouses, transit locations and storage structures you need, which warehouse serves which customer region, and whether stock moves in one step or several. These answers shape Odoo's locations, routes and replenishment rules, so changing them later is costly. In a test database, create sample receipts, internal transfers and deliveries across each warehouse, confirm that routes pick the intended source location, and check that reordering rules raise purchase needs at the expected minimum quantities. Confirm which of these features your chosen edition includes.
Purchasing and vendor terms
Decide who may create purchase orders, which approval thresholds apply, how vendor price lists are maintained, and which payment terms and currencies each supplier uses. Supplier lead times and minimum order quantities feed replenishment, so inaccurate vendor data produces poor buy suggestions. A partner should test a full cycle in a test database: request, purchase order, receipt, vendor bill matching, and a price change that updates the next order. Also check how partial deliveries and returns to vendors post to stock and accounting.
Dropshipping routes
Decide which products ship directly from a supplier, how that supplier confirms dispatch and receives customer delivery details, and who owns returns. Odoo's dropshipping setup connects a sales order to a purchase order, so one product can be stocked in one warehouse and shipped by a vendor elsewhere. Test each product type in a sandbox. Confirm that a sale creates a purchase to the correct vendor, that stock valuation and invoicing stay correct, and that the customer receives tracking. Confirm the supplier integration method before scoping it.
Carrier and marketplace connections
Decide which carriers you ship with, which marketplaces and sales channels send orders, and which system owns order status, stock levels and tracking numbers after each handoff. Every connection needs a named owner for failures such as duplicate orders or stock counts that drift apart. Confirm each carrier and marketplace against Odoo's connector listings and the Odoo Community Association documentation before assuming support, because availability varies by connector. In a test database, verify label generation, tracking write-back, cancellations and stock sync after a return.
Food distribution package
Decide which products carry lot numbers, expiry dates or shelf-life rules, and how picking should respect them. Traceability must run from customer deliveries back to supplier receipts, so recall requirements shape the lot design. Confirm what the Food distribution package installs, which of its features need the Enterprise edition or the Custom plan, and which handling or labeling needs your business requires that would need custom development. In a test database, run a recall trace from a customer delivery to the receiving lot and check that expired lots are blocked from picking.
Beverage package with excise and deposits
Decide which excise regimes apply to each product and jurisdiction, how duty is calculated and when it becomes payable, and how returnable containers and deposits are recorded across invoices, stock and credit notes. Excise and deposit rules vary by jurisdiction, so confirm them with your tax advisers and the Odoo localization for your country before configuration begins. A partner should test a sale, a container return and a credit note in a test database, confirming that duty and deposit amounts post to the correct accounts and appear correctly on the reports your authority or customers require.
How excise and deposit handling is scoped before the build
Excise duties and returnable deposits change what a sale costs, what appears on an invoice, how stock is valued and how a return is reversed. Because each of these touches several parts of Odoo at once, the mapping of excise and deposit rules to the business's real transactions should be completed before anyone configures taxes, products or valuation. A configuration built on assumptions tends to fail first on the returns desk or at the month-end close, when the numbers stop agreeing with what was actually shipped and collected.
Start with a short working session with the finance and tax team. Settle which products are subject to excise and which jurisdictions apply to each shipping point, including whether duty is due on the move between warehouses, on sale to a licensed customer, or on export. Ask who determines the rate when a product changes strength or pack size, and how exemptions are evidenced. Write the answers down product by product, because the Beverage Distributor package and the Food distribution package are starting points that encode general assumptions, not a ruling on your tax position.
Next, settle how deposits are recorded and refunded. Decide whether a returnable container is a product line, a separate deposit item, or a tracked asset held on the customer's account. Confirm when the deposit becomes a liability, when it is released, and whether a refund is paid in cash, credited to the account or netted against the next order. Each choice drives the accounts used, the stock moves for empties and the way a partial return is credited. Ask the finance team to walk through three or four returns of different ages and condition, since those cases expose the gaps.
Also list the reports the business must produce before the build starts. Typical examples are excise returns for each authority, deposit liability schedules, reconciliations between stock valuation and the general ledger and customer statements showing deposits held. For each report, record the source fields, the owner who signs it off and the frequency. Your Odoo partner can then check whether standard reporting covers the requirement or whether a custom report is needed, and that decision affects the scope and the quote.
Treat the Beverage Distributor package as a starting point to be tested, not accepted. Duplicate the production database into a test environment, using the database duplication option with neutralization that Odoo documents for test copies, so that live customer and email data is not exposed. Then run a fixed set of real transactions through the copy: standard sales, partial and full returns, deposit refunds, transfers between warehouses and a period close. Compare each result with the figure the tax team expects. Confirm the exact duplication and neutralization steps against Odoo's on-premise documentation for your version before you rely on them.
Compliance considerations for distribution businesses
Distribution businesses carry tax, excise, payment and access obligations that vary by country and product. The cards below set out what each area covers in Odoo and what to confirm before go-live. Tax and regulatory requirements must be confirmed with your advisers and the relevant authorities.
Fiscal localization for your country
Odoo's fiscal localization packages set the chart of accounts, tax groups and tax reports for a specific country. For a distributor, the rules that matter most usually apply to purchases, sales, intra-company transfers and goods shipped across borders. Confirm with your tax adviser which localization your entity needs, which tax returns Odoo produces for it, and which returns you still prepare outside Odoo. Test with sample transactions before you rely on the output.
Excise and deposit reporting
Beverage and food distributors often owe excise duty and must track returnable container deposits, and both affect invoices, stock valuation and periodic returns. Odoo's Beverage Distributor and Food distribution packages cover excise and deposit handling as starting points. Ask which duty rates, deposit types and report formats your authority requires, and whether Odoo generates them directly or a separate export is needed. Confirm how each product maps to its duty and deposit category before go-live.
Electronic invoicing where mandated
Some countries require distributors to issue electronic invoices in a prescribed format or through a clearance or exchange network. Odoo's electronic invoicing for these mandates is covered on the Odoo compliance and Odoo features pages on this site, so this card focuses on what to check. Confirm whether your jurisdiction mandates e-invoicing for your sales, which format and channel apply, and whether the feature is available in your edition, version and hosting type. Plan test submissions before the first live invoice.
PCI DSS scope for online payments
If your eCommerce site or customer portal takes card payments, the design of the payment flow determines how much of your environment falls within PCI DSS scope. Redirecting customers to a hosted payment page generally keeps card data out of your systems, while handling card numbers on your own pages expands scope considerably. Identify the payment provider, the integration method and every system that stores, processes or transmits account data. Confirm the final scope with your qualified assessor.
Access controls and sign-in options
Odoo documents sign-in through LDAP, Google Sign-In, Microsoft Azure OAuth and two-factor authentication. LDAP can also create a user on first login from a template, which changes how joiners and leavers are provisioned. Decide which identity source is authoritative for office staff, drivers and warehouse users, and confirm which methods your Odoo edition and version support. Document who can change access rights, and test the removal of a leaver's access before go-live.
Evidence and assessment boundaries
DeployOpen configures Odoo, documents the controls and collects the evidence that auditors and assessors typically request. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those decisions. Ask each assessor which evidence they expect for each control before the build starts. Agree in the written scope which artifacts DeployOpen will deliver and who keeps them.
Rollout phases for a distribution implementation
The sequence moves stock, purchasing, pricing and channel rules from how the business runs today into a tested Odoo configuration, then cuts over warehouse by warehouse or entity by entity with support in place afterward. Each phase closes with a written output that the next phase depends on.
Map stock flows, purchasing, pricing and channels
The implementation partner and your operations, purchasing, finance and sales leads walk through how goods move today, from supplier receipt through putaway, replenishment, picking, shipping and returns, and how prices, discounts, and customer channels are set and applied. The output is a process map for each warehouse and entity, with the gaps between current practice and Odoo's standard flows listed as decisions for the business to make. The phase is complete when the process owners have signed off on the maps and the open decisions have named owners.
Decide the edition and hosting model
Before any build starts, the team confirms which Odoo edition and hosting type fit the required apps, multi-company and multi-warehouse needs, custom modules, external API access and integrations. Odoo's published pricing states which plans can be hosted on Odoo.sh or on-premise and which features each plan includes, and the decision also depends on the Enterprise subscription terms and the support window of the chosen version. The output is a written decision record covering edition, hosting, environments and the upgrade path, which the quote and the project plan both reference.
Plan data migration and cleanse master records
Product, supplier, customer, pricing, opening stock and open order data are inventoried from the source systems, and the team agrees which records move, which are archived and which are not needed. Duplicate products, inconsistent units of measure, stale supplier terms and incomplete customer addresses are corrected in the source before extraction where possible, and the mapping from old fields to Odoo fields is documented. The phase closes when the cleansed extracts pass the agreed checks and the business has signed off on opening stock counts for each warehouse.
Configure Odoo and build any custom modules
The team configures warehouses, locations, routes, replenishment rules, purchase and sales settings, price lists, taxes, and the accounting setup that matches the process maps. Where standard apps do not cover a required rule, such as an excise or deposit calculation, a special approval path or a bespoke report, the partner designs and builds a custom module under version control and documents it for the internal team. The output is a configured test environment and a list of custom modules with their owners, dependencies and upgrade notes.
Build integrations for carriers, marketplaces and banks
Connections to shipping carriers, marketplaces, banks and any other external systems are built against the agreed interface specifications, with credentials held in the client's secrets store and not in the database. Each integration is tested for failed calls, duplicate messages, rate limits and reconciliation of amounts and statuses, and the team confirms which side owns error handling. The phase is complete when each integration has a documented data flow, a runbook for failures and a successful run of its test scenarios.
Validate the test database with real transactions
A copy of the production data is loaded into a test database, with outbound email, payments and external calls disabled, and the business runs real orders, receipts, transfers, returns, invoices and payments through the configured flows. Stock levels, costing, tax and ledger balances are compared with the source system and the discrepancies are resolved and retested. The output is a signed validation record listing each scenario, its result and any known exceptions that the business accepts before go-live.
Cut over by warehouse or entity
The cutover runs in the order agreed in the plan, either one warehouse or legal entity at a time or all at once where the business has chosen that approach. The team freezes transactions in the source systems, performs the final data load and reconciliation, switches integrations on, and confirms the first live orders and receipts with the operations teams. The phase closes when stock, open orders and ledger balances match the agreed checkpoint, and the rollback decision window has passed without a rollback being required.
Provide post-go-live support and handover
After cutover, the team monitors transaction volumes, integration logs and month-end reconciliations, resolves defects and handles change requests according to the support arrangement set in the written scope. Internal administrators receive documentation, training and runbooks for configuration changes, backups and upgrades, and the handover includes the schedule for the next Odoo version upgrade. The phase is complete when the support terms are closed out or moved to an agreed retainer, and the internal team has run a full month-end without escalation.
Which Odoo version to go live on and how upgrades are planned
Choose the Odoo version by how long it will receive support across the life of your distribution operation, not by which release is newest on launch day. Odoo 20.0 was released in September 2026, with standard support planned until September 2029. Odoo 19.0 (September 2025) is planned for standard support until September 2028, and Odoo 18.0 (October 2024) until September 2027. Odoo 17.0 standard support ended in September 2026, so a project that starts on it would begin without standard support coverage. Map these dates against your go-live date, your warehouse rollout schedule and the years you expect to run the system before the next major change.
Standard support covers security updates and bug fixes on Odoo Online, Odoo.sh and on-premise. Security patches are provided only during standard support, which makes the end date the practical deadline for any version you run. For a distributor, that deadline should sit well after the point where multi-warehouse stock, replenishment rules, carrier and marketplace connectors, and any excise or deposit configuration are stable. Ask the vendor to confirm the planned end date for your chosen version at contract time, and check whether your hosting type and plan have access to any extended support option, since Odoo documents that paid extended support is limited to Odoo.sh for select versions and to on-premise.
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so a go-live on a version with a three-year standard window still means a forced upgrade within the project's first operating cycle. Odoo's upgrade service moves a database to a newer supported version by producing an upgraded test database, which you should test before the production upgrade. Budget for that test database as a planned project item, not an afterthought. Testing effort typically covers stock valuation, open purchase and sales orders, replenishment and reordering rules, shipping carrier and marketplace connections, Food Distribution or Beverage Distributor configuration, and any custom modules you have added. Community edition has no access to the upgrade service, and on-premise use of the service requires an Enterprise subscription.
Before you sign, confirm in writing which Odoo version the scope is built on, its planned support end date, and the hosting type you need. Odoo's pricing page indicates that only the Custom plan can be hosted on Odoo.sh or on-premise and that multi-company, Odoo Studio, external API access and custom modules are included only in that plan, so check that the plan matches your warehouse structure and integrations. Ask whether the upgrade test database, its testing and the porting of custom modules are in the fixed scope or priced separately, who runs the production upgrade, and how the upgrade is scheduled around your stock counts and month-end close.
Questions distributors ask before hiring an implementation partner
What drives the cost of an Odoo distribution project?
Scope is the main driver. The number of warehouses, legal entities, currencies and price lists, the integrations with carriers, marketplaces, banks and accounting tools, and the volume of data to clean and migrate all change the effort. Data quality matters as much: duplicate products, inconsistent units of measure and incomplete customer records add cleaning work before configuration starts. Custom modules add development and testing effort beyond configuration. Licensing is a recurring cost. Odoo's pricing page lists per-user monthly plans, and on-premise or Odoo.sh hosting requires the Custom plan, which also includes multi-company, Odoo Studio, external API access and custom modules. Ask the partner to separate one-time services from recurring licenses, hosting and support in the quote.
Can a distributor implement Odoo with its own team?
Yes, for simple scopes. A single-warehouse distributor with standard sales, purchasing and inventory flows can often configure Odoo with its own staff, using Odoo's documentation and a test database to try changes before they reach production. The work becomes risky when it touches excise duties, container or bottle deposits, or links to carriers, marketplaces and banks. These rules vary by jurisdiction and fail in ways that ordinary testing can miss, so a specialist should review the design and test cases. Plan for an internal owner who understands the business rules, a testing period using real order samples, and a process for future upgrades. Confirm your team's capacity before you commit to a date.
How long does an Odoo distribution implementation take?
No single figure applies, so duration depends on the written scope. The main inputs are the number of warehouses and entities, the integrations in scope, how much master data must be cleaned and migrated, whether custom modules are needed, and how quickly the business can make decisions in each phase. Delays most often come from unresolved pricing and tax rules, slow sign-off on test results and data that is not ready for migration. Ask for a phased plan with start and end points for each phase, the testing windows and the conditions for go-live. Identify which items depend on your team, and make sure any timeline you receive traces back to the scope document.
What must the business provide before an Odoo project starts?
Process owners come first: people who can decide purchasing, replenishment, pricing and returns, and who will sign off test cases. Clean master data is next, including products, units of measure, customer and supplier records, price lists and opening stock counts. The business must also decide pricing and tax rules, including how discounts, excise and deposits are calculated, and provide access to carriers and marketplaces through credentials, sandbox accounts and technical documentation. Someone must own the test database and user acceptance testing, and the business should name who approves changes after go-live. Missing any of these usually moves dates, so list each item in the project plan with a named owner.
Do we need Odoo Enterprise or the Custom plan for distribution?
It depends on your hosting, entity structure and integrations. Odoo's pricing page lists Standard as all apps on Odoo Online only, so a distributor that needs on-premise or Odoo.sh hosting must use the Custom plan. Custom also includes multi-company, Odoo Studio, external API access and custom modules, which multi-entity distributors and those integrating through the API commonly need. Enterprise is a separate question tied to the edition. Its source code is not publicly available and requires a subscription or partner access, and on-premise use of Odoo's upgrade service requires an Enterprise subscription. The Community edition has no access to that service. Check the current pricing page and app list against your processes before you choose hosting, because that choice shapes the rest of the architecture.
Why do excise and deposit handling need specialist review?
Excise and deposit handling change how prices, invoices and stock movements are recorded, and errors often surface late, at month-end close or tax filing. Odoo's Beverage Distributor and Food distribution packages give a starting point, but the rules depend on your jurisdiction, product categories, and how returnable containers or items move between warehouses and customers. A specialist should review the tax mapping, the deposit product structure, return flows and reporting outputs against your local requirements. Test with real transactions, including partial returns, credit notes and multi-warehouse transfers. Confirm with your tax advisor which rules apply, and document each decision so future upgrades and module changes can be tested against it.
What should a quote for an Odoo implementation include?
A useful quote lists phases, deliverables and acceptance criteria for each one. Look for separate lines for discovery and process mapping, configuration, data migration with cleaning rounds, integrations with their test plans, training and go-live support. Ask for a test plan that covers order-to-cash, procure-to-pay, replenishment, returns and any excise or deposit cases, with the owner of each test. The upgrade plan should name the target version, the test database process and the support window. Odoo's standard support covers three years after a major release, and major upgrades on Odoo Online and Odoo.sh are mandatory every two years, so ask how upgrades will be scheduled. DeployOpen works from a fixed scope agreed in writing before work starts. Also request the support terms: channels, hours, inclusions and anything billed separately.
Which Odoo version should a distributor target for a new project?
Target a version whose standard support runs well beyond your planned go-live. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are only provided during that period. Odoo 19.0 has standard support until September 2028, and Odoo 17.0 standard support ended in September 2026. Extended support is limited to Odoo.sh for select versions and to on-premise, and SaaS versions cannot use it. A rollout started on a version near the end of its support window often triggers an upgrade project soon after go-live. Check the support dates when you select the version, and ask the partner for a written upgrade plan that names the next target and the test window.
How DeployOpen scopes and delivers a distribution implementation
DeployOpen plans, implements, customizes, integrates, documents and supports Odoo inside your own cloud accounts, data centers or air-gapped networks. For distribution businesses, the work starts with the stock, purchasing, shipping and excise or deposit rules you run today, and is written into a fixed scope before any build begins.
How we scope
- Engagements are fixed-scope, with the warehouses, companies, product rules and carrier links agreed in writing before work starts.
- Scope maps how stock moves across multiple warehouses, including purchasing, replenishment and any dropshipping flows you need.
- Scope states whether the Food distribution or Beverage Distributor package, with its excise and deposit handling, is a starting point or a custom design.
How we build
- Configuration of Inventory, purchasing and replenishment rules is built and checked against sample orders from your own catalog.
- Shipping carrier and marketplace connectors are built or configured, and each is tested with live-style transactions in a test database.
- Custom modules are limited to gaps the written scope identifies, and each one is documented and tested before it reaches production.
How we hand over
- Handover includes the written configuration record, integration notes and runbooks for warehouse and purchasing staff.
- Test copies are made by database duplication with neutralization, so integrations do not send live orders or messages from non-production systems.
- Your team receives an upgrade plan that accounts for Odoo's version support windows and the upgrade service test-before-production step.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the implementation.
- Upgrade work follows Odoo's documented path, with an upgraded test database checked by your team before any production cutover.
- Confirm with Odoo which version your edition supports, since standard support windows and extended support options differ by edition and hosting.
