Будем считать это чудом (что твой код ты выполняешь для тобою же создаваемого объекта). Обычно установку ссылки нового неокрепшие умы суют в модуль объекта или даже подписку.

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

Поэтому всегда нужно - когда устанавливаешь ссылку нового, сначала проверить, а нет ли там уже ее (не установил ли ее кто-то уже ранее).

Согласен, но в моем случае создать задачу с обработкой заполнения конечно можно, но в БП она не попадет, а значит и в этот участок кода (т.к. это обработчик события БП). А если кто ее еще и в ТЧ БП подсунет то такая задача не будет обслужена уже в прикладном коде. Потому безопасно)

Все время забываю, вызывается ли обработка заполнения при программном создании.
А путает меня всегда то, что ПриКопировании - вызывается и при программном копировании.

ну на такую наркоманию я не рассчитываю) там уже есть *переопределяемый. Пусть нарики там играются

Ты и сам можешь наступить потом на эти грабли. Нарик добавит в обработку заполнения установку ссылки нового, а ты потом сам же в свой код и добавишь вызов метода "Заполнить" сразу после "СоздатьОбъект".

А тут точно нужен идентификатор?

не, тут точно нет. Это ж пример. А в жизни мне надо УИД задачи пульнуть в Телеграм. А задача имеется только в таком виде

СсылкаНаМойСправочник.УникальныйИдентификатор()

Я про то что .ПолучитьСсылку() и без принудительной установки сгенирит ссылку. Или вы пихаете в ссылку уид из телеги?

да да, заталкивать УИД я и не планировал. Я здесь так написал чтобы было понятнее какой УИД мне нужен))

В этом кстати основная ошибка во всем этом процессе. Уведомления пользователям рассылаются в транзакции записи БП. А он, сука, ещё ж откатиться может. Но это в планах есть)

То что он может откатиться я бы не считал основной ошибкой. Основной - то что оно вообще происходит в транзакции, даже если вероятность отката исключена.

Если не про код выше (что про уведомления) а о концепции в целом при условии исключенного отката - хрен знает, предмет для диалога. Гора отложенных действий по выходу из транзакции тоже такое себе как по мне. Появляется или очередь на уведомления\действие. Или в после записи куча прикладного говна а не уведомляли ли уже (выполняли ли действие) а точно ли объект новый, а если не новый то изменились ли данные для уведомления\действия и вот вот все

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

А насчет внутри (всегда гарантированно завершающейся) транзакции - такая логика тоже никак технически надежно не реализуется.

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

Ходят слухи, что шина данных поддерживает транзакционность. но я не видел

а кстати что по этому поводу говорят про генерацию ФЗ в транзакции для действий "условно не обязательных"? Ну т.е. я в транзакции поднял ФЗ, сказал уведомить пользователей и больше на это ФЗ не смотрю. Это ок?

Типа получаем техническую возможность поиметь событие "после успешной транзакции"? Но даже если и так, то попытка отправки может не завершиться успешно, а значит все равно нужна хранимая очередь.

Это ок

Значит там моей картинке почти все ок)