Мой вариант решения. Приходная накладная есть, ее не может не быть. Единый запрос в расходной накладной, и один проход. Отчет с макетом.
Основные недостатки на мой нетребовательный взгляд:
1. Везде отсутствуют индексы во временных таблицах. Это ошибка.
2. Приходная накладная - в таблицу движений регистра попадают дубли строк табличной части. Нет группировки.
3. Заказ покупателя - тоже самое. Проверка на превышение резерва над количеством в заказе реализована с выгрузкой в ТЗ. Это ошибка.
Тут достаточно обойти строки ТЧ в цикле и сравнить резерв и количество. Выдать ошибку. Группировать не надо - это не формирование движений. Да и необходимость для пользователя в одной строке указать резерв больше заказа и в другой меньше, да так чтобы в сумме было все ок, весьма сомнительна. Ради этого выгружать в ТЗ - экзаменатору не объясните, ведь можно было этого избежать.
Очень сомнительно использовать соединение с таблицей справочника номенклатура для получения представления ссылки на элемент этого справочника. Есть функция ПРЕДСТАВЛЕНИЕ языка запросов 1С, которую можно использовать для получения представления ссылки, есть в конце концов значение, получаемое через точку от ссылки - Ссылка.Представление. Они немного по разному работают, но все же.
4. Расходная накладная. Ввод на основании реализован так же с выгрузкой в ТЗ, ошибка. На экзамене нужно этого по максимуму избегать, если не можете необходимость выгрузки аргументировать.
Регистр "Резервы"Использована традиционная методика проведения, а нужна новая. Поэтому записывать пустой набор в этот регистр тоже излишне.
Для формирования движений данные из регистра не нужны. Их можно получить уже после записи и осуществить контроль отрицательных остатков. Причем тут даже отказа не будет.
В реализованном Вами решении Количество пишется равное количеству в резерве, однако списываться может и меньшее количество товара, те по заказу может оставаться товар в резерве после списания расходной накладной.
Регистр Остатки Блокировка по складу на мой взгляд не нужна. Да, в этом случае заблокируется меньше записей РН, однако необходимо получить общий остаток по всем складам и вычислить свободный остаток перед формированием движений документа. Это соображение приводит к тому, что необходимо блокировать все записи с номенклатурой из ТЧ по всем складам. Потому что конкурирующая транзакция может изменить остаток на другом складе, таким образом изменится и свободный остаток, чего нам допустить нельзя.
Вы интересно реализовали условие по расходной, которая может быть введена только на основании заказа покупателя. В форме обрабатывается событие изменения поля ввода ЗаказКлиента. Однако при беглом осмотре в режиме исполнения в заказе кнопки "создать на основании" не нашел, а в расходной нашел. При чем создается заказ на основании расходной накладной.
Я просто запретил пользователю редактировать это поле и добавлять строки в табличную часть. Реализацию можно ввести только на основании заказа.
Вроде все написал. Работоспособность самого решения не проверял, смотрел только код и конфигурацию.