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

Odoo

Модуль

Odoo Purchase

Замовлення постачальнику — джерело надходжень, рахунків від постачальника і вхідного ПДВ.

Шлях у меню
Закупівлі → Замовлення
Технічна модель
purchase.order, purchase.order.line
Редакція
2026-05-28

Що це і навіщо

Purchase — дзеркало Sales, тільки в інший бік. Тут живе purchase.order: те, що замовляємо в постачальника. Підтвердив PO — отримав stock.picking на прихід. Постачальник привіз — оприбутковуєш. Прийшов рахунок — створюєш account.move типу in_invoice і прив’язуєш до PO. Ланцюг замкнувся: очікуємо товар, отримуємо його, платимо.

Для виробничого підприємства Purchase — це не тільки матеріали, а й послуги: оренда, транспортування, аутсорс. Кожен PO визначає, на який рахунок ляже витрата (через product.category → property_account_expense_categ_id) і яку аналітику отримає. Без аналітики на PO собівартість оборонного замовлення А-1234 ніколи не зійдеться з планом.

Як це працює

Стани: RFQ (Request for Quotation) → Purchase Order → Done. RFQ — це коли ще не обрав постачальника або чекаєш комерційної пропозиції. PO — підтверджене замовлення, з якого утворюється stock.picking типу incoming.

Що відбувається при «Confirm Order»:

  1. Створюється stock.picking (тип «Receipts»), очікує надходження.
  2. Заводиться stock.move на кожен рядок із кількостями.
  3. Сам PO переходить у стан purchase, а date_planned стає очікуваною датою отримання.

Коли товар реально прийшов — натискаєш «Receive Products» на picking, валідуєш. Тоді створюються stock.valuation.layer (для anglo-saxon) або проводки відразу на 20-30/631 (для continental). Для UA-практики ми завжди вмикаємо anglo-saxon, бо це коректна реалізація FIFO/AVCO.

Інвойс постачальника — окремий документ. На PO є кнопка «Create Bill». Краще створювати через неї: тоді Odoo сам підтягне рядки й кількості і налаштує трирівневе звіряння PO ↔ Picking ↔ Bill. Якщо щось не збігається — побачиш червоне.

# Створення PO
po = self.env['purchase.order'].create({
    'partner_id': supplier.id,
    'order_line': [(0, 0, {
        'product_id': raw_material.id,
        'product_qty': 1000,
        'price_unit': 25.50,
        'analytic_distribution': {str(contract.id): 100},
    })],
})
po.button_confirm()

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

Стандартний Odoo Purchase не знає про:

  • Вхідну податкову накладну. ПН надходить окремо в ЄРПН від постачальника. Її треба підв’язати до Bill через кастомну модель (у Oblik-ERP це є, у стандарті — ні).
  • Довіреність на отримання ТМЦ. Окрема форма, прив’язана до конкретного PO і відповідального.
  • М-4 (прибутковий ордер). Це наш первинний документ при надходженні на склад. У стандартному Odoo — лише англійський «Receipt». Видаткова накладна постачальника також є, але форматується інакше.

Що з коробки добре працює: трирівневе звіряння (PO/Picking/Bill), reordering rules, supplier lead times. На це не треба нічого допилювати.

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

ТОВ «УкрПром-Тех» закуповує через Прозоро для державних замовників. Pipeline такий:

  1. Виграли тендер на Прозоро → у нас з’являється договір з військовою частиною А-XXXX.
  2. Для виконання нам потрібні комплектуючі — формуємо PO постачальникам.
  3. Кожен PO має analytic_distribution на той самий контракт А-XXXX, що й SO. Так собівартість і дохід зустрічаються в одній аналітиці.

При надходженні від постачальника обов’язково скануємо серійні номери компонентів (через stock.lot). Це частина трасабіліті — потім зможемо довести, який саме компонент пішов у який виріб для замовника. Без цього не працюють ні ВТП-сертифікація, ні гарантійний облік.

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

  • Bill створили вручну, без PO. Тоді немає трирівневого звіряння. Бухгалтер може провести оплату до того, як товар прийде. Правило: всі Bills йдуть через кнопку на PO. Виняток — комуналка і дрібнота.
  • Кількість в Bill більша, ніж у Picking. Odoo дозволить, але це тривожний сигнал: або постачальник «домалював», або ми недосканували. Перевіряти через звіт «Bill Matching».
  • Забули account_id на product.category. PO підтверджується, picking валідовано — але проводка не пройшла, бо рахунок не визначений. Перевірятимеш у Settings → Inventory → Operations → Stock valuation account.
  • Lead time неправильний. PO заплановано на завтра, а реально товар їде 3 тижні. Тож MRP бачить, що матеріал «буде завтра», і запускає виробництво. Налаштовуй supplier lead time як параметр на product.supplierinfo.
  • Аналітики дві — продаж в А-1234, закупівля в А-9999. Маржа порахується неправильно. Правило: PO успадковує аналітику від відповідного SO або від проєкту, якщо це make-to-order.

Дотичне

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