телефонуйте

38(050) 966-66-66

Пишіть нам

[email protected]

Еволюція контролінгу в SAP S/4HANA

03.04.2024

ALLOY

S/4HANA

304

Еволюція контролінгу в SAP S/4HANA

Контролінг, як явище, є абсолютно аутентичним в SAP. Терміни, які запровадив SAP в контролінгу, такі як МВВ (місце виникнення витрат), МВП (місце виникнення прибутку), контирування, цикли розподілу та розкладки витрат, колектор витрат на продукт, стали вже канонічними та використовуються в професійному словнику фінансистів. Якщо треба стисло назвати в чому унікальність системи SAP, сміливо можна сказати що це наявність окремого функціоналу для управлінського обліку – контролінгу, абсолютно інтегрованого з іншим функціоналом системи .

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

Еволюція контролінгу в SAP S/4HANA виявляється у тому, що функціональні та архітектурні об’єкти системи стали легко зрозумілими на основі спрощення процесів, збільшення прозорості та можливостей аналізу. 

Для прикладу, проект впровадження SAP S/4HANA в компанії на першому кроці включає витрати на впровадження шляхом підтвердження використаного часу. Оскільки проект є комерційним, дохід визнається таким чином,  щоб отримати відповідний реалізований дохід. Результати визнання доходу мають бути доступні в головній книзі, що дозволить показати маржу за проектом і пов’язаним з цим сегментом ринку (сегмент ринку це клієнт і продукт, який є реалізацією SAP S/4HANA).

Підхід в SAP ERP:

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

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

З цими налаштуванням ви зіткнетеся з такими проблемами:

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

Підхід в SAP S/4HANA:

З впровадженням SAP S/4HANA ви отримуєте інтеграцію головної книги, контролінгу і аналіз маржинальності в одній таблиці даних, і це є першим спрощенням. Аналіз результатів все ще є окремою програмою та окремими таблицями у БД, які не містяться в універсальному журналі. Таким чином, для аналізу результу все ще необхідно оновлення інших таблиць контролінгу.

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

Розрахунок відображається в універсальному журналі на кроці 3. На цьому кроці виконується розрахунок із документом 2 до головної книги для оновлення балансу та звіту про прибутки та збитки. Також проводиться документ 3, який кредитує проект і дебетує сегмент прибутковості. Перші два рядки розраховують реалізований дохід; наступні дві позиції покривають витрати.

Аналіз маржинальності тепер виконується в універсальному журналі. Коли ви виконуєте звіт по проекту впровадження SAP S/4HANA, ви побачите два рядки:

  1. Дохід від впровадження SAP S/4HANA (260 тугриків)
  2. Розрахунок вартості послуг за впровадження SAP S/4HANA (200 тугриків)

Виконавши агрегацію цих даних, ви отримуєте маржу у 60 тугриків.

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

Це суттєве спрощення. Визнання доходу на основі подій ініціюється проводкою витрат. Це негайно відображає реалізований дохід та незавершене виробництво. Нормативна звітність головної книги моментально стає актуальною з записом витрат.

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

Це призводить до наступних переваг:

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

Цікаво зазначити, що можна переглянути незавершене виробництво (НзВ) і резервні відрахування, привласнені ознакам CO-PA (аналіз результатів). НзВ раніше відображалося тільки для балансових одиниць і місць виникнення прибутку, а тепер можна переглянути коригування виручки та нараховану виручку, прив’язані до всіх ознак CO-PA. Для керівників проектів це величезна перевага, якщо в проекті є незавершене виробництво.

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

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

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

  • Реальне контирування. У кожному рядку може бути лише одне. Воно визначається полем “Тип контирування”. Наприклад, KS – означає центр витрат, OR – означає замовлення, PR – означає проект і так далі. Подальші процеси, такі як доплати, визнання доходу та розрахунок, можуть виконуватися лише по реальному об’єкту контирування.
  • Атрибути контирувань, доступні лише для звітності. На них не виконуються подальші операції. На одній позиції журналу може бути кілька присвоєних об’єктів контролю.

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

  • Сценарій замовлення послуги (Service order scenario). Позиції замовлення на обслуговування є реальними об’єктами контирування та об’єктами контролю в SAP S/4HANA. Ви призначаєте сегмент прибутковості на основі інформації, наданої в замовленні на послугу, як то клієнт і проданий продукт.
  • Внутрішньофірмовий сценарій (Intercompany scenario). Ви кредитуєте центри витрат у компанії-постачальнику, що є реальними об’єктами контируванням, і присвоюєте проект від компанії-одержувача.

Висновок

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

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

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

Коментарі (0)
Додати коментар
Схожі публікації