Каждый разработчик, работающий с крупными корпоративными системами на платформе 1С:Предприятие 8.3 (особенно с такими масштабными конфигурациями, как 1С:ERP Управление предприятием 2), рано или поздно сталкивается с дилеммой: как доработать типовой документ под уникальные требования бизнеса и при этом не превратить последующие обновления системы в бесконечный ночной кошмар? Выход новых релизов происходит регулярно, изменения в типовом коде вендора могут быть кардинальными, а бизнес требует непрерывности процессов.
В этой статье мы подробно разберем, как спроектировать архитектуру доработок для документов 1С:ERP 2.0 так, чтобы процесс обновления конфигурации оставался быстрым, предсказуемым и безопасным.
Давайте проанализируем три базовых варианта, которые чаще всего приходят на ум разработчикам, и оценим их жизнеспособность в реалиях крупного внедрения.
При таком подходе новые реквизиты добавляются непосредственно в метаданные документа, а логика пишется в его модулях. Плюс: максимальная простота разработки и стабильность хранения данных. Огромный минус: при каждом обновлении придется вручную сопоставлять код через инструмент сравнения/объединения, восстанавливать затертые участки и тестировать все заново. Этот путь ведет к колоссальным трудозатратам на сопровождение.
Это современный стандарт разработки. Новые реквизиты, формы и модули создаются внутри расширения, а основная конфигурация остается на полной поддержке ("на замке"). Плюс: типовое обновление проходит в один клик. Минусы: расширения имеют свойство "ломаться" при изменении структуры метаданных поставщиком. Захваченные визуально формы часто выдают критические ошибки применимости после обновления ERP. Кроме того, существует риск временной потери доступа к данным при аппаратных сбоях или некорректном отключении расширения.
Разработчик полностью копирует типовой документ (например, РеализацияТоваровУслуг), называет его по-своему и внедряет туда весь необходимый функционал. Плюс: обновление конфигурации никак не затрагивает этот объект. Жирный минус: этот вариант абсолютно нежизнеспособен для ERP-систем. Типовой документ глубоко интегрирован в сотни механизмов: партионный учет, закрытие месяца, отчетность, подсистемы бюджетирования, интеграции и регламентированного учета. Создав дубликат, вы будете вынуждены переписать половину ERP-системы, чтобы подружить её с вашим новым документом.
Выяснив, что ни один из чистых подходов в отдельности не является идеальным, перейдем к разбору современных архитектурных инструментов, которые позволяют реализовать надежный гибридный подход.
Прежде чем добавлять физические реквизиты в метаданные документа (в основной конфигурации или в расширении), необходимо задать вопрос: обязательно ли менять структуру таблиц базы данных? Библиотека стандартных подсистем (БСП), на базе которой построена 1С:ERP, предоставляет мощнейший инструмент — Дополнительные реквизиты и сведения.
Рассмотрим подробнее преимущества этого механизма:
УправлениеСвойствами.Если же бизнес-логика требует сложного поведения реквизита (например, участие в индексах, жесткая типизация, использование в сложных запросах для высокой производительности), то физического добавления реквизита в метаданные не избежать. В этом случае мы переходим к гибридной схеме.
Опыт крупных внедрений показывает, что наиболее безопасной является следующая схема разделения труда:
Основная причина, по которой "слетают" расширения после обновления 1С:ERP — это визуальный захват форм документов в расширение. Если вендор в новом релизе удалит, переименует или переместит какой-то элемент интерфейса на типовой форме, ваше расширение выдаст ошибку применимости, и пользователи не смогут работать.
Разберем по шагам, как решить эту проблему с помощью программного изменения форм:
ПриСозданииНаСервере с помощью аннотации &После.Посмотрим на пример реализации такого кода:
&После("ПриСозданииНаСервере")
Процедура ИСТ_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверим, нет ли уже созданного элемента, чтобы избежать дублирования
Если Элементы.Найти("ИСТ_ДополнительноеПоле") = Неопределено Тогда
// Определим родительскую группу на форме, куда хотим поместить наше поле
ГруппаНазначения = Элементы.ГруппаШапка; // Имя типовой группы на форме документа
// Программно добавляем элемент формы
НовыйЭлемент = Элементы.Добавить("ИСТ_ДополнительноеПоле", Тип("ПолеФормы"), ГруппаНазначения);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
// Связываем элемент с реквизитом, который мы добавили в документ в основной конфигурации
НовыйЭлемент.ПутьКДанным = "Объект.ИСТ_ДополнительноеПоле";
НовыйЭлемент.Заголовок = "Дополнительная аналитика";
КонецЕсли;
КонецПроцедуры
При таком подходе, даже если дизайн типовой формы в новом релизе 1С:ERP изменится, процедура отработает корректно. В худшем случае, если разработчики 1С полностью удалят группу ГруппаШапка, код вызовет исключение, которое легко локализовать, изменив имя родительской группы в одной строке кода, при этом сама конфигурация не заблокируется.
Когда стоит задача изменить алгоритм проведения документа (например, скорректировать проводки по регистру бухгалтерии Хозрасчетный или движения по оперативным регистрам на основе новых реквизитов), худшее решение — это править процедуру ОбработкаПроведения в модуле объекта.
Вместо этого мы рекомендуем использовать Подписки на события. Этот механизм является частью платформы и работает чрезвычайно стабильно.
Выясним схему работы через подписки:
ОбработкаПроведения.Рассмотрим пример кода обработчика подписки на событие:
// Процедура размещается в нетиповом общем модуле с флагами "Сервер", "Вызов сервера"
Процедура ИСТ_ДокументыОбработкаПроведения(Источник, Отказ, РежимПроведения) Экспорт
// Исключаем обработку при загрузке данных (например, через обмен)
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Проверяем тип источника, если подписка оформлена на несколько документов
Если ТипЗнч(Источник) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
// Наша логика изменения проводок
// Обращаемся к реквизиту, добавленному в основную конфигурацию
Если ЗначениеЗаполнено(Источник.ИСТ_ДополнительноеПоле) Тогда
// Получаем коллекцию движений по интересующему нас регистру
ДвиженияХозрасчетный = Источник.Движения.Хозрасчетный;
// Выполняем анализ или модификацию наборов записей
Для Каждого Проводка Из ДвиженияХозрасчетный Цикл
// Пример корректировки аналитики (субконто) на основании нашего реквизита
// Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.НаправленияДеятельности] = Источник.ИСТ_ДополнительноеПоле;
КонецЦикла;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Разработчики фирмы "1С" прекрасно понимают потребности партнеров и клиентов в кастомизации системы. Поэтому в 1С:ERP внедрена развитая система переопределяемых общих модулей. Почти для каждой ключевой подсистемы существуют модули с постфиксом Переопределяемый (например, ЗапасыИЗакупкиПереопределяемый, ПроведениеСерверУППереопределяемый и т.д.).
Внутри этих модулей разработчики вендора специально оставляют пустые процедуры-шаблоны или процедуры с минимальной логикой, которые вызываются в ключевых точках бизнес-процессов. Изменяя код в таких модулях, мы действуем в рамках официальной архитектуры системы, разработанной вендором, что сводит к минимуму вероятность конфликтов при обновлении.
Подводя итог, сформируем краткий свод правил, которому мы рекомендуем следовать при выполнении любых доработок типовых документов в 1С:ERP 2:
&После("ПриСозданииНаСервере").Соблюдение этих архитектурных стандартов позволит вам поддерживать конфигурацию 1С:ERP в актуальном состоянии, тратя на процесс обновления считанные часы вместо недель кропотливой ручной работы.