Как управлять выбором вида документа при вводе нового в общем журнале 1С 7.7?

При работе в 1С:Предприятие 7.7 часто возникает задача ограничения или автоматизации выбора видов документов при нажатии кнопки «Новый» в общем журнале. Стандартный механизм платформы жестко зашит в ядро системы: как только пользователь нажимает клавишу Insert или кнопку с плюсом в общем журнале, 1С принудительно вызывает системный диалог выбора типа документа. Давайте разберемся, как можно изменить это поведение и какие подходы существуют для решения данной задачи.

Ограничения стандартного механизма

Важно понимать, что общий журнал документов в 1С 7.7 является объектом, поведение которого определяется на уровне метаданных системы. Стандартные события формы, такие как ПриНачалеВыбора или ПриОткрытии, не позволяют перехватить нажатие клавиши «Новый» до того, как система инициирует открытие диалога выбора. Это происходит до вызова процедур модуля формы, поэтому штатно «отменить» этот выбор или подменить его своим списком без дополнительных инструментов не получится.

Метод №1: Архитектурный подход — отказ от общего журнала

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

1. Создадим новую обработку, которая будет выполнять роль «Рабочего места пользователя».
2. Вместо штатного журнала разместим на форме ТабличноеПоле или используем СписокЗначений для отображения документов.
3. Для ввода нового документа добавим свою кнопку на форму. Так как это наша кнопка, мы полностью контролируем её поведение в процедуре ПриНажатии.
4. Программно сформируем список доступных видов документов и откроем форму нужного объекта методом ОткрытьФорму() или ОткрытьФормуМодально().

Этот метод позволяет полностью изолировать пользователя от стандартных диалогов платформы и реализовать любую логику фильтрации, проверки прав или автозаполнения еще до момента создания документа.

Метод №2: Использование внешней компоненты FormEx

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

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

Процедура ПриОткрытииФормыДокумента(ФлагСтандартнойОбработки, идВидаОткрываемогоДокумента, идОткрываемогоОбъекта, идТекущегоЖурнала, п4, идКопируемогоОбъекта, идВидаТекущегоВЖурнале, флВводНаОсновании, идВидаДокументаОснования, флРежимПросмотра, п10, п11, п12, п13, ПараметрФормы)
    // Проверяем, находится ли пользователь в нужном нам журнале
    Если идТекущегоЖурнала = objMetaDataWork.GetMetaDataID(Метаданные.Журнал("Счета")) Тогда
        // Подменяем логику выбора документа
        идВидаОткрываемогоДокумента = идВидаТекущегоВЖурнале;
        идВидаТекущегоВЖурнале = 0;
        идТекущегоЖурнала = 0;
    КонецЕсли;
КонецПроцедуры

Разберем, что происходит в данном примере:

• Мы используем объект objMetaDataWork, предоставляемый компонентой FormEx, чтобы получить идентификатор журнала.
• Если пользователь находится в «Счетах», мы принудительно переопределяем переменные, которые определяют тип создаваемого документа.
• Таким образом, мы можем «обмануть» стандартный алгоритм 1С, подставив нужное нам значение идентификатора вида документа.

Рекомендации по реализации

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

Однако, если стабильность работы системы — ваш приоритет, создание собственных специализированных журналов (обработок) является более предпочтительным. Это исключает риски, связанные с возможной несовместимостью внешних компонент с разными версиями операционных систем или обновлениями 1С:Предприятия 7.7.

В завершение, рассмотрим еще один «трюк», часто упоминаемый опытными разработчиками: создание дополнительного журнала, в котором выбраны только нужные документы, с последующей попыткой подмены метаданных. Однако этот способ считается ненадежным и нестабильным, поэтому мы рекомендуем остановиться на двух описанных выше методах как на наиболее предсказуемых и безопасных для стабильной работы вашего программного комплекса.