Заполнение реквизитов документа при проведении другого

[vitasw]

тогда:
- или делаете РС периодическим и тупо записываете новую запись в РС
- или делаете РС независимым.

[Dirijabl]

С этим получилось справиться, в регистр пишутся правильные записи. А теперь чтобы изменить реквизиты на форме в Заявке, нужно перепровести этот документ обязательно? Или к какому событию можно прицепиться, чтобы автоматом при проведении ПП реквизиты в заявке менялись?

[vitasw]

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

[Dirijabl]

Допустим, информационная запись. Откуда ее формировать, из тоже обработки проведения пп?

[vitasw]

В при открытии документа

[TerverVl]

НЕЛЬЗЯ в модуле проведения документа менять реквизиты самого документа-объекта

Мне кажется, или вопрос ставился другой? При проведении документа "Платёжное поручение исходящее" на
основании документа "Заявка на расходование денежных средств" мы меняем реквизиты именно заявки, а не проводящегося
в данный момент документа. И для чего нужен регистр сведений в этом случае?
Проще взять реквизит "ДокументОснование" платёжного поручения, проверить его на соответствие типу
"ДокументСсылка.ЗаявкаНаРасходованиеДенежныхСредств", от этой ссылки получить объект, установить нужные значения
реквизитов этого объекта и его записать.

p.s. единственно по методологии нужно делать это в транзакции, или сделать контроль, что документ проведён без ошибок,
чтобы при ошибке проведения платёжного поручения, изменения в заявке не происходили.

[vitasw]

мы меняем реквизиты именно заявки, а не проводящегося

Без разницы. НЕЛЬЗЯ. Запишите/Запомните/набейте наколку на открытом участке тела. В модуле документа нельзя менять реквизиты чего угодно. Это аксиома из разряда "запрос в цикле".

Проще взять реквизит...

Проще?! Проще руками есть, но все почему-то пользуются столовыми приборами.
Ну ловите ваше проще...
1. Обработка даты запрета редактирования
2. Проверка на отсутствие пометки удаления у заявки
3. Проверка что объект-заявка не занят другим пользователем
4. Обработка отмены проведения ПП
И это только те моменты, что лежат на поверхности.
Может все таки при решения задач подходить с критерием "правильно", а не "проще"?
Единственным очень частным случаем, когда я допускаю возможность редактирования другого объекта, это вариант при котором "другой" объект является чисто служебным и пользователь даже не подозревает об наличии этого "другого" объекта. В качестве "другого" объекта в таком случае может выступать справочник, но никак не документ.

[TerverVl]

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

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

[vitasw]

Для записи в регистр сведений нужно сделать большинство указанных проверок.

Чего это вдруг?!?! Никаких других проверок для осуществления записи в регистр делать не нужно, кроме тех что уже реализованы в типовых.

1. Если документ по какой-либо причине не провёлся - в регистр не пишем.

Ииии? я по-моему этот пункт не указывал. Это само-собой разумеющееся. Тем более, что проверка уже реализована в рамках типового кода.

2. Для заявки, помеченной на удаление вообще не имеет смысла создавать документ на её основании.

Причем тут целесообразность ввода на основании?!?! речь идет о редактировании основания. К тому же сделать основании непроведенным/помеченным на удаление задним числом большинство типовых пропускает.

3. При отмене проведения документа нужно удалить запись в регистре сведений.

В туже степь. Если РС подчинен регистратору, то не нужно. По той же причине, что в большинстве типовых код очистки набора записей уже реализован.

В базах, в которых я работаю как пользователь, успешно применяю подобные ускорители, избавляющие от лишних кликов мышкой,

"ускорители..."?!?! ну-ну. У вас в базе полтора пользователя? и никто никогда ничего не меняет задним числом? и все вкурсе об ваших "ускорителях" и специфике работы таких "ускорителей" и все пользователи всегда проверяют всю цепочку документов? Вы просто ни разу не разгребали непонятку, например, годичной давности.

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

[TerverVl]

По делу:
Корректную реализацию можно подсмотреть в типовой бухгалтерии 3.0
Там реализован регистр сведений "СтатусыДокументов" и дальше можно найти как реализована работа со статусами.