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

Odoo

Модуль

ПН і РК в Odoo для ЄРПН

Як Odoo працює з податковими накладними: складання, реєстрація в ЄРПН, моніторинг статусу, типи причини та РК для коригувань.

Шлях у меню
Бухгалтерія → Документи → Податкові накладні
Технічна модель
account.move (з кастомізаціями для ПН/РК)
Редакція
2026-05-28

Що це і навіщо

Податкова накладна (ПН) — це фіскальний документ, який платник ПДВ складає на дату першої події (відвантаження або передоплати, ПКУ 187.1) і реєструє в ЄРПН. Розрахунок-коригування (РК) — додатковий документ, який змінює раніше складену ПН (повернення, виправлення помилки, зміна ціни). Усі ПН/РК — публічні в реєстрі, тому помилка коштує штрафу (ст. 120-1 ПКУ, до 50% суми ПЗ).

Стандартний Odoo не знає ПН. Він знає інвойси (account.move типу out_invoice). Тому ПН в українській інсталяції — це окрема модель або розширення account.move з додатковими полями: тип причини, дата складання, дата реєстрації, статус в ЄРПН, серійний номер. Інтеграція з ЄРПН — окремий API-канал.

Як це працює

Логічна модель:

  1. Подія, яка тригерить ПН. Якщо оплата йде після постачання — це підтвердження інвойсу (інвойс і є першою подією); якщо наперед — отримання передоплати (першою подією стає платіж); якщо відвантаження — валідація picking.
  2. Створення ПН. Вручну (кнопка «Скласти ПН» на інвойсі) або автоматично через server action. Заповнюються поля: номер, дата складання, контрагент, рядки з номенклатурою і кодом УКТЗЕД, ставка, тип причини.
  3. Підписання. ПН підписується КЕПом директора або уповноваженого. У Odoo це окремий шар — інтеграція з модулем КЕП або з зовнішніми сервісами (M.E.Doc, Сота, FreDoc).
  4. Відправка в ЄРПН через API ДПС. Відповідь приходить асинхронно. Статуси: «Очікує підтвердження» → «Зареєстровано» / «Відмова».
  5. Моніторинг. Cron щоп’ятнадцять хвилин перевіряє статуси ПН зі станом «В очікуванні» й оновлює state запису.

Аналогічно для РК: створюємо РК → підписуємо → реєструємо → чекаємо статусу.

# Спрощена модель ПН
class TaxInvoiceUA(models.Model):
    _name = 'tax.invoice.ua'

    name = fields.Char('Номер ПН')
    date_compiled = fields.Date('Дата складання')
    reason_type = fields.Selection([
        ('02', '02 - Постачання неплатнику'),
        ('07', '07 - Експорт'),
        ('09', '09 - Звільнено від ПДВ'),
        ('14', '14 - Касовий метод'),
    ])
    state = fields.Selection([
        ('draft', 'Чернетка'),
        ('signed', 'Підписана'),
        ('sent', 'Відправлена в ЄРПН'),
        ('registered', 'Зареєстрована'),
        ('rejected', 'Відмова'),
    ])
    erpn_response = fields.Text('Відповідь ЄРПН')

Шлях у меню: Бухгалтерія → Документи → Податкові накладні (для кастомної моделі) або Бухгалтерія → Замовники → Інвойси → Tax Invoices (для розширення account.move).

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

Типи причини, які треба підтримувати:

  • Без коду (порожньо) — звичайна реалізація платнику ПДВ.
  • 02 — постачання неплатнику ПДВ (фізособа, дрібний ФОП).
  • 07 — експорт за межі митної території.
  • 09 — операції, звільнені від оподаткування (ст. 197 ПКУ).
  • 14 — постачання за касовим методом (ст. 187.7, 187.10).
  • 15 — складена платником сама собі (умовний продаж, безоплатна передача).

Для дат:

  • Дата складання = дата першої події (відвантаження або передоплата).
  • Дата реєстрації = дата відправки в ЄРПН. За правилом має бути в межах 1090 днів від дати складання, але для нормальної роботи — у місяці складання, інакше ПК у покупця «зависає».

Для номенклатури — обов’язкові коди УКТЗЕД (для товарів) і коди ДКПП (для послуг). У стандартному Odoo цього немає — додаємо як поля на product.template.

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

ТОВ «УкрПром-Тех» побудувала ось такий процес:

  1. Підтверджуємо SO для замовника ЗСУ. Створюється інвойс.
  2. Перша подія — відвантаження. Під час валідації picking server action створює ПН з типом причини «без коду» (звичайна реалізація) або «09» (звільнення за п.32 підрозд.2 розд.ХХ для постачання військовим).
  3. Підписання. Через інтеграцію з ID.gov.ua або з нашим внутрішнім КЕП-сервером.
  4. Реєстрація. Прямий API-виклик в ЄРПН ДПС.
  5. Моніторинг. Cron Check ERPN status щоп’ятнадцять хвилин. Якщо «Зареєстровано» — оновлюємо стан і додаємо у декларацію. Якщо «Відмова» — створюємо завдання бухгалтеру з причиною.

Для експортних операцій (тип 07) додатково перевіряємо наявність МД у статусі «оформлено». Без неї експортна ПН — це передчасна декларація і потенційний штраф.

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

  • ПН складена з помилкою в УКТЗЕД. Покупець не побачить її у Д5. Виправлення — РК на сторно і нова правильна ПН. Те саме з ІПН покупця.
  • Не встигаємо у 15-денний термін реєстрації. Штраф з 16-го дня — від 10% до 50% суми ПДВ. Налаштуй reminder за день до дедлайну.
  • Ліміт у СЕА не дотягує. Спробували зареєструвати ПН на 200 тис. ПЗ, а ліміт — 150 тис.: ЄРПН відмовить. Профілактика — звіт «Сьогодні треба зареєструвати ПН на N, доступний ліміт M». Якщо нестача — поповнити СЕА або відкласти реєстрацію.
  • РК не пройшло — друга сторона не підписала. Зменшуюче РК реєструє покупець. Завис у статусі — отже, покупець або не підписав, або відмовляється. Залежно від ситуації — нагадування чи зміна оформлення угоди.
  • Дата складання — на день раніше першої події. ЄРПН відмовить з помилкою «дата не відповідає першій події»: ПН не може передувати операції.
  • На експортній ПН ставка 20% замість 0%. Класична плутанина з fiscal position. Виправлення — РК і нова ПН.
  • Аванс частково повернули, а РК не склали. ПН так і висить у повному обсязі, тож декларація завищує ПЗ. На повернуту частину завжди складай РК.
  • ПН на безоплатну передачу не складено. Безоплатна передача (наприклад, гуманітарна допомога чи зразок) — теж оподатковуване постачання за ринковою ціною. Тип причини 15, складають самі на себе.

Дотичне

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