При планировании масштабных доработок в типовой конфигурации 1С:Управление торговлей 11 (УТ 11) перед разработчиком всегда встает дилемма: использовать механизмы основной конфигурации или выносить все изменения в расширения. Опыт показывает, что крайности (делать всё только в расширениях или только в конфе) ведут к проблемам при поддержке. Разберем сбалансированную стратегию, которая позволит сохранить управляемость системы и минимизировать время на обновление.
Для начала проанализируем, как объем изменений влияет на выбор инструмента. Если планируется затронуть до 25% конфигурации (новые документы, регистры, изменение типовой логики), чистая работа в расширениях может привести к нестабильности. Рассмотрим основные правила разделения доработок:
Выясним причину, почему новые реквизиты и объекты стоит держать в основной конфигурации. При добавлении реквизита в расширение платформа создает в СУБД отдельную таблицу. При каждом запросе происходит соединение (JOIN) основной таблицы и таблицы расширения, что при больших объемах данных замедляет работу системы. Проанализируем правильный алгоритм работы с объектами:
Рассмотрим порядок включения возможности изменения:
Включаем возможность изменения конфигурации, устанавливая правило «Редактируется с сохранением поддержки». При этом для объектов, которые мы не планируем менять, лучше оставить правило «Только просмотр». Это позволит визуально выделять измененные объекты в окне настройки поддержки.
Важный нюанс: Если вы добавляете новые реквизиты в типовые справочники или документы, делайте это в основной конфигурации. Расширения плохо работают с определяемыми типами и критериями отбора, что может стать блокирующим фактором при сложной разработке.
Доработка форм — самый трудозатратный процесс при обновлениях. Разберем по шагам, как минимизировать риски. Вместо того чтобы переносить форму типового объекта в расширение и менять ее визуально, используем программный код в расширении. Посмотрим на пример кода, который добавляет реквизит на форму при её создании:
&После("ПриСозданииНаСервере")
Процедура прф_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Добавляем новую группу на форму
НоваяГруппа = ЭтаФорма.Элементы.Добавить("прф_ГруппаДополнительно", Тип("ГруппаФормы"), ЭтаФорма.Элементы.ГруппаШапка);
НоваяГруппа.Вид = ВидГруппыФормы.ОбычнаяГруппа;
НоваяГруппа.Заголовок = "Дополнительная информация";
// Добавляем поле, связанное с новым реквизитом объекта
НовоеПоле = ЭтаФорма.Элементы.Добавить("прф_СпецСтатус", Тип("ПолеФормы"), НоваяГруппа);
НовоеПоле.ПутьКДанным = "Объект.прф_СпецСтатус";
НовоеПоле.Вид = ВидПоляФормы.ПолеВвода;
КонецПроцедуры
Такой подход гарантирует, что даже если 1С полностью изменит визуальный состав формы в обновлении, ваш код либо продолжит работать, либо просто не найдет родительский элемент (что легко исправить), но не приведет к потере всей формы расширения.
Проанализируем ситуацию с изменением алгоритмов проведения или расчетов. В 1С предусмотрено несколько аннотаций. Разберем их приоритетность:
Если изменения критически важны и затрагивают глубокие расчеты (например, механизм НДС или расчет себестоимости), лучше вносить их прямо в основную конфигурацию. Почему? Потому что в окне трехстороннего сравнения при обновлении вы будете наглядно видеть, что изменил вендор и как это пересекается с вашим кодом. В расширениях такой наглядности при обновлении основной базы достичь сложнее.
Рассмотрим технические «ловушки», которые могут встретиться при попытке вынести всё в расширения:
Для поддержания системы в актуальном состоянии используйте следующую методику:
ит_ или прф_). Это исключит конфликт имен, если 1С в будущем добавит реквизит с похожим названием.EDT и систему Git. Это значительно упрощает отслеживание истории изменений в расширениях по сравнению с классическим хранилищем.Таким образом, мы проанализировали гибридный подход: структура данных — в конфигурации, интерфейс и перехват событий — в расширении. Это «золотая середина», которая позволяет системе оставаться производительной и при этом относительно легкой в обновлении.