Сайт для бухгалтеров №1 в Украине

Получайте
новости почтой!


13.05.19
17570 7 Печатать

Особливості обліку ПДВ у програмі 1С: Бухгалтерія для України редакція 2.0.

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

  1. Регулювання порядку визначення першої події по ПДВ за допомогою налаштуваннясистеми взаєморозрахунків з контрагентами
  2. Шляхи вирішення помилок, що стосуються питання визначення першої події.

Інформація буде  актуальна для такого способу ведення обліку ПДВ, коли не використовується «складний облік» в договорах з контрагентами.

Яка закладена логіка обліку?

Облік взаєморозрахунків з покупцями та постачальниками в Бухгалтерії 2.0  побудований схоже, тому розглянемо на прикладі постачальників.

Для обліку ПДВ з постачальниками 1С:Підприємством передбачено 3 регістра:

  1. Регістр накопичення «Придбання податковий облік»
  2. Регістр накопичення «Очікуваний і підтверджений ПДВ придбань»
  3. Регістр бухгалтерії«Журнал проводок» (бухгалтерський облік)

Рушійним  регістром є «Придбання податковий облік», саме його дані визначають, які будуть проводки по ПДВ та записи регістру «Очікуваний і підтверджений ПДВ придбань», тобто саме цей регістр вираховує першу подію.

Регістр «Очікуваний та підтверджений ПДВ придбань» показує чи всі податкові накладні отримані згідно з визначеною першою подією.

Як саме це працює?

Дані регістру групуються за ознаками: Організація, Договір контрагента, Документ розрахунків, Зворотна тара, Ставка ПДВ, Вид діяльності ПДВ, Ознака придбання основних фондів (див. скрін 1). Дані порівнюються по виміру «Подія» за  таким парним значенням: «Оплата постачальнику» та «Надходження від постачальника», «Повернення оплати постачальником» та «Повернення постачальнику».

Скрін 1.

Наприклад, проводиться документ «Списання з банківського рахунку» з певним набором значень на суму 6000 грн з ПДВ 20%. Якщо документ перший з таким набором значень , тобто тільки почали працювати з клієнтом по договору, то система перевіряє, що залишку по регістру немає, а отже вся сума документа є першою подією по ПДВ.

Далі вводимо документ «Надходження товарів і послуг» з тим же набором вимірів, але з сумою  15 000 грн. Система знаходить записи за таким набором вимірів з парною подією на суму 6000 грн., зараховує цю суму в другу подію, а на різницю в 9 000 грн формує нову першу подію. В  той час, якщо хоч один із вимірів не співпаде, то документ вважатиметься зовсім окремою ситуацією і перша подія сформується на всю суму 15 000 грн. Більшість помилок пов’язані саме з відмінністю  цих вимірів.

Основні помилки

Далі, ми розглянемо всі помилки по взаєморозрахункам з контрагентами по ПДВ за  причинами виникнення:

1) непослідовне введення документів,

2) відмінність вимірів,

3) ручне виправлення сум ПДВ та проводок,

4) відображення взаєморозрахунків за допомогою документу «Операції»,

5) некоректні налаштування системи,

6) незакрите повернення.

1) Непослідовне введення документів.

Всі досвідчені користувачі програми 1С:Підприємство знають, що дата та час створеного облікового документа мають значення. Чому може статись помилка під час визначення першої події у зв’язку із часом введення? Розглянемо ситуацію: бухгалтер  вводить накладні, а ось банк спочатку проводить через систему клієнт-банку, а потім за підсумками дня/тижня завантажує в програму за допомогою спеціальної обробки. Підприємство зробило передплату за товар і наступного дня отримало товар. Бухгалтер вносить накладну, по ній програма вираховує першу подію. Потім робить завантаження виписок з клієнт-банку за попередній день.   1С:Підприємство  по передплаті також рахує першу подію, адже на момент проведення (дата та час) платіжного документа ніяких інших операцій не зафіксовано. Вноситься податкова накладна і в результаті маємо дебетове сальдо  рахунку 6442, якого не повинно бути.

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

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

2) Відмінність вимірів.

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

Наприклад, які бувають помилки:

  • придбали основний засіб, а в платіжному документі не поставили ознаку ОФ (основні фонди);
  • в платіжному документі вказали один договір, а в надходженні товарів і послуг - інший;
  • в платіжному документі вказали розрахунковий документ, а в надходженні товарів і послуг не вказали або вказали інший (якщо взаєморозрахунки за договором ведуться з деталізацією по розрахункових документах (див. скрін 2));
  • та інші.

Скрін 2.

3) Ручне виправлення сум ПДВ та проводок.

Періодично трапляються випадки, коли користувачі виправляють суму ПДВ автоматично розраховану системою згідно вказаної ставки. Це також призводить до подальших помилок. Якщо платіж був проведений на загальну суму, частина якої оподатковується ПДВ, а частина ні, то правильним буде розбити цю суму на 2 рядки та вказати різні ставки (Без ПДВ та 20%), а не виправляти самостійно  суму ПДВ. Як це зробити відображено нижче (див. скрін 3).

Скрін 3.

4) Відображення взаєморозрахунків з контрагентами за допомогою документа «Операції».

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

5) Некоректне введення залишків.

Всі вищевказані причини помилок стосуються також і документа введення залишків. Якщо, наприклад, встановити ставку «Без ПДВ» для контрагента, з яким взаєморозрахунки ведуться за ставкою «20% ПДВ», то вказана в документі сума буде враховуватися системою окремо, що також призведе до викривлення записів по регістрах під час  введення наступних  документів.

6) Некоректні налаштування системи.

Для того, щоб був можливий облік ПДВ по організації, має бути налаштована облікова політика, а саме заповнена схема оподаткування «Податок на прибуток та ПДВ» або «Єдиний податок та ПДВ».

Також слід перевірити налаштування в договорі з контрагентом (див. скрін 2 та скрін 4 ): реквізити «Складний облік ПДВ» та  «Схема податкового обліку».

Скрін 4.

Третя складова налаштувань – рахунки розрахунків з контрагентами. Для того, щоб перевірити всі  налаштування цього регістру необхідно зайти в меню «Довідники» – група «Купівлі та продажі» – Рахунки розрахунків з контрагентами. Якщо у вас це налаштування не виведене в меню, ви можете  швидко додати його, користуючись вказівками на скріні 5.

Скрін 5.

При першому старті системи створюються налаштування рахунків за  замовчуванням.

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

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

Скрін 6.

Скрін 7.

7) Незакрите повернення.

В Бухгалтерії 2.0 повернення обліковуються окремими документами або видами операцій документа, й відповідно, на окремих вимірах «подія» регістрів з обліку ПДВ. В регістрі «Придбання податковий облік» це такі парні значення: Повернення оплати постачальнику та Повернення постачальнику. В регістрі «Очікуваний і підтверджений ПДВ придбань» це подія «повернення».

Як виникає незакрите повернення і що з цим робити?

Наприклад, придбали  і оприбуткували товар, оплатили його, потім повернули товар і отримали натомість  інший. А оплату не повертали – ось і класична ситуація незакритого повернення. Для того, щоб програма надалі коректно вираховувала першу подію необхідно закрити повернення, тобто зробити документ «Коригування боргу» (див. скрін 10).

! Зверніть увагу, якщо оплата товару пройшла після повернення, то коригування проводити не потрібно.

Щоб показати випадок незакритого повернення, відображені звіти: оборотно-сальдова відомість по рахунку 631 та «Універсальний звіт» по регістру накопичення «Придбання податковий облік» до коригування та після нього (див скрин 8, 9, 11, 12 ).

Звіти до коригування.

Скрін  8.

Скрін 9.

Коригування боргу.

Скрін 10.

Звіти після коригування.

Скрін 11.

Скрін 12.

Як бачимо  зі скріншотів, коригування боргу закриває цикл взаєморозрахунків.

Що стосується операцій повернення, зверніть увагу, що документи Додаток 2 до ПН слід вводити з видом операції «повернення» лише  у випадку реального повернення товарів чи коштів, у всіх інших -  слід вибирати вид операції «зміна суми компенсації» (див. скрін 13)

Скрін 13.

Ми розглянули всі основні моменти. Сподіваємось, що відтепер облік взаєморозрахунків з контрагентами по ПДВ у програмі Бухгалтерія для України редакції 2.0 стане легким та швидким процесом.

Інформацію надала компанія СОФТКОМ

Бухгалтер 911 подчеркивает: содержание авторских материалов может не совпадать с политикой и точкой зрения редакции. Среди авторов материалов, которые публикуются, есть не только представители редакционной команды.

Информация, представленная в конкретной публикации, отражает позицию автора. Редакция не вмешивается в авторские материалы, не редактирует тексты и, следовательно, не несет ответственности за их содержание.

Комментарии
  • Ігор
13.05.19 10:56

Так, не погано. Однак наступного разу краще приклад на продаж. Якраз тут важливіше не помилитись (особливо з першою подією та не "здвоїти" ПН) бо свій ПДВ контролює постачальник.

Ответить
  • СОФТКОМ
13.05.19 12:11

Ігоре, дякуємо за тему для майбутньої статті! 

Ответить
  • Виталька
13.05.19 14:45

Досвідчені користувачі крім перегляду ОСВ також переглядають та контролюють регістри обілку (в т.ч. очікуваний і підтверджений ПДВ куплі-продажу та придбання-продаж податковий облік ), оскільки мають уявлення про те як взагалі формуються проводки в програмі. 

Ответить
  • СОФТКОМ
13.05.19 16:00

Виталька, ми впевнені, що стаття є корисною як для початківців-користувачів, так й для досвідчених бухгалтерів. Якщо у вас виникнуть додаткові питання, будемо раді відповісти по тел.: (044) 50-141-50

Ответить
  • МС
13.05.19 19:27

Это что, такая типа ненавязчивая реклама продукта?))
Для меня все равно 2.0 в 200 раз менее удобна, чем 1.2, и эта статья - очередной штришок к общей нелицеприятной картине 2.0

Ответить
  • СОФТКОМ
15.05.19 15:02

МС, речь не идет об удобстве 2.0 по сравнению с 1.2. Удобно или нет, а есть уже пользователи, которые работают в 2.0, есть пользователи, которые только перешли или планируют переход.  С целью облегчить работу этим бухгалтерам и была написана данная статья.  Готовы с вами обсудить преимущества 2.0 и помочь в ее использовании, обращайтесь. Будем рады!

Ответить
  • МС
16.05.19 19:59

СОФТКОМ, спасибо! я попробовала в ней работать и так и не поняла, зачем было в новой версии программы (2.0) ухудшать условия работы по сравнению с предыдущей версией (1.2) и никому не советую переходить с 1.2 на 2.0!!!

Ответить
Спасибо, что читаете нас Войдите и читайте дальше
Для того, чтоб распечатать текст необходимо оформить подписку
copy-print__image
Данная функция доступна только
авторизованным пользователям