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

итак, оно таки заработало. Халявы не вышло, ето стоило многих слез, писания на бейсике, понимания, что на крутых новомодных языках студенты пишут гораздо быстрее меня, битья головой об майкрософт, потеряны годы(((, но оно работает в одном excel-e, умеет само генерить part number от разных производителей, помогает извлекать свои параметры (путем выполнения 100500 операций replace разом) из txt bom файла, умеет заполнять параметры для новых компонентов, если идентичные есть в базе, умеет понимать сколько уникальных плат в общем перечне, умеет формировать перечень уникальных чего надо купить, просто поставив цифири сколько плат каждого типа надо... короче делает чего хотелось

Агрегатирование так и не получилось.
Говорил же делать в Access.
Вообще-то VBA поддерживает автоматизацию.
Можно было бы генерацию самих первичных BOM-ов иницировать из VBA.

Уважаемый, в файле 100 Gb кривых макросов на корявом языке, которые делают все - и агрегатирование, и автоматизацию.... там даже распарсенный файл на страничке 3 лежит уже готовый. на странице 3 поле brd нужно удалить, там агрегатированная информация для количества плат, указанного на странице 2, чистить лень было. Access на хрен не нужен - разве что у Вас перечни по 65525 позиций и их больше 1) Лично у меня на все мои разработанные платы не наберется более 2000 типов неуникальных компонент. Так что лет через 10 я может и смогу достигнуть ограничений одной страницы Excel) Если под автоматизацией Вы имеете в виду разработку дополнительных костылей под Mentor, выгребание Bom скриптом из базы проекта, и сохранение в базе Excel(Access) дополнительной информации еще и о RefDes - ето не мой случай, у меня итоговая база собирается из примерно 6-7 библиотек, сделанных совершенно по разным правилам, в моем случае без ручного труда не обойтись. В противном случае ничего не надо делать, просто перейти в DMS)
В смысле я благодарен за совет (я его рассматривал в начале всерьез), и мне нравится sql... просто я не понимаю как его в данном случае прислонить - для данной проблемы такое решение сильно избыточно

Блин, прочитал всю тему целиком и увидел, что уважаемые AlexandrY и Vitan в самом начале описали решение, которое было в итоге получено, и у AlexandrY решение получилось прикольнее моего . стыдно. но что же делать? играли, как умели) Тогда, может кто подскажет насчет итоговой цены ? В смысле может быть уважаемые гуру поделятся, как они делают.... Собсно способ определяется практически полностью ответом на вопрос "где взять базу с ценами на компоненты, какая информация в ней есть в каком виде".
Подозреваю, что собственные солидные ПАРАМЕТРИЗОВАННЫЕ базы должны быть у всех агрегаторов типа Mouser, Farnell, крупных дистрибов, брокерфорумов и импортных efind. Круче всего было бы найти интерфейс к какому-нибудь e-find с возможностями параметрической фильтрации типа yandex.market. То есть понятно, что efind и smd-component и есть готовая база и интерфейс, но парсить их неудобно... нужно что-нибудь попроще.

Ничего страшного, понимание приходит с опытом.


Про параметризованные базы. Ессно, они есть у перечисленных господ, достаточно зайти на их сайты.
Про интерфейсы к ним. С ходу вспоминается оркад с его CIS-ом, в котором можно подключаться к подобному сервису прямо в процессе рисования схемы. Сервис называется, емнип, ActiveParts (или как-то так). В других САПРах тоже наверняка подобное найдется. Ну и DMS можно настроить, ясно дело. Отдельные особо повернутые товарищи (типа меня) создают такие базы у себя с нуля, если интересно могу кинуть ссылку, где почитать тут на форуме.
Про цены. Имхо, в России это нереально (брать актуальные цены из интернета). У меня этот вопрос не решен, но я вижу только одно решение - в виде интеграции с бухгалтерией. При этом для предварительной оценки цены компонента на этапе рисования схемы у меня решения нет. Но хотелось бы придумать. С удовольствием готов обсудить варианты.

в смысле CIS и DMS в среде показывает цену устанавливаемого компонента ? Учитывает объем закупки (масштаб производства) ?


все интересно, плз. хотя по бухгалтерии имхо основной недостаток - никакой гарантии повторяемости.


почему по Вашему нереально в России ?
а в мире реально ? как ето можно по Вашему делать ?



Насколько я понимаю - на этапе рисования - значит только средства среды - значит CIS и DMS... Вы же сказали что они ето позволяют.... ?

вообще если у кого есть знакомые в efind, можно просто спросить как у них ето http://www.efind.ru/services/all4bom/optimize/ сделано: стадо сисястых теток, или бородатых линуксоидов.

дополнительный на мой взгляд существенный ньюанс состоит в том, что есть китайские компоненты, и они дешевле в 10-100 раз. Вчера, например был приятно удивлен USB коннекторами по 5 рублей. По сравнению с Molex -просто халява, но грань здесь очень тонкая: нужно знать, что и где можно брать, а что низя... и вот етот вопрос очень хреново представляю себе алгоритмическую реализацию...

Вообще-то я решения никакого не давал Просто направление.

Если бы использовали Altium, то там прямо в контекстном меню каждого компонента на схеме есть опция поискать его у продавцов.
Altium ищет теперь у Farnell, Newark, Mouser, Allied, Arrow, Digi-Key.
Использует для этого их WEВ сервисы, у каждого сервиса Altium имеет свой пароль и name. Соответственно некоторые ему выдают цены в австралийских долларах и вообще считают, что клиент из Австралии.
Учитывается в цене и объем закупки. Но это конечно низкий уровень.

Сейчас вы сподвигли меня поискать решения более универсальные и я нашел, что http://octopart.com/ предлагает очень простое API для доступа к гораздо большему количеству продавцов.

Тогда технология для Altium-а была бы такая.
Получаем BOM-ы, сводим в одну таблицу в Access и запускаем процедуру VBA которая по всем строкам сканирует HTTP запросами сервис octopart.com. Ответы приходят в виде JSON файлов. В Access VBA они парсятся достаточно удобно. Переводим минимальные цены с учетом объема закупки в наш сводный BOM.
Тут еще бы надо учитывать таможенные сборы и доставку и оптимизировать по ним.

А для учета количества закупаемых компонентов у меня в параметрах стоят 4-е цены для 1, 10, 100 и 1000 компонентов. До сих пор ввожу их вручную.

опа. очень интересно, благодарствуем, поглядим.


а как же автоматизация ?

Показывает, если настроите. С учетом объемов (партий) сложнее, но при особом желании тоже можно.


Да вот... Только многабукав...


Сказал. Только одно другому не мешает. Средства позволяют, но воспользоваться ими я не могу, т.к. см. ниже.







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

черт. и правда нашел ошибку в своем скрипте при объединении позиций по разным платам(((

Щас сделаем.
Ответ на запрос из VBA Octopart уже возвращает, но его JSON довольно навороченный.
Сделать парсинг за полчаса не удалось.

ну, по мне так бред. Давайте все прикрутим к альтиуму и получим нахаляву Mentor DMS + ERP... Занятие гна Тау называется - колхозить Альтиум.
Но, по секрету, мостры уже все скрутили. OdaMasterLib, CIS, автоматические генераторы компонентов и корпусов - все уже сделано монстрами. Интересно, когда Тау дойдет до идеи IODesigner-а, и насколько качественно в его базе решается вопрос прав доступа и реляций ? Лично я больше верю Mentor, чем группе этузиастных товарищей, конкурировать с ним не собираюсь. Ето было бы затруднительно даже затрачивая на ето все свое время, а тем более на перекурах... Будет дорого стоить денег и времени. В итоге получится как всегда.
Такой грустный опыт уже имеется(((
Различие потребностей обязательно приведет к разбродам и форкам. На мой взгляд завязывать компонент (УГО,футпринт) и его part number - безнадежная идея.
А группа товарищей гна Тау по-моему демонстрирует типичный совковый подход - у нас большое предприятие, мы все сделаем красиво и побольшому и забесплатно. Только вот посчитать во что обойдутся издержки на глюки и освоение косой и и недостаточно эффективной системы для большого коллектива - и выходит, что Mentor почти бесплатный. Зато команда разработчиков самодельной базы никогда не останется без хлеба.... пока осел не сдохнет. Это одна из современных модификаций распила бюджета, только не страны, а своей конторы. У меня на работе таких оптимизаторов пруд пруди.

А идея про octopart действительно представляется интересной...

Хм, Тау там участвовал скорее как советчик, а не как создатель, он свои задачи решил. Да и я тоже.
Там обсуждались больше идеи, чем реализация. Насчет реализации и потраченного времени я согласен, но многие идеи там здравые. Что с ними делать, каждый решает сам.


Объясните, пжл, как Вы его собираетесь использовать в России?

Сделал автоматизацию поиска компонентов и цен прямо из BOM-а в Access используя WEB сервис Octopart и расчет цены BOM-а.
Выложу в отдельной теме.

класс. ждем ссылку

Вот она

тоже искал подобные программы для того чтобы сортировать компоненты, добавлять в проект.
Из небольшого разнообразия нашел самую оптимальную elela ее надругом форуме чел показал и частично перевел http://monitor.espec.ws/section13/topic222942.html Но к сожалению не доконца, а так отличная программа, со всем тем что мне надо.
Еще смотрел программы склад производства- платную и бесплатную. Но как-то непонравилось- писали недалекие люди для себя, а пото на рынок вывели. Попадались еще но как-то под себя я непонял как их передалеть

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

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

Эт тупиковый путь.
Основой для таких программ являются первичные документы и ничего больше: планирование, поступление, складирование, производство, продажи, отгрузка...
Все остальное только объекты действий.
Разделять на компоненты и изделия это плодить дополнительные измерения которые только усложнят SQL запросы.
Компоненты и изделия это просто динамические аттрибуты (возможно с историей) для листьев дерева объектов.

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

Для небольшого мелкосерийного производства что требуется?
1) Знать остатки материалов на складе.
2) Знать количество готовых изделий.
3) Знать на сколько готовых изделий осталось материалов.
4) Прикинуть стоимость заказа материалов для возможности произвести N изделий и составить номенклатуру этого заказа. Бонусом - с учетом аналогов у одного или разных поставщиков.

Вторично:
5) Знать сколько изделий кому продано, каких именно, когда, почем. Знать какие еще заказы висят в ожидании исполнения. Исходя из всего этого примерно оценивать прибыль и планировать ценовую политику. Автоматизировать формирование выставляемых счетов и учет их оплаты.
6) Различные сервисные функции - учет возвратов по браку, например.


Это понятно.

Сложность работы БД меня не волнует, меня интересует простота моей работы Нажал в программе кнопку "Изготовлено N изделий" и в базе автоматом списались все необходимые для N изделий материалы и добавились эти самые N изделий. Заодно выскочило предупреждение. если какого-то компонента осталось меньше, чем на 50 (100/200/1000) изделий.

В принципе да. Деление скорее принципиальное, чем практическое. Компоненты (материалы) - это всегда неделимые, приобретаемые на стороне позиции для внутренних нужд. Изделия могут быть как такими же неделимыми и приобретаемыми на стороне, так и составными из компонентов или других изделий.

Разработчик SLS.
Склад-Лайт ( freeware )

http://www.sls.ru/downloads/lite/skladlitefree.exe

P.S.
Не все есть, что хотелось бы, но - "бэзвоздмэздно", же

Самого нужного там как раз и нет

Делимые они или не делимые, это все условности.
Делайте сразу все делимым и без ограничений на количество уровней иерархии.

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

В каком месте она бесплатная?

Внимательнее надо быть:
http://www.sls.ru/produce/skladlite.php

Ссылку на free я уже приводил - см. страницу выше:
http://www.sls.ru/downloads/lite/skladlitefree.exe

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

Вообще-то можно ограничится и T-SQL при большом желании.
Есть специальная учебная база для бесплатной MS SQL Express - AdventureWorks2012

Это база охватывает весь бизнес процесс мелкого производтсва.
Там и закупки, и продажи и само производство с иерархическими структурами комплектующих, технологическими маршрутами и BOM-ами.
В ней используется только T-SQL.