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

Odoo

Модуль

Cash Basis Tax — касовий метод ПДВ у Odoo

Як налаштувати tax_exigibility='on_payment' для постачальників ЗСУ (ст. 187.7) і комуналок (ст. 187.10). Wizard для ПН на дату платежу.

Шлях у меню
Бухгалтерія → Налаштування → Податки → Cash Basis
Технічна модель
account.tax, account.move (cash_basis_transition_account_id)
Редакція
2026-05-28

Що це і навіщо

Стандартне правило ПДВ — перша подія (ПКУ 187.1). Що раніше відбулося: відвантаження чи оплата — на ту дату нараховуємо. Але є винятки, де ПДВ йде тільки за касовим методом — на дату фактичного платежу. Це:

  • Стаття 187.7 ПКУ — постачання Збройним Силам, СБУ, МВС та іншим силовим за державним оборонним замовленням.
  • Стаття 187.10 ПКУ — комунальні послуги населенню, теплопостачання, водопостачання.

Логіка проста: касовий метод захищає постачальника від касового розриву — коли ПДВ уже нараховано, а грошей ще немає. Для оборонки і комуналки, де платежі затримуються на місяці, це рятує від сплати податку зі свого.

Отже, ПДВ-зобов’язання і ПДВ-кредит виникають на дату руху грошей, а не на дату документа. У Odoo за це відповідає механізм Cash Basis Taxes.

Як це працює

На account.tax є два поля для касового методу:

  • tax_exigibility = 'on_payment' (замість стандартного on_invoice).
  • cash_basis_transition_account_id — рахунок-транзит, на якому «висить» ПДВ, поки немає платежу.

Що відбувається, коли складаєте інвойс зі ставкою cash basis 20%:

  1. Створюється account.move (інвойс). Сума 100 + 20 ПДВ = 120.
  2. Проводки base: DR 361 / CR 703 на 100 (база — звичайна).
  3. Проводки tax (відстрочена): DR 643 / CR транзит-рахунок 6442 на 20 (а не на 6411). Тобто ПЗ ще не нараховано.
  4. На інвойсі стан = posted, але tax_amount у декларацію не йде (бо tax_exigibility=on_payment).

Коли реєструєте платіж:

  1. Створюється account.payment і реконсилиться з інвойсом.
  2. Odoo автоматично запускає cash basis adjustment — окремий журнальний запис.
  3. Цей запис: DR 6442 (транзит) / CR 6411 (реальний ПЗ) на 20. Тепер ПДВ потрапить у декларацію за період платежу.
# Налаштування cash basis на новій ставці
cash_basis_tax = self.env['account.tax'].create({
    'name': 'ПДВ 20% — касовий метод',
    'amount': 20,
    'type_tax_use': 'sale',
    'tax_exigibility': 'on_payment',
    'cash_basis_transition_account_id': transit_account.id,
})

Шлях у меню: Accounting → Configuration → Taxes → відкрити tax → Advanced Options → Cash Basis.

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

Що треба налаштувати для cash basis з нуля:

  1. Рахунки транзиту. Зазвичай це 6442 для відстроченого зобов’язання і 6443 для відстроченого кредиту. Українські бухгалтери їх називають «643 — Податкові зобов’язання» (відстрочене) і «644 — Податковий кредит» (відстрочений). Створи їх, якщо їх ще немає.
  2. Окремі tax records.
    • «ПДВ 20% касовий — продаж» з tax_exigibility='on_payment' і cash_basis_transition_account_id=6442.
    • «ПДВ 20% касовий — закупівля» з аналогічними налаштуваннями для 6443.
  3. Fiscal positions.
    • «Касовий метод — продаж ЗСУ» (підміняє звичайні ставки касовими для замовників-військових).
    • «Касовий метод — закупівля комуналки» (підміняє вхідні).
  4. Прив’язка fiscal position до партнерів. Військові частини, комуналки.
  5. Дата складання ПН. За касовим методом ПН складається на дату платежу, а не на дату відвантаження. У Odoo для цього потрібна окрема логіка:
    • Або вручну: отримали платіж — натискаєте кнопку «Скласти ПН».
    • Або server action: на post payment → автоматично створити ПН з типом причини 14.

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

ТОВ «УкрПром-Тех» працює з касовим методом ось так:

Сценарій 1: продаж військовій частині за оборонним замовленням (ст. 187.7).

Партнер «Військова частина А-1234» має fiscal position «Касовий — продаж 187.7». При створенні SO Odoo підставляє ставку «ПДВ 20% касовий — продаж». Інвойс підтверджуємо — ПЗ висить на 6442. Якщо це звичайне відвантаження, ПН поки не складаємо.

Військова частина платить (часто через 30-60 днів після прийняття). При реєстрації платежу:

  1. Cash basis adjustment: 6442 → 6411.
  2. Server action: створюється ПН з типом причини 14 (постачання за касовим методом), дата складання = дата платежу.
  3. ПН реєструється в ЄРПН.
  4. ПН потрапляє у декларацію за період платежу.

Якщо платіж надходить частково — створюється кілька ПН на кожну частину.

Сценарій 2: купівля комунальних послуг (ст. 187.10).

«ЛКП Тепловодоканал» має fiscal position «Касовий — закупівля 187.10». Отримали Bill — ПК висить на 6443. Платимо комуналці — cash basis adjustment 6443 → 6442 (наш ПК). Чекаємо ПН від постачальника — звіряємо суму.

Два моменти. По-перше, cash basis adjustment не залежить від наявності вхідної ПН — це окрема логіка ПК. По-друге, реальний ПК потрапляє до декларації тільки тоді, коли постачальник зареєстрував вхідну ПН в ЄРПН. Це окрема перевірка через моніторинг реєстру.

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

  • Один tax record, два режими. Хотіли як «звичайний 20% за замовчуванням, але якщо партнер військовий — касовий». Не вийде. Cash basis — це окремий tax record. Підміна через fiscal position.
  • cash_basis_transition_account_id не заданий. Adjustment не пройде, ПДВ висить на 643/644 назавжди. Декларація буде сильно занижена. При створенні cash basis tax — це обов’язково.
  • Дата ПН ≠ дата платежу. Стандартно account.move-інвойс має дату документа. Cash basis adjustment теж створює move з датою платежу. Але ПН для ЄРПН треба скласти руками з правильною датою. Якщо забув — складаєш пізнішою датою, у ЄРПН все одно проходить, але аудитор бачить.
  • Частковий платіж. Заплатили 50 з 120. Cash basis adjustment робить пропорційно: 5 з 10 (а не 20 — це тільки база, бо ПДВ сидить усередині суми). Якщо складається ПН — теж на пропорційну суму. Перевір, чи бухгалтер це розуміє.
  • Сторно платежу. Зробили reverse payment. Cash basis adjustment теж сторнується. Якщо вже зареєстрували ПН — потрібно скласти РК. Не забути.
  • Fiscal position змінила tax, але не на cash basis. Підставила «звичайний 20%» замість «касового 20%». Тоді нараховуєш на дату інвойсу — і весь сенс касового методу втрачено. Перевір саме tax_dest_id у account.fiscal.position.tax.
  • ПК комуналки тягнеться без ПН. Заплатили, cash basis adjustment пройшов — і ПК потрапив у декларацію. Але ПН від комуналки ще не зареєстрована в ЄРПН. За ст. 198.6 ПКУ право на ПК виникає тільки після реєстрації. Тому до cash basis треба додати ще одну перевірку: чи зареєстрована вхідна ПН, перш ніж включати її в декларацію.

Дотичне

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