Як влаштовані розширення на AL, чому кожна доробка коштує двічі й за якими критеріями вирішувати, що робити стандартом, а що кодом.
Коротка відповідь. У Business Central доробки не змінюють саму систему. Вони живуть окремо — як розширення, написані мовою AL. Саме тому оновлення від Microsoft двічі на рік не перетворюються на проєкт.
У локальних системах попереднього покоління доробка правила конфігурацію, і кожне оновлення означало ручне злиття змін. Через кілька років компанія просто переставала оновлюватися — оновлення коштувало дорожче за користь. Розширення цю проблему знімають, але не роблять доробки безкоштовними.
Перша вартість очевидна — розробка. Друга проявляється через півроку.
| Стаття | Коли виникає | Що впливає на суму |
|---|---|---|
| Розробка | Одразу | Складність логіки, кількість зачеплених процесів |
| Тестування | Одразу | Скільки сценаріїв треба перевірити |
| Супровід оновлень | Двічі на рік | Кількість розширень і глибина втручання |
| Доопрацювання | При зміні процесів | Наскільки код прив'язаний до конкретного сценарію |
Третій рядок — той, який не закладають у бюджет. Microsoft випускає два великі релізи на рік, і кожне розширення перевіряється на сумісність. Одна невелика доробка — це кілька годин двічі на рік. П'ятнадцять доробок — це вже постійна стаття витрат, порівнянна з підтримкою.
Робоче правило: доробка виправдана, якщо процес дає конкурентну перевагу й не закривається стандартом. Усе інше — привід переглянути процес, а не писати код.
| Ситуація | Рішення | Чому |
|---|---|---|
| Процес унікальний і приносить гроші | Доробка виправдана | Це ваша перевага, підлаштовуватися під стандарт немає сенсу |
| Друкована форма під вимоги контрагента | Доробка виправдана | Дешево, ізольовано, не зачіпає логіку |
| Інтеграція з банком, сайтом, обладнанням | Зазвичай виправдана | Часто є готові рішення — спершу перевірити ринок |
| «У нас завжди так робили» | Спершу перегляньте процес | Часто звичка, а не потреба; стандарт може бути кращим |
| Зручніше розташувати поля | Не потрібна | Персоналізація сторінок робиться налаштуванням |
| Нестандартний звіт | Часто не потрібна | Перевірте фінансові звіти, розмірності й Power BI |
Ознака здорового проєкту: 80–90 % процесів закриваються стандартом. Якщо доробок більше — питання не до системи, а до того, чи правильно вона обрана під ваші задачі.
Не для того, щоб писати код, а щоб ставити правильні питання підряднику.
Головне питання підряднику звучить так: чи залишиться у нас вихідний код розширень. Відповідь «ні» означає, що змінити підрядника ви не зможете без переписування доробок з нуля.
Ні. Розширення на AL живуть окремо від базової системи й не блокують оновлення. Але після кожного великого релізу їх перевіряють на сумісність — це закладається в підтримку.
Залежить від складності логіки й кількості зачеплених процесів. У структурі бюджету впровадження кастомна розробка займає від 0 до 25 %: нуль, якщо все закривається стандартом, чверть — якщо процеси справді нетипові.
Це питання договору, і його варто ставити до підписання. Правильна відповідь — замовник отримує вихідний код розширень, розроблених у межах проєкту. Інакше змінити підрядника без переписування з нуля неможливо.
У багатьох компаніях так, особливо в торгівлі та послугах зі стандартними процесами. Персоналізація сторінок, розмірності й фінансові звіти закривають більшість запитів без коду.
Орієнтир простий: якщо стандартом закривається менше 80 % процесів, це сигнал перевірити, чи правильно обрана система або чи не намагаєтесь ви відтворити в ній логіку старої.
Для більшості компаній ні. Розширення розробляє й супроводжує партнер, а всередині достатньо людини, яка розуміє процеси й може сформулювати задачу.
Ця стаття пояснює логіку й типові помилки. Розробку розширень: об'єкти, таблиці, сторінки й публікацію в середовищі — розбираємо на курсі «Базове програмування мовою AL». Заняття онлайн у режимі реального часу, з розбором ваших робочих ситуацій.
Залиште контакти — і ми надішлемо деталі безкоштовного аудиту процесів. Відповідаємо протягом одного робочого дня.
або напишіть напряму: nbcs365@zohomail.eu · +380 98 107 5878