Всем доброго времени суток!

Помогите советом.
Используется типовая конфигурация, не хотелось бы менять типовые модули у типовых объектов или использовать расширение.

Сделан свой регистр сведений, который заполняется при проведении документа.
Но надо вывести пользователю заполненную по документу форму записи в регистр, чтобы он, если надо изменил данные, согласился на сохранение или отказался.
На проведение документа навешан обработчик события, который обращается в серверный общий модуль.
Естественно из этого общего модуля форму для пользователя открыть не получится.

Вообще такое у кого-нибудь встречалось?
Может быть, как-то иначе надо организовывать работу или есть алгоритм, как это реализовать?

прикольно будет перепроводить 100500 документов

(0) вынеси форму набора записей своего регистра в форму документа и пусть пользователь там записывает

"не хотелось бы менять типовые модули у типовых объектов или использовать расширение", если прям так то доп. обработку привяжи к документу.

(0) >> регистр сведений, который заполняется при проведении документа. Но надо вывести пользователю заполненную по документу форму записи в регистр, чтобы он, если надо изменил данные.

А что должно произойти при перепроведении документа?
Алгоритм проведения должен перезаполнить записи регистра или каким-то образом догадаться, что пользователь менял ручками записи и менять их снова - нельзя?

Или ты что-то очень криво рассказал.
Или разрабатывается очень кривое архитектурное решение. Просто дичь какая-то.

(4) По хорошему если что-то правится руками, то за этим может скрываться сущность которой может быть нужен свой документ.

(5) Да там может быть вообще всё что угодно. Подробности только автор ветки может рассказать.
Но есть одно золотое правило. Регистр и документы движения должны быть спроектированы таким образом, чтобы обеспечивалась неизменность движений (наборов записей) при сколько угодном количестве перепроведений документа любым способом (интерактивно или программно), при перепроведении задним числом (движения не должны зависеть от изменения данных после проведения документа) и при ретроспективном движении (обратным ходом).
Исключения конечно могут быть (например, регистры расчета с их перерасчетами). Но не думаю, что это тот самый случай.

"Но надо вывести пользователю заполненную по документу форму записи в регистр, чтобы он, если надо изменил данные, согласился на сохранение или отказался."
Зачем пользователю менять данные в движениях документа?

Большое спасибо всем откликнувшимся!
Согласен, может быть действительно «кривое» решение.
(1) спасибо за подсказку, как то не подумал, но естественно мне надо только тогда, когда пользователь интерактивно проводит и не когда он проводит обработкой. Просто как то не предполагал, что документ ПриемНаРаботу кому-то надо будет перепроводить списком.
(2) интересное предложение, спасибо, даже в голову почему-то не пришло. Это ведь через расширение тогда реализовывать?
(3) не смог понять - когда и кем будет запускаться доп. обработка?
(4) мы пошли по пути наименьшего сопротивления. В доп РС хотим хранить дату, когда в первый раз физ. лицо начало сотрудничать с компанией (группой компаний) и данные текущего документа по которому оно оформлено (трудовой договор, договор ГПХ и т.п.). При оформлении нового документа «приема на работу» данные регистра сотрудник может поменять (текущий правовой документ отношений), а дату начала сотрудничества трогать не будет. Т.е. как сотрудник оставит данные в регистре – так и правильно, только ему потом с ними работать и отвечать за них.
(5) торопились и о таком варианте тоже не подумали. Просто показалось, что ради 5ти полей создавать новый документ – это может быть слишком. Опять же – понимаем, что по большому идёт дублирование информации, если это ещё и документом фиксировать, не знаю. Но надо подумать.
(6) хорошее замечание, попробуем в свете вами сказанного переосмыслить то, что решили нагородить
(7) ваш ответ имеет смыл некоторых предыдущих советов, реально надо ещё раз переосмыслить не торопясь