Головна » ODOO » Облік ПДВ в ERP Odoo Enterprise (РБО від Self-ERP)
ODOO

Облік ПДВ в ERP Odoo Enterprise (РБО від Self-ERP)

Поділіться з друзями - підтримайте проект

Print Friendly, PDF & Email

Підводні камені автоматизації обліку ПДВ

Облік ПДВ в Україні має свої особливості, які роблять його унікальним у світі та які дуже ускладнюють його автоматизацію. Зараз на ринку немає жодного рішення, яке б дозволяло повністю автоматизувати цю ділянку обліку – навіть і тому ж BAS (тьху на нього) цей процес напівавтоматичний.

Немає такого механізму і в Odoo – тож треба було його придумати та реалізувати з нуля.  Півтори роки тому в мене була спроба це зробити, я про неї писав ось тут, але вона на превеликий жаль не була доведена до кінця у зв’язку з подіями 24 лютого. В цьому році мені випав шанс взяти участь у проєкті компанії Self-ERP по створенні регламентованого бухгалтерського обліку (РБО) на базі Odoo Enterprise в якості власника продукту (є така роль в IT-сфері). Тепер мені хочеться представити вам функціонал, який нами був реалізований для обліку ПДВ.

Але для початку трохи про проблематику автоматизації обліку ПДВ.

В українському податковому законодавстві є таке чудове явище, як перша подія. Її визначення наведено в ст. 187 ПКУ:

187.1. Датою виникнення податкових зобов’язань з постачання товарів/послуг вважається дата, яка припадає на податковий період, протягом якого відбувається будь-яка з подій, що сталася раніше:

а) дата зарахування коштів від покупця/замовника на банківський рахунок платника податку як оплата товарів/послуг, що підлягають постачанню, а в разі постачання товарів/послуг за готівку — дата оприбуткування коштів у касі платника податку, а в разі відсутності такої — дата інкасації готівки у банківській установі, що обслуговує платника податку;

б) дата відвантаження товарів, а в разі експорту товарів — дата оформлення митної декларації, що засвідчує факт перетинання митного кордону України, оформлена відповідно до вимог митного законодавства, а для послуг — дата оформлення документа, що засвідчує факт постачання послуг платником податку.

При цьому перша подія може визначатися по різному. Згідно з пунктом 18 Порядку №1307, податкова накладна складається на кожне повне або часткове постачання товарів/послуг, а також на суму коштів, що надійшли на поточний рахунок як попередня оплата (аванс). По суті, ця ж норма прописана у пункті 201.7 ПКУ. Як відокремити одне постачання від наступного, у ПКУ чіткої відповіді немає. Втім, слід виходити з поняття господарської операції з постачання товарів. Адже об’єктом оподаткування ПДВ є саме операція постачання, то й передбачається, що аванс перераховується під операцію постачання. Якщо постачання врегульовується договором, то першу подію слід визначати в розрізі договорів, якщо договору немає – то за основу розрахунку першої події слід брати рахунки на оплату (“рахунки-фактури” мені не дуже подобається термін) або замовлення. Як визначати першу подію вирішує підприємство самостійно в залежності від ситуації – при цьому для різних контрагентів механізм її визначення може бути різний.

Також ПДВ може виникати при настанні певних подій. Наприклад, купили щось у постачальника і почали використовувати те, що купили у негосподарській діяльності  – треба виписати податкову накладну. Або прийняли самостійне рішення ліквідувати основний засіб, а він не повністю замортизований – будь ласка, оформіть податкову накладну, і т.д. Держава робить все для того, щоб зібрати більше коштів з бізнесу. Спрощення обліку ПДВ дозволило зробити просте і зрозуміле IT рішення для бухгалтерів та спростило б його адміністрування. Але хто ж хоче втрачати годівницю та корупційну складову? І страждати повинні і бухгалтери, і айтішники (як це не дивно).

Ті рішення, які є зараз на ринку, по різному розв’язують дану проблему. В західних облікових системах (наприклад в SAP Business One) та в більшості вітчизняних  реалізований найпростіший варіант – в розрізі рахунків (замовлень), в деяких є можливість вести облік ПДВ і в розрізі договорів, і в розрізі рахунків. Огляди деяких вітчизняних облікових систем (Діловод, Майстер:Бухгалтерія, Дебет-плюс тощо) ви можете знайти в моєму блозі у розділі “Обзоры” тож зараз я не буду детально зупинятися на тому, як в них влаштований облік ПДВ.

Розраховувати ПДВ можна і в момент проведення документів, але перед формуванням податкових накладних (основного документа в обліку ПДВ) треба зробити так, щоб вони були проведені в хронологічній послідовності (життя воно таке, що бухгалтери досить часто проводять документи заднім числом) – для цього в деяких облікових системах є окрема процедура – перепроведення документів. В більш складних IT-рішеннях (наприклад ERP-системах) – зробити таку процедуру може бути нереально. Тому в деяких ERP-системах звісно є реалізований облік ПДВ, але в досить обмеженому вигляді. Тож треба було знайти інший шлях і він був знайдений :)

ERP Odoo та ПДВ: початок

Облік взаєморозрахунків

Як ви вже зрозуміли об’єктом оподаткування ПДВ є операція з постачання по якій виникають взаєморозрахунки з контрагентом. В обліку такі операції які пов’язані з постачанням фіксуються кількома документами, основними з яких є: документ реалізації (видаткова накладна, акт) та банківська виписка (позиція виписки, платіжне доручення). В результаті відображення в обліку цих документів з’являється інформація по рахунку обліку взаєморозрахунків (наприклад по 361).

Деякі підприємства (їх небагато, але вони є) використовують для обліку передплат окремі рахунки авансів, коли ж потім з’являється заборгованість клієнта – в системі робиться взаємозалік авансу та заборгованості. Ці ж рахунки авансів бухгалтери використовують при обліку ПДВ. З’явився кредитовий оборот по такому рахунку (як правило це буде 6811) – все є перша подія, можна виписувати податкову. Більшість підприємств рахунки авансів не використовують, бо їх використання ускладнює облік і як на мене є зайвим (проте деякі мої колеги з цим не згодні).

В ERP Odoo немає такого поняття як рахунок авансу. Всі взаєморозрахунки з контрагентом відображаються на одному рахунку. Причому якщо в обліку є аванс, то він відображається по кредиту рахунку обліку взаєморозрахунків( наприклад по 361) і така сума відображається як незвірена. Коли ж обліку з’являється заборгованість – її можна звірити з оплатою (при цьому додаткові проведення не робляться). Звірка дуже цікавий інструмент в Odoo і я про неї можливо більш детально розкажу в одній із наступних публікацій.

Для того, щоб відстежувати першу подію достатньо відстежувати зміну сальда (залишка) по рахунку обліку взаєморозрахунків в розрізі необхідно аналітики (замовлення або договір) після кожної операції, а для цього в обліку треба мати таку аналітику.

Така аналітика була нами додана ще на першому етапі реалізації регламентованого обліку.

Чи є перша подія (в розрізі необхідної аналітики) можна визначити по формулі:

Кінцеве сальдо по кредиту – Початкове сальдо по кредиту + Дебетовий оборот

Вона і була взята нами за основу.

Податки в ERP Odoo

В Odoo звісно є облік податків, але він ніяк не пристосований до наших реалій. В інших країнах звісно ж є такий податок як ПДВ, але податкові зобов’язання там виникають, або в момент виникнення доходу, або в момент надходження коштів на рахунок. В деяких країнах підприємства навіть можуть обирати – яка в них буде база оподаткування. І погодьтесь – так рахувати ПДВ значно простіше. Звісно для Odoo Україна не була та не є основним ринком збуту і робити локалізацію під Україну найближчим часом вона точно не буде. Тож це повинні зробити українські компанії.

Як влаштований облік податків в Odoo? Досить просто. У системі є окремий об’єкт “Податок” на рівні якого ми можемо задати формулу розрахунку податку та рахунок бухгалтерського обліку, на якому відображатиметься його сума. При цьому податки поділяються на три групи (сфери застосування): для продажу, закупівлі та інші. Тобто якщо ми, наприклад, створюємо податок ПДВ зі ставкою 20% — ми маємо створити як мінімум два податки: один для сфери продажів, другий для сфери закупівель. На рівні податку також визначається буде даний податок включатися в ціну чи ні.

При продажах чи закупівлях ми можемо використовувати більше одного податку. Сума кожного податку відображатиметься на рахунках, які ми вкажемо в налаштуваннях, при цьому цю суму можна розкидати на кілька бухгалтерських рахунків у певному відсотковому співвідношенні (у наших реаліях це не потрібно).

Усі податки об’єднуються у групи. Тобто ми можемо створити групу податків «ПДВ 20%» і додати до неї наші 4 податку з такою ставкою (два зі сфери продажу та два зі сфери закупівель — пдв 20%, пдв в т.ч. 20%).

Облік ПДВ в ERP Odoo

Загальну реалізовану нами схему обліку ПДВ можна представити в наступному вигляді:

Налаштування

Для того, щоб система робила все правильно – її слід коректно налаштувати. Цих налаштувань не так багато, але всі вони важливі.

По-перше, слід налаштувати картку компанії і вказати там ІПН, ЄДРПОУ, податкову інспекцію та відповідальних осіб.

По-друге, в картці контактів повинні стояти вірні налаштування відстеження першої події. Міняти часто я їх не рекомендую, це може призвести до плутанини.

По-третє, в картці продуктів повинні бути зроблені вірні налаштування: код УКТЗЕД,чи імпортний це товар, код за ДКПП та обрані правильні податки, які будуть використовуватися при продажах та закупівлях.

По-четверте, податки які ви будете використовувати при продажах повинні належати до правильних груп податків.

І по-п’яте, в системі повинні бути зроблені вірні налаштування в загальних налаштуваннях.

Продажі

Давайте розгляньмо більш детально організацію процесу продажів в системі (з точки зору обліку). Основним документом для відображення продажів в Odoo є замовлення на продаж. Він є підставою для формування переміщення по складу та інвойсу покупця (в наших реаліях – видаткової накладної або акту, але ми цей документ називаємо документом реалізації). Також є окрема сутність – договір, яку можна вказати в замовленні і вона є обов’язковою, якщо обраний варіант розрахунку першої події в розрізі договорів.

Якщо надходить оплата, то її ми можемо прив’язати до замовлення та/або договору. В момент проведення оплати, якщо в обліку є заборгованість її ми можемо звірити з платежем (в такому разі аналітика “договір” та “замовлення” візьмуться зі звіряємого документу реалізації). Якщо ж у нас передплата, то в інтерфейсі банківської виписки є можливість вказати замовлення та/або договір по якому її слід зафіксувати (такий платіж має статус “Відкритий баланс”).

Якщо передплату слід зафіксувати по декількох замовленням/договорам, то користувач самостійно створює стільки позицій банківської виписки скільки потрібно.

Якщо на рівні контрагента обраний варіант відстеження першої події “В розрізі договорів”, то при проведенні платежу можна не вказувати по якому замовленню цей платіж, але в такому разі при формуванні податкових накладних номенклатура та ставка ПДВ буде братися із налаштувань системи і бухгалтеру доведеться самостійно наповнювати таку податкову номенклатурою, а надалі – контролювати номенклатуру в подальших податкових накладних. Доречі, такі податкові помічаються відміткою “Перевірити” і бухгалтер буде одразу бачити, що є сформовані податкові з дефолтною номенклатурою.

Звіт “Перша подія”

Для відображення розрахунку першої події нами був доданий окремий звіт, який так і називається – “Перша подія”. Він містить наступні налаштування:

  1. Період звіту – за який період ми хочемо проаналізувати дані та сформувати записи по першій події (а також податкові накладні та розрахунки-коригування)
  2. Рахунок – обрати варіант “Дебітор” (податкові зобов’язання) або “Кредитор” (податковий кредит)
  3. Перша подія – обрати один із варіантів: “В розрізі замовлень”, “В розрізі договорів”, “В цілому по контрагенту”. При вибору варіанту будуть відображатися тільки ті контрагенти в яких обраний відповідний варіант. Є ще варіант “Усі”, але він призначений для аналізу в цілому вже сформованих податкових зобов’язань.
  4. Партнери – можна обрати контрагентів по яким ви хочете подивитися інформацію або/та сформувати податкові зобов’язання
  5. Опції – можна обрати групування по договорах або замовленнях в залежності від того який варіант обраний в налаштуванні “Перша подія”, а також розгорнути/згорнути увесь звіт.
Звіт по першій події – в розрізі замовлень

Бухгалтер має змогу в цьому звіті перевірити розрахунок першої події, перейти у документ – джерело першої події, запустити процедуру (за період звіту або по конкретному партнеру) створення записів по першій події (Дт 6431 Кт 6432) та податкових накладних/розрахунків коригувань (далі буду їх називати податкові документи). В колонці ПДВ відображається сума податку у сформованих податкових документах.

Після формування податкових документів він прямо зі звіту може перейти в запис по першій події та податковий документ.

Основним джерелом номенклатури для податкових документів є замовлення на продаж, тож його дуже важливо вказувати в момент проведення платежів. Якщо сума першої події менше ніж сума замовлення, то у сформованій податковій накладній кількість номенклатури буде вказана пропорційно (наприклад сума замовлення 100000 грн, а сума документа реалізації – 70000, в такому разі до номенклатури буде застосований коефіцієнт 0,7).

Для того, щоб переформувати податкові документи – їх спочатку слід видалити в системі.

Перша подія завжди відображається записом Дт 6431 Кт 6432 на суму податку (рахунки беруться із налаштувань). Це пов’язано з тим, що документ реалізації  завжди в момент проведення робить запис по ПДВ – Дт 361 Кт 6431. Якщо він є джерелом першої події, то запис по першій події закриє 6431 в “нуль” і залишиться лише сума на 6432, яку в свою чергу закриє в “нуль” податкова накладна (Дт 6432 Кт 6412).

Податкові документи

Основним документом в обліку ПДВ – є податкова накладна. Вона в системі може формуватися:

  • автоматично – зі звіту по першій події. Це ті податкові накладні які пов’язані з продажами;
  • напівавтоматично – з сесії точки продажів. Це податкові накладні які формуються у роздрібній торгівлі, де, як відомо немає першої події і податкові складаються за щоденними підсумками операцій.
  • вручну – коли бухгалтер розуміє, що йому треба виписати податкову накладну при настанні певних подій в господарській діяльності компанії.
Податкова накладна в ERP Odoo

Податкова накладна має в системі певний життєвий цикл. Зареєстровані податкові накладні мають бути переведені у статус “Зареєстровано”. Податкова накладна також має зв’язок з замовленням та/або договором.

На підставі податкової накладної можна сформувати розрахунок-коригування (РК). РК автоматично створюється у двох випадках: поверненні товару (формуванню в системі кредит-ноти) та поверненні коштів. В інших випадках він формується вручну. Заповнення табличної частини РК бухгалтер здійснює самостійно.

Розрахунок-коригування в ERP Odoo

Податкову накладну та розрахунок-коригування можна вивантажити у файл формату xml, а потім його можна завантажити у сервіс для здачі звітності (наприклад – Медок).

Податковий кредит та податкові документи постачальника

Механізм відстеження першої події по постачальника, як любить казати один з наших розробників, дзеркальний тому, який використовується для податкових зобов’язань. І це дійсно так – подивіться ще раз на схему вище. Але тут ситуація трохи інша. Податковий документ постачальника має дещо спрощений вигляд і в ньому фіксується лише сума на яку нам постачальник надав податкову накладну.

Податковий документ постачальника в ERP Odoo

Система розраховує першу подію по постачальниках і ми через звіт можемо запустити процедуру створення записів по першій події. Потім коли у нас з’являється в системі податковий документ постачальника ми його можемо звірити з записом по першій події (знову ця звірка випливла, але що поробиш – це базовий інструмент системи).

Перша подія по постачальниках в обліку має вигляд – Дт 6442 Кт 6441 на суму податку (рахунки беруться з налаштувань). Інформація про податки береться з замовлення на купівлю, якщо його немає – тоді використовується ставка податку із налаштувань.

Податковий документ постачальника можна або імпортувати з файлу у форматі xml, або створити вручну.

Декларація з ПДВ

Після того як сформовані наші податкові накладні та розрахунки коригування, проведені податкові документи постачальника можна розпочинати формування податкової декларації з ПДВ.

Її можна сформувати за довільний проміжок часу (як правило він буде дорівнювати місяцю). Вона заповнюється автоматично (сама декларація, додаток 1 та додаток 5) на підставі тих даних які є в системі.

Користувач в разі потреби може відредагувати дані в декларації і зберегти внесені зміни. Після того як декларація сформована та перевірені – її можна вивантажити у файли формату xml та завантажити у сервіс для подання звітності.

Висновки

Той функціонал який був описаний вище можна сказати був створений з “нуля”, але як на мій погляд вийшло точно не гірше ніж в інших облікових системах.

Тож український бізнес вже може з більшим інтересом дивитися в сторону Odoo, як заміннику російських продуктів – 1С та BAS. А на підході у нас заробітна плата та облік основних засобів. Тож стежте за оновленнями в моєму блозі. Буде цікаво.

Джерело: Блог консультанта


Поділіться з друзями - підтримайте проект
Мітки

Наша розсилка