Рано или поздно крупный бизнес, использующий отечественное ПО для управления ресурсами предприятия, сталкивается с классической проблемой: конфигурация 1С:ERP за несколько лет активной эксплуатации оказывается настолько сильно переписана под нужды пользователей, что её обновление превращается в бесконечный технологический кошмар. Ситуация усугубляется, когда база отстает от релизов вендора на год или два, а обновления устанавливаются точечно — «кусками» — по запросу бухгалтерии или смежных отделов.
В этой статье мы подробно проанализируем, почему ручной перенос кода из новых релизов неизбежно приводит к потере стабильности системы, и разберем по шагам проверенные методологические и технологические подходы, которые позволяют вернуть систему к обновляемому виду, снизить затраты на поддержку и сохранить лояльность бизнес-пользователей.
Когда программисты переносят отдельные механизмы из свежих релизов 1С:ERP в старую базу, они совершают опасную ошибку. Современная ERP-система — это монолитный организм с высокой степенью связности метаданных. Перенося одну форму или модуль, вы сталкиваетесь с эффектом домино: этот модуль требует новые общие модули, те в свою очередь задействуют измененную структуру регистров сведений или новые реквизиты справочников. В итоге вам приходится «тащить» за собой огромный пласт кода.
Рассмотрим подробнее ключевые подходы, которые помогут решить эту проблему раз и навсегда.
Основное правило современной разработки на платформе 1С:Предприятие 8.3 — основная конфигурация должна оставаться на поддержке поставщика («на замке»), а все доработки должны быть вынесены в расширения конфигурации.
Рассмотрим этот процесс по шагам:
&Перед, &После или &Вместо.Посмотрим на пример правильного перехвата процедуры проведения документа в расширении с помощью аннотации &После, которая не затирает типовую логику и гарантирует легкое обновление:
&После("ОбработкаПроведения")
Процедура Расш1_ОбработкаПроведения(Отказ, РежимПроведения)
// Наша кастомная логика, выполняемая после типового проведения
Если Не Отказ Тогда
ПровестиДополнительныйУчет();
КонецЕсли;
КонецПроцедуры
Использование аннотации &Вместо следует минимизировать, так как при изменении сигнатуры или логики исходного метода вендором расширение может перестать компилироваться. Отдавайте предпочтение аннотациям &Перед и &После.
Очень часто кастомизация оперативного контура 1С:ERP ломает механизмы закрытия месяца и формирования регламентированной отчетности. Чтобы избавить бухгалтерию от постоянного стресса перед сдачей деклараций, применяется проверенный архитектурный паттерн — разделение контуров.
Суть метода заключается в следующем:
Классический Конфигуратор 1С крайне плохо справляется со сравнением и объединением сложных модулей и управляемых форм. Для упрощения процесса обновления крупных баз рекомендуется использовать 1C:Enterprise Development Tools (EDT) в связке с системой контроля версий Git.
Выясним преимущества этого подхода:
features/update-to-2.5). Разработчик может спокойно решать конфликты слияния неделями, тестировать базу, в то время как основная команда продолжает вести текущую поддержку в ветке master.BSL Language Server или платформы SonarQube позволяет автоматически находить в вашем кастомном коде обращения к устаревшим (deprecated) процедурам конфигурации ERP, которые были удалены вендором в новой версии.При точечном или накатываемом обновлении критически возрастает риск регрессионных ошибок (когда исправление кода в одном месте ломает проведение документов в другом). Ручное тестирование силами аналитиков или пользователей стоит дорого и занимает много времени.
Разберем, как автоматизировать этот процесс:
Если конфигурация отстала от текущих релизов более чем на 2 года (например, вы все еще работаете на ветке ERP 2.4, когда актуальна 2.5), а процент измененных объектов превышает 50%, стандартное обновление «накатом» может стоить дороже, чем внедрение системы заново.
В такой ситуации оптимальным решением является так называемый «переход через свертку»:
Если бизнес-процессы компании требуют сложнейших расчетов (например, динамическое ценообразование, построение цепочек поставок, сложный расчет KPI), реализация этих алгоритмов непосредственно внутри ERP делает её монолитной и «необновляемой».
Проанализируем архитектурную альтернативу: перенос расчетов во внешние веб-сервисы (написанные на C#, Java, Python или даже в отдельные базы 1С). В самой 1С:ERP при этом создается лишь легкий API-интерфейс для обмена данными через HTTP-сервисы.
Посмотрим на пример вызова внешнего микросервиса расчета цен из общего модуля 1С:ERP:
Функция ПолучитьРасчетЦенИзМикросервиса(ДанныеНоменклатуры)
Соединение = Новый HTTPСоединение("api.company.com", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL());
Запрос = Новый HTTPЗапрос("/v1/calculate-prices");
Запрос.УстановитьТелоИзСтроки(ПреобразоватьДанныеВJSON(ДанныеНоменклатуры), КодировкаТекста.UTF8);
Ответ = Соединение.ОтправитьДляОбъекта(Запрос);
Если Ответ.КодСостояния = 200 Тогда
Возврат РаспарситьJSON(Ответ.ПолучитьТелоКакСтроку());
Иначе
ВызватьИсключение "Ошибка обращения к сервису расчета цен!";
EndIf;
КонецФункции
Благодаря такому подходу ядро 1С:ERP остается чистым, а сложные расчетные алгоритмы обновляются независимо в рамках микросервисной архитектуры.
Подведем итог: Не позволяйте сиюминутным требованиям пользователей превратить вашу ERP-систему в груду неподдерживаемого кода. Переводите доработки в расширения, используйте современные инструменты слияния кода и автоматического тестирования, а для регламентированной отчетности держите чистую базу БП 3. Это сбережет ресурсы компании и обеспечит стабильную работу бизнеса.