Программа для учёта деталей

Всем доброго времени суток!
Подскажите пожалуйста кто нибудь простенькую программу.Что нибудь вроде базы данных для радиодеталей.Чтобы не рыться в коробках и по полкам,а то за год накопилось разнообразие нереализованных деталей и в голове уже всё не помещается))

0

У меня есть такая на диске, там только советские детали описаны, поэтому не пользуюсь.
Этот диск у меня уже много лет лежит, кто то мне его переписал, ещё когда у меня интернета не было )

0

Видимо это оно: Справочник радиолюбителя. У меня подобных несколько дисков было, а потом ещё и DVD с ним и кучей всех радиотехнических журналов. Да, было время, когда инета не было нормального... ах сколько же я был диалапщиком-то... страшно вспомнить. У меня меж прочим модем-то US Robotics Courier в чёрной коробочке и прошитый до V.92 что-ли где-то пылится.

Тут возникает закономерный вопрос к ТЗ: у нас комп подключен к инету или нет? Вот Proteus не стыдится скачивать инфу прямо из сети, чтобы показать pdf.

0

Лучше без Интернета. ПДФ можно брать из локальной папки, главное при наполнении своей базы деталей указать где лежит ПДФ к конкретной детальке...

0

По идее не должен. Не во всякую глубинку еще добрался инет. Да и вообще, привязка к определенным серверам - палка о двух концах. Равно как и к точке подключения, будь то вайфай, витуха, телефонная линия или gprs\3g модем. Я так считаю потому, что нет единого стандарта (и вряд ли будет) у радиолюбителей - как же все-таки хранить детали? У одного они по кассам разложены, у другого по спичечным коробкам, у третьего вообще туча плат на балконе и выпаивает по мере необходимости =). И запросы разные. Мне, например, не улыбается в гараж еще и интернет отдельный покупать-проводить, и ставить туда более-менее мощный комп. Вот винт - да, накидал бы в базу и даташитов и фото на много гигабайт. А какой сервер выдержит такие обьемы, если учесть что с базой работает более одного человека? Кто его будет хостить, оплачивать? Такие проекты без коммерциализации рано или поздно загнивают и прекращают жить...
А ведь можно учитывать не только дискретку, но и платы, модули. Например, у меня валяется куча рабочих БП от принтеров, сканеров, зарядники всякие. Иной раз надо 6 вольт - и перерываешь всю коробку\полки в надежде найти именно такой БП. А так - кинул в базу фото, описал вкратце что он умеет (или даже схему приложил). Или даже не только радиокомпоненты - можно и инструмент различный, если его много и он мелкий - метчики,плашки, метизы в наличии. Но, повторюсь - изначально функционал программы должен дорабатываться конкретным человеком под конкретные цели. Например, в спринт лайоут добавление компонента весьма просто - нарисовал, сгруппировал, сохранил под именем. Всё! И по папочкам разбил - сразу видно где кварцы, где дроссели. Внешне же - простое дерево с плюсиками. Новую группу добавил (создал папку в каталоге), разбил на подгруппы - как угодно. И каталогизировать тоже можно что угодно таким методом. Одно лишь различие - раскрывающиеся подветви дерева в лайауте есть не что иное как папки, а конечные элементы - файлы. А для каталогизатора нужно немного не так - общая БД, с описанием элемента (поля уже по вкусу) и ссылкой на определенный каталог. Это как я вижу самый простой функционал программы. Формат БД? На мой взгляд, лучше DBF, дабы в случае чего список деталей можно было бы просмотреть стандартным офисом (и даже на кпк!).

0

Я посмотрел формат этих БД из справочников. Вообще, программки написаны на Дельфи. Дельфи 3 даже, я так думаю. В те времена эта версия бродила по дискам. А вот с .dat файлами сложнее. Там очень много информации и, в общем, было бы не плохо её перенять. В 4-х из шести папок с базами есть "драйвер" для работы с ними. Это файл toodf.dll. На поверку при помощи Dependency Walker выяснилось, что эта dll экспортирует до боли знакомые хрени: RAROpenArchiveData(), RARCloseArchive() и так далее. Если кто помнит то смутное время в прошлом тысячелетии и писал на Дельфи, то наверняка ему попадалась на глаза такая штука как UnRar.dll, которая позволяла работать с rar-архивом. Короче говоря, те dat-файлы - это скорее всего запароленные rar-архивы старого формата, т.е. там просто лежат кучкой файлы и папки. Вот такая это "БД". Когда-то я сам хотел так хранить данные, но так просто подружиться с unrar.dll не получилось. Максимум, собрал демку, чтобы посмотреть структуру архива.

К сожалению, напрямую достать данные из data.dat не удалось, т.к. формат современный winrar не опознал. Но есть вариант воспользоваться этой же библиотекой и известным интерфейсом к этим функциям, чтобы прочитать (или выгрузить) все данные из архивов. Стоит или нет этим заморачиваться? А поля и таблицы взять по аналогии можно, но их ведь и заполнять придётся.

0

Вставлю свои 5 центов для тех, кто соберется писать свою прогу.
Полезно предусмотреть в базе для детальки кроме технических характеристик еще и, скажем так, экономические:
1. Поставщик
2. Размер партии
3. Вид упаковки (reel, и .т.д)
4. Стоимость за ед
5. Дата заказа
6. Номер документа по которому был заказ

.. и производственных:

7. идентификатор изделия куда деталь поставили
8. конечный заказчик которому все ушло
9. номер документа по которому отдали заказчику

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

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

0

2//Mt
Это требования к проге какого-нибудь мелкого производственника... А вот о простом радиогубителе, изготовителе сэмплов забыли...

0

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

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

по пунктам:
1,2,4,5 нужны.
номер документа сомнительно конечно, но может пригодиться.
7,8 нужны.

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

0

Я исходил из того, что если уж программа учета нужна, то не для того кто делает 2-3 изделия в год - там и табличка в экселе вполне прокатит (и сортировки есть и поиск и формочки можно запрограммировать).

Отслеживание заказов и алерты это круто, но это млин уже какой-то ERP получится и не самый слабый... впрочем если делать модулями и не пытаться все сразу - будет работать. Написать модули отслеживания своих заказов в digikey и т.д., точнее предоставить интерфейс - народ сам напишет :)

Если действительно делать такую штуку, то, IMHO конечно, делать ее стоит как Web-приложение с бекэндом на MySQL/PostgreSQLи каким-нибудь mediation (или как там сейчас принято писать web-приложения со сложной логикой?). Триггеры и хранимые процедуры уже вроде везде есть.

Так что соорудить каркас и дать возможность сообществу писать модули.

0

Чем больше данных о детали в базах - тем меньше времени и желания все это каждый раз заполнять...

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

После перестройки, в 90х годах - стало не до электроники. Главной проблемой было - выжить при уже "мировых ценах" на зарплату в 15-20 долларов. Многие вообще без работы тогда остались. На работе пришлось заняться программированием, электронщикам у нас делать было уже нечего. Как, впрочем, и сейчас...

Только после 2000г немного полегчало, смог снова вспомнить свое хобби. Начал просматривать информацию в Интернете, что в мире эдектроники делается. Сориентировался, годах в 2002-2005 почти полностью обновил свою элементную базу, от резисторов и конденсаторов, до микроконтроллеров.

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

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

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

Делать что-то такое, жутко универсальное, да еще и даром, в наше время - утопия. Никто этим заниматься не будет.
В то же время - не так уж сложно каждому сделать что-то простенькое, чисто под свои требования. Это можно за несколько дней накидать, даже не имея особого опыта. В Дельфи, Буилдере, на крайняк - даже в Акцессе - это делается элементарно, учебников и обучающих статей - полно. Если получится удачно - можно предложить другим, просто "как есть". Дареному коню - в зубы не смотрят. Не нравится - не ешь...

Но затевать сложный проект, да еще с коллективной разработкой - только время терять. Даже по этой теме уже видать, насколько противоречивые у людей требования. Такие проекты обычно ни к чему не приводят.

Сообщение от //Mt Отслеживание заказов и алерты это круто, но это млин уже какой-то ERP получится и не самый слабый...

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

0

Сообщение от SWK ...

SWK, а сказать то вы что хотели?

А то такой огромный текст, а мысль всего одна - "не нужно" мол...

0

привыкай. ;)

0

Сообщение от //Mt Сообщение от SWK ...

SWK, а сказать то вы что хотели?

А то такой огромный текст, а мысль всего одна - "не нужно" мол...
Мысль то может быть и одна, зато какая подача...

0

Увы, к сожалению, и со второго раза вскрыть архив не удалось. Я написал посредник на Delphi, чтобы вести лог обмена с библиотекой toodf.dll, но, увы, лог показал, что её функции не используются для работы с data.dat файлом. Тоже подтвердил и filemon из Sysinternals, который показал, что программа работает с архивом напрямую, а эту библиотеку вообще почему-то не использует. У меня всё-равно есть большие сомнения, что они используют собственный формат файла. Печалька, однако. Я уж было хотел просто переделать их проект. Всё есть, а вот данных самих нету.

П.С. Мой метод, оказывается, давно описан был.

0

Сообщение от //Mt SWK, а сказать то вы что хотели? А то такой огромный текст, а мысль всего одна - "не нужно" мол...

Дико извиняюсь... Все забываю, что у современной молодежи мала емкость буфера - больше 2-3 строк текста они не воспринимают, забывая после второй строки, что было в первой...

О, приятно, сошел за молодежь и я :)

Но все-таки хотелось услышать аргументы кроме "у вас ничего не выйдет" и "это никому не нужно" и, желательно, без предысторий в стиле Масяни.

С моей точки зрения, подобный проект выльется в 1 месяц разработки техзадания (т.е. работы software orshitect), 1 месяц работы технического дизайнера и 3 месяца работы квалифицированного разработчика - это если писать его как заказное ПО - ничего сложного.

0

Насчет полей и делений на подкатегории. Удобно бы было, чтобы их конфигурировал сам юзер под конкретную задачу. Кому-то надо поставщик и цену, а кому-то даташит и схему. Сделать просто добавляемые поля по таблице (ну или с запасом), далее кому надо -заполнят, кому не надо - скроют. И API не шифровать, а предоставить задел на будущее - вдруг кто-нибудь допилит и сделает еще лучше? А то вон как с этими базами - зашифровали, а в итоге они уже древнючие и нормально уже с ними не поработаешь.
P.S. Лично мне проще посидеть дня два и отфотать все запасы с занесением в базу, чем мучаться как сейчас - а сейчас иной раз бывает проще пойти купить, чем что-то найти на полках. А это растратно-с, в рамках хобби. Для мелких производственников все же 1с больше подходит. Да и с ихними средствами уж можно потратиться на "небольшую" 1ску или подобное. И таки пользуют, даже в мелких конторках. А им пофиг на структуру транзистора, там лишь бы продать или провести в бухгалтерию счета ;-)

0

Сообщение от //Mt С моей точки зрения, подобный проект выльется в 1 месяц разработки техзадания (т.е. работы software orshitect), 1 месяц работы технического дизайнера и 3 месяца работы квалифицированного разработчика - это если писать его как заказное ПО - ничего сложного.

Да никто и не говорит, что это сложно. Я лишь говорю, что вряд ли кто будет это делать даром, забросив свою работу и другие дела.

Сообщение от //DmytrySot Насчет полей и делений на подкатегории. Удобно бы было, чтобы их конфигурировал сам юзер под конкретную задачу. Кому-то надо поставщик и цену, а кому-то даташит и схему. Сделать просто добавляемые поля по таблице (ну или с запасом), далее кому надо -заполнят, кому не надо - скроют.

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

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

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

В более поздних своих программах я еще делал возможность при работе с программой выбирать, какие поля показывать, какие - нет, - или 2-3 фиксированных варианта (краткий, полный просмотр), или показ части полей по умолчанию, и добавление других для просмотра из их полного списка (пометив нужные). Можно также сохранять текущие настройки пользователя в .ini - файле. Все это несложно.

Можно и всякие отчеты ввести, и, например, экспорт в Эксель, и многоплатформенность. Но это уже более трудоемко.

Отчеты? Может быть... А вот список того, что надо купить/докупить для конкретного проекта/ов было бы неплохо... и с этой бумажкой в нигазин, на рынок...

0