Добрый день.

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

(0)Дык если записи не было, то и события нет.
Зачем оно вам ?

Если документ не записался - то откуда возьмётся ПослеЗаписи() ?
finally в 1с пока нет...

(1), в процессе записи происходят проверки. И подробные данные о результатах этих проверок хранятся в ДопСвойствах.
Нужно после попытки записи (даже неудачной) эти данные получить и сохранить в данных формы

(3) зачем? что делать когда проведение будет из списка вызвано или вообще не интерактивно?

(4) Очевидно же - запишет в ЖР. А вот если из формы, то красиво хочет показать пользователю.

(5) показать пользователю и так можно
СообщениеПользователю никто не отменял

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

(5), это не сообщения, а структура с данными, которые потом отображаются пользователю

(3)Ну и пиши эту хрень в ПриЗаписи куда нужно, если ошибка..Нафига после ?

(9) Так если ПриЗаписи отвалится, так и транзакция тоже )))
Куда предлагаешь писать?

(10) в файл

(11), мне эти данные нужны на время существования формы документа. Зачем в файл писать? 0_о

(12) тогда показывай сообщение

или пихай в оповещение

как сделано, например во всех типовых при печати чека

оповещение из модуля объекта не отправить

(15), оповещение из модуля объекта?

пока что придумал только один вариант - передавать в параметры записи адрес хранилища, в которое помещать нужные данные.
А ПередЗаписью подключать обработчик ожидания, который сработает после записи и получит результат из хранилища...
Не факт что сработает))

А почему обработка идет именно после, а не при или перед?
Там что, данные сильно меняются?

А ты, если видишь что это интерактивная запись - не отказывайся от нее :) Тогда сможешь словить ПриЗаписиНаСервере(), обработать все что надо и отказаться уже там.
А адрес временного хранилища для своей структуры пихай в доп-свойства в ПередЗаписьюНаСервере()

Хотя о чем это я? Не надо хранилища. Ты ж в ПриЗаписиНаСервере прямо доп-свойства и поймаешь.

(19) Бывает так, что проверка очень "тяжелая" и получение всех нужных данных требует почти дублирования всего алгоритма проведения.

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

(18) жди, скоро может будет готов "сервер оповещений", там хоть что хоть куда послать можно

(22) Да эт понятно.
А вот зачем показывать что-то кроме ошибки при неудачной записи, не понимаю.

(25), пользователям нужен более подробный отчет. Данные для него уже собраны на этапе записи документа. Чтобы не собирать данные повторно, я их передаю через ДополнительныеСвойства.

(26) Так при отказе и показывай их, как вариант.
А так, да. Событий для показа чего-то нет. Обработчик вариант, конечно, но только если они форму раньше не закроют.

1. не делать отказ в ПриЗаписи()
2. разбирать доп.параметры в данные формы в ПриЗаписиНаСервере()
3. делать отказ в ПриЗаписиНаСервере() если доп.параметры соответствующим образом заполнены

полная, правильная реализация, даже без учета ограничения (7), такая

Процедура ПередЗаписьюНаСервере(...)
  ТекущийОбъект.ДополнительныеСвойства.Вставить("Отказ", Ложь);
КонецПроцедуры

Процедура ПриЗаписи(...)
  //тут необходимые проверки
  Если ПроверкиНеПройдены Тогда
    Если ДополнительныеСвойства.Свойство("Отказ") Тогда
      //заполнить другие ДополнительныеСвойства для передачи в форму
      //если из формы, то отказа будет там
      ДополнительныеСвойства.Отказ = Истина;
    Иначе
      //если не из формы, то отказ будет тут
      Отказ = Истина;
    КонецЕсли
  КонецЕсли
КонецПроцедуры

Процедура ПриЗаписиНаСервере(...)
  Отказ = ТекущийОбъект.ДополнительныеСвойства.Отказ;
  //перекладываем в форму другие ДополнительныеСвойства
КонецПроцедуры

ну и раз это документ, то, при наличии проведения, нужно его проскочить

Процедура ОбработкаПроведения()
  Если ДополнительныеСвойства.Свойство("Отказ") И ДополнительныеСвойства.Отказ Тогда
    Возврат;
  КонецЕсли

  //далее проведение
КонецПроцедуры

(20), (28), Спасибо за решение!
Проверил, всё гуд работает.

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

(32) "теперь бизнес-данные хотя и косвенно зависят от представления"
это так, но ТС этого и надо

(32) Критикуя - предлагай :)

(32) "то есть надо всегда помнить, про этот самый параметр"
А зачем помнить

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

С другой стороны, контекст объекта не зависит от этого свойства. Если объект его не учтет, то объекту это не помешает. А если форма "забудет" ему его дать, то код написан, в этом смысле, безопасно.

(35) ПриЗаписи вообще убрать нельзя, только с условием по параметру
ибо может быть проведение не из формы

(36) кто-то предлагает ПриЗаписи убрать?

(38) >>1. не делать отказ в ПриЗаписи()

(38) Не делать отказ - с целью добраться до ПриЗаписиНаСервере
Да, "не делать отказ" - параметрическое поведение. Код приведен в (29)

Запись/Проведение не из формы никак не пострадает
Запись/Проведение никак не пострадает если форма забудет сформировать параметр

(39) согласен, норма вариант
единственное в новых типовых стали бросать исключения, когда в проведении что-то пошло не так

(30) Угу, а потом еще "проскочить" все подписки на событие проведения, которые не анализируют Отказ, а молча делают свое дело :)

(39) Если в очередной момент забудут о том, что модуле документа нужно не Отказ ставить при интерактивном проведении, а ДополнительныеСвойства.Отказ - то форма перестанет ловить событие и красиво формировать отчет об ошибках. Неудобненько. Особенно учитывая, что это стопудово будет плавающей проблемой. Но все равно лучше вариантов не проглядывается.
(41) Ихнее молчаливое дело спокойно откатится в итоге. Тут проблемы нет.

(41) полезно было бы услышать альтернативные возможности

(42) не подготовил свойство - не получил "красивость". Все эта зависимость остается контексте одной формы. Норм же

(42) "Тут проблемы нет" // Ну, на самом деле есть, когда из формы начнут по пессимистичному сценарию проводить много разных сеансов. Удлиняем транзакцию и сопутствующие блокировки, когда могли бы сразу отлуп до обработок проведения выдать.
Случай редкий, конечно, т.к. ожидаемый сценарий оптимистичный все-таки, но все-таки такое интерфейсное ублажение - это лишняя трата мозготоплива - приходится помнить про этот нюанс.

(42) "Ихнее молчаливое дело" может зависеть от проведения которого не случилось, следовательно, что может пойти не так и привести к исключению

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

Т.е., повторюсь, решение не безболезненное и поэтому неуниверсальное :(

(46) Это так. Но у ТС вряд ли будет пропуск проведения, как ты предполагаешь. Если бы нужные проверки можно было бы сделать без проведения, то и весь этот сыр-бор не нужен был. Т.е. вероятность исключения все равно остается, но она хотя бы не невелика. Тут уже ничего не поделаешь.

"хотя бы невелика"

(48) Да. Но вполне приемлемо, ИМХО, в отсутствие альтернатив.

(47) "то надо куда-нибудь с кем-нибудь этой инфой поделиться"
Ну если эту "дележку инфой" делать в рамках транзакции, при этом эта "дележка" не откатываема, то - тоже не фонтан

(47) А вот это вполне реальный вариант, при котором будет очень больно.

(52) Ну а как еще организовать распределенную транзакцию между разными системами без брокера (как чаще всего и делается в 1С)? В какой-то момент приходится полагаться на то, что раз до последнего момента исключения нет, то транзакция завершена успешно.

(53) нельзя делится "грязными" данными из транзакции. Это даже без обсуждаемого бантика

(49) "Если бы нужные проверки можно было бы сделать без проведения, то и весь этот сыр-бор не нужен был" // Погоди, так предлагаемый сыр-бор в (28) вроде как раз и предполагает, что проверки только до обработки проведения сделаны.
Т.е. он не учитывает кейс, когда надо при отлупе в обработке проведения протащить это в форму.

(56) Сама идея это учитывает как раз. trad это как опцию протащил.

(55) Пример не единственный. Просто факт остается фактом: мы скрываем от последующего кода флаг Отказа, и про это надо потом всегда помнить

(54) слишком глубоко. Думать нужно в конкретной обстановке

(57) Ну т.е. если без обработки проведения никак, то нужно не в ПриЗаписи, а в ОбработкеПроведения городить эти доп. свойства и пропуск взвода Отказа, так?

(60) " не в ПриЗаписи, а в ОбработкеПроведения "
Это зависит от характера проверок у ТС. Этого нам не известно

(60) Да. Придется заменять все Отказ = Истина на какой-нить ОтказатьсяОтЗаписи().

+(56) И ведь еще веселее будет, когда ты Отказ скрыл в ПриЗаписи, а в ОбработкахПроведения его типовой код все-таки взвел.
Все, в форму ничего не придет в таком случае же, т.е. схема разрушилась?

Но ТС и так уже что-то подобное делает, так как во всех точках отказа собирает инфу для последующего отображения.

(62) Вот и я про то же в (63) :)

(63) ну да, ОбработкахПроведения нужно подгонять под правила принятые в данном контексте.
Я выше писал, что функциональности в одном контексте должны же играть по общим правилам

(63) Да. Любой "нелегальный" отказ приведет к необработке события. Но это можно захачить в последней подписке :) Типа если Отказ, а проведение интерактивное, то "отказываемся от отказа" и пишем инфу про необработанную ошибку, чтобы вовремя исправить.

(67) "Но это можно захачить в последней подписке :)" // А потом добавят еще одну подписку... или поменяют последовательность их выполнения

(66) Ну вот и возвращаемся к (32) :)

(68) подписку обозвать - СамаяСамаяНаВсеВременаПоследняяПодписка

(69) Угу. А потом к (34)

(69) пожалуй я соскочу

на последок вякну. Подписки эти сами являются источниками (32)

(73) Так можно договориться до того, что весь код должен быть в линейной портянке а все остальное - от лукавого.

я сейчас одну крамольную вещь покажу, только ногами не бейте:

&НаКлиенте
Процедура ПередЗаписью(Отказ, ПараметрыЗаписи)
    
    //ФлагЗаписи - реквизит формы, тип булево
    
    Если Не ФлагЗаписи Тогда
        ФлагЗаписи = Истина;
        Отказ = Истина;
        ВсеХорошо = Истина;
        Попытка
            Записать(ПараметрыЗаписи);                
        Исключение
            Заголовок = "Что-то пошло не так!";    // вот здесь обрабатываем!                    
            ВызватьИсключение;
        КонецПопытки;                    
    Иначе
        ФлагЗаписи = Ложь;
    КонецЕсли;     
    
КонецПроцедуры

(75) Идея понятна. Если не возникнет проблем с пробрасыванием ошибок через временное хранилище - то отличный выход.