ПЕНСИОНЕРКА а если вышестоящая входит еще более вышестоящую , причем к количестве не равном 1
Именно так и есть. Говорил же - написал функцию, которая пробегает по сборкам вверх(используя OWN) и считает реальное количество

ldfanateужастный код. За использование goto программистов-базицников линейкой по рукам ещё в конце 90ых начали бить (ну кроме on error goto разумеется). :)Полностью согласен...... Ужасный.....Но я по образованию не программист, поэтому сделал так - работает... Подскажете как переделать - буду очень благодарен.

ПЕНСИОНЕРКАчто то мне показалось, что у вас отдельная таблица на каждое изделие
Нет, таблица одна. Но для каждого изделия в ней своя структура дерева.

ПЕНСИОНЕРКА тогда еще более неясно, как ваша функция работает, особенно если в изделии может повторяться одна и та же сборка/деталь несколько раз
Вот картинка. структрура видна
выделенная нода - прокладка - 2 шт в сборке подушка
Сборок Подушка в сборке Доработка кресла - 2 шт
Функция на вход использует код записи( на картинке в конце после /)
Берет по нему количество -2, и по коду записи же находит код вышестоящей записи по дереву -
код сборки Подушка, берет их количество - 2, перемножает, находит код вышестоящей записи - Доработка...
и тд пока есть вышестоящая запись.

Каждая нода в дереве - строка в таблице. По коду детали и коду изделия находим запросом нужные записи,
Для получения количества прям в запросе вызываем приведенную функцию. Ну дальше уж как захочется....
Да, запросы с такой функцией выполняется не очень быстро. Но приемлемо, учитывая что это требуется не очень часто.
Основная статистическая обработка будет проводится не в моей базе, а в 1С ERP, куда будут грузится ресурсные спецификации









ПЕНСИОНЕРКАдробные применяемости вообще не предусмотрены
Ага. Не может быть 0,5 болта, 0,2 гайки или 1,4 сборочных единицы. Материалы считаются совсем по другому

ПЕНСИОНЕРКА но зато может быть
....

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

Stanislav PНа мой взгляд Вы пытаетесь управленческую задачу по построению бизнес-процесса решить на программном уровне, а потом отдать этот процесс в работу..
Абсолютно верное замечание! Почти. Руководство в курсе, и сейчас фактически перестраивается часть бизнес процесса(документооборот) в связи с появлением новых задач.

Оба предложенные варианта имеют недостатки.
Stanislav PЕсли использовать первый вариант (состав составного изделие нельзя менять и всегда делать новое), то у продажников могут начаться проблемы: два одинаковых дивана с разными артикулами, хотя между ними разница в одну гайку, что не существенно для покупателя, но по базам у продавцов и бухгалтеров это будут два отдельных номенклатурных изделия. А это геморрой в бумагах - выставлены счета на один товар, а выдается другой..
Итоговое изделие достаточно велико и дорого, их в год продается и изготавливается всего несколько шт, структура каждого изделия долго и нудно согласовывается с заказчиком, так что тут неразберихи не может быть.
Продажников вообще нет)) эти вещи по другому продаются....

Stanislav P При использовании второго варианта выше приведённой проблемы нет, но появляется необходимость хранить временную (версионную) составляющую изделия. То есть, неделю назад выписали счёт на диван с болтами и его продали, а сегодня внесли изменение в изделие и вместо болтов там стоят шурупы и тогда изменится состав документа двухнедельной давности (должны быть болты, а стоят шурупы), так как оба счета ссылаются на одну и ту же запись, но с разным составом..
Вот че-то похожее пока и происходит, правда в отсутствие сквозной базы данных.


Stanislav PПоэтому, сначала обсудить с руководством сам процесс, а потом уже программировать.
Высшее руководство не знает, как надо - как всегда на среднем звене создаем концепцию, которая нам наиболее удобна - нам же в итоге и работать. А так руководство конечно в курсе всего что происходит....

ldfanate Для продажников придётся сбоку ещё один тип связей прикрутить, чтобы увязать такие однородные Изделия под потребности продажников, - номенклатура готовых изделий на складе готовой продукции (обычные МТР), регистрация поступления из производства на склад и далее классический складской учёт.
Не, не придется - нет продажников.... Нет готовых изделий на складе и не может быть.... на складе могут быть только детали и отдельные сборочные единицы. Специфическая продукция....

Stanislav PSerg197311, отдельные сборочные единицы так-же согласовываются и изменяются как и конечный продукт? Так же могут быть изменены в процессе разработки?
Да, также....Там ТЗ с приложениями листов на 10-15, и в процессе выполнения бывают к нему изменения....

ldfanateА что, для специфической продукции правила учёта, действующие в РФ, не применяются? Испод-полы торгуем??
Все применяется. Потребитель - на 90% государство. Причем так стало в последнее время, и вот тут и появились новые задачи.....

ldfanateСкладской учёт, отгрузка заказчику, соответствующие ведомости, товаро-транспортные накладные и проч. не выписываете вовсе??
А разве для этого нужны продажники?

ldfanateСебестоимость выпуска готовой продукции и прочие показатели, зависящие в т.ч. и от эффективности производства, складских запасов, ТЗРов и проч., - не считаете? Считаем, считаем.... для чего еще эта база нужна-то... за исключением складских запасов.

Да - отгрузки нет. Изделие монтируется на еще большее изделие заказчика нашими силами.