ИМХО, удобно юзать справочник товаров организованный в виде дерева. Где узлями дерева могут быть как сами группы товаров - так и особый вид - Сборка (комплектующих). Тогда, прикладной интерфейс формирования табличной части СЧЕТА, легко поймет - что в некой строке счета, указан ID товара - что есть собственно сборка. И при необходимости - найдет, например цены комплектующих и сделает расчет цены комплекта.

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

Деревяшка позволит легко делать Сборку_на_сборку. Дополнительно, я уже "проповедовал" идею хранения в деревяшке ССЫЛОК (линков...ярлыков) на другие элементы деревяшки....при помощи дополнительноко Поля БД. В данном случае, это позволит из единого списка комплектующих - сочинять разные Сборки.

Если я правильно понял - это для постоянных комплектов.

Да, безусловно. Касательно переменных - то тут некуда не деться, их надо описывать "на лету", с хранением описалово в прикладной таблице БД.
1 вариант - строки счета - тоже узлы дерева ..в пределах одного счета...
при этом,
узел (имя комплекта) имеет атрибут - кол-во, цена,стоимость
строка (элемент комплекта) имеет атрибут кол-во, цена,стоимость
2 вариант - допол_таблица перекрестных ссылок - хранит в себе Номера строк счета + имя комплекта. (

По видимому,1 вариант более выгоден тем что всегда имеется :

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

2 вариант выгоден тем, что для внедрения учета - "в старой системе отчетов" не надо ни че менять. Для новых задач - просто получатся новые отчеты.