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

Odoo

Модуль

Odoo Accounting — журнальні записи і подвійний запис

Як Odoo веде подвійний запис: account.move як універсальний документ-проводка, журнали як шафи, account.move.line як рядок.

Шлях у меню
Бухгалтерія → Журнальні записи
Технічна модель
account.move, account.move.line, account.journal, account.account
Редакція
2026-05-28

Що це і навіщо

Accounting — це серце Odoo для бухгалтера. Усе, що відбувається в інших модулях, рано чи пізно перетворюється на account.move (журнальний запис) із набором account.move.line (рядків). Інвойс — це move. Платіж — теж move. Внутрішнє переміщення сировини у виробництво за anglo-saxon — знову move. Один уніфікований документ, на який «нанизано» подвійний запис.

Зручність у тому, що бухгалтер дивиться на все через ту саму призму. Хочеш побачити проводку — відкриваєш move, бачиш ліві (DR) і праві (CR) рядки. Потрібна ручна корекція — створюєш новий move у журналі «Miscellaneous». Треба закрити рахунок — закриваєш суму проводкою, як завжди.

Як це працює

Модель проста і потужна:

  • account.account — план рахунків. Це довідник: код (201, 631, 703), назва, тип (asset/liability/equity/income/expense), валюта-обмеження.
  • account.journal — журнали як «шафи». Типи: sale, purchase, cash, bank, general. У кожній компанії є хоча б по одному.
  • account.move — документ-проводка. Має дату (date), журнал (journal_id), стан (draft / posted / cancel), назву (name, наприклад «INV/2026/00123»).
  • account.move.line — рядок проводки. Має рахунок (account_id), debit/credit, partner, аналітику, валюту.

Інваріант: сума debit рядків move дорівнює сумі credit рядків. Odoo не дозволить запостити незбалансований move.

# Ручний move — корекція
move = self.env['account.move'].create({
    'journal_id': journal_misc.id,
    'date': fields.Date.today(),
    'line_ids': [
        (0, 0, {'account_id': acc_91.id, 'debit': 1000, 'credit': 0,
                'analytic_distribution': {str(contract.id): 100}}),
        (0, 0, {'account_id': acc_23.id, 'debit': 0, 'credit': 1000}),
    ],
})
move.action_post()

Стан posted — це коли проводка увійшла в облік. Після цього рядки в стандарті не редагуються (lock date зазвичай вмикають). Треба виправити — або сторно через reverse move, або нова проводка-корекція.

Шлях у меню: Accounting → Customers / Vendors / Accounting → Journal Entries. Звіти: Accounting → Reporting.

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

З коробки в Odoo Enterprise з l10n_ua ти отримуєш:

  • Український план рахунків (1, 2, 3, 4, 5, 6, 7, 8, 9 класи за наказом 291).
  • Базові журнали (sale, purchase, cash, bank, misc).
  • ПДВ-ставки 20%, 7%, 0%, без ПДВ.

Чого з коробки немає — і що додає Oblik-ERP або власні модулі:

  • Друкована форма «Бухгалтерська довідка» (для ручних коригувань).
  • Касова книга з підсумками за день (стандартний журнал каси є, форми — немає).
  • Розрахунково-платіжна відомість.
  • Декларація з ПДВ у форматі ДПС.
  • Об’єднана звітність ЄСВ/ПДФО.
  • Українські фінзвіти: Баланс (1М), Звіт про фінансові результати (2М).

Anglo-saxon чи continental: для UA вибираємо anglo-saxon. Він правильно рахує собівартість за FIFO/AVCO і дає stock.valuation.layer для аудиту. Continental спрощує життя на старті, але потім обертається важкими проблемами зі звітами собівартості.

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

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

  • Кожен account.move.line для витратного рахунку (23, 91, 92, 93) обов’язково має analytic_distribution. Якщо немає — server action блокує action_post.
  • На рядку собівартості реалізації (902, 903) аналітика тягнеться із SO/MO. Так і бачимо: «контракт А-1234 заробив 2,1 млн ₴ за собівартості 1,68 млн ₴».
  • Окремий журнал «ПДВ — обов’язки» і «ПДВ — кредит». Це не стандартний підхід, але українському бухгалтеру так зрозуміліше. У ньому — лише рух за рахунками 641/643/644/6442.

Закриття місяця у нас — це послідовність: курсова переоцінка → закриття WIP за MO → розподіл ЗВВ → перевірка ПДВ-лімітів → формування декларації → постинг.

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

  • Lock date не встановлено. Бухгалтер може запостити проводку у «закритий» місяць — і звіти за минулі періоди пливуть. Встановлюй tax_lock_date, period_lock_date, fiscalyear_lock_date після кожного періоду. Розблокувати може тільки адмін.
  • Continental увімкнено, anglo-saxon не запрацював. Тоді stock.move не дає проводок, а склад накопичується в системі без бухгалтерського відображення. Аж раптом — «де у мене 2,5 млн на 201?». Дивись Settings → Inventory → Anglo-Saxon Accounting.
  • account.move без партнера. На покупцеві/постачальнику чи на рядку з 631/361 partner_id обов’язковий, інакше реконсиляція не працює і звіт «Заборгованість покупців» порожній. Виправляється тільки сторно і перепостингом.
  • Один рахунок на дві ставки ПДВ. Налаштував 6411 під 20% і 7% разом — декларація вийде неправильна. Розводь: 6411-20 і 6411-7. Не лінуйся.
  • Reverse без правильної дати. Сторно вже закритого move лягає поточною датою, а це псує порівняльну аналітику. Завжди став reverse_date на дату оригіналу (для бухгалтерських цілей) або поточну (для виправлення поточного). Чітко розумій, чого саме хочеш.
  • Misc-журнал — звалище. Туди скидають усе, що нікуди не пасує. Через рік аудитор не розбере, де там сторно, де коригування, а де — пробний запис. Заведи окремі misc-журнали: «Коригування», «Закриття місяця», «ЗП ручна».

Дотичне

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