Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
Сейчас организовано так
Таблица MAIN - сборочные единицы и детали в неструктурированном порядке - типа общий каталог
Таблица MAIN1 - описание конкретных ИЗДЕЛИЙ, где содержится точная информация о составе(дереве) ИЗДЕЛИЯ с его полной структурой.
связь по id компонента
Пока это было только для технологов - это работало норм. Сейчас планируется расширение функций и подключение к базе с таблицами конструкторского отдела. Они будут работать не в Аксе, а через VBA модуль в программе CATIA
ВОПРОС - Как организовать правильное (оптимальное) использование сборочных единиц разработанных ранее в новых проектах.
Примечание 1- уникальность состава сборочной единицы естественно обеспечивается, при изменении состава единицы хоть на 1 винт - это уже новая сборочная единица.
вижу 2 варианта
1) получать данные о структуре сборки из табл MAIN1(брать из какого-то уже выполненного изделия) и при необходимости копировать их в новый проект.
2) создать промежуточную таблицу, связанную с MAIN, и содержащую информацию о составе сборочных единиц
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
Вопрос локальный, я полагаю что не стоит идти сильно вглубь и вширь всей базы.....

ROIОднозначного ответа вы не получите.

Да его и не существует наверное, однозначного-то...
Ну хоть какой-нибудь бы

Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....

ЛапухХотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.

Ну кому непонятно..... тот может и не отвечать
Вот Jossу, Idfanatу, vmagу точно все понятно и их ответы-советы все по существу)

Слегка сумбурно просто потому, что на данный момент в конторе нет четкой концепции документооборота, на данный момент ее просто никакой нет, и я собственно ее и создаю сейчас.
В планах стоит создавать электронную структуру изделий, хранить ее в базе данных и работать в дальнейшем с ней. Чертежи - что бумажные, что файлами .CATDrawing - совсем отдельная история, с кучей своих заморочек, и поэтому сейчас я рассматриваю только 3D модели сборок и самих деталей. Понимаю, что есть хороший выход - купить готовую PLM(PDM) и внедрить ее. На то что бы так не поступать есть множество причин, и они все не относятся к данной теме.
И собственно я колеблюсь между 2-мя направлениями
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц. После выполнения проекта все не вошедшие в него промежуточные версии сборки ( по желанию конструкторского отдела) выводятся из номенклатуры и файлы удаляются. История внесения изменений хранится в базе в текстовом виде.
В этом случае отдельная таблица со структурой сборок не нужна- можно найти структуру выбранной сборки в таблице с реализованными проектами и использовать ее. Еще плюс - на каждую сборку в номенклатуре обязательно есть свой единственный файл .CATProduct, точно ее описывающий, вся архитектура сборки хранится не только в базе, но и в этом файле.
Минус - даже если убрать или добавить 1 шайбу - требуется создать новый файл головной сборки. Но это легко реализуется программными методами из базы.
2) Изменения в сборке допускаются, структура основной сборки хранится в отдельной таблице - допустим SBORKI. Каждое изменение оформляется/согласовывается и хранится с указанием его применяемости. Именно так и был организован старый советский документооборот. Но так было сделано ИМХО потому, что основой был бумажный чертеж. Создать компьютерный документ, описывающий структуру сборки (типа файла .CATProduct) тогда просто не было возможности.
При этом у нас теряется уникальность файла сборки-нельзя открыть структуру из SBORKI и использовать ее. Надо обязательно поднимать всю историю изменений по всему дереву сборки. Избежать создания нового файла сборки все равно не получается, придется хранить и файл со структурой основной сборки, и файлы с реальной структурой, реализованной в проектах. Рано или поздно, когда изменений будет больше какого-т количества, все равно придется создать новую основную сборку и хранить и ее файл.
В общем я пока не определился.....
несколько дней назад думалось про создание доп таблицы SBORKI
на данный момент склоняюсь к варианту по п1, без нее....
Думаю-соображаю....

Лапух
Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного.
Толцытеся.... и отворится вам!

ldfanate Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.
Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре.

code OWN sernn codever qt
151 145 1 59 1
152 146 1 60 1
153 146 1 61 1

Типа так
Code - код текущей записи в MAIN1
OWN - код вышестоящей записи из MAIN1
sernn - код изделия
codever - код детали(сборки) из основного каталога MAIN
qt - количество

ПЕНСИОНЕРКА мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например

А вот этого уже не понял я.....

ПЕНСИОНЕРКАSerg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке

ldfanate
Такой вариант видится наиболее надёжным :).
Вот и я пока к нему склоняюсь......

Я в таблице храню только количества деталей/сборок в вышестоящей сборке. Если надо посчитать винты такие-то в изделии или в сборке такой-то - это делаю функцией на vba.

ПЕНСИОНЕРКА а если вышестоящая входит еще более вышестоящую , причем к количестве не равном 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Себестоимость выпуска готовой продукции и прочие показатели, зависящие в т.ч. и от эффективности производства, складских запасов, ТЗРов и проч., - не считаете? Считаем, считаем.... для чего еще эта база нужна-то... за исключением складских запасов.

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

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

Stanislav P Есть большое подозрение, что Own или sernn или codever лишнее поле в таблице MAIN1
Так как в таблице MAIN1 должно хватить четырёх полей для описания всех деталей входящих в составное изделие.
Да? А какое?
OWN - указывает к какой вышестоящей сборке принадлежит эта запись(деталь, подсборка). Если его убрать - теряется структура изделия, невозможно построить дерево вхождений.
sernn - указывает к какому именно изделию относится эта деталь/сборка
Конечно, можно вместо этого поля привязать еще одну табличку, в которой будут записи с указанием номера ИЗДЕЛИЯ только для головной сборки. Но это сильно затормозит процесс выборки, построения дерева и обработки статистики, а экономия места в базе совсем небольшая.Так что я решил поступить так.
codever - это указание на саму деталь /сборку. Без этого вообще никак ИМХО.
qt - количество этой детали в вышестоящей сборке. как без него - тоже не понимаю
Если сможете помочь оптимизировать - буду очень благодарен.

ldfanateи наверное, номенклатура готовых Изделий, и Спецификаций к ним будет ещё и соотноситься с номенклатурой Платформ. Т.е. будут частичные и полные аналоги взаимозаменяемости.

Да в том то и особенность. Практически каждое ИЗДЕЛИЕ - индивидуально, его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты (сборочные единицы).

ldfanate авторПрактически каждое ИЗДЕЛИЕ - индивидуально, его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты

Бедные интенданты, как потом тыловое обеспечение запчастями обеспечивать в условиях войны?.
На всякий случай) дабы чего не случилось) ИЗДЕЛИЕ по сути - комплект мебели))

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

ПЕНСИОНЕРКА неужели у вас все детали входят СТРОГО в свою сборку, т.е. нет деталей, которые входят в несколько сборок/подсборок(хотя бы гайки и подобное)
Да есть конечно! полно! А что вызывает сомнения?
Есть несколько записей с разным количеством в узле(qt) и одинаковым кодом ИЗДЕЛИЯ(sernn) и кодом детали codever
но отличающихся OWN - кодом вышестоящей сборки.