Розбираємо розробку AL для Business Central: аналогія з офісною будівлею

By Mirko Peters · 2026-08-27

Коли ви керуєте сучасним бізнесом, система планування ресурсів підприємства є в самому центрі щоденних операцій. Платформи на кшталт Dynamics 365 Business Central «з коробки» охоплюють усе: від фінансів і управління клієнтами до запасів, замовлень на продаж і рахунків.

Automatically translated with AI from the original post. Read the English original

Коли ви керуєте сучасним бізнесом, система планування ресурсів підприємства є в самому центрі щоденних операцій. Платформи на кшталт Dynamics 365 Business Central «з коробки» охоплюють усе: від фінансів і управління клієнтами до запасів, замовлень на продаж і рахунків. Утім, реальні бізнес-процеси рідко вкладаються в один шаблон. Що робити, якщо вашій компанії потрібен спеціальний крок погодження, додаткове поле даних, унікальний розрахунок або бізнес-правило, якого немає в стандартному застосунку? Довгий час налаштування ERP-системи означало балансування на небезпечному канаті між потрібним функціоналом і ризиком опинитися в пастці проблем під час майбутніх оновлень. Сьогодні завдяки сучасним підходам до розробки ситуація принципово змінилася. У цій публікації ми розберемо концепції сучасної моделі розширень Microsoft's, розглянемо базові будівельні блоки розробки на AL і з'ясуємо, чому відокремлення власного коду від ядра застосунку є ключем до стабільної ERP, готової до майбутнього.

Навіщо бізнесу налаштовувати ERP-системи

Перш ніж розбиратися, як працює розробка, варто зрозуміти, навіщо взагалі потрібні налаштування. Business Central охоплює величезну низку стандартних бізнес-процесів, які добре підходять багатьом традиційним компаніям. Проте жодні дві організації не працюють абсолютно однаково. Наприклад, спеціалізованому дистриб'ютору продуктів харчування можуть знадобитися суворий облік партій і показники терміну придатності, що виходять за межі базового складського обліку. Регіональній сервісній компанії може бути потрібен додатковий внутрішній етап погодження, перш ніж рахунок можна буде завершити. Спеціалізованому роздрібному продавцеві можуть знадобитися детальні рівні клієнтських бонусів і відстеження лояльності.

Такі унікальні вимоги не обов'язково означають, що треба повністю переписувати бізнес-процеси або відмовлятися від ERP. Часто бізнесу просто потрібно, щоб Business Central розумів ще один фрагмент даних або дотримувався одного конкретного внутрішнього правила перевірки. Історично складним завданням було те, як упроваджувати такі зміни безпечно й не пошкодити цілісність системи.

Аналогія з офісною будівлею для сучасних розширень

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

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

Розуміння AL і моделі розширень

AL — це скорочення від Application Language. Це спеціалізована мова програмування, створена Microsoft для розробки власної функціональності саме для Dynamics 365 Business Central. За допомогою AL розробники можуть додавати, змінювати й удосконалювати бізнес-процеси, розрахунки, перевірки, записи та сторінки.

Найважливіше, що треба усвідомити, — це не лише синтаксис самої мови AL, а архітектурна парадигма моделі розширень. У старих версіях продукту, часто пов'язаних із застарілим середовищем розробки C/AL у Dynamics NAV, розробники нерідко змінювали безпосередньо вихідні об'єкти застосунку. Це давало глибоку кастомізацію, але створювало жорсткий зв'язок між основною системою та вашим власним кодом. Щоразу, коли Microsoft випускала оновлення, розробникам доводилося вручну порівнювати вихідний код із внесеними змінами й узгоджувати їх. Сучасна модель розширень AL позбавляє від цієї головного болю: ваші зміни пакуються як незалежні розширення, які працюють поруч зі стандартним кодом застосунку, а не перезаписують його.

Спершу стандартна функціональність, потім кастомізація

Те, що ви можете кастомізувати Business Central, ще не означає, що це завжди варто робити. Зміна системи лише через те, що типовий робочий процес трохи відрізняється від звичного в старому програмному забезпеченні, може без потреби збільшити витрати на супровід у довгостроковій перспективі. Найкращі практики адміністрування ERP завжди виходять із принципу «спершу стандартна функціональність, потім кастомізація».

Перш ніж написати хоч один рядок коду AL, команди розробників і керівники бізнесу мають поставити собі три базові запитання: з якою саме проблемою стикаються наші співробітники? Що має відбуватися натомість? Чи може стандартний Business Central вирішити це, якщо ми скоригуємо бізнес-процес? Розробку на AL варто залишати для сценаріїв, у яких стандартний продукт справді не відповідає критично важливій бізнес-вимозі.

Ключові будівельні блоки AL

Створюючи розширення, розробники працюють із конкретними програмними компонентами, які називаються об'єктами. Об'єкт — це окрема частина застосунку, призначена для виконання певного завдання. Розглянемо основні будівельні блоки, з яких складається рішення на AL.

Таблиці, поля та сторінки

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

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

Розширення таблиць і розширення сторінок

Що робити, коли в стандартному Business Central є майже все необхідне, але потрібна ще одна точка даних, наприклад власний рівень винагород лояльності для клієнтів? Замість створення нової таблиці клієнтів, яка дублювала б наявні основні дані, розробник створює розширення таблиці. Стандартна таблиця клієнтів залишається недоторканою, а розширення просто додає поряд із нею нове поле.

Звісно, додавання поля до таблиці саме собою не робить його видимим для персоналу. Для цього розробники використовують розширення сторінок. Розширення сторінки вбудовує нове поле разом із необхідними групами, діями чи кнопками безпосередньо в стандартні екрани інтерфейсу Business Central. Співробітники й надалі працюють на звичних стандартних сторінках, а розширення бездоганно виводить на них спеціалізовані дані, потрібні вашому бізнесу.

Кодові модулі, тригери та події

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

Код виконується в певних точках життєвого циклу застосунку, які називаються тригерами. Тригер спрацьовує автоматично, коли відбувається конкретна дія: наприклад, коли користувач відкриває сторінку, змінює значення поля або намагається провести рахунок. Подібно до цього події дають змогу вашим розширенням «прослуховувати» сповіщення, які розсилає стандартний застосунок. Business Central може повідомити, що документ незабаром буде проведено, а ваше розширення миттєво отримує цю подію і виконує власну логіку перевірки саме в потрібний момент.

Висновок: як зберегти ваш ERP готовим до оновлень

Налаштування системи планування ресурсів підприємства більше не має бути ризикованою справою, яка ламає оновлення. Завдяки сучасній моделі розширень Microsoft і можливостям розробки на AL організації можуть адаптувати Business Central саме під свої операційні потреби, зберігаючи основний застосунок повністю чистим і стабільним. Уявіть свій ERP як добре спроєктовану офісну будівлю, де власні доповнення безпечно під'єднуються до зовнішніх конструкцій, а не руйнують внутрішній каркас. Такий підхід забезпечує гнучкість, ефективність вашого бізнесу та готовність до кожного майбутнього оновлення програмного забезпечення.

Щоб глибше зануритися в цю тему і почути думки експертів щодо сучасних практик розробки, обов'язково послухайте відповідний епізод подкасту: Dynamics 365 Business Central AL Development.