Отчет по дефициту материалов для готовой продукции УНФ

Конфигурация: Управление нашей фирмой (1.6.18.98)

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

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

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

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

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

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

P.S. Написал много, но по сути тут требования, которые для опытного программиста само собой разумеющиеся. Это защита от кривой реализации, поэтому все нюансы прописал в ТЗ. Надеюсь, не задел ничьих чувств )