Odoo native ties analytic accounting almost entirely to financial and sales/purchase documents — invoices, vendor bills, timesheets, and expenses. Warehouse operations sit outside that loop: a stock.picking and its stock.move lines carry no analytic dimension, so when goods physically move between projects, cost centers, branches, or funding sources, there is no clean way to attribute that movement. Teams end up reconstructing the analytic split in spreadsheets after month-end, or forcing everything through manual journal entries that drift from the actual picking data. The gap widens in Odoo 17/18/19, where analytic is modeled as a multi-dimensional account.analytic.line structure (plan-based distributions rather than the legacy single-tag field), and stock simply does not participate.

This build-to-order module adds first-class analytic dimensions to the picking flow. We extend stock.picking and stock.move with an analytic_account_id (Many2one to account.analytic.account) and an analytic-tag / analytic-distribution field aligned to your Odoo version — a Many2many to the legacy account.analytic.tag on 17.0 where you still use tags, or a JSON analytic_distribution widget bound to your analytic plans on 18.0/19.0. Header-level values propagate to move lines via @api.onchange and a @api.depends compute, while still allowing per-line overrides for mixed pickings. Where you need the values to reach the general ledger, we hook _get_stock_valuation_layers / the account-move creation path so that valuation and inventory journal entries carry the analytic account and tags through to account.analytic.line, giving you real analytic reporting on stock movements instead of an after-the-fact estimate.

Technically, the work is a clean, upgrade-safe module: a dedicated __manifest__.py depending on stock and analytic (plus stock_account when GL propagation is in scope), model extensions via _inherit, view inheritance (XML xpath into the picking and operations forms, and OWL/list views for the move lines), and access control through ir.model.access.csv plus record rules so warehouse users can set dimensions without touching accounting configuration. Default analytic accounts can be derived from the source/destination stock.location, the operation type, or the linked project via automated actions, and every field is exposed over the XML-RPC / JSON-RPC API so external systems and integrations read and write the same dimensions. We add QWeb report touches (analytic columns on the picking / delivery slip) and optional pivot/group-by views so operations and finance share one source of truth. It is delivered against Community or Enterprise, with the Enterprise-only features (studio-style customizations, advanced analytic dashboards) respected rather than reimplemented.

Delivery is build-to-order: we start with a short scoping call to confirm your Odoo version, edition, which documents must carry analytics, whether GL propagation and multi-company are in play, and how default dimensions should be derived. You approve a fixed-scope quotation, we build on a staging clone of your database, run UAT with you, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company setups, GL/valuation propagation, custom default-derivation logic, and migration of historical picking data increase the quoted scope.