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


Вы ГОСТ покажите сначала.


Во-первых, строка "10n" уже ошибочна, ибо номинал должен записываться как "10 нФ". Во-вторых, можно спросить, а что Вы этим хотите добиться?

Я просто спросил у конструкторов как делать спецификацию, люди как бэ за это деньги получают. Но лично кажется достаточно логично и правильно сортировать по номиналу.
Вот нашел какой-то первый попавшийся (см. картинку):
ГОСТ 2.108-68
Единая система конструкторской документации
Спецификация


Быстро Вы однако сдались ,дело в том что весь функционал MS SQL Server можно использовать в Microsoft Access. И триггеры и хранимые процедуры и все остальное. Повторяю в состав поставки Access входит SQL Server.



Вы понимаете меня ,на чем именно я поставил акцент понятно? А добиться я хочу правильной и эффективной работы с ПО.

Закупки начинает заинтересованное лицо из базы. Можно заявить отдельные ПКИ, можно составить заявку под план производства NN изделий , можно комбинированно. Закупщик по заявке запрашивает поставщиков , получает счета, вбивает в базу дату и номера счетов, сроки оплаты ( если узнает у бухов) , сроки поставок, и прочее прочее , пока товар не придет на склад.

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

да.

Пожалуй откажусь, вот такой вот я фрукт.

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


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

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


Готов взять свои слова обратно, лишь бы не спорить об аксессе. Черт меня дернул...


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


А вот что Вы делаете, когда счет Вам пришел, а там написано не то, что Вы заказывали (до буквы не совпадает). Думаю, Вы понимаете, о чем я.


Знаю-знаю! Это от лени, чтобы не забивать эти параметры из даташитов в базу при добавлении компонентов. Угадал?

И пункт девятый также обязывает сортировать в порядке возрастания основных параметров. И это правильно.
Не понимаю, почему вы спорите и отстаиваете противоположную точку зрения? Просто представьте себе , что вам нужно заказать 450 резисторов отсортированных в алфавите..
Все, этот вопрос не обсуждается, если вы не согласны, то я не буду настаивать.

Если из 1С нельзя "взять" текущее состояние склада по той или иной позиции, то это уже не бухгалтерия.

---
vitan, да, берите обратно свои слова об Access.

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

Я не могу представить, пока не увижу от Вас примера. Со своей стороны могу привести пример, в котором это трудностей не составляет. Вот он:

А Ваш пример какой?


Беру.
Интересно, а Вы уже имеете рабочую систему с аксессом? Шутка.


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

Этот вопрос считаю закрытым. У меня будут компоненты отсортированы по номиналу. Во-первых это требование ГОСТа, во-вторых это логично, что не менее важно.


Да, конечно. Я работаю в связке Altium/Access. Для ввода данных в базу данных используется клиент написанный на VB

у нас половина счетов проходит через мусорку такова жисть.
если Кд будет следовать наименованиям тупых менеджерских фантазий в счетах - это дело надо пресекать. Мы пресекли. А вы еще нет ?

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

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


Я не смог. Расскажите, как!
Нет, серьезно! Если половину счетов - в мусорку, то как же работать? Вам действительно удается заставить менеджеров переписывать счета?


Читаю и не верю своим глазам! Я хочу у Вас работать! У нас, чтобы заставить бухгалтерию что-то понять, надо быть, как минимум финансовым директором! А эталон - только счет.

Так вы вы в базе ведете одно а в спецификацию выводите другое? Тогда это лишний труд плюс гора ошибок.
У меня в базе всего несколько полей ID, ParentID, Name, Library Ref, Footprint Ref и никаких дополнительных полей. Поля ID и ParentID и определяют иерархию.

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

Этот вопрос закрыт, не так ли?


Хм... Концепция, конечно, серьезная... Уникальный ключ применяется в базах данных всю жизнь и думать над этим не стоит.
Если говорить конструктивно (попробую еще раз), то в приведенном скриншоте я лично вижу большую проблему. Она в том, каким образом строится дерево компонентов. Я уже писал в ветке альтиума об этом, могу посоветовать не смешивать в одной классификации разные признаки. Примером ошибки служит деление компонентов на выводные и поверхностные на первом уровне и на 10% и 5% на втором. Это разные признаки, и такая классификация не поможет никому, кроме схемотехника. Сделате базу такой - она принесет (воможно) облегчение только схемотехнику.

В том смысле что сортировать по номиналу закрыт, но это детали, главное совсем в другом.



Вы видите проблему, а я решение проблемы. Для меня важно смотреть на компоненты именно в таком разрезе и желательно при этом понимать что эти компоненты либо есть на складе либо их реально можно достать без траблов. На этом стоп, дальше совсем другая песня и совсем другие подходы. И если есть желание решать эти другие вопросы, в том числе и те о которых уже говорили выше, то нужно не смешивая одно с другим строить параллельные системы и связываться по ключу, который собственно может быть составным, ну это уже тонкости.
В том то и дело, что если правильно разделить таблицы, то можно будет казалось бы несовместимые вещи совместить. Мне например нужна "схемотехническая" база моделей, а бухгалтер должен работать с первичкой, но связаться эти два вида деятельности/работ могут и должны именно на основе компонента, его уникальности и свойств. Тогда, и только тогда, можно будет каждому заниматься своим делом, при этом работая в единой системе "Центральная БД предприятия"

Читаю и валяюсь... И после этого кто-то кидает камни в сторону Design Entry, который не-CIS? Успехов в ваших базах Концепция, философия... а на самом деле получаются костыли, для подпорки процесса который без них не может обойтись. Нет, я понимаю, что в данных реалиях без этого обойтись не получается, но выглядит все это грустно...

Звучит правильно, но меня терзают смутные сомнения... Схему данных можете показать?


Это Вы о ком? И о каком процессе? Как вы его себе представляете?