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

Odoo

Модуль

СЕА ПДВ — ліміт реєстрації ПН в Odoo

Як в Odoo відстежувати ΣНакл — баланс електронного рахунку ПДВ, поповнювати його вчасно й не впиратися в ліміт під час реєстрації ПН.

Шлях у меню
Бухгалтерія → ПДВ → Ліміт реєстрації
Технічна модель
sea.vat.balance (кастомізація)
Редакція
2026-05-28

Що це і навіщо

СЕА — Система електронного адміністрування ПДВ. У ній кожен платник має «електронний рахунок» — віртуальну скарбничку, з якої «списується» право зареєструвати ПН. Формула спрощено: ΣНакл = ΣПК + ΣПопПод + ΣМитн − ΣНаклВид. Тобто скласти ПН можеш рівно на стільки, скільки в тебе «зайшло» (від постачальників, з митниці й поповнень) мінус те, що вже видав.

Звідси наслідок: якщо в тебе багато експорту (0% — вихідного ПДВ нема), але дуже мало внутрішніх закупівель із ПК, ліміт буде куций, і ПН ти не зареєструєш. Доведеться поповнювати рахунок СЕА власними грошима. А найболючіше це б’є саме тоді, коли в тебе криза кешфлоу. Звідси й завдання: прогнозувати ліміт і за потреби поповнювати наперед.

Як це працює

Технічно в Odoo цього з коробки немає взагалі. Потрібен кастом-модуль, який:

  1. Інтегрується з API кабінету платника ДПС і тягне поточне значення ΣНакл (зазвичай раз на годину).
  2. Зберігає історію. Окрема модель sea.vat.balance з полями date, accumulated_in (входить), accumulated_out (виходить), available_limit (поточний доступний).
  3. Малює дашборд. Графік за останній місяць і прогноз на найближчі дні з урахуванням запланованих ПН.
  4. Видає попередження. Якщо доступний ліміт < суми ПН на сьогодні — алерт бухгалтеру.
class SeaVatBalance(models.Model):
    _name = 'sea.vat.balance'
    _order = 'date desc'

    date = fields.Datetime('Час оновлення', required=True)
    accumulated_in = fields.Float('ΣВх (від постачальників + митниця + поповнення)')
    accumulated_out = fields.Float('ΣВих (видані ПН)')
    available_limit = fields.Float('Доступний ліміт', compute='_compute_available')

    @api.depends('accumulated_in', 'accumulated_out')
    def _compute_available(self):
        for rec in self:
            rec.available_limit = rec.accumulated_in - rec.accumulated_out

Шлях у меню (для кастому): Бухгалтерія → ПДВ → СЕА ліміт.

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

Що змінює ліміт у плюс:

  • Реєстрація вхідних ПН від постачальників (поповнення ΣПК).
  • Розрахунки митниці під час імпорту (ΣМитн).
  • Поповнення електронного рахунку з банку (ΣПопПод).
  • РК на зменшення вихідного ПДВ (повернення товарів покупцем зменшує те, що ми видали).

Що зменшує:

  • Реєстрація вихідних ПН (наша ΣНаклВид).
  • РК на збільшення вхідного ПК (постачальник нам зменшує — наш ПК іде вниз).

Особливість: експорт (0%) — теж, формально, реєстрація вихідної ПН. Але оскільки ПДВ = 0, то й ΣНаклВид не приростає. Звідси «експортники не мають проблем зі СЕА».

Найбільше потерпають:

  • Підприємства на касовому методі (часто комуналки, спецтехніка для ЗСУ). Вхідний ПК не зараховується в ΣПК до оплати, а вихідний ПН так само лягає лише на дату оплати — усе зміщується в часі.
  • Підприємства з великою часткою «безПДВшних» витрат (зарплати, амортизація — на них ПДВ немає, отже й ΣПК не зростає), але великим вихідним ПЗ.

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

ТОВ «УкрПром-Тех» має змішану структуру: цивільні замовлення з ПДВ і оборонні зі звільненням за п.32 підрозд.2 розд.ХХ ПКУ. Для оборонних ПДВ ми не нараховуємо (ставка 0% або звільнення), але ПН все одно реєструємо (тип 09). Ліміт там не «з’їдається» — це наша перевага.

Дашборд у нас показує:

  • Поточний ΣНакл (свіжість — 15 хв).
  • ПН за сьогодні до реєстрації (сума).
  • Прогноз на 7 днів (на основі підтверджених SO і запланованих відвантажень).
  • Червона зона: якщо доступний ліміт < очікуваних ПН на найближчі 3 дні.

Поповнення СЕА — окремий процес. Платіжне доручення на спецрахунок ДПС, далі через API перевіряємо, що ΣПопПод зросла. Бувають затримки до доби — їх теж треба закладати в прогноз.

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

  • Не моніторимо ліміт. Несподівано не зареєстрували ПН. ЄРПН видає «303 — недостатньо коштів на електронному рахунку». Покупець не отримує ПК, угода зривається. Профілактика — щоденне зведення на дашборді, алерт за критичної суми.
  • Поповнення СЕА на завищену суму. Гроші безпідставно «лежать» у ДПС — повернеш їх тільки за заявою через 365 днів. Поповнюй точно під потребу + 10% буфер.
  • Постачальник виписав РК на зменшення — наш ПК упав, а ми його вже використали. Класична пастка. Постачальник склав РК на сторно або зменшення — і наш ліміт мінусується. Стеж за вхідними РК у реєстрі ЄРПН.
  • Експорт = 0% = ліміт не зменшується, але декларація все одно треба правильна. ПН складається з типом 07, у ΣНаклВид не йде. Це не означає, що декларацію можна не подавати — рядок 2.1 заповнюй коректно.
  • Імпорт послуг від нерезидента. Платник складає ПН сам собі, тип 14 (умовний продаж послуг). Це збільшує і ΣПК (вхідне), і ΣНаклВид (вихідне) — нетто нуль, але рух є. Забув скласти — потім доведеться боляче перераховувати.
  • Кеш у Odoo застарів. Ліміт у дашборді 500 тис, а в реальності — 50. ПН не пройде. Перевір cron, частоту оновлення з API ДПС.

Дотичне

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