⚒ База знань · виробничий облік USD41,42 ПДВ20% МЗП8 000

Odoo

Модуль

Odoo Inventory — склад, рухи, оцінка

Фізичні і логічні рухи запасів: stock.move як атом обліку, stock.quant як зріз наявності, anglo-saxon як основа собівартості.

Шлях у меню
Склад → Операції
Технічна модель
stock.picking, stock.move, stock.quant, stock.location
Редакція
2026-05-28

Що це і навіщо

Inventory — це нервова система Odoo. Усе, що рухається фізично — сировина від постачальника, напівфабрикат у виробництві, готова продукція на відвантаження, повернення від клієнта — проходить через цей модуль. У центрі дві моделі: stock.move (атомарний рух «з точки А в точку Б, скільки чого») і stock.quant (зріз: «зараз у локації X лежить N штук партії Y»).

Для бухгалтерії Inventory — джерело більшості автоматичних проводок. При увімкненому anglo-saxon-обліку кожне валідоване переміщення на складі генерує stock.valuation.layer і відповідну account.move.line. Тобто бухгалтер не сидить і не пише проводки на 201/20 — це робить склад своїми діями. Звідси й вимога: всі рухи на складі мають бути коректними. Помилка комірника — це помилка бухобліку.

Як це працює

Концептуально Odoo моделює склад як граф локацій:

  • view — папка для угрупування (наприклад, «Склад сировини»).
  • internal — наша фізична локація (полиця, секція).
  • supplier — віртуальна локація постачальників.
  • customer — віртуальна локація клієнтів.
  • production — куди рухається матеріал у виробництво, звідки виходить ГП.
  • inventory / loss — корекції, інвентаризація, списання.

Кожне stock.picking (накладна переміщення) має тип (incoming, outgoing, internal, manufacturing) і містить кілька stock.move. Кожен move — це «source location → destination location + product + qty». Стани: draft → confirmed → assigned (зарезервовано) → done.

# Зріз наявності у локації
quants = self.env['stock.quant'].search([
    ('location_id.usage', '=', 'internal'),
    ('product_id', '=', product.id),
])
total_qty = sum(quants.mapped('quantity'))
available = sum(quants.mapped('available_quantity'))  # без резервів

Шлях у меню: Inventory → Operations → Transfers (всі переміщення), Reporting → Stock Valuation (вартісна оцінка).

При валідації picking з anglo-saxon Odoo пише:

  • При надходженні від постачальника: DR 201 / CR Stock Input (тимчасовий рахунок до приходу інвойсу).
  • При відвантаженні клієнту: DR Stock Output / CR 26 (списання ГП).
  • При виробництві: DR 23 / CR 201 (списання матеріалу у виробництво).

У контексті українського обліку

Стандартний Odoo Inventory — солідна база. Що з коробки добре:

  • Multi-warehouse, multi-location.
  • Rules (push/pull) — як товар рухається між зонами.
  • Reordering rules — автоматичне поповнення.
  • Партійний облік (stock.lot).
  • Серійні номери.

Чого не вистачає для UA:

  • Інвентаризаційні відомості за формою М-21 (інв-3, інв-19). У стандарті — лише англомовний stock.inventory (а в новіших версіях Odoo цю модель прибрали взагалі, замінивши on-the-fly корекціями stock.quant). Це означає, що для українського аудитора треба окрема друкована форма.
  • Картка складського обліку (форма М-12). Хронологія руху за конкретною позицією. У Odoo є представлення stock.move.line за продуктом — але форму М-12 треба роздруковувати окремо через QWeb.
  • Облік МШП (малоцінні швидкозношувані). Українська специфіка: при видачі зі складу — списання на витрати, але треба вести облік у експлуатації. У Oblik-ERP це окремий модуль; у стандарті — нема.

Як ми робимо (defense-контекст)

На ТОВ «УкрПром-Тех» склад — це місце, де серійні номери народжуються і живуть. Без них немає трасабіліті, без трасабіліті немає права експорту ВТП. Тому:

  • Сировина зі специфічних компонентів іде з обов’язковими stock.lot. При надходженні комірник сканує номер партії від постачальника. Цей номер потім тягнеться у MO → у готовий виріб.
  • Серійники готових виробів — обов’язкові. Для кожної партії генеруємо за схемою [модель].[рік].[номер]. Серія прив’язана до контракту через аналітику.
  • Окремий warehouse «Defense — карантин». Туди потрапляє все, що очікує контролю (вхідний QC, передавання у виробництво). Перехід далі — лише за документом контролера. Так у нас фізично відокремлено сертифіковану продукцію.

Типові граблі

  • available_quantity від’ємна. Хтось списав більше, ніж було. Зазвичай — продали наявне, але інвентаризація показала менше. Перевір stock.quant із quantity ≠ available_quantity — там є непідбиті move-резерви.
  • Списали не з тієї локації. Випливає вже у звіті: «чому собівартість партії з листопада потрапила в МО з січня?» Якщо локацій багато, а жодна не закріплена за конкретними операціями — FIFO «пливе». Використовуй put-away rules для жорсткого маршрутування.
  • Anglo-saxon вимкнено посеред року. Тепер старі рухи з anglo-проводками, нові — без. Звіт собівартості став невпізнаваним. Не вимикай anglo-saxon після старту.
  • Inventory adjustments як милиця. Помилка у системі — комірник «вирівнює» через корекцію. У звіті валютного контролю — таємнича втрата сировини. Корекції лише після службової записки, з причиною і підписом, не частіше ніж раз на квартал.
  • stock.lot не використовується там, де треба. Продали готовий виріб клієнту, з’явилася претензія — а ми не можемо відстежити, з якої сировини зроблено. Налаштуй tracking='lot' або 'serial' на product.template для всіх defense-категорій.
  • Переміщення без analytic_distribution. Більшість stock.move не потребують аналітики (внутрішній рух). Але якщо рух дає витрату (списання у виробництво або брак) — аналітика на picking чи на ту лінію account.move критична для звітності за контрактом.

Дотичне

Де цей модуль зустрічається12