Підводні камені автоматизації обліку ПДВ
Облік ПДВ в Україні має свої особливості, які роблять його унікальним у світі та які дуже ускладнюють його автоматизацію. Зараз на ринку немає жодного рішення, яке б дозволяло повністю автоматизувати цю ділянку обліку – навіть і тому ж 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 є замовлення на продаж. Він є підставою для формування переміщення по складу та інвойсу покупця (в наших реаліях – видаткової накладної або акту, але ми цей документ називаємо документом реалізації). Також є окрема сутність – договір, яку можна вказати в замовленні і вона є обов’язковою, якщо обраний варіант розрахунку першої події в розрізі договорів.
Якщо надходить оплата, то її ми можемо прив’язати до замовлення та/або договору. В момент проведення оплати, якщо в обліку є заборгованість її ми можемо звірити з платежем (в такому разі аналітика “договір” та “замовлення” візьмуться зі звіряємого документу реалізації). Якщо ж у нас передплата, то в інтерфейсі банківської виписки є можливість вказати замовлення та/або договір по якому її слід зафіксувати (такий платіж має статус “Відкритий баланс”).
Якщо передплату слід зафіксувати по декількох замовленням/договорам, то користувач самостійно створює стільки позицій банківської виписки скільки потрібно.
Звіт “Перша подія”
Для відображення розрахунку першої події нами був доданий окремий звіт, який так і називається – “Перша подія”. Він містить наступні налаштування:
- Період звіту – за який період ми хочемо проаналізувати дані та сформувати записи по першій події (а також податкові накладні та розрахунки-коригування)
- Рахунок – обрати варіант “Дебітор” (податкові зобов’язання) або “Кредитор” (податковий кредит)
- Перша подія – обрати один із варіантів: “В розрізі замовлень”, “В розрізі договорів”, “В цілому по контрагенту”. При вибору варіанту будуть відображатися тільки ті контрагенти в яких обраний відповідний варіант. Є ще варіант “Усі”, але він призначений для аналізу в цілому вже сформованих податкових зобов’язань.
- Партнери – можна обрати контрагентів по яким ви хочете подивитися інформацію або/та сформувати податкові зобов’язання
- Опції – можна обрати групування по договорах або замовленнях в залежності від того який варіант обраний в налаштуванні “Перша подія”, а також розгорнути/згорнути увесь звіт.
Бухгалтер має змогу в цьому звіті перевірити розрахунок першої події, перейти у документ – джерело першої події, запустити процедуру (за період звіту або по конкретному партнеру) створення записів по першій події (Дт 6431 Кт 6432) та податкових накладних/розрахунків коригувань (далі буду їх називати податкові документи). В колонці ПДВ відображається сума податку у сформованих податкових документах.
Після формування податкових документів він прямо зі звіту може перейти в запис по першій події та податковий документ.
Основним джерелом номенклатури для податкових документів є замовлення на продаж, тож його дуже важливо вказувати в момент проведення платежів. Якщо сума першої події менше ніж сума замовлення, то у сформованій податковій накладній кількість номенклатури буде вказана пропорційно (наприклад сума замовлення 100000 грн, а сума документа реалізації – 70000, в такому разі до номенклатури буде застосований коефіцієнт 0,7).
Для того, щоб переформувати податкові документи – їх спочатку слід видалити в системі.
Перша подія завжди відображається записом Дт 6431 Кт 6432 на суму податку (рахунки беруться із налаштувань). Це пов’язано з тим, що документ реалізації завжди в момент проведення робить запис по ПДВ – Дт 361 Кт 6431. Якщо він є джерелом першої події, то запис по першій події закриє 6431 в “нуль” і залишиться лише сума на 6432, яку в свою чергу закриє в “нуль” податкова накладна (Дт 6432 Кт 6412).
Податкові документи
Основним документом в обліку ПДВ – є податкова накладна. Вона в системі може формуватися:
- автоматично – зі звіту по першій події. Це ті податкові накладні які пов’язані з продажами;
- напівавтоматично – з сесії точки продажів. Це податкові накладні які формуються у роздрібній торгівлі, де, як відомо немає першої події і податкові складаються за щоденними підсумками операцій.
- вручну – коли бухгалтер розуміє, що йому треба виписати податкову накладну при настанні певних подій в господарській діяльності компанії.
Податкова накладна має в системі певний життєвий цикл. Зареєстровані податкові накладні мають бути переведені у статус “Зареєстровано”. Податкова накладна також має зв’язок з замовленням та/або договором.
На підставі податкової накладної можна сформувати розрахунок-коригування (РК). РК автоматично створюється у двох випадках: поверненні товару (формуванню в системі кредит-ноти) та поверненні коштів. В інших випадках він формується вручну. Заповнення табличної частини РК бухгалтер здійснює самостійно.
Податкову накладну та розрахунок-коригування можна вивантажити у файл формату xml, а потім його можна завантажити у сервіс для здачі звітності (наприклад – Медок).
Податковий кредит та податкові документи постачальника
Механізм відстеження першої події по постачальника, як любить казати один з наших розробників, дзеркальний тому, який використовується для податкових зобов’язань. І це дійсно так – подивіться ще раз на схему вище. Але тут ситуація трохи інша. Податковий документ постачальника має дещо спрощений вигляд і в ньому фіксується лише сума на яку нам постачальник надав податкову накладну.
Система розраховує першу подію по постачальниках і ми через звіт можемо запустити процедуру створення записів по першій події. Потім коли у нас з’являється в системі податковий документ постачальника ми його можемо звірити з записом по першій події (знову ця звірка випливла, але що поробиш – це базовий інструмент системи).
Перша подія по постачальниках в обліку має вигляд – Дт 6442 Кт 6441 на суму податку (рахунки беруться з налаштувань). Інформація про податки береться з замовлення на купівлю, якщо його немає – тоді використовується ставка податку із налаштувань.
Податковий документ постачальника можна або імпортувати з файлу у форматі xml, або створити вручну.
Декларація з ПДВ
Після того як сформовані наші податкові накладні та розрахунки коригування, проведені податкові документи постачальника можна розпочинати формування податкової декларації з ПДВ.
Її можна сформувати за довільний проміжок часу (як правило він буде дорівнювати місяцю). Вона заповнюється автоматично (сама декларація, додаток 1 та додаток 5) на підставі тих даних які є в системі.
Користувач в разі потреби може відредагувати дані в декларації і зберегти внесені зміни. Після того як декларація сформована та перевірені – її можна вивантажити у файли формату xml та завантажити у сервіс для подання звітності.
Висновки
Той функціонал який був описаний вище можна сказати був створений з “нуля”, але як на мій погляд вийшло точно не гірше ніж в інших облікових системах.
Тож український бізнес вже може з більшим інтересом дивитися в сторону Odoo, як заміннику російських продуктів – 1С та BAS. А на підході у нас заробітна плата та облік основних засобів. Тож стежте за оновленнями в моєму блозі. Буде цікаво.
Джерело: Блог консультанта
