При работе с типовыми решениями 1С перед каждым разработчиком и архитектором рано или поздно встает вопрос: где та грань, за которой адаптация системы под нужды бизнеса превращается в «архитектурный кошмар»? Ситуация, когда бизнес требует внедрения нового разделительного признака (аналитического разреза) во все складские и финансовые блоки, является классическим вызовом. Разберем по шагам, как оценить адекватность таких требований и какие инструменты платформы использовать, чтобы не превратить обновление конфигурации в бесконечный и дорогостоящий процесс.
Прежде чем приступать к написанию кода, проанализируем ситуацию с точки зрения глобального подхода к сопровождению системы. Существует две полярные стратегии:
Для принятия решения выясним причину, по которой бизнесу недостаточно имеющихся механизмов (например, направлений деятельности или характеристик). Если потребность в новой аналитике обоснована, переходим к выбору технического решения, минимизирующего вмешательство в «ядро».
Первым делом рассмотрим подробнее возможности Библиотеки стандартных подсистем (БСП). Это наиболее безопасный способ добавить аналитику без изменения метаданных.
Дополнительные реквизиты позволяют добавить поле в документ или справочник, которое будет визуально доступно пользователю. Дополнительные сведения хранятся отдельно и не нагружают сам объект метаданных. Главный плюс — полная сохранность при обновлении. Однако, если этот признак должен участвовать в сложных алгоритмах проведения по регистрам, возможностей БСП может быть недостаточно, так как потребуется переписывать запросы в модулях проведения.
Современный стандарт разработки диктует использование расширений. Это позволяет изменять логику, не снимая основную конфигурацию с поддержки. Проанализируем риски этого подхода:
ЗапасыНаСкладах), платформа на уровне СУБД будет выполнять соединение таблиц. При миллионах записей это может привести к деградации производительности.Тем не менее, для задач добавления «разделительного признака» расширения являются приоритетным инструментом. Мы можем перехватить процедуру проведения документа через &После или &Вместо и дополнить движения регистра данными из нашего нового реквизита.
Если задача требует глубокого изменения аналитики в складском блоке, эксперты рекомендуют не трогать типовые регистры, а создавать свои. Разберем этот метод:
Вместо того чтобы добавлять измерение в типовой регистр ВыручкаИСебестоимостьПродаж, мы создаем собственный регистр накопления с нужной нам структурой. Для заполнения данных используем механизм Подписок на события.
Пример реализации подписки на событие ОбработкаПроведения:
Процедура ПриПроведенииДокументаДляСобственногоУчета(Источник, Отказ, РежимПроведения) Экспорт
// Проверяем, что документ проведен и не содержит ошибок
Если Отказ Тогда Возврат; КонецЕсли;
// Создаем набор записей нашего собственного регистра
НаборЗаписей = РегистрыНакопления.МойСобственныйУчетЗапасов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(Источник.Ссылка);
// Заполняем движения на основе данных документа и типовых движений
Для Каждого СтрокаТЧ Из Источник.Товары Цикл
Движение = НаборЗаписей.Добавить();
Движение.Период = Источник.Дата;
Движение.Номенклатура = СтрокаТЧ.Номенклатура;
// Добавляем наш уникальный разделительный признак
Движение.ДопАналитика = Источник.НашНовыйРеквизит;
Движение.Количество = СтрокаТЧ.Количество;
КонецЦикла;
НаборЗаписей.Записать();
КонецПроцедуры
Этот подход гарантирует, что при обновлении конфигурации типовая логика не «сломает» ваши данные, так как они изолированы в отдельном объекте.
Прежде чем «городить огороды» из кода, посмотрим на ситуацию со стороны бизнеса. Существует «правило 20%»: если доработки затрагивают более пятой части типовых модулей, стоимость сопровождения системы в долгосрочной перспективе может превысить стоимость внедрения нового решения с нуля.
Рассмотрим альтернативу: иногда дешевле изменить бизнес-процесс компании (например, регламентировать использование существующих полей или нанять дополнительного сотрудника для сверки данных), чем оплачивать сотни часов работы программиста по переписыванию ядра ERP-системы и последующей мучительной борьбе с багами при каждом обновлении.
Если решение о доработке принято, выясним правила «хорошего тона» современной разработки:
Подписки на события вместо модификации модулей объектов. Используйте Расширения для интерфейсных правок.Подведем итог: добавление нового аналитического признака — это адекватная задача, но она требует архитектурной дисциплины. Стремитесь к созданию «чистого ядра», вынося всю специфичную логику в изолированные подсистемы и расширения. Помните, что лучший код — это тот, который не придется переписывать при следующем релизе платформы или конфигурации.