Документ в процедуре ПриЗаписи() производит рассылку уведомлений.
Нужно что бы он делал это единожды. И я добавил реквизит типа булево.
Что бы отслеживать его значение.
Где правильно его задавать?
А то как я понял, что если я задаю его в процедуре ПриЗаписи, как, -

                ОтправленоУведомлениеОплачено = Истина;


То значение не сохранается.

В РС

(1) А в реквизит я могу сохранить?

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

(3) тогда я применил отслеживание смены статуса.

И я так понимаю я все же могу сделать проверки и задать значение этого реквизита. Но в процедуре ПередЗаписью(), Верно? Если делать без регистра сведений.

Компания в США закрывает сервис, наши цепляют к нему vpn через Британию и траффик Ливингстара ходит через Буманный альбион при каждой записи документа, а пользователи курят, ведь это erp2.x и автор, ясно дело, накосячил с блокировками...
Судьба

(4) При записи уже транзакция открыта и изменение в объект в этой транзакции не внести.

(6) Я пробую ПередЗаписью() сейчас.

Я понял что ПриЗаписи() не подходит.

ПриЗаписи уже поздно, надо ПередЗаписью

(6) Ну да. Получается что не подходит это. В ПриЗаписи() будет значение уже. и не сработает отправка. С регистром сведений нужно разбираться начинать для этого.

(8) Отправка сделана в ПриЗаписи. Так как там проверяется смена статуса.
Хотя возможно, по количеству Тч, следует перенести отправку из ПриЗаписи() в ПередЗаписью() .

Просто дай нам знать, где ты работаешь, мы поможем.

(11) Работодателю поможем?)

(11) Дима, сорян за оффтоп, стукнись в телегу или глянь в почту плз

(0) У меня стойкое-престойкое чувство Дежа Вю. Опять уведомления, опять при записи...

(14) День сурка немного затянулся)

(15) не день сурка, а ночь охотника)

В процедуре ПередЗаписью() не рекомендуется, или даже нельзя делать отправку?

По этому следунт отдать предпочтение регистру сведений, или можно?

Терпеливый охотник дождется добычи.

(17) Придется "нужно разбираться начинать для этого" с фоновыми заданиями, Стар.

Я хотел остановиться на отправке в процедуре ПередЗаписью(), она происходить будет раз. Вполне же можно?

(20) вам все можно, не переживайте. А по теме, подумайте, что будет если документ попадет в Отказ=Истина ПриПроведении. Нужен ли вам такой документ в отправке?)

(21) **я буду, в прошлый раз ты ему говорил ровно то же самое)

(0) >>Документ в процедуре ПриЗаписи() производит рассылку уведомлений.
После этого детали говнокода можно уже не читать

(22) я ж говорю - день сурка)

(21) >>А по теме, подумайте, что будет если документ попадет в Отказ=Истина ПриПроведении

В принципе, годным решением будет слать ещё одно сообщение в догонку, в котором просить считать первое недействительным. Pro tip

Если хотим быстро и дохер - делаем фоновое в ПриЗаписи. В фоновое отправляем Ссылку и ВерсиюОбъекта, в фоновом раз в секунду смотрим, не изменилась ли Версия в базе. Как изменилась - шлем.
Если хотим долго и нам важна доставка - в ПриЗаписи пишем в РС ссылку и Статус и его регламентным обрабатываем.

Но НочнойОхотник ниасилит

(26) Хреновое решение
Предположим, что почтовый сервер прилег (или еще чего случилось) и ничего не отправилось
А второй попытки отправить уже не будет
Тогда уж писать в регистр сведений, а из него регзаданием отправлять
В ДО так и сделано, кстати

(27) Ну я же написал - что похер, отправилось или нет - делаем как пункт 1.

(28) Так получается, что либо совсем говнокод через отправку в призаписи без всяких ФЗ, либо уж делаем РС и отправку из него РЗ
Второй-то вариант не сложнее твоего

(29) У меня есть решение, когда выполняется 1 варианта в 95% случаев после проведения документа, а потом то, что не обработалось, ночью добирает 2 вариант.

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

(30) В принципе тоже вариант, да, если запускать ФЗ при записи дополнительно, а не по расписанию РЗ

(26) а хорошо ли создавать фоновые задания в транзакции? Не будет ли проседания по скорости?

(33) Это быстро

(33) Мы же их не ждем

У фонового один недостаток - групповое проведение,когда на каждый документ будет создаваться задание,которое будет ждать окончания транзакции.

(26) "Если хотим долго и нам важна доставка" - если важна именно доставка - то план обмена (например, с нестандартной обработкой регистраций изменений и/или сообщений обмена). А в "ОтправленоУведомлениеОплачено"(0) лучше хранить номер сообщения обмена (или после отправки уведомлений, или после подтверждения получения уведомлений).

*(37) Если есть "связка" первоисточника(документа) с его вторичными данными(уведомление) - то необходимо первоначально продумать вариант их взаимодействия между собой. В типовых есть множество таких примеров: документ и его движения; документ и счет-фактура... но мне больше нравится решения подобные типовому функционалу ЗУПа "Документ принят в ПФР".

(35) но подготавливаем, но вещь интенресная, по-моему в типовой УТ тоже распределение запасов так делается