При работе с конфигурациями на базе единой ERP-платформы (к которым относятся 1С:ERP Управление предприятием, 1С:Комплексная автоматизация и 1С:Управление торговлей) разработчики и администраторы часто сталкиваются с внутренними механизмами, которые управляют отображением интерфейса и логикой поведения программы. Одной из таких важных, но малозаметных "подкапотных" настроек является функциональная опция УправлениеТорговлей. В этой статье мы разберем, какую роль она играет в системе, почему в версии 11.5 её поведение изменилось и как это влияет на привычные названия статей расходов.
Рассмотрим архитектурную особенность современных решений 1С. Поскольку ERP, КА и УТ строятся на базе единого кода (так называемой конфигурации-донора), большая часть объектов метаданных у них идентична. Однако целевая аудитория у этих продуктов разная: менеджеру в торговой компании не всегда нужно видеть сложные термины регламентированного или производственного учета, которые обязательны для бухгалтера на крупном заводе.
Функциональная опция УправлениеТорговлей — это технический маркер. Проанализируем её основную задачу: она сообщает программному коду, что в данный момент база запущена именно как "Управление торговлей". Это позволяет системе автоматически "упрощать" терминологию. Например, вместо сложного бухгалтерского названия Формирование резервов по сомнительным долгам пользователь видит лаконичное Прочие расходы.
Посмотрим на конкретный пример реализации этой логики в модуле менеджера плана видов характеристик СтатьиРасходов. В процедуре ЗаполнитьПредопределенныеСтатьиРасходов разработчики заложили условие, которое меняет представление объектов в зависимости от установленной опции. Разберем фрагмент кода:
ИначеЕсли СтатьяРасходов = ПланыВидовХарактеристик.СтатьиРасходов.ФормированиеРезервовПоСомнительнымДолгам Тогда
СтатьяРасходовОбъект.ТипЗначения = Новый ОписаниеТипов("СправочникСсылка.Организации");
СтатьяРасходовОбъект.ВариантРаспределенияРасходовРегл = Перечисления.ВариантыРаспределенияРасходов.НаНаправленияДеятельности;
Если ПолучитьФункциональнуюОпцию("УправлениеТорговлей") Тогда
СтатьяРасходовОбъект.Наименование = НСтр("ru = 'Прочие расходы'");
КонецЕсли;
СтатьяРасходовОбъект.ВидДеятельностиРасходов = Перечисления.ВидыДеятельностиРасходов.ПрочаяДеятельность;
Проанализируем эту ситуацию подробнее. Если система определяет, что это УправлениеТорговлей, она программно переименовывает предопределенную статью. В 1С:ERP или 1С:КА это условие не сработает, и пользователь увидит полное название, связанное с резервами по сомнительным долгам, так как там ведется полноценный регламентированный учет.
Многие пользователи при обновлении с версии 11.4 на 11.5 заметили странное поведение: в документах вместо привычных Прочих расходов вдруг появились Резервы по сомнительным долгам. Выясним причину этой метаморфозы.
В релизах ветки 11.5 компания 1С провела масштабный рефакторинг. Функциональная опция УправлениеТорговлей в её старом виде начала выводиться из эксплуатации. Разберем, что изменилось:
Важный момент: Если вы видите "страшные" названия в УТ 11.5, это не означает, что в программе включился блок сложного бухучета. Это лишь признак того, что механизм визуального переименования предопределенных данных не сработал при обновлении.
Если после перехода на 11.5 вы столкнулись с избыточной терминологией, рассмотрим шаги по исправлению ситуации. Проблема обычно кроется в том, что предопределенные данные не были обновлены с учетом новых правил идентификации конфигурации.
Во-первых, проанализируем состояние базы через консоль кода. Нам необходимо убедиться, что система понимает свой тип. В новых версиях за это могут отвечать специализированные константы или настройки в общем модуле ОбщегоНазначенияУТ (или аналогичных для ERP-линейки).
Во-вторых, разберем способ принудительного обновления. Для этого можно вызвать процедуру обновления предопределенных данных. В программном коде это выглядит примерно так:
// Пример вызова обновления статей через внешнюю обработку
ПланыВидовХарактеристик.СтатьиРасходов.ЗаполнитьПредопределенныеСтатьиРасходов();
При выполнении этой процедуры система заново пройдет по алгоритму, который мы рассматривали выше. Если текущие программные флаги (уже новые, пришедшие на смену опции УправлениеТорговлей) установлены верно, наименования вернутся к "торговому" виду.
Подводя итог, отметим: функциональная опция УправлениеТорговлей — это классический пример "маскировки" сложности в рамках единой кодовой базы. Главное, что нужно помнить:
СтатьиРасходов в момент первичного заполнения или обновления базы.Понимание этих внутренних механизмов помогает быстрее диагностировать "странности" в поведении программы после обновлений и поддерживать интерфейс в удобном для пользователей виде.