Есть форма объекта справочника (УФ). Основной реквизит - "Объект".
На форме команда "ПодтвердитьСтатус". По команде вызывается клиентская процедура, из которой зовется серверная процедура, в которой уже выполнятся установка статуса:
Объект.Статус = Перечисления.Статус.ОК;

Все нормально отрабатывает, на форме вижу, что статус изменился. Но вот модифицированность формы не устанавливается. Полез искать в чем может быть дело.
Нашел на ИТС https://its.1c.ru/db/metod8dev#content:2206:hdoc
Судя по статье, модифицированность должна ставится. Поставил последний релиз движка (8.3.27.1859). Там все так же.
Если на команде поставить галку "Изменяет сохраняемые данные", то модифицированность устанавливается, но такое решение не подходит для общего случая (статус по команде может и не меняться при заданных условиях).

Что я делаю не так?

установи модифицированность= истина, делов то?

(0) А после установки статуса запись объекта не происходит?

(0) Согласно статьи не так. Сам устанавливай.

(0) "статус по команде может и не меняться при заданных условиях"
значит делай (1), без вариантов

(0)

Открыл типовой код "ЗаказКлиента" ФормаДокумента

Модифицированность = Истина;

Раскидано как грязи.

(0) для начала статья для ОФ, ну и да, пиши модифицированность= истина

2(1)(4) Есть более сложные сценарии, хотелось бы понять почему встроенный механизм не работает.
2(2) Нет, конечно. Только присвоение статуса.
2(3) Как это "не так"?

2(5) Это какой-то... позор...

2(6) Более свежего не нашел.

(7) "Есть более сложные сценарии, хотелось бы понять почему встроенный механизм не работает. "

нуу, потому-что гладиолус

https://wiki.kint.ru/index.php/%D0%9A%D0%B0%D0%BA_%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%B8%D1%82%D1%8C_%D0%BF%D1%80%D0%B8%D0%B7%D0%BD%D0%B0%D0%BA_%D0%BC%D0%BE%D0%B4%D0%B8%D1%84%D0%B8%D1%86%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D1%84%D0%BE%D1%80%D0%BC%D1%8B_(1cv82)?ysclid=mhvxpei1yu689127690
Почему не меняется модифицированность УФ при изменении ТЧ программно&ysclid=mhvxnowhob89145961

(7) "встроенный механизм не работает"
Работает. На ручные изменения из формы и вызов команд с признаком "Изменяет сохраняемые данные". Ты сам заявил, что в эти сценарии не попадаешь.
Никакого позора. Штатное поведение.

2(10) Где это штатное поведение описано? Я нашел только вот эту приведенную с ИСТ информацию от 1С.
Если на команде поставить "Изменяет сохраняемые данные", то при вызове этой команды будет установлена модифицированность даже если ничего не меняется. Поэтому не подходит.
Ставить везде явное изменение модифицированности - это реально маразм какой-то.

2(9) В последней ссылке последний коммент как раз и предполагает, что признак должен автоматически выставляться системой.

(11) Почему маразм?
Тыжпрограммист - управляй кодом, а платформа отслеживает действия пользователя. Всё логично.

2(13) Потому что система знает, что объект изменен. Сообщать ей дополнительно, что форма, к которой относится этот объект,  изменена - маразм. Получается типа мы меняем объект, у которого стоит признак "Сохраняемые данные", но механизм автоматического вопроса о сохранении не включаем. Много есть сценариев, когда нам эти изменения в сохраняемых данных не надо сохранять?

(11)

это общеизвестно
или цель ветки намекнуть, что документация 1с (о ужас) несовершенна?

И все-таки это скорее ошибка архитектуры платформы. Но это моё мнение

2(15) Цель ветки была - узнать что я неправильно делаю.
А общеизвестный глюк системы - все же несколько не "штатное поведение".

(14) В УФ все несколько сложней
Объект и открытая форма это разные вещи
Изменение объекта != Изменение данных формы

Короче да поведение платформы в данном случае выглядит нелогично
Приходится самостоятельно заботиться об установке флага модифицированности формы
Но иначе пришлось бы делать некий механизм чтобы наоборот не взводить в некоторых случая модифицированность, при программном изменении кодом а не интерактивном пользователем

А если серьезно то в 1С наворочено куча всего
Чего в других системах и языках/фреймворках тупо нет
Ту же модифицированность на настоящих ЯП придется реализовывать самому
И с большими геморами

(18) тогда нужен пример, в котором требуется не взводить модифицированность при программном изменении основного объекта

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

я к чему? я бы свойства ПриИзменении вообще бы перенес в объект с формы

(20) Неправильное восприятие
Объект на форме - это по сути ссылка (или ее отсутствие) на объект в СУБД
И некие данные формы (которые ничем не отличаются от обычных реквизитов формы) в которых содержатся последние считанные данные объекта СУБД

Модифицированность по идее показывает отличие данных объекта формы от данных объекта СУБД
И никак не влияет (не связана) на просто реквизиты формы

ПриИзменении - это именно событие формы
У объекта СУБД есть только ПриЗаписи, с различием новый или нет

Короче надо воспринимать это как есть
Разработчики платформы долго думали и решили что так будет логичней и правильней

И пока оно работает - его не будут трогать/менять

(7) так у тебя при этом никакое поле не связано с этим реквизитом.

(21) ну вот поэтому оно и так. 1С всю бизнес-логику запихало в формы по сути
А тот же заказ клиента прилетает с http-сервиса и вы всю логику заполнения повторяете

2(23) В реальном коде так:
&НаСервере
Процедура КомандаПодтвердитьДоговорНаСервере()
    Объект.СтатусДоговора = Перечисления.СтатусДоговора.Подтвержден;
    НоваяСтрокаЛога = Объект.ЛогПодтверждения.Добавить();
    НоваяСтрокаЛога.Сотрудник        = ПараметрыСеанса.глТекПользователь;
    НоваяСтрокаЛога.ДатаДействия    = ТекущаяДата();
    НоваяСтрокаЛога.Действие        = "Подтвержден";
    Элементы.КомандаПодтвердитьДоговор.Видимость = Ложь;
КонецПроцедуры

&НаКлиенте
Процедура КомандаПодтвердитьДоговор(Команда)
    КомандаПодтвердитьДоговорНаСервере();
КонецПроцедуры

СтатусДоговора выведен на форму в поле с типом "Поле надписи", табличная часть ЛогПодтверждения выведена на форму в виде таблицы с установленным крыжиком "Только просмотр".

Это сильно меняет контекст проблемы?

(20) "А в чем разница интерактивно и программно?"

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

2(26) Программист поменял скрытые реквизиты, пользователь закрыл форму, вопрос о сохранении модифицированных данных не возник, реквизиты не сохранились. Зачем менял?

(26) если вы их поменяли, вы их записывать субд не будете? А зачем меняли?
И да, если такой сценарий есть - напишите пожалуйста

(27) чтобы они записались при условии, что пользователь запишет объект.
Короче возможность управлять флагом модифицированности однозначно фича, а не баг. Поведение абсолютно логичное.

(27) А точно нигде модифицированность не скидывается?
А точно нигде нет Записать()?
А точно после закрытия статус не сохраняется?

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

(8) https://its.1c.ru/db/v8327doc#bookmark:dev:TI000000396