Поки в інформаційному просторі обговорюють теоретичні аспекти SAF-T UA, команда De7 Partner зосереджена на вирішенні реальних викликів, що виникають під час впровадження нашого продукту “SAF-T UA для SAP” для українських платників податків. Це сприяє постійному та системному вдосконаленню рішення – як з технічного боку, так і з урахуванням побажань користувачів.
Матеріал нижче є розширеною версією заявки “Restrictions of the table FIRUD_CF_OFF_ACC for account offsetting pairs (for SAF-T UA)” (розміщено не ресурсі SAP Customer Influence), яку ми створили з надією, що локалізація SAP буде вдосконалена в частині функціональності по розбору кореспонденції рахунків у випадках, якщо вона не застосовувалась до певної дати.
Ми щиро розраховуємо на голоси партнерів SAP, які точно мають доступ до ресурсу, для вирішення заявки, що сприятиме формуванню звіту SAF-T UA у системах SAP незалежно від обраного рішення.
Ця стаття також:
– розкриває основні відмінності між double-entry system та dual-entry system;
– обґрунтовує облікову природу кореспондуючої пари з погляду законодавчих вимог;
– пояснює основні відмінності “старої” та “нової” кореспонденції рахунків у SAP;
– наводить приклад відображення облікового документа в звіті SAF-T UA;
– пояснює проблеми із функціональністю щодо кореспонденції рахунків у SAP, які виникають в окремих випадках.
SAF-T UA у SAP: "стара" та "нова" кореспонденції, яких архітектурно немає, та проблеми, що доводиться вирішувати
У ERP SAP нативно не передбачено відображення бухгалтерського документа у системі подвійного запису, натомість інформація відображається та зберігається попозиційно, де одна позиція – це інформація про конкретний бухгалтерський рахунок із проведеною сумою та атрибутами, що характеризують дану позицію (контрагент, місце виникнення витрат, основний засіб, контракт, матеріал тощо). Деякі науковці називають таку систему бухгалтерського обліку як «dual-entry system» (Alan Sangster, с. 302), тоді як в Україні історично використовується «double-entry system».
Принципова різниця у відображенні облікового документа при double-entry system та dual-entry system відображена на рисунку 1 нижче.
Розглядаючи звичайний обліковий документ SAP (рис. 2), легко помітити, що він відображений у dual-entry system.
У таблицях SAP інформація зберігається подібним чином (рис. 3).
У зв’язку із застосуванням dual-entry system у західних країнах (і як наслідок – у їх облікових системах), структура файлу SAF-T для країн ЄС передбачає, що для кожного вузла <Line> (як частини облікового документу) буде підібрана інформація щодо відповідного рахунку із його сумою та атрибутами, аналітиками. За кордоном не поширена система ведення подвійного запису бухгалтерських проведень (double-entry system), як це є в Україні внаслідок радянської окупації та повсюдним використанням російської облікової системи 1С (та її варіацій у інших назвах), архітектурне рішення якої засноване на принципі подвійного запису, що очевидно обумовило зміну структури українського формату звіту SAF-T.
З метою забезпечення вимог щодо деяких локальних українських звітів, які (вимоги) обумовлені дотриманням частини 3 статті 9 Закону України «Про бухгалтерський облік та фінансову звітність в Україні», українською локалізацією SAP постачається функціональність, що дозволяє розбирати бухгалтерський документ в систему подвійного запису та зберігати таку інформацію в окремі таблиці.
Розберемось, що власне є кореспондуючою парою з точки зору законодавства та загальних вимог до бухгалтерського обліку.
Згідно з пунктом 1.2 Наказу «Про затвердження Положення про документальне забезпечення записів у бухгалтерському обліку», «первинні документи – це документи, створені у паперовій або електронній формі, які містять відомості про господарські операції», тобто про реальні факти, що мають місце в господарській діяльності. Факт закупівлі або продажу товарів/послуг повинен бути зареєстрований у вигляді податкового документа у базі даних ЄРПН відповідно до ст. 201.10 ПКУ.
Згідно з Порядком №1307, податкова накладна містить деталізовані у Розділі Б дані у розрізі опису (номенклатури) постачання товарів/послуг та їх кількості з відповідними цінами постачання. Порядок та наповнення позицій номенклатури податкової накладної повинні строго відповідати порядку та змісту позицій у первинному документі (видатковій накладній), що підтверджується численними роз’ясненнями ДПС (наприклад, № 1438/ІПК/99-00-21-03-02-06 on 19/06/2023, № 1337/ІПК/99-00-21-03-02-06 on 29/05/2023 тощо).
Згідно з пунктом 1.3 Наказу «Про затвердження Положення про документальне забезпечення записів у бухгалтерському обліку», «записи в регістрах бухгалтерського обліку проводяться на підставі первинних документів, створених відповідно до вимог цього Положення». В Україні, як зазначалось вище, первинні документи відображаються в обліку завдяки double-entry system, для якої кожна позиція облікового документа відображає кореспондуючу пару з її атрибутами. Використання double-entry system також регулюється Інструкцією №291.
Українська версія звіту SAF-T UA (опублікована на офіційному веб-сайті ДПС) передбачає застосування double-entry system у облікових документах, що призводить до потреби обов’язкового відображення кореспондуючих пар із їх атрибутами (матеріал, кількість, одиниця вимірювання, податки тощо) для кожного вузла <Line> у структурах IV.1 Sales information (SalesInvoices)”, ІV.2 Purchases (PurchaseInvoices), ІV.3 (Payments).
Перш ніж перейти до особливостей відображення облікових документів SAP у звіті SAF-T UA, розглянемо особливості так званої «старої» кореспонденції, яка поступово відходить у минуле з активним поширенням SAP S/4HANA та хмарних технологій.
Відображений вище документ (рис. 2, 3) буде збережений наступним чином у системі подвійного запису (рис. 4):
Як бачимо, спеціальна таблиця для збереження подвійного запису містить інформацію лише про кореспондуючі рахунки, індикатори Дт (D) / Кт (S) та суму. При цьому, у випадку документів продажу, рахунок 36100100 потрапляє у три позиції відповідно до кореспондуючих сум на рахунках 70200000 (суми 1000.00 грн та 2000.00 грн) та 64301010 (сума 600.00 грн). Даних про пов’язану із запасами (матеріалами) інформацію у стандартній таблиці для збереження кореспондуючих пар для «старої» кореспонденції – немає. Позаяк, завдяки гнучким налаштуванням команда De7 Partner у своєму продукті “SAF-T UA для SAP” надає можливість на основі таких даних витягнути коректну інформацію з точки зору вимог звіту SAF-T UA. Там, де це неможливо зробити з об’єктивних причин (наприклад, в деяких випадках при Account-based CO-PA), – дані для звіту SAF-T UA вибираються розробленими логіками на основі налаштувань.
Розглянемо детальніше на прикладі документа з рис. 2, яким чином у структурі ІV.1 Відомості про продаж (SalesInvoices) відображати позиції для документів продажу у вузлах ІV.1.4.21 <Line> (рис. 5), які передбачають інформацію про AccountID та CorrespondingAccountID. Останнє поле було додане саме для українського формату звіту SAF-T.
Виходячи із принципів збереження облікової інформації, за основу для позицій (вузол ІV.1.4.21 <Line>) звіту SAF-T UA потрібно брати інформацію зі спеціальної таблиці J_3RKKRS, яка зберігає інформацію про подвійний запис. У такому випадку окремому вузлу <Line> відповідатиме запис із номером із поля «Split No» таблиці J_3RKKRS. На рис. 5 у двох останніх колонках відображено інформацію, що стосується відповідно 1-ої та 2-ої позиції розглянутого документа. Третя позиція, що стосується субрахунку 643, не повинна виводитись окремим вузлом <Line> для розділу ІV.1 Відомості про продаж (SalesInvoices) у сформованому звіті.
У зв’язку з тим, що формат звіту SAF-T для українських платників податків заточений під специфіку локальних загальнопоширених облікових систем, для систем SAP зі старою кореспонденцією рахунків не залишається вибору окрім як використовувати описаний вище підхід, що, на наш погляд, закладає потенційні ризики у зв’язку з відсутністю прозорості даних відображуваних бухгалтерських документів SAP у звіті SAF-T UA: у звіт будуть виводитись не первинно збережені дані облікових документів, а «штучно» (з погляду архітектури рішення SAP) інтерпретована інформація іншого виміру (рис. 4), що доповнена атрибутами з первинних таблиць SAP, у яких зберігаються облікові документи.
Найновіша версія SAP – S/4HANA – має ряд особливостей, які роблять її більш ефективною порівняно зі старішими версіями SAP (ERP). Однією з таких особливостей є таблиця ACDOCA, яку ще називають універсальним журналом для збереження найповнішої інформації про бухгалтерський документ.
Таблиця ACDOCA, зокрема, зберігає актуальну для управлінського обліку інформацію (наприклад, ознаки для аналізу прибутковості, бюджетні контирування). Внесені бухгалтером позиції облікового документа дробляться відповідно до ознак спліттінгу (від англ. – splitting), в межах яких дотримується баланс (сума дебетових позицій дорівнює сумі кредитових).
У зв’язку з технічними змінами, у S/4HANA також змінився підхід до визначення кореспондуючих рахунків головної книги – тепер інформація про кореспондуючі пари зберігається в основній таблиці ACDOCA, а отже кореспонденція позицій розбирається не на основі позицій звичайного вигляду документа (як це є у старій версії SAP), а на основі більш деталізованих позицій таблиці ACDOCA.
На рис. 6 відображено документ із SAP S/4HANA, що подібний до прикладу вище (рис. 2).
Після спліттінгу документ виглядатиме, як на рисунку 7. Як бачимо, позицій стало більше у зв’язку з наявністю двох місць виникнення прибутку (MPV1 та MPV2), в межах яких дотримано баланс.
У таблиці ACDOCA документ із рис. 7 виглядатиме, як на рис. 8, де у полі (колонці) «Коресп. рахунок» записаний номер кореспондуючої позиції (із dual-entry system). Результат роботи «нової» кореспонденції рахунків обумовлює використання більш зручних алгоритмів вибору повноцінної інформації для звіту SAF-T UA, навіть у випадках, коли досягнути коректної кореспонденції рахунків в рамках поточного локалізаційного рішення – неможливо (такі проблеми були вирішені нашою командою з метою забезпечення партнерів звітом, що містить коректну інформацію з точки зору вимог).
Основним недоліком нової кореспонденції рахунків у S/4HANA є той факт, що неможливо «заднім числом» інтерпретувати облікові документи у систему подвійного запису.
Для таких випадків SAP пропонує використовувати окрему програму інтерпретації, що базується на спеціальній таблиці FIRUD_CF_OFF_ACC, яка, на жаль, не містить пов’язаної із запасами інформації, як і не містить посилання на відповідні логістичні таблиці. Позаяк, ця таблиця дозволяє виводити у звіти коректну інформацію про обороти, що достатньо для звіту про рух грошових коштів, але недостатньо для будь-якого іншого аналізу з точки зору вимог українського законодавства використання системи подвійного запису та для підготовки звіту SAF-T UA відповідно до його формату.
З метою забезпечення законодавчих вимог, таблиця FIRUD_CF_OFF_ACC повинна заповнюватись інформацією про кореспонденцію з урахуванням позицій первинних документів (отже, позицій документів із таблиць RSEG, VBRP, MSEG) та має мати наступні поля: * : AWREF, AWITGRP, AWORG, AWITEM, KTOSL, MSL, RUNIT, MEINS, EBELN, EBELP, UMSKZ, UMSKS, RMVCT, ANLN1, BWASL, BWART.
* Ми розуміємо, що різні рішення для створення звіту SAF-T UA у SAP можуть використовувати різну логіку щодо того, яким чином отримувати у звіт повноцінну інформацію для кожної позиції первинного документа, базуючись на функціональності щодо розбору кореспонденції рахунків від SAP, але намагались надати необхідний та достатній перелік полів, які допоможуть будь-якому рішенню.
