Добрый день. Как правильно заполнять такие реквизиты документа, которые есть на форме, но нет в объекте? Значения хранятся в регистре сведений, я хотел сделать через менеджер записи, но регистр подчинен регистратору, и через менеджер записи добавить в него не получится. Платформа 8.3.22.1851

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

(0) что ты собрался добавлять через менеджер записи?
Ты же говоришь на форму надо прочитать.

(0) при обработке проведения, наверное. Движения называется

(0) Правильно их заполнять из модуля проведения документа

(1) Спасибо, сделал вот так, работает:

// создали набор
НаборЗаписей = РегистрыСведений.упПеревозчикПоРейсу.СоздатьНаборЗаписей();

// установили в нем отбор по измерениям
                    НаборЗаписей.Отбор.Регистратор.Установить(стр.Рейс);                    НаборЗаписей.Отбор.Регистратор.Использование = Истина;

// прочитали то, что есть в базе
                    НаборЗаписей.Прочитать();

// добавили свое
НоваяЗапись = НаборЗаписей.Добавить();
                    ЗаполнитьЗначенияСвойств(НоваяЗапись, СтруктураЗаполненияРегистра);

// записали общий набор обратно
                    НаборЗаписей.Записать();

(4) Почему через набор записей неправильно?

(6) Потому что Вы не умеете им пользоваться.

(5) а если во время проведения будет отказ=истина?
запись в регистре так и останется

через доп свойства можно передать данные.
а потом уже в обработке проведения записывать как обычное движение

https://www.koderline.ru/expert/narabotki/article-programma-1s-dopolnitelnye-svoystva/

(8) еще надо предусмотреть ОбменДанными.Загрузка = Истина. еще надо предусмотреть локализационные процедуры обработки. еще надо предусмотреть проверку на существование нетипового регистра. еще надо....

(8) Я не делаю проведение, а заполняю регистр внешней обработкой. Подставляю перевозчика в документ рейс. Разве обязательно для этого проводить документ?

(10) Плохая архитектура

(11) Подскажите, пожалуйста, новоиспеченному программисту, в чем вы видите проблему? Перевозчика в рейс пользователи указывают интерактивно, когда фактически известно кто повезет. А до этого момента нужны примерные плановые расходы, которые считаются только при установке перевозчика, для этого есть фиктивный перевозчик. Чтобы пользователям не проставлять вручную одно и то же в несколько десятков рейсов, я пишу обработку

(12) Что произойдет когда пользователи захотят перепровести документы за месяц например?

(12) Со слова "фикция" начинаются все беды и баги. Программы должны быть честными, как молитвы.

(12) Чем ПустоеЗначение хуже фиктивного перевозчика? :)

(13) Пока не знаю, зачем им может понадобиться перепроводить рейсы... Перевозчика назначают через некоторое время (в течение дня, недели). Если не назначат, то при перепроведении останется фиктивный, уже записанный в регистр, или я не прав?

(15) Плановые расходы по рейсу рассчитываются из номера тарифа, который указывается в соглашении, которое заключается с перевозчиком. Считаю что проще указать фиктивного перевозчика с неким тарифом, чем переписывать логику формирования расходов

(17) Вы Ваше "считаю" согласовали с аналитиками, архитекторами, пользователями?

(18) Если бы в нашей организации были аналитики и архитекторы, я бы сюда не писал :) А пользователи сами и попросили это

(19) Тогда Вы сами себя назначили архитектором и Вам самим расхлёбывать последствия Ваших решений. Можете считать как Вам угодно. Можете загонять фиктивные значения в регистры, редактировать их внешними обработками, короче творить любую дичь с базой и конфой. Только имейте в виду, что всё записывается в этот долбанный блокчейн и другой программист обязательно наткнётся на Ваш программный код, на Ваши архитектурные решения. И вот тогда он выйдет на Вас...