Разбираем разработку на AL для Business Central: аналогия с офисным зданием

By Mirko Peters · 2026-08-27

При управлении современным бизнесом ваша система планирования ресурсов предприятия находится в самом центре повседневных операций. Такие платформы, как Dynamics 365 Business Centr…

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

Когда вы управляете современным бизнесом, система планирования ресурсов предприятия находится в самом центре ежедневных операций. Такие платформы, как Dynamics 365 Business Central, из коробки охватывают всё: от финансов и управления клиентами до запасов, заказов на продажу и счетов. Однако бизнес-процессы в реальной жизни редко укладываются в один шаблон. Что делать, если вашей компании нужен особый этап согласования, дополнительное поле данных, уникальный расчёт или бизнес-правило, которого нет в стандартном приложении? Долгое время адаптация ERP-системы означала балансирование на канате между получением нужной функциональности и риском попасть в кошмар из-за сбоев при будущих обновлениях. Сегодня благодаря современным подходам к разработке ситуация принципиально изменилась. В этой статье мы разберём концепции модели расширений Microsoft, познакомимся с базовыми строительными блоками разработки на AL и поймём, почему отделение пользовательского кода от ядра приложения — главный ключ к стабильной и устойчивой к будущим изменениям ERP-системе.

Зачем бизнесу адаптировать ERP-системы

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

Такие особые требования не обязательно означают полную переделку бизнес-процессов или отказ от ERP. Зачастую бизнесу нужно лишь, чтобы Business Central понимал один дополнительный элемент данных или применял одно конкретное внутреннее правило проверки. Исторически сложность заключалась в том, как внедрить эти изменения безопасно, не нарушив целостность системы.

Аналогия с офисным зданием для современных расширений

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

Модель расширений 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. Сотрудники продолжают работать на привычных стандартных страницах, а расширение незаметно выводит на экран специализированные данные, которые нужны вашему бизнесу.

Кодъюниты, триггеры и события

Хранение данных и пользовательский интерфейс важны, но приложениям также нужна логика для расчёта значений и обработки процессов. Кодъюниты обеспечивают специальное место для этой многократно используемой бизнес-логики. Например, если уровень лояльности клиента определяет конкретный процент скидки, код этого расчёта может храниться в централизованном кодъюните, а не дублироваться неловко на нескольких страницах и в отчётах.

Код выполняется в определённых точках жизненного цикла приложения, которые называются триггерами. Триггер срабатывает автоматически при наступлении конкретного действия — например, когда пользователь открывает страницу, изменяет значение поля или пытается отправить счёт на проводку. Аналогично, события позволяют вашим расширениям реагировать на уведомления, которые рассылает стандартное приложение. Business Central может сообщить, что документ вот-вот будет проведён, и ваше расширение мгновенно получит это событие и выполнит собственную логику пользовательской проверки в нужный момент.

Заключение: как сохранить ERP готовым к обновлениям

Настройка системы планирования ресурсов предприятия больше не должна быть рискованной задачей, которая ломает обновления. Используя современную модель расширений Microsoft и возможности разработки на AL, организации могут адаптировать Business Central под свои уникальные операционные потребности, сохраняя при этом основное приложение полностью чистым и стабильным. Представьте ERP как хорошо спроектированное здание, где дополнения надёжно подключаются к внешнему контуру, а не разрушают внутреннюю конструкцию. Такой подход помогает бизнесу оставаться гибким, эффективным и полностью готовым к каждому будущему обновлению программного обеспечения.

Чтобы глубже разобраться в теме и услышать мнение экспертов о современных практиках разработки, обязательно послушайте связанный выпуск подкаста: Dynamics 365 Business Central AL Development.