Смаколики SAP S/4HANA. Універсальний журнал, частина 2

Як ми вже визначили, універсальний журнал (Universal Journal) це місце яке має всю необхідну фінансову інформацію про всі бізнес-операції, зареєстровані у вашій компанії і на поточний час – це місце, яке стає єдиним джерелом правди для фінансової звітності, даних планування та даних групової звітності вашої компанії.

Єдине джерело істини

Дані фінансової звітності

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

Дані планування

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

Підхід до об’єднання позицій в один документ у SAP S/4HANA також було використано для позицій планування. Основною причиною для розгляду використання нової таблиці планування, а не застарілих таблиць планування, є узгодженість універсального журналу. Ідея полягає в тому, що будь-які ринкові сегменти, які організація додає до своїх операційних завдань для звітування про прибутковість, існують як для фактичних, так і для запланованих даних. Тому будь-які галузеві розширення, які активують/додають, додаткові поля у універсальний журнал, вони додаються до обох таблиць. Звичайно, існують також відмінності, що відображають різні способи збору даних для планування, незалежно від того, здійснюється це «знизу вгору» за допомогою функцій автоматичного калькулювання для окремого виробництва чи замовлення на технічне обслуговування або “зверху вниз” із SAP Analytics Cloud або SAP Business Planning and Consolidation (SAP BPC).

Архітектура системи

Найпростіший спосіб уявити архітектуру системи в SAP S/4HANA — це два кола, показані на малюнку нижче:

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

У той час як багато організацій здійснюють контролінг підприємства та певний облік центрів витрат у базовому ERP, складність місцевих правових вимог часто змушує їх переносити корпоративний контроль до окремого сховища даних. Ця спроба поєднати два набори вимог в одній архітектурі звітності є фундаментальною зміною в SAP S/4HANA.

Задоволення різних вимог за допомогою одного документа

Давайте почнемо з того, що розглянемо, як аспекти, зображені на малюнку вище, пов’язані з різними параметрами звітності. Загальним виміром у кожному документі є обліковий запис/елемент витрат — ключ до відповідності та керування. Вимоги відповідності зазвичай зосереджені на коді компанії, тоді як більш детальна інформація знаходиться в центрах витрат, замовленнях, проектах і сегментах ринку та використовується для цілей керування. Центри прибутку, зазвичай, також використовуються для відповідності та керування, одержуючи своє початкове призначення від контролінгових об’єктів для статей прибутків і збитків, і потім призначаються балансовим рахункам.

Універсальний журнал дозволяє нам фіксувати параметри звітності для внутрішньої та зовнішньої звітності в одному документі. Якщо ви звикли працювати з окремими програмами для кожної цілі, спочатку це може здатися обмеженням. Можуть бути справжні причини для створення двох документів для представлення різних бізнес-цілей. Наприклад, вам може знадобитися представити ту саму господарську операцію відповідно до МСФЗ (або корпоративних принципів бухгалтерського обліку) і місцевих принципів бухгалтерського обліку. Для реалізації цієї ідеї введено принципи ведення бухгалтерських книг, які дозволяють вам зафіксувати два різні документи, які представляють, наприклад, придбання активів відповідно до різних стандартів бухгалтерського обліку.

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

Справедливості заради, необхідно сказати, що існує два підходи для ведення паралельних обліків – звичний підхід по рахункам та підхід по різним регістрам. Метод рахунків: різні підходи до оцінки відображаються на різних рахунках. Для кожного з обліків створюється своя версія фінансової звітності. Наприклад, у фінансовій звітності згідно з П(с)БО України враховуються лише ті рахунки, які дотримуються цього принципу бухгалтерського обліку. Метод бухгалтерських книг (регістрів) в S/4HANA дозволяє в рамках бухгалтерського обліку Головної книги одночасно керувати кількома «головними книгами» і, таким чином, створювати різні фінансові звіти.

На наш погляд, ведення паралельних регістрів є більш прогресивним підходом. Як мінімум, завдяки можливості мати компактний план рахунків. Та й кількість розбіжностей в обліках набагато менше ніж подібності.

Розширення універсального журналу

Хоча легко уявити універсальний журнал як спосіб згортання різноманітних фінансових програм із SAP ERP в одну структуру, важливо також розуміти, що у вас є нові варіанти розширення цієї структури відповідно до ваших конкретних вимог — можливо, для додавання стратегічного бізнес-одиниці або операційного підрозділу до цієї структури. У цьому контексті ви також повинні знати, що галузеві поля для бухгалтерського обліку в державному секторі та бухгалтерського обліку спільного підприємства також вважаються розширеннями. Універсальний журнал містить структури для бухгалтерського обліку в державному секторі (ACDOC_SI_PS) і бухгалтерського обліку для спільних підприємств (ACDOC_SI_JVA), які містять усі поля, необхідні для цих галузей. Вони автоматично оновлюються з кожним записом у журналі, але щоб побачити вміст цих полів у звітах, вам потрібно активувати відповідне розширення для галузі у моделі даних при налаштуванні системи.

Бухгалтерські книги та їх використання

Усі фінансові операції відносяться до бухгалтерської книги. Книга 0L надається за замовчуванням, тому, якщо ви нічого не зробите, усі ваші фінансові операції буде відображено у книги 0L.

Примітка Alloy: Книги які починаються з цифр поставляюся компанією SAP. Ви не можете створити ,бухгалтерську книгу яка починається з цифри, тому що це область імен SAP. А тому ми не рекомендуємо видаляти книги, які поставляються системою без  вагомих підстав.

Книга визначає багато основних елементів вашого підходу до бухгалтерського обліку, включаючи дозволені валюти та принципи обліку. Книга 0L може використовуватись в усіх юридичних особах і завжди підтримує місцеву та світові валюти. Наступний рівень конфігурації бухгалтерської книги визначає принцип бухгалтерського обліку, тож ви можете вказати, що один з підходів відповідає US-GAAP, а інший наприклад IFRS.

Окрім підтримки багатьох локальних принципів бухгалтерського обліку, багато організацій, які переходять на SAP S/4HANA, також вирішують використовувати другу книгу для підтримки загального принципу бухгалтерського обліку, який застосовується до всіх призначених кодів компанії (наприклад, МСФЗ, якщо їх штаб-квартира знаходиться в Європі або US-GAAP, якщо їх штаб-квартира знаходиться в Сполучених Штатах). Головний офіс також визначає валюту групи, причому в кожній із дочірніх компаній використовуються різні місцеві валюти.

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

Примітка Alloy: З нашого досвіду ми рекомендуємо використовувати також окрему книгу для податкового обліку.

Це все приклади використання паралельних книг.

Загальний підхід: Завжди існує один головний регістр – 0L. Додаткових регістрів може бути декілька – в залежності від вимог. Існує можливість також створювати розширені регістри – вони призначаються стандартному регістру та успадковують всі журнальні записи стандартного регістру для звітності. Проводки, зроблені явно в розширеному регістрі, відображаються в ньому, але не в основному стандартному регістрі. Розширений регістр зберігає дельта-значення та вказує на інший регістр.

У SAP ERP спеціальні бухгалтерські регістри також були налаштовані як паралельні бухгалтерські книги для обов’язкової звітності (наприклад, спецрегістр для податкового обліку) або для управлінського обліку, податків або інших аспектів. 

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

Підхід SAP ERP призвів до високої надмірності даних, оскільки спеціальна книга зазвичай містить 95% тих самих даних, що й головна книга, лише з 5% коригувань. Навпаки, налаштування SAP S/4HANA призводить до відсутності надлишкових даних і чіткого відокремлення даних.

Компанії також створювали спеціальні бухгалтерські книги в SAP R/3 і SAP ERP, щоб включати до них додаткові поля, але це більше не потрібно, оскільки додаткові поля можна легко додати безпосередньо в універсальний журнал.

Додаткові валюти та їх вплив

Універсальний журнал дозволяє працювати з більшою кількістю валют, ніж у SAP ERP, де компонент фінансового обліку підтримував три валюти, а компонент контролінгу підтримував дві валюти.

З точки зору валюти, валюта групи (тип валюти 30) є еквівалентом валюти контролінгової одиниці, і кожен код компанії має власну місцеву валюту (тип валюти 10). Повертаючись до вимог відповідності, у деяких країнах також існує потреба в додатковій валюті, наприклад у твердій валюті (тип валюти 40) або валюті на основі індексу (тип валюти 50), щоб відповідати місцевим законам та вимогам до звітності. Також часто юридичним особам, які активно торгують із сусідньою державою, потрібно вести облікові записи як у місцевій валюті (наприклад, швейцарські франки чи мексиканські песо), так і у функціональній валюті (наприклад, євро для Швейцарії або долари США для Мексики).

Новим у SAP S/4HANA є те, що ви можете додати власний тип валюти на додаток до тих, які надаються в SAP ERP. Програми головної книги вже підтримують десять валют, якщо всі валютні поля заповнено в універсальному журналі, а інші програми поступово додають можливість обробки кількох валютних полів.

Примітка Alloy: На поточний момент (2023 рік), на жаль, модуль управління запасами все ще обмежений трьома валютами, а тому рахунки запасів не підтримують фінансові розширення з десятками валют.

Підсумуємо красоти універсального журналу:

• “Взяти найкраще з усіх світів”
• Одна позиція таблиці з повною інформацією
• Дані зберігаються один раз: узгодження не потрібні
• Зменшення обсягу пам’яті за рахунок усунення надмірності
• Швидка багатовимірна звітність
• Якщо ж все ж таки BW використовується, то потрібен лише один екстрактор
• Вторинні витрати “прийняті в сім’ю” – вони теж стали рахунками єдиного плану рахунків
• Паралельні книги
• Розширюваність користувацькими полями
• Розширені регістри
• До 999 999 рядків в документі універсального журналу. Але загальний документ у форматі вводу, на жаль, має поки, на 2023 рік, старі обмеження у 999 позицій.
• Розширене управління валютами (доступна кількість валют, можливість вести власні валюти)
• “Лагідне” закриття – в першу чергу завдяки усуненню необхідності узгодження (відсутня проводка запасів в обліку необоротних активів, не потрібна звірка FI-CO) та не потрібні окремі процедури по роботі з додатковими книгами (FI-SL)
• Удосконалення консолідації в режимі реального часу.