Презентації вендорів показують ідеальну картину, у якій усе працює з коробки. Реальні проєкти виглядають інакше: там завжди є місцева фіскалізація, галузева специфіка й процеси, які не вкладаються в типову модель.
Нижче — п’ять задач із проєктів CBPM Service. Кожна показує, де закінчується стандартний функціонал і починається робота архітектора.
Ювелірний бренд: продажі, розкидані між чотирма системами
Компанія виробляє й продає ювелірні вироби через B2B- і B2C-канали в кількох країнах. До проєкту закупівлі й виробництво велися в BAF, роздріб — у Magento і Magestore, а фінансовий облік із ПДВ-звітністю жив в Excel. Жодна система не була пов’язана з іншою: будь-яка операція між ними означала ручне перенесення й звірку.
Окрема складність — галузева. Кожен виріб має серійний номер, пробу, розмір, тип і вагу вставок, чисту вагу золота та гарантію. Типова ERP-система такої деталізації не передбачає, тому команда розробила розширення: додаткові поля товару, окрему таблицю серійних номерів, поля ваги в документах продажу й поверненнях.
Результат першого етапу, запущеного за чотири місяці:
- підготовка документів поповнення магазинів — з двох днів до 40 хвилин
- трудомісткість формування інвойсів — мінус 30%
- час проведення інвентаризації — мінус 25%
Показово, що ключовою умовою такого темпу стало управлінське рішення: замовник призначив керівника проєкту з реальними повноваженнями, а перша особа долучилася як спонсор до щомісячних нарад.
Роздріб у чотирьох країнах: LS Central і фіскалізація
Наступний етап того ж клієнта — побудова роздрібного контуру для магазинів в Іспанії, Україні, Нідерландах і Польщі. Кожна локація має власні фіскальні вимоги, але мережа мала працювати за єдиними стандартами.
Архітектура така: окремі локальні бази BC для кожної країни як самостійні фіскальні контури, LS Central POS розгорнуто всередині них, а дані передаються через API у центральну MAIN-базу. LS Central обрано не випадково — це розширення всередині Business Central, а не окрема POS-система, тож зникає цілий шар інтеграцій, де зазвичай губляться дані.
Найцікавіша частина — українська фіскалізація. Стандартний LS Central не вміє працювати з Checkbox (ПРРО), тому кастомне рішення розробляли з нуля: авторизація каси, відкриття й закриття зміни, фіскальні чеки, X- та Z-звіти. Кожна подія логується з контрольним станом, тож збій у фіскальному ланцюжку видно одразу, а не наприкінці зміни.
Сьогодні на платформі працюють сім бутіків, а нові локації підключаються без перебудови архітектури.
Українська локалізація всередині міжнародного проєкту
Питання, яке чують від кожного клієнта: чи можна вести звичний український облік у міжнародній системі. У межах того ж впровадження команда розгорнула окрему базу BC для України з регламентованим обліком — закупівлі, прихід товарів, основні засоби, амортизація, кадри та зарплата.
Налаштовано клієнт-банк із вивантаженням зарплатних відомостей, а обмін документами між базами двох країн працює через intercompany-механізм автоматично. Українська бухгалтерія при цьому залишається в звичній логіці, а група отримує дані в єдиному форматі.
Група компаній: одна база для управлінського обліку
Коли бізнес працює в кількох країнах, кожна локальна база веде свій регламентований облік — і зібрати картину групи можна лише вручну. Рішенням стала центральна MAIN-база: вона агрегує дані з локальних баз і зовнішніх систем, підтримує міжкраїнні сценарії та формує звітність P&L.
Окремо реалізовано консигнацію між Іспанією та Нідерландами. У стандартній ERP-логіці консигнація — це рух між складами однієї системи, тут же вона охоплює дві бази в різних юрисдикціях із різним фіскальним відображенням і вимогами Intrastat та ESL. Система синхронізує стан консигнаційного складу й сама формує документи в момент продажу.
Дистриб’ютор ПЗ: коли центром обліку стає угода
IITD продає програмне забезпечення за партнерською моделлю: закупівля у вендора, розгортання у кінцевого споживача, тестування й оплата проходять через партнера, а частина процесу живе в CRM. Класична структура «замовлення — відвантаження — оплата» таку схему не описує.
Команда перебудувала логіку так, щоб центром обліку стала потенційна угода — навколо неї збираються продажі, закупівлі, маршрут товару й терміни дії ліцензій, контроль яких налаштовано аж до друкованих форм. Паралельно в управлінській базі з’явилася підсистема зарплати з мультивалютним нарахуванням і виплатою в іншій валюті, а кадровий облік зібрано в трудовій угоді. Обмін витрат і доходів між локальними базами та управлінською тепер зіставляє рахунки й аналітики автоматично.
Що спільного у цих проєктах
Різні галузі, різні країни, різні задачі — але схема повторюється.
- Стандарт покриває більшість, кастом закриває решту. Доопрацювання з’являються там, де типовий функціонал справді не працює: фіскалізація, галузеві атрибути, міжкраїнна консигнація
- Етапність замість «великого вибуху». Перший етап дає робочий результат за місяці, а не за роки
- Логування замість довіри. Кожен обмін між системами має статус і причину відхилення — інтеграція залишається керованою
- Повноважений керівник з боку замовника. Пункт, який щоразу впливає на строки більше за технічні рішення
Як побудований шлях до такого результату
Усі описані проєкти реалізовані за методологією CBPM Service: передпроєктне дослідження з Fit-Gap-аналізом, оцінка з відхиленням до 10%, спринти з проміжним результатом кожні два тижні та супровід консультантів під час першого закриття звітного періоду.
За 25 років у ERP-автоматизації команда завершила понад 200 проєктів у 12 галузях і має гібридну експертизу в Business Central, 1С, BAS та Odoo. Повні версії кейсів із деталями архітектури й технічних рішень доступні в розділі портфоліо.
Якщо у вашій компанії схожа задача, почніть із безкоштовної експрес-оцінки: дві-три зустрічі й перелік необхідних робіт на виході.
Часті запитання
Чи підходить Business Central для компаній з підрозділами в кількох країнах?
Так. Робоча архітектура — окремі локальні бази під фіскальні вимоги кожної країни плюс центральна база для управлінського обліку групи.
Чи можна фіскалізувати касові операції в Україні через Microsoft Dynamics?
Так, через інтеграцію з ПРРО. У типовому функціоналі такого механізму немає, тому інтеграцію реалізують окремим рішенням.
Скільки триває перший етап впровадження?
Залежить від обсягу. У наведеному кейсі підсистему продажів запустили за чотири місяці завдяки чітко зафіксованим межам проєкту.
