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

2) Делать статусы и менять статус по мере отработки каждого вида документа, и как следствие учить обработку продолжать работу адекватно с любого статуса.

Сейчас склоняюсь больше к первому варианту, но хотелось бы услышать мнение более умных людей о том, как лучше решать подобную проблему. (На тему посмотри как делает типовая: типовая поступает правильно и не делает цепочку документов, ну или я не смог найти подобного примера :( )

1. Транзакция.
Для этого и придумана, не вижу смысла изобретать что-то новое, если тем более нет промежутка во времени между созданием документов, сразу вся цепочка.
Если есть промежутки - тут можно бизнесс-процесс замутить какой-нибудь

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

В данной транзакции уже происходили ошибки...

если важна цепочка документов - то Вам к "последовательностям"

то есть
1. обработка "все хорошо" в одной транзакции
2. все документы регистрируем в новой последовательности
3. делаем регламент востановления последовательности для корректной обработки измений задним числом
4. делаем регламент оповещения по почте "все плохо", в случае если неактуальная последовательность не востанавливалась более Х часов

(0) или стоит отказаться от всех документов и заменить их одним - корректировкой записей Рг

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

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

(5) сможет. Но защита от вандализма пользователей - это отдельная песня, в данном случае я не пытаюсь решить подобную проблему. Цель, чтобы обработка сама по себе выдерживала пользователя, который не умеет читать сообщения, а не загоняла себя в состояние, когда без помощи специалиста и лома её к жизни не вернуть.

(7) *и не загоняла себя

(7) Автоматически создаваемые цепочки документов - это зло. Если можно обойтись без этого - то лучше обойтись, и делать всё одним документом.

(9) Не спорю и даже полностью согласен, что цепочки - это зло.  Ибо уже сталкивался с их реализациями и успел наплеваться. Но я пока не уверен, что написать свой документ, заменяющий цепочку из 3х типовых - это оправданно. Особенно с учетом, что  есть желание сохранить поддержку конфигурации.

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

Спасибо всем большое.

если на стене висит ружье, значит оно выстрелет....

варианта два для получения отказоустойчивости

1. делаешь Один документ с разными статусами и всю логику обработки вносишь внутрь документа
2. делаешь несколько документов и к ним последовательность с механизмом контроля

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

(13) 3. Пишешь все в одной транзацкции и не паришься со статусами и последовательностями

(14) а потом приходит студент из франя и тупо лезет в заднее число и правит пару доков :)

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

(15) Зависит от задачи. Если задача просто создать документы в определенной последовательности, то не нужно ничего городить. А если важно влияние в учете одних документов на другие, то да.