Почему в УНФ 3.0 скрываются команды групповой смены состояния заказа покупателя?

При разработке и сопровождении конфигурации «1С:Управление нашей фирмой» (УНФ 3.0) разработчики нередко сталкиваются с непонятным поведением командной панели и контекстного меню динамического списка документов ЗаказПокупателя. В конфигураторе свойство Видимость у групп ФормаУстановитьСостояние и СписокКонтекстноеМенюУстановитьСостояние установлено в Истина, однако в самом начале серверного обработчика ПриСозданииНаСервере в точке останова мы видим, что видимость уже сброшена в Ложь. При этом глобальный поиск по конфигурации не находит явных строковых присвоений вида Элементы.ФормаУстановитьСостояние.Видимость = Ложь;.

Разберем детально механизм платформы, логику разработчиков типового решения, а также корректные способы решения этой задачи без нарушения бизнес-логики программы.

Механизм платформы: работа функциональных опций

Выясним причину, по которой элемент формы получает признак невидимости еще до выполнения первой строки кода в модуле формы. В платформе «1С:Предприятие 8.3» видимость элементов, групп и команд формы может управляться не только программным кодом, но и механизмом Функциональных опций (ФО).

Проанализируем последовательность инициализации управляемой формы платформой:

1. Платформа считывает состав элементов формы из метаданных конфигурации.
2. Проверяется привязка элементов, групп и связанных с ними команд к функциональным опциям конфигурации.
3. Если функциональная опция в текущей информационной базе отключена (или ее значение запрещает отображение объекта), платформа автоматически переводит свойство Видимость элементов в Ложь.
4. Только после применения всех правил функциональных опций управление передается в обработчик события ПриСозданииНаСервере.

В типовой УНФ группы команд быстрой смены состояния жестко связаны с опцией использования простой модели состояний без разделения на виды заказов. Когда в программе начинает использоваться учет по видам заказов, платформа автоматически исключает эти элементы из интерфейса еще до запуска кода формы.

Бизнес-логика типового решения: зачем скрывать команды

Рассмотрим, почему разработчики типовой конфигурации скрывают групповую установку состояний в общем списке при включении видов заказов покупателей:

1. Разные наборы состояний для разных видов документов. В простой модели действует единый сквозной список состояний. Однако при использовании видов заказов каждому виду назначается собственный набор этапов и уникальная карта маршрутов. Статус, корректный для одного вида заказа (например, «В производстве»), может отсутствовать в виде заказа на оптовую отгрузку.
2. Неопределенность групповой операции в списке. В динамическом списке пользователь может выделить одновременно несколько документов с разными видами. Командная панель и контекстное меню не могут предложить универсальный выпадающий список состояний, так как для разных выделенных строк набор допустимых значений не совпадает.
3. Контроль бизнес-процессов и проверок. В УНФ 3.0 переход заказа на определенный этап часто сопровождается контролем бизнес-логики: обязательным указанием причины закрытия, фиксацией ответственного, контролем взаиморасчетов или запуском автоматических действий ассистента управления. Прямая смена состояния «в обход» логики этапа приводит к искажению данных в воронке продаж и CRM-аналитике.

Риски принудительного включения видимости через код

Попытка решить вопрос «в лоб», прописав принудительное включение видимости в расширении или модуле формы, влечет за собой ряд проблем:

// Такой подход приводит к коллизиям:
Элементы.ФормаУстановитьСостояние.Видимость = Истина;
Элементы.СписокКонтекстноеМенюУстановитьСостояние.Видимость = Истина;

Если видимость команды ограничена функциональной опцией на уровне метаданных команды, включение видимости группы в коде формы может оставить сами кнопки неактивными (свойство Доступность = Ложь). Кроме того, если пользователь массово назначит заказу статус, не входящий в разрешенный список его вида заказа, при последующей записи или проведении возникнут ошибки валидации данных.

Варианты решения проблемы

Рассмотрим штатные и корректные проектные способы организации работы пользователей.

1. Отключение ведения учета по видам заказов

Если предприятию не требуются разные цепочки продаж и используется единый сквозной процесс обработки всех заказов, разделение по видам можно просто отключить. Разберем шаги:

1. Перейдем в раздел Настройки — Еще больше возможностей — Продажи.
2. Снимем флаг использования видов заказов покупателей.
3. После отключения функциональная опция изменит свое значение, и команды быстрой установки состояний автоматически вернутся на командную панель и в контекстное меню списка без изменения конфигурации.

2. Работа через специализированные рабочие места и воронку продаж

При включенных видах заказов типовая методология предполагает перевод этапов в интерфейсах, где установлен жесткий отбор по конкретному виду заказа. Проанализируем режим отображения списка заказов в виде канбан-доски: когда пользователь выбирает конкретный вид заказа, колонки канбана отображают именно его этапы, а смена состояния выполняется простым перетаскиванием карточки заказа между колонками.

3. Массовая корректировка через групповое изменение реквизитов

Если требуется разовая или периодическая сервисная смена состояний у массива документов, правильнее использовать стандартную обработку Групповое изменение реквизитов:

1. Открываем обработку и выбираем документ Заказ покупателя.
2. Обязательно настраиваем отбор: указываем конкретный Вид заказа.
3. В списке реквизитов находим Состояние и выбираем значение, входящее в цепочку данного вида заказа.

4. Динамическое формирование подменю в расширении

Если регламент предприятия жестко требует смену состояния из контекстного меню списка при включенных видах заказов, программная доработка должна учитывать ограничения модели данных. Разберем правильный алгоритм реализации:

1. При изменении выделения строк динамического списка анализируем реквизит ВидЗаказа у всех выделенных документов.
2. Если выделены заказы с разными видами, отключаем доступность команды смены состояния или выводим предупреждение.
3. Если вид заказа у всех выделенных строк строго одинаковый, программно запрашиваем список состояний, привязанных к данному виду, и динамически наполняем кнопки подменю соответствующими значениями.

Такой подход обеспечивает целостность учетных данных и сохраняет корректную работу аналитических отчетов конфигурации.