Проблематика
Отсутствие учета НДС согласно норм украинского законодательства делало ODOO неприспособленной для ведения регламентированного учета и не отвечало запросам отечественных бухгалтеров. Решение этой проблемы было для меня приоритетом номер один при проектировании и разработке решения для ведения такого учета.
В большинстве нормальных стран с учетом НДС не возникает особых проблем. Первое событие всегда возникает по отгрузке и проводка по налогу делается инвойсом. В отечественном законодательстве была когда-то попытка перейти на такой порядок определения первого события, но дальше разговоров в этом направлении не пошло и у нас первое событие определяется по тому что первое произошло: отгрузка или оплата. Цель такого порядка определения понятна: увеличить базу налогообложения налогом и дать бухгалтерам больше головной боли. Это наверное и есть причиной того, что НДС является одним из самых сложных налогов в учете.
В ODOO понятно, что про особенности украинского законодательства никто не думал и сам налог есть в инвойсе (наш аналог расходной накладной), но его нет в банковской выписке (вообще нет — если конечно не включать кассовый метод учета доходов).
Например в 1С проблема расчета первого события решается процедурой перепроведения документов, то есть ты ведешь учет, документы у тебя делают проводки по первому событию, ты проводишь что-то задним числом и у тебя проводки уже неправильные. Но не беда, ты запускаешь процедуру перепроведения документов в хронологическом порядке и у тебя проводки по НДС становятся правильными.
Так как ODOO это ERP система, да еще вдобавок к тому не документоориентированная, такая процедура там не доступна. До 13-й версии там вообще был такой подход, что если ты провел документ и он неправильный, ты его не мог отменить, а только сделать его корректировку (эта проблема решалась установкой отдельного модуля).
За все годы работы с ODOO у меня было несколько вариантов решения данной проблемы. Один из них это использовать встроенный механизм реконсила (сверки), но такой способ неприменим если вы что-то можете провести в системе задним числом (а такая ситуация вполне может быть).
Поэтому я решил пойти несколько другим путем, с которым и хочу вас познакомить.
Как устроен учет налогов в ODOO
Но для начала давайте вкратце рассмотрим как устроен учет налогов в базовой ODOO.
В системе есть отдельный объект account.tax на уровне которого мы можем задать формулу расчета налога и счет бухгалтерского учета на котором будет отражаться сумма рассчитанного налога. При этом налоги делятся на три группы (сферы применения): для продаж, для закупок и прочие. То есть если мы например создаем налог НДС — мы должны создать два налога: один для сферы продаж, второй для сферы закупок. На уровне налога также определяется будет ли данный налог включаться в цену либо нет при продаже либо закупке чего-либо.
При продажах либо закупках мы можем использовать больше одного налога. Сумма каждого налога будет отражаться на счетах которые мы укажем в настройках, при этом эту сумму можно раскидывать на несколько бухгалтерских счетов в определенном процентном соотношении (в наших реалиях это не нужно).
Все налоги объединяются в группы. То есть мы можем создать группу налогов «НДС 20%» и добавить в нее наши 4 налога по НДС(два из сферы продаж из сферы закупок — ндс 20%, ндс в т.ч. 20%).
Первое событие и ODOO
Настройки первого события
Первое событие может отслеживаться по разному: в целом по контрагенту, в разрезе договоров заключенных с контрагентом либо вообще по расчетным документам ( например в разрезе выставленных счетов). В первой итерации я принял решение остановиться на первых двух вариантах. Для этого нужно было решить вторую проблему: добавить возможности вести учет взаиморасчетом в разрезе договоров (этого функционала нет в базовой ODOO), что нами и было сделано.
На уровне контрагента теперь можно определить как будет рассчитываться первое событие по взаиморасчетам с ним.
Слово взаиморасчеты я употребил не случайно. Бухгалтера часто для определения верности расчета первого события (суммы выписанных налоговых накладных — нашего налогового обязательства) пользуются формулой:
Сумма первого события = Конечное сальдо по кредиту — Начальное сальдо по дебету + Дебетовый оборот по счету (данная формула работает если не было возвратов)
То есть если бухгалтер ведет взаиморасчеты с клиентами на 361 счете, то анализируя 361 счет за определенный период можно сказать на какую сумму нужно выписать налоговые накладные за этот период.
НДС обязательства (сумма налога) =
= (Сальдо Кт субсчета 361 на конец отчетного периода — Сальдо Кт субсчета 361 на начало отчетного периода +
+ Оборот по Дт субсчета 361 за отчетный период) : 1,2 * 20% (если ставка налога 20)
Значит нам надо сделать отдельную пометку на уровне бухгалтерского счета для учета взаиморасчетов, которая бы нам указывала что по этому счету нужно отслеживать первое событие.
Для поставщиков все работает также только в другую сторону:
Сумма первого события по налоговому кредиту = Конечное сальдо по дебету — Начальное сальдо по дебету + Оборот по кредиту.
Опять таки мы должны анализировать счет взаиморасчетом в поставщиков (тип «Кредиторская задолженность»)
Налоговый кредит по НДС =
= (Сальдо Дт субсчета 631 на конец отчетного периода —
— Сальдо Дт субсчета 631 на начало отчетного периода +
+ Оборот по Кт субсчета 631 за отчетный период) : 1,2 х 20 %
Если мы отслеживаем первое событие по договорам (в контрагенте стоит такая пометка), то анализировать взаиморасчеты мы должны в разрезе договоров (формула та же).
Следующим шагом будет настройка налогов. В налоге мы определяем что этот налог у нас будет ндс-ным налогом. А группе к которой он относится присвоим соответствующий код ставки налога (которые нам понадобится для налоговой накладной)
Далее в общих настройках мы определяем какие счета у нас будут использоваться при учете первого события. Набор стандартный
Далее нам надо решить проблему с определением суммы налога на уровне позиции банковской выписки — мы должны иметь возможность указать платеж у нас с ндс или нет
Эта информация чисто информативная и не отображается в бухгалтерской проводке, которую делает банковская выписка. Но эта информация нам потребуется в дальнейшем для формирования налоговых накладных.
Расчет первого события
После того как бухгалтер провел все документы за определенный период (приходы, расходы и банковские выписки) он может запустить расчет первого события за этот период.
При расчете первого события создаются бухгалтерские проводки (записи журналов) с привязкой к документу источнику первого события и автоматически формируются налоговые накладные
Все проводки и налоговые накладные создаются в статусе черновика и расчет первого события можно запускать столько раз сколько нужно до момента проведения в учете проводок или налоговых накладных. Все счета для проводок берутся из настроек.
Номенклатура для налоговых накладных берется из реализации товаров и услуг (инвойса), если источником первого события был инвойс или из заказа продаж указанного в позиции банковской выписки. Если позиция банковской выписки была без указанного заказа продаж, номенклатура берется из настроек компании и такие налоговые помечаются как требующие проверки.
Аналогично мы поступает для расчета первого события по поставщикам
Налоговые накладные поставщиков автоматически не формируются. Их можно либо создать вручную, когда нам поставщик даст налоговую накладную либо импортировать такую налоговую в формате xml.
Первое событие всегда делает одну проводку, счета для которой берутся из настроек, как правило это будет проводка ДТ 6431 Кт 6432
Если первым событием была оплата, то если вторым событием будет инвойс (реализация), то он сделает проводку Дт 361 Кт 6431 и 6431 у нас свернется в «0». А оборот по 6432 закроет в «0» налоговая накладная.
Если же первым событием был инвойс (реализация), то он при проведении сделает проводку Дт 361 Кт 6431. Если при расчете первого события выяснится, что инвойс (реализация) является первым событием, то проводка Дт6431 Кт6432 свернет 6431 в «0». А оборот по 6432 закроет в «0» налоговая накладная.
Реализация в ODOO делает такую проводку:
Например продали клиенту товар на 12000,00 грн (в т.ч. НДС — 2000)
Дт 361 — 12000
Кт 702 — 10000
Кт 6431 — 2000, то есть 702 сразу сворачиваться
Налоговые накладные, расчеты -корректировки и налоговые накладные поставщиков
Налоговые накладные
Налоговая накладная может создаться автоматически при расчете первого события, может быть сформирована из сессии/сессий точки продаж либо ее можно сформировать вручную. С первым случаем мы уже познакомились.
Если компания пользуется функционалом точки продаж, то есть ведет розничную торговлю, то ей нет смысла формировать налоговую накладную на каждую продажу (заказ точки продаж), а нужно сформировать сводную налоговую накладную по итогам сессии/сессий точки продаж, которая будет в себя включать все проданные товары. Сформированные таким образом налоговые накладные привязываются к сессиям точки продаж.
Давайте познакомимся ближе с документом «Налоговая накладная»
Налоговая накладная имеет в системе определенный жизненный цикл: черновик, подготовлен, на регистрации, зарегистрирована. Для регистрации налоговой накладной в ЕРНН ее можно выгрузить в формат xml и загрузить в сервис для подачи отчетности (Медок, Соната, Арт-Звит,…_).
Сама налоговая накладная имеет дату создания, срок регистрации и ее можно пометить как незарегистрированную либо как зарегистрированную с опозданием. Во вкладке «Налог» делается подитог по всем налогам в документе.
Во вкладке «Дополнительная информация» можно указать причину невыдачи налоговой накладной покупателю, сводная ли это налоговая и если да, то указать тип сводной налоговой.
После проведения в учете налоговая накладная сделает проводку с использованием тех счетов, которые указаны в настройках.
Расчеты-корректировки
Если мы сформировали налоговую накладную неправильно и успели ее зарегистрировать/отобразить в отчетности, то для того чтобы ее исправить мы должны на нее сформировать расчет-корректировку (РК).
Расчеты-корректировки уже формируются автоматически при возвратах товара либо ее можно создать вручную. В самой РК мы должны указать к какой налоговой накладной мы ее выписываем.
В самой РК мы можем указать, что мы корректируем количество или цену и указать причину корректировки.
Сама РК имеет свой жизненный цикл, как и налоговая накладная. И ее также можно выгрузить в файл формата xml.
Налоговые накладные поставщиков (и корректировки к ним)
Сама налоговая накладная поставщика имеет два типа: налоговая накладная и расчет-корректировка. В самом документе не указывается номенклатура, а просто отображается сумма на которую нам поставщик дал документ. Создать этот документ мы можем либо вручную либо импортировать из файла xml (только для типа «Налоговая накладная»)
Подытожим
Таким образом я в ODOO решил вопрос с первым событием и с автоматизацией процесса формирования налоговых накладных.
Если говорить про будущие планы по развитию данного решения, то среди них есть такие:
- Декларация по НДС с приложениями и выгрузка в XML (это планировалось сделать до конца марта, но планы немного поменялись)
- Возврат денежных средств и корректировка налоговых обязательств (при расчете первого события)
- Возврат товара поставщику и корректировка налогового кредита (при расчете первого события)
- Возврат денежных средств поставщику и корректировка налогового кредита (при расчете первого события)
- Отслеживание первого события если при продаже (закупке) используется
больше одного налога (например — акциз) - Реализация механизма годового перерасчета НДС (но это вопрос неблизкого будущего)
