Добрый день!
Суть задачи в том что в процедуре "ПриЗаписи" документа "ЗаказКлиента" если по определенным условиям Отказ становится равен Истина - делать запись об этом в определенный регистр сведений (режим записи - независимый).
Так как "ПриЗаписи" работает в "неявной транзации", запись которую я формирую программно в регистр сведений откатывается.
Вопрос: Каким образом можно решить такую ситуацию?

тему что-то криво написал, сори.

а что за задача прикладная? зачемп писать в регистр?

В регистр необходимо фиксировать данные о том, что заказ не смог "влезть" в доставку.
Условно в день мы можем принять 1 тонну, принято 990 кг, поступил заказ на 200 кг, отвезти мы его уже не можем так как превышается лимит.
Пользователю выводится сообщение с ошибкой, заказ не проводится.  
Информацию необходимо зафиксировать для того чтобы в дальнейшем отобразить ее в отчетах.

Делай проверку и запись в ОбработкаПроверкиЗаполнения

(4) могут быть уже не актуальные данные

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

если эта работа исключительно в форме документа то можно сделать проверку ПередЗаписью формы
там транзакция еще не началась

(7) Все получилось после того как перенес свои проверки в модуль форму в процедуру передЗаписьюНаСервере. Спасибо! Буду тестировать!
Всем большое спасибо за помощь.

(0)
Пиши в ФоновомЗадании

Уважаемые, в итоге сегодня я продолжил работу над задачей и понял что перенесение данного кода в модуль формы мне не подходит, т.к. необходимо чтобы механизм отрабатывал не только когда зашли в заказ и провели, а также когда он проводится из формы списка, любого рабочего места и т.д.
Взгрустнул. (9) В фоновом задании я не могу фиксировать момент, когда у нас заказ не влез в доставку.

в (4) же дали ответ https://its.1c.ru/db/pubdevguide83/content/612/hdoc

правда обработка проверки может сработать не только при попытке записи

не пробовал, но возможно прокатит передать запись в регистр веб-сервису, опубликованного к этой же базе.

(10) //В фоновом задании я не могу фиксировать момент, когда у нас заказ не влез в доставку.
Почему? В "ПриЗаписи" ставишь условие ограничения, если оно срабатывает: Отказ = Истина и запускаешь фоновое задание на запись в РС с нужными параметрами. При откате транзакции, фоновое отработает.

(11) Следует учитывать, что обработчик ОбработкаПроверкиЗаполнения вызывается не при каждой записи объекта, в частности, он не вызывается в случаях если запись были инициирована программно. - https://its.1c.ru/db/v8std#content:463:hdoc

(3) "Пользователю выводится сообщение с ошибкой, заказ не проводится" // Вот в форме ПередЗаписьюНаСервере и делай

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

Хотя ФЗ попахивает костылём

(3) "Пользователю выводится сообщение с ошибкой, заказ не проводится. Информацию необходимо зафиксировать для того чтобы в дальнейшем отобразить ее в отчетах."
А дальше что пользователь делает с заказом?

(3) Типовая конфигурация? Какая? Какая версия?

(16) Технически это нереализуемо без внешнего контура контроля

(20) почему не реализуемо?

(21) Потому что ФЗ - увы - ненадежный механизм

Писать в файлик или во внешний сервис.

(22) в чем конкретно заключается ненадежность? Или ты ответишь как в ветке про инвестиции "может случиться что угодно"?

В транзакции невозможно писать в базу данных факт отмены транзакции.
Вариантов только два: либо писать не в транзакции, либо не в базу данных. Во всяком случае не в базу данных 1С.
Из нативного - проще всего представляется писать в ЖР, а в регистр сведений перебрасывать по регламенту.

Я спрашиваю про надёжность получения факта успешного завершения фз

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

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

(28) ты чему это?

Под технологией я подразумеваю например подсистему формирования отгрузок в ут11 или в ерп. Где не нужно искать способ обойти транзакцию итп

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

(3) Не нужно устанавливать Отказ = Истина.
Делай свои проверки в процедуре модуля объекта ПередЗаписью()
Если проверка не пройдена то:
1) РежимЗаписи = РежимЗаписиДокумента.Запись;
2) Записываешь инфу в твой регистр сведений
3) Выводишь сообщение пользователю

(31) ты упрощаешь и не берешь во внимание весь процесс, а именно то, что поступивший заказ не был обработан

(33) + и вопрос там не про транзакции а про заказы и отгрузки

ПередЗаписью() запиши в регистр сведений информацию об ошибке
После проведения удали эти записи, если все прошло нормально

(24) Отмена программно - без гарантии. Выполнение - тоже.

+(36) Выполнение = статус имеет выполнено, а по факту - код даже не выполнялся.
Поэтому нужен внешний контроль там, где нужна гарантия.

(37) по какому факту? ты о чем? хотя можешь не отвечать, точнее отвечать не нужно.

(33) Возможно я не до конца понял изначальную задачу ТС и обобщил не в ту степь. Если у него в статусы заказов упирается и причины отказа, тогда это тупо реквизитами заказа можно завести и в ПередЗаписью все просчитывать.

(39) Конфликт блокировок перед записью не просчитаешь.

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

(40) Так я тоже сначала повелся на то, что ТС нужна статистика отказов. А на самом деле он бизнес-процесс пытается выстроить. Читай (3)

(42) Ты прав, ПередЗаписью.