Buyers and procurement teams rarely fight your own product master data — they fight the supplier's. Every vendor sends their own SKU codes, their own descriptions, their own price breaks, and their own view of what is actually in stock, and none of it matches how your products are set up in Odoo. Native Odoo captures a slim slice of this on the product.supplierinfo records reachable from the Purchase tab: a vendor, a vendor product code and name, a minimum quantity, a price, and a validity window. What it does not model is the vendor's full catalog as the vendor sees it, the vendor's live or last-imported available stock per item, richer price structures, or a clean workspace where a buyer can compare what several suppliers say about the same thing before raising a purchase order. When that context lives in spreadsheets and inboxes, buyers key the wrong code, miss a better price break, or commit to a vendor who cannot actually fulfil.

This is a build-to-order module we design and build for your database — it is not an existing download. We extend the vendor/product relationship with new models (models.Model) that hold the vendor's own product records, their price lines, and their available-stock figures, each linked back to your product.template/product.product and to res.partner. Vendor prices are expressed as their own lines with quantity breaks, currency, unit of measure, and validity dates, and @api.depends compute fields surface the current best applicable price and the freshest known stock figure directly on the product form so a buyer sees it without hunting. We wire clean views (XML, and OWL components where an interactive comparison panel earns it), list and form layouts for the vendor catalog, and optional QWeb reports such as a per-vendor price/availability sheet. Access is governed by ir.model.access.csv plus record rules so a purchasing user sees vendor data while it stays scoped by company, and automated actions or scheduled jobs can flag expired prices or stale stock. Where you already receive vendor feeds, we expose the models over Odoo's XML-RPC/JSON-RPC API so an external sync — a CSV drop, an EDI file, or a supplier portal export — can update prices and stock on a schedule rather than by hand.

Because it is built to your scope, the module respects your realities: multi-company record rules, your currencies and units of measure, your existing supplier records, and whether you run Community or Enterprise (the core models here are Community-compatible; Enterprise-only touchpoints are only introduced when your edition and workflow call for them). We target Odoo 17.0, 18.0, or 19.0 and pin the build to your running version so the ORM APIs, view architecture, and manifest (__manifest__.py) dependencies match exactly.

Delivery is build-to-order. It starts with a short scoping call to confirm which vendor attributes matter, how prices and stock arrive, and what the buyer's daily workflow should look like; from that we produce a fixed quotation and a written scope. Typical delivery is one working week from confirmed scope, depending on integration and data-migration depth. You get the module built, installed on a staging database for UAT, then promoted to production with a rollback plan, plus documentation and a support window. Pricing starts from $999 (indicative, single-company base scope); multi-company record rules, live vendor-feed integrations (EDI/CSV/API), deeper price-list logic, and the volume of historical vendor data to migrate increase the quoted scope.