В идеале все проверки при записи/проведении объектов нужно делать в подписках на события или в обработчиках объекта. Делать это же в формах неверно ввиду того, что у объектов может быть множество форм. У меня не укладывается в голове как можно использовать эту прописную истину в клиент-серверном варианте работы на управляемых формах - эти обработчики отрабатывают на стороне сервера с которого возможность взаимодействия с формами отсутствует.
Допустим сообщения можно положить в регистр сведений, но как уведомить форму о событии на сервере?

(0) Интерактив при проведении - это же так замечательно. Особенно когда запускается проведение 100500 документов обработкой.
Слава Будде, что 1С это запретило, но всегда находятся ценители...

(0) ОбщегоНазначенияКлиентСервер.СообщитьПользователю( в обработке выдаст сообщение пользователю после возвращения с сервера. А если еще и ключи проставить, то будет облако около нужного элемента в управляемом режиме

(1) фигню сказал - всегда можно предусмотреть временное отключение любого механизма при массовой обработке. например обмен данными.

(2) сообщить пользователю выводит сообщения категории ошибок, что не всегда требуется.

(4) ну если не требуется, не выводи

+ СообщениеПользователю конечно можно использовать если у запрпрет категорический, а если запрет не категорический?

как уведомить о потенциальной ошибке с подтверждением действия?

(6) на сервере не должно быть не категорических запретов. Или транзакция выполняется или откатывается, промежуточных состояний нет

(7) ПоказатьВопрос()

(9) чисто клиентская фишка

(10) естественно, а от кого ты на сервере ждешь "подтверждения действия"??

(8) давайте рассмотрим такой случай: транзакция откатывается с вопросом. при утвердительном ответе помещаем в дополнительныеСвойства объекта Флаг и повторяем транзакцию с фиксацией

(11) как ты на клиенте получишь ответ от сервера и задашь вопрос?

(12) а что мешает все узнать до того, как мучать сервер? И флаг не нужен, а в дополнительные свойства кладем уже правильный ответ

+ чтобы получить ответ от сервера на клиенте сначала нужно вызвать этот самый сервер с клиента. НО события модуля объекта с клиента не вызываются!

(3) Фигня в (0) описана. Хочешь интерактива - для этого есть формы. Много форм - нам искренне жаль тебя, честно.

(14) приходим к 0 - форма это не то место где должны выполняться проверки!!!

(15) И это правильно. Привыкай к логике клиент-серверной работы.

(17) почему? религия?

(17) А сервер - это не то место, где надо задавать вопросы пользователю.

(17) форма это то место, где происходит весь интерактив

(19) потому что для этого предназначены обработчики модуля объекта или подписки

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

(22) проверки, требующие ответа пользователя должны делаться в формах, и неважно где будет располагаться сама процедура проверки

(22) Сам придумал?

(24) если говорить про документы, то место где должны выполняться все проверки это обработка проведения документа.

(23) Механизмы взаимодействия клиента и сервера есть. Осталось дело за малым: изучить их.

(26) Ну и проверяй там, кто мешает то?

(26) заполнение реквизитов документа тоже?

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

(23) Механизм оповещения клиента с сервера мог бы быть приятной плюшечкой. Но и без него всё можно организовать лёгким движением руки. И ты в (12) сам написал что нужно сделать: Запускаешь проведение - получаешь отказ, на клиенте задаёшь вопрос, устанавливаешь нужные флаги и снова запускаешь проведение.

Это ты ещё с немодальностью не сталкивался плотно.

(31) значит мыслил я все же в нужном направлении. исключение на клиенте обработать можно. но как вернуть статус из обработки проведения? регистр сведений? еще механизмы?

+ с немодальностью вроде ничего сложного. опеделяешь процедуру обработчика и все.

(32) регистр сведений отпадает. При откате транзакции он возвратится в исходное состояние.

временное хранилище?

(32) Дополнительные свойства объекта, например.

Объект.ДополнительныеСвойства.Вставить("ЗаписьБезПроверок", Ложь);
Попытка
  Объект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
  РезультатПроведения = Объект.ДополнительныеСвойства.РезультатПроведения;
КонецПопытки

+Приведу еще один довод почему я считаю правильным выполнять проверку в обработке проведения - в соответствии с концепцией проведения сначала проводим, потом контролируем остатки лучшего места для выполнения проверки просто не найти.

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

(31) КАК отловить на форме результат проведения? так же выяснилось что есть проблема анализа формой результата выполнения проведения - так обработчики событий формы ПриЗаписиНаСервере, ПослеЗаписиНаСервере, ПослеЗаписи (клиент) не срабатывают при отмене транзакции проведения (Отказ = истина). Таким образом стандартно на форме никак нельзя узнать на клиенте когда и чем завершилась попытка проведения объекта.
Так, можно было бы красиво решить задачу если передавать в ДополнительныеПараметры объекта ПередЗаписьюНаСервере флага интерактивного проведения. В модуле объекта проверять наличие этого флага и возвращать в тех же ДополнительныхПараметрах дополнительной информации для анализа и взаимодействия с пользователем на клиенте. В обработчике ПослеЗаписиНаСервере результат поместить в реквизит формы, а из обработчика ПослеЗаписи (клиент) проверяя соответствующие реквизиты формы задавать необходимые вопросы.

37+ при такой реализации не возникает проблем при массовом проведении документов - флаг интерактивности отсутствует.

Как вариант напрашивается решение выполнять отказ от проведения на клиенте в обработчике ПослеЗаписиНаСервере

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

(37)и? - если остатков не хватает, тут же задаем пользователю вопрос "ну и х... с ними?" - контроль остатков обычно безусловно запрещает проведение

(40) вы не поняли сути вопроса - никаких вопросов в транзакции

(41) ключевое слово "обычно"

Вариант отказа на форме "не взлетел" - если отказываться в серверном обработчике формы ПриЗаписиНаСервере клиентский обработчик формы ПослеЗаписи где можно было бы организовать интерактивную работу попросту так же не отрабатывает(((

Может у кого еще есть мысли как отловить на клиенте результат проведения???

Единственное что остается - делать распроведение из ПослеЗаписи(((

А чем обычное сообщение то не устраивает?

(45) правильно в форме перед записью. Несколько форм - сделай функцию в общем модуле

А. Теперь понял что автор хочет. В кратце - это не здорово даже чисто с медицинской точки зрения.

(48)  То, что в форме нельзя поймать отмену транзакции - тоже нездорово, как ни крути.

Баг платформы?
Интересно в 1С кто-нибудь обращался с подобным вопросом?

(49) Почему нельзя? Очень даже можно.

(51) нашел?

(52) Что нашёл?

(50) Это не баг. Записи же не было.
(51) Как?

(54) При помощи мегаизвратов, естественно, но тем не менее, при сильном желании можно.

(55) Ну и каким мегаизвратом можно в форме поймать событие отката транзакции записи? Обработкой ожидания?

(56) Как вариант. Но правильнее всего будет строить алгоритм работы программы под клиент-серверный вариант, при котором это будет не нужно.

Это болезнь всего софта целой эпохи от доса и до сих пор (уходит на убыль).
Компьютерщики, фантазирующие об искусственном интеллекте представляли (и реализовывали) программу как диалог между человеком и компьютером. Отсюда все эти окошки в которых почти-как-живой-компьютер на "Вы" спрашивает пользователя о дальнейших действиях, словно лакей, ожидающий приказаний. "Вы точно хотите скопировать этот файл?"

А оказывается на самом деле пользователю удобнее общаться со своими материалами без посредников. Карандаш не задает вопросов. Так что нахер посредников. Нахер диалоги.

(57) а на этой фразе у вас было сильно многозначительное выражение лица???

(57)(58) Знакомые песни. А когда 1С реализует это в очередном релизе, будете с умным видом кивать и говорить как это бывает полезно в отдельно взятых случаях.

(60) В смысле знакомые песни? Я это знал ещё с института, когда изучали клиент-серверные системы. И речи об 1С там и близко не было :))

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

(62) Клиенту не нужен прогресс-бар. Клиенту нужна программа, в которой нет необходимости вообще видеть прогресс-бары. И ждать выполнения тоже.

(63) Клиенту не нужна программа. Клиенту нужно, чтобы всё само.

И желательно вчера.

(64) Ты правильно уловил мою мысль

Твоя мысль меня никак не греет, потому как мы тут больше о реальном мире.

(67) О реальном мире или таки об 1с?

(68) да Вы таким макаром далеко щас зайдете

(69) Я макаром не хожу... Я обычно хожу ногами...

(70) это пока))

что до меня, то я более чем уверен, что механизм появится