Odoo Inventory, Philippines

Designing routes for goods that travel by sea

In Odoo, a route is the chain of steps stock follows, such as receive, store, pick and ship, or hub to branch. For a Philippine network the important design work sits between warehouses. I usually set up resupply so a branch can be replenished from the hub automatically by reordering rules, with three visible stages: picked and dispatched at the hub, on the vessel, and received at the branch.

Points to settle with your logistics lead:

• Who owns stock at sea. If the shipping line or forwarder is responsible during the voyage, a transit location per lane makes losses and claims easier to trace.
• Partial and damaged arrivals. Branch receipts must allow short or damaged quantities, with the difference sent to a claims location rather than written off immediately.
• Lead times by lane. A Cebu branch and a Mindanao branch need different replenishment lead times, and typhoon season can stretch both; I agree a review routine rather than a fixed number.
• Direct-to-branch imports. Some containers clear at a southern port and never touch Manila, which needs its own receipt route.

The parent platform view, including why this matters for the whole Odoo decision, is on my Odoo consultant Philippines page; this page goes deeper into the stock design itself. The general features are described on the Odoo Inventory product page.

Lots, expiry and consignment with retail chains

Food, beverage, personal care and health products in the Philippines move through supermarket chains, drugstores and wholesalers who will reject short-dated stock. Odoo can track lots with expiry and related dates, and a first-expiry-first-out removal strategy makes pickers take the oldest valid lot. Lot tracking at receipt is extra work for the warehouse, so I agree with your team which products truly need it.

Consignment is the harder part. When your goods sit on a retailer's shelf but remain your property until sold, the stock must stay in your books at a location that represents that retailer. I design:

• A location per consignment customer, or per store where the retailer reports by store.
• A replenishment move from your warehouse to that location, with no sales invoice yet.
• A sell-through routine that turns the retailer's sales report into a delivery out of the consignment location and the related invoice.
• A periodic count comparing Odoo's consignment balance to what the retailer reports, with pull-outs and bad orders recorded separately.

Whether consigned goods change how invoices or delivery receipts are issued is a question for your tax advisor; I make the Odoo flow match whatever they decide. Related patterns are on inventory and warehousing.

Third-party warehouses, dropship and barcode scanning

Many Philippine distributors rent space from logistics providers rather than run every warehouse themselves. In Odoo, a third-party warehouse is still a warehouse, with your stock in it, but the people moving the goods do not use your system. The design question is how orders and confirmations travel between you and the provider: a shared file, the provider's portal or an API connector. I define that exchange, its timing and who corrects mismatches, before any developer is asked to build it.

Dropship routes suit project orders where a supplier delivers straight to the customer site, for example building materials or equipment for a large account. The purchase and sale stay linked, and no stock passes through your warehouse.

For barcode scanning, Odoo's dedicated barcode app has been an Enterprise feature in recent versions, so a Community deployment needs another approach. I check:

• Which steps genuinely benefit from scanning, usually receipt, picking and count.
• Whether supplier cartons carry usable barcodes or you must label on receipt.
• How scanners behave on the Wi-Fi and mobile data at each branch.
• What happens at a branch when the connection drops mid-pick.

Multi-company stock, such as an importing entity selling to a distribution entity, is also possible in one database; the intercompany accounting side is on my Odoo Accounting Philippines page.

Delivery receipts, invoices and the Philippine localization

Odoo Inventory moves stock; the tax effect of a sale is handled in Odoo Accounting through taxes, journals and the Philippine fiscal localization. For a Philippine distributor, that split matters because the documents that leave the warehouse and the invoice that follows may both need to meet BIR requirements for a computerized system. What those requirements are for your business is for your tax advisor to say.

What I check with your advisor and your implementer:

• Which document travels with the goods: a delivery receipt printed from the Odoo transfer, a sales invoice, or both, and what each must show.
• Numbering and series for each branch that issues its own documents, and whether Odoo's sequences meet the advisor's expectations.
• VAT on stock movements such as samples, free goods and consignment pull-outs, which often have no sales order behind them.
• Landed costs on imports, so freight, duties and brokerage reach product cost, with import tax handled by the accounting setup.

The localization's coverage of these points differs by version and edition and changes over time. I confirm it with Odoo or the partner in a test database, and where it lacks something, such as a required print layout or report, I record a gap with a proposed fix and an owner. My gap analysis service is how those items are tracked.

When Odoo Inventory is not the right tool here

Odoo Inventory is capable, but there are Philippine situations where I would steer you elsewhere or ask for more proof first.

• Small online sellers. A business selling mainly through marketplaces with one storeroom may be better served by a lighter tool; my Zoho Inventory Philippines page covers that path.
• Van sales as the core model. Odoo can treat each van as a location, but route accounting, cash collection on the road and offline invoicing usually need a specialist van sales app integrated with Odoo.
• Heavy third-party logistics dependence where the provider's system is the real source of truth and cannot exchange data reliably.
• No one to own master data. Routes, reordering rules and lot settings decay without an owner, and replenishment quietly stops working.

When Odoo does fit, I can stay involved as an independent reviewer through implementation, checking configuration against the agreed design, running user acceptance tests and reviewing the first stock counts. If you are still deciding between platforms, start with the Philippines ERP consultant page, and for wider market context see the Philippines hub. Manufacturers should also read my Odoo Manufacturing Philippines page.