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