нужна программа автоматизированного учета комплектации Опции

[a123-flex]

Суть: разработано много разных плат, у каждой платы свой набор компонент
Хочется иметь софтину, в которой удобно вести учет: формировать перечень для закупки N плат каждого вида (чтобы объединяла одинаковые позиции)
Возможно считать цену (с учетом изменения цены от объема закупки).
Возможно учитывать склад.

А то я уже задолбался в эксель головой стучаться
Посоветуйте чего-нибудь

[AlexandrY]

Суть: разработано много разных плат, у каждой платы свой набор компонент
Хочется иметь софтину, в которой удобно вести учет: формировать перечень для закупки N плат каждого вида (чтобы объединяла одинаковые позиции)
Возможно считать цену (с учетом изменения цены от объема закупки).
Возможно учитывать склад.

Я это делаю в MS Access. Довольно элементарно.

Следующие шаги:
1. В Altium Designer создается для проекта Job - файл

Назовем его BOM.job.
2. В категории Report Outputs создаем Bill of Matereals так чтобы туда попали все интересующие поля и экспортируем в таблицу Excel.
3. Этот же Job файл содержащий только задание на Bill of Matereals вставляем во все остальные проекты плат и также формируем там аналогичные BOM-ы в формате Excel
4. Создаем Access базу данных и вставляем туда все Excel BOM-ы через связывание.
5. Создаем UNION запрос и на базе всех BOM-ов создаем единую сводную таблицу.
6. На основе сводной таблицы создаем PIVOT запрос и и проводим агрегацию по одинаковым компонентам.
7. Получаем таблицу где одинаковые компоненты собраны в одну позицию, но при этом можно видеть информацию сколько компонентов входит в каждую плату.

Способ в принципе работает с любым пакетом умеющим экспортировать BOM-ы в Excel или даже CSV.

[a123-flex]

Я это делаю в MS Access. Довольно элементарно.

pivot не помню, но номиналы Access понять не сможет. Или у Вас номинал - текстовое поле ?
тогда не получится нормальной сортировки по номиналу.
а если цифровое, тогда получите 10 мкф = 10 пф
а если приведете в экспоненциальный вид, тогда нечитаемо будет

[vitan]

а если цифровое, тогда получите 10 мкф = 10 пф
а если приведете в экспоненциальный вид, тогда нечитаемо будет

А что мешает просто записывать в виде 0,0001, 0,000001 и т.д, т.е просто в Фарадах?

[a123-flex]

А что мешает просто записывать в виде 0,0001, 0,000001 и т.д, т.е просто в Фарадах?

ето читается еще хуже чем экспоненциальная форма, и так же неудобно для заказа

В Access есть с несколько десятков inline функций парсинга и конвертирования строк и чисел в обе стороны, а в запросы SQL от начала времен можно было вводить вычисляемые поля.
Так что номиналы не проблема.

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

мда, а о вычисляемых полях я как-то позабыл за давностью времен.
по-моему финалисты определены: Access или TDD. Вот если бы найти еще удобочитаемую инструкцию как правильно конвертить Bom в TDD, и рекомендации, как правильно с ним работать, было бы совсем хорошо. А то данные я импортировал, а он еще чего то непонятного требует. А понятного и нужного, наоборот, не требует)

[vitan]

ето читается еще хуже чем экспоненциальная форма, и так же неудобно для заказа

О май гад! Ну что мешает рядом еще одну колонку сделать, в которую либо тупо руками либо процедурой заносить значение с префиксом? Это если без него жить нельзя. У меня, например, вообще такой колонки нет, а есть только код заказа компонента и все в порядке, никто не мучится. Кроме того, если у Вас ментор (Вы же его еще не снесли по причине кривизны?), то именно этот формат он корректно использует в dxdatabook, там стоит только настроить эти самые множители в свойствах библиотек.

Вот если бы найти еще удобочитаемую инструкцию как правильно конвертить Bom в TDD, и рекомендации, как правильно с ним работать, было бы совсем хорошо. А то данные я импортировал, а он еще чего то непонятного требует. А понятного и нужного, наоборот, не требует)

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

[a123-flex]

О май гад! Ну что мешает рядом еще одну колонку сделать, в которую либо тупо руками либо процедурой заносить значение с префиксом? Это если без него жить нельзя. У меня, например, вообще такой колонки нет, а есть только код заказа компонента и все в порядке, никто не мучится. Кроме того, если у Вас ментор (Вы же его еще не снесли по причине кривизны?), то именно этот формат он корректно использует в dxdatabook, там стоит только настроить эти самые множители в свойствах библиотек.

код заказа компонента лежит у меня в колонке comments и является необязательным атрибутом компонента, и вот почему: если Вы посмотрите в етот запрос(http://smd-component.ru/webcatalog/section.php?act=search&s_id=66&p_name=&c370l[]=12&c556l[]=19&c373num1=0.01&c373f1=6&c373num2=0.01&c373f2=6&on_pages=20), то увидите 11 одинаковых конденсаторов 0.01 мкф, от 5 производителей. У них 11 разных part number. В случае, если
Ваш part number временно out of stock, Вам придется делать следующее: расшифровывать Ваш part number, выписывать строку параметров, идти куда-то, и выбирать по этой строке другой компонент. Не проще ли сразу сделать строку основным параметром, а partnum- вспомогательным, и сделать так, чтобы строки было удобно просматривать.

О май гад! У меня на работе конструктора в этой же манере разговаривают. Я им говорю: если вы хотите, то можете пользовать TDD для ускорения оформления документов. Они мне: мы работаем в компасе, а в TDD очень много непонятных настроек, мы ничего не понимаем, напиши нам инструкцию.
Я поначалу даже написал и даже выложил в вики внутреннюю (хотите, скопирую сюда? гы-гы-гы).

да хочу

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

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

[vitan]

код заказа компонента лежит у меня в колонке comments и является необязательным атрибутом компонента, и вот почему: если Вы посмотрите в етот запрос(http://smd-component.ru/webcatalog/section.php?act=search&s_id=66&p_name=&c370l[]=12&c556l[]=19&c373num1=0.01&c373f1=6&c373num2=0.01&c373f2=6&on_pages=20), то увидите 11 одинаковых конденсаторов 0.01 мкф, от 5 производителей. У них 11 разных part number. В случае, если
Ваш part number временно out of stock, Вам придется делать следующее: расшифровывать Ваш part number, выписывать строку параметров, идти куда-то, и выбирать по этой строке другой компонент. Не проще ли сразу сделать строку основным параметром, а partnum- вспомогательным, и сделать так, чтобы строки было удобно просматривать.

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

да хочу

Серьезно? Ок, я завтра сделаю, но учтите, что она для наших реалий, а не для Ваших.

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

Поздно пить боржоми, когда почки отказали.

[a123-flex]

Хорошо, я вижу, Вы не заморачиваетесь с заменами.

разумеется в свои макеты я могу ставить что хочу и что мне удобно. При сборке с клеймом приемки весь головняк с закупкой на закупанах, и уж они там отрываются в полный рост: 2 цены для конторы, закупка отбраковки из Китая, и все такое прочее...

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

Вы почти правильно все обрисовали, за исключением того, что ключевым полем в таблицах компонентов должны быть все-таки параметры компонента. Указывая готовый парт, вы таким образом расширяете зону имеющих существенное для схемы значение параметров, и, например, при передаче базы в ведение Ваших подчиненных, увеличиваете возможность не купить что надо, или сделать ошибку. Делать partnum основой неправильно хотя бы потому, что иногда парт снимается с производства.
К тому же, я например, во всех изделиях стараюсь проводить унификацию узлов - если у нас есть, например, узел 1 Гбит ethernet трансивера, зачем делать его заново в другом изделии. Так вот, в разных изделиях может быть разный перечень разрешенных - у меня например есть такой прецедент. В этой ситуации опора на partnum 100% приведет к удвоению работы по формированию перечня.

Серьезно? Ок, я завтра сделаю, но учтите, что она для наших реалий, а не для Ваших.

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

Поздно пить боржоми, когда почки отказали.

почки пока не отказали. в ожидании Вашей инструкции ковыряю Access

[vitan]

разумеется в свои макеты я могу ставить что хочу и что мне удобно. При сборке с клеймом приемки весь головняк с закупкой на закупанах, и уж они там отрываются в полный рост: 2 цены для конторы, закупка отбраковки из Китая, и все такое прочее...

Ок, речь о макетах. Запомним это.

Указывая готовый парт, вы таким образом расширяете зону имеющих существенное для схемы значение параметров, и, например, при передаче базы в ведение Ваших подчиненных, увеличиваете возможность не купить что надо, или сделать ошибку.

Указывая готовый парт, я таким образом гарантирую, что парметры, не указанные в перечне (а при такой постановке вопроса я могу вообще ни одниго параметра не указывать,верно?) не повлияют на работу изделия, ибо я (разработчик) в явном виде указываю, что я рассчитал схему для данного конкретного партнамбера.
Если же я настолько крут (у Вас там, я слыхал, лучшие из лучших работают?), что могу позволить себе выставить на схему абстракуную деталь, заданную только парочкой параметров, то это не значит, что я это буду делать всегда. Довольно часто мне надо будет выставлять на схему именно конкретный партнабмер, говоря тем самым, что замены тут недопустимы.
При этом база у меня должна быть одна, и она должна позволять работать в двух стилях сразу. Кроме того, как Вы сами заметилии, для разных проектов могут быть разные перечни разрешенных, а также нужен склад, закупки и т.д. Как это все сделать? Только имея в качестве ключа партнабер реальной детали. Тогда это будет база деталей, а не база абстракций. Вот и всё.

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

Как Вы понимаете, это описывается в базе спец. полем, например "дата снятия с производства".

К тому же, я например, во всех изделиях стараюсь проводить унификацию узлов - если у нас есть, например, узел 1 Гбит ethernet трансивера, зачем делать его заново в другом изделии. Так вот, в разных изделиях может быть разный перечень разрешенных - у меня например есть такой прецедент. В этой ситуации опора на partnum 100% приведет к удвоению работы по формированию перечня.

Че-то не уловил, почему? Потому что год назад сняли с производста деталь, которая там забита? Так следить надо и списки допустимых замен формировать.