Для керівництва це означало відсутність єдиної управлінської картини по групі: щоб отримати P&L або звірити показники між локаціями, потрібні були ручні вивантаження з кількох систем і зведення в таблицях. Зі зростанням мережі й розширенням географії цей підхід ставав дедалі менш керованим.
Управлінський облік • P&L звітність • Консигнація
Впровадження центральної бази управлінського обліку з агрегуванням даних з різних локацій
Для компанії з власним виробництвом і продажами через B2B/B2C канали в кількох країнах команда CBPM Service спроєктувала центральну базу Business Central MAIN для управлінського обліку групи. Її задача — агрегувати дані з локальних операційних баз і зовнішніх систем, підтримувати транскордонні сценарії, зокрема консигнацію, та забезпечувати звітність P&L у межах усієї мережі.
📑 MAIN-база
Спроєктовано архітектуру MAIN-бази як єдиного центру управлінського обліку групи
📉 API-обмін
Побудовано API-обміни з локальними базами, BAF/1C, Magento та іншими джерелами
🕐 Реалізовано
консигнаційні сценарії
між Іспанією та Нідерландами з автоматичним формуванням документів
Ситуація до проєкту: дані в кількох системах, консолідації немає
Дані про продажі, витрати та взаєморозрахунки були розподілені між кількома несумісними системами. Сформувати достовірний P&L по мережі в режимі реального часу без ручного зведення було неможливо.
Консигнаційні операції між країнами, обміни між локальними базами та зовнішніми системами не мали єдиного контуру контролю. Будь-яка розбіжність між даними виявлялась лише під час ручної звірки та з затримкою.
Інфраструктура групи охоплювала локальні бази Іспанії, України, Нідерландів і Польщі, BAF/1C Manufacturing, Magento, SAGE та регуляторні контури. Зібрати актуальну управлінську картину з такої кількості джерел без системного рішення було структурно неможливо.
Запит та критичні вимоги
Запит клієнта передбачав побудову центрального управлінського контуру, який агрегує дані з операційних систем групи та формує єдину аналітичну картину. MAIN-база мала залишатись відокремленою від локальних фіскальних контурів і не дублювати їх, лише отримувати дані та перетворювати їх у управлінську звітність.
1. Централізована MAIN-база управлінського обліку
Ключовою вимогою було впровадити MAIN-базу як єдине середовище управлінського обліку для консолідації даних із локальних баз і зовнішніх систем без дублювання фіскальних контурів.
2. API-обмін з усіма джерелами даних
Система мала забезпечити стабільне API-отримання ключових сутностей: Items, Locations, Customers, Orders та Dimensions з локальних баз і зовнішніх систем без втрати цілісності даних.
3. Консигнаційні сценарії та P&L-звітність
MAIN-база мала підтримувати консигнаційні операції між країнами та формувати звітність P&L, як інструмент контролю фінансових показників по всій мережі.
4. Логування та контроль якості обмінів
Критичною вимогою було мінімізувати ризики некоректного зіставлення товарів, серійних номерів і клієнтів між базами. Кожен обмін мав логуватися зі статусом і можливістю відстеження розбіжностей.
5. Інтеграція з чинною екосистемою
MAIN-база мала підключитися до локальних BC-баз, BAF/1C Manufacturing, Magento та SAGE без порушення їхньої операційної роботи. Окремий фокус приділявся коректному зіставленню довідників між усіма базами.
6. Розділення управлінського та регуляторного обліку
MAIN-база не мала замінювати локальні фіскальні контури. Для сценаріїв між Іспанією та Нідерландами необхідно було зберегти коректне відображення ПДВ, зворотного нарахування, звітності ESL та Intrastat у відповідних локальних базах.
Що і як команда CPBM зробила
Підхід
Підхід будувався на чіткому розподілі: локальні бази залишаються операційними та фіскальними контурами кожної країни, а MAIN-база виконує роль управлінського центру, який отримує з них дані через API і перетворює їх у єдину аналітичну картину. Це дозволило не порушувати локальний регуляторний облік і водночас забезпечити консолідацію по всій групі без ручних зведень.
Архітектура MAIN-бази
Рішення побудоване на окремій базі Business Central MAIN для управлінського обліку групи. Дані надходять через API з локальних баз і зовнішніх систем: Items, Locations, Customers, Orders, Dimensions. Передбачено реєстри відправлених документів, Exchange Log List і мапінг довідників між базами — це забезпечує контроль над станом кожного обміну і дозволяє виявляти розбіжності до того, як вони впливають на звітність.
Консигнаційні сценарії в управлінському контурі
Консигнаційні операції між країнами ЄС потребували окремої логіки на рівні MAIN-бази. Товар фізично переміщується до приймаючої країни, але право власності переходить лише в момент продажу кінцевому покупцеві — це потребує різних документів у локальних базах і в MAIN-базі.
Реалізовано сценарій, за якого MAIN-база отримує інформацію про Posted Statement і автоматично трансформує її в облікований рахунок продажу зі складу консигнації приймаючої країни, зі звіркою між базами.
Стандартний функціонал і кастомізація
Стандартний функціонал BC
Використовується як основа для управлінських сутностей і документів.
Кастомізація зосереджена там, де стандарт не покриває потреб
Специфічні API-обміни між базами, консигнаційна логіка, нові таблиці для мапінгу довідників, журнали логування обмінів і поля серійних номерів та ваги у відповідних документах.
Розділення контурів як архітектурний принцип
Відокремлення MAIN-бази від локальних фіскальних баз — не технічне рішення, а архітектурний принцип. Локальні бази зберігають повну операційну та регуляторну незалежність, зокрема щодо ПДВ, ESL та Intrastat. MAIN-база отримує з них лише управлінські дані, без втручання у фіскальний облік локацій.
Реалізація та робота з командою замовника
Робота будувалася поетапно: спочатку проєктувалася архітектура MAIN і локальних баз та визначалися інтеграційні контури; потім мапінг довідників, API-обміни, консигнаційні сценарії та звітність P&L; на завершення тестування звірок між базами.
Однією з ключових умов успішного виконання проєкту в чотиримісячний термін стало те, що замовник призначив відповідального керівника проєкту з повноваженнями приймати рішення, а перша особа долучилася як спонсор проєкту до щомісячних координаційних нарад. Це дало змогу підтримувати оперативну комунікацію, своєчасно узгоджувати питання й контролювати виконання завдань без затримок і потреби в ескалації.
Підґрунтя для управлінської прозорості
Команда CBPM Service збудувала архітектуру, яка вирішує вихідні проблеми консолідації та водночас закладає основу для масштабування: нові локації та джерела даних можна підключати без перебудови центрального контуру.
З'явилося єдине середовище, куди стікаються управлінські дані з усіх операційних джерел, без ручного зведення в таблицях.
Консигнаційні операції між країнами відображаються в управлінському обліку автоматично, з коректним розподілом документів між локальними базами і MAIN-базою.
Кожен обмін між базами фіксується зі статусом, а розбіжності виявляються системно, а не під час чергової ручної звірки.
Сформовано основу для P&L-звітності та міжбазових звірок у межах усієї мережі.
Сформовано інфраструктурну основу для P&L-звітності та міжбазових звірок по всій мережі.
