Единая форма оформления спецификаций

[VOleg 228]

Есть идея оформлять спецификации по единой форме, чтобы при переходе с единичной на групповую и обратно ни менять номера позиций как в варианте А, ни форматки, как в варианте Б.

Единая форма СП на основе единичной спецификации с добавлением столбца "Исполнение" (Исп). Взамен или рядом с "Зоной".

Примерно так:

[brigval 690]

Есть идея оформлять спецификации по единой форме, чтобы при переходе с единичной на групповую и обратно ни менять номера позиций как в варианте А, ни форматки, как в варианте Б.

Единая форма СП на основе единичной спецификации с добавлением столбца "Исполнение" (Исп). Взамен или рядом с "Зоной".

Примерно так:

Если не придерживаться ЕСКД, можно делать как угодно. Главное, чтоб на производстве понимали, что Вы задумали.

[GOLF_stream 293]

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

[VOleg 228]

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

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

Я веду речь о том, что пора от вариантов А, Б, В и Г уже уйти к единому варианту. Есть другие предложения?

Если не придерживаться ЕСКД, можно делать как угодно. Главное, чтоб на производстве понимали, что Вы задумали.

Мне кажется, что ЕСКД именно в этом вопросе уже подотстало от реальной жизни.

А на производстве все любят и очень сильно именно вариант А!!!

Кстати, можно ли Вас попросить в Текселе сделать возможным замены имени столбца "Зона" на "Исп"???

[Tiro 12]

Думаю, что назначение спецификации "основным" документом в ЕСКД было сделано не зря. Это подтолкнуло переход от приоритета конструирования к приоритету управления производством. Дальше нужно логическое продолжение и встанет вопрос как хранить данные, как их утверждать, и как их выводить. По уму нужно отказываться от форматок. Реквизитные данные с "подписями" на производстве даром не нужны и они неудобны для компьютерной обработки. Имея состав изделия (неважно, в какой среде) всегда можно вывести "полную" спецификацию и ведомости покупных, стандартных и каких только нужно составных частей с нужными атрибутами. А что еще более важно, из состава всегда можно спрогнозировать потребности в составных частях на будущее. Бумага тут не поможет, поэтому не "душите" себя рамками ГОСТ. Создавайте полную спецификацию на исполнение, как и было раньше у Вас и как GOLF_stream советует.

[brigval 690]

Создавайте полную спецификацию на исполнение, как и было раньше у Вас и как GOLF_stream советует.

Вообще-то, ЕСКД запрещает создавать спецификации исполнений (как и запрещает самостоятельные чертежи исполнений деталей). В контексте сказанного выше.

Разрешается создавать спецификации исполнений только при базовом способе выполнения КД.

[brigval 690]

Кстати, можно ли Вас попросить в Текселе сделать возможным замены имени столбца "Зона" на "Исп"???

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

А Тексель изначально ориентирован на максимально возможное соответствие ЕСКД. Поэтому уж извините. За доработку не возьмусь.

[brigval 690]

Кому интересно:

Я видел групповые спецификации на более чем 200 исполнений. Наверное, в этом случае все-таки предпочтительнее одна групповая спецификация. По любому.

[VOleg 228]

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

А Тексель изначально ориентирован на максимально возможное соответствие ЕСКД. Поэтому уж извините. За доработку не возьмусь.

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

А вот к ГОСТ у меня есть претензии. И в частности по оформлению спецификаций. Ведь чтобы из единичной СП сделать групповую - это практически повторное проектирование. А 4 типа СП ставят в тупик любую систему ПДМ... Впрочем, они вообще эту тему обходят стороной. В Ворк Групп даже слова такого нет, а SWE что-то невнятное про XML ... даже не расслышать...

И я в своей ПДМ просто работал с отдельными СП для каждого исполнения. А вот при разработки новой решил хорошенько подумать над этим вопросом. Уже несколько месяцев работа остановлена именно из-за СП. Перепробовал все, что можно и решение, удовлетворяющее всем 4 вариантам по ГОСТ не найдено. А вот идея по Единой Форме СП пришло. И я его озвучил.

Так что я сам пока в заблуждении, но свет в конце тоннеля вижу...

Может в конце концов мой теперешний вариант окажется тупиковым, и мы (или я) найдем лучшее решение, а может это будет признано Гениальным Решением Века!!!

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

Вот первое описание того, что я предлагаю...

Единая_форма_оформления_спецификаций.doc

[brigval 690]

Вот первое описание того, что я предлагаю...

Не уверен, что эта форма может стать заменителем спецификации по ЕСКД. Кроме ГОСТ 2.106 и ГОСТ 2.113 есть еще несколько стандартов, рагламентирующих записи в спецификации. На вскидку это ГОСТ 2.109, 2.413, 2.418. У Вас про них ничего не сказано.

А если кому-то понядобится указывать зоны?

А если исполнений будет очень много?

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

И т.д. и т.п.

[VOleg 228]

Компьютеру-то все-равно.

Как раз проблема существующего ЕСКД - это компьютер.

Вот хоть у кого-нибудь получилось создать ПДМ, способную воспринимать все 4 формы оформления СП (А, Б, В и Г) и, соответственно, выдавать на печать в любой из этих форм???

И как это сделать получив СП в варианте А, потом выдать в варианте Б??? Чертеж сможет оставаться актуальным?

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

Так что либо дайте алгоритм решения, либо эти ГОСТы на помойку... Впрочем, есть и третий путь (это из сказки про золотую, серебряную и чугунную трубы - надеюсь знаете).

А начальство требует перевести формат Б в формат А без изменения чертежей!!!

Кто сможет???

[brigval 690]

Как раз проблема существующего ЕСКД - это компьютер.

Причем тут компьютер, кусок железа?

Вот хоть у кого-нибудь получилось создать ПДМ, способную воспринимать все 4 формы оформления СП (А, Б, В и Г) и, соответственно, выдавать на печать в любой из этих форм???

Очень часто, стремление сделать "все в одном" приводит к пустой, никому не нужной работе. Вид спецификацийй должен зависеть от вида выпускаемых изделий, от традиций на предприятии. Например, нет групповых чертежей. Можно всю жизнь спокойно работать в спецификации по вар. А и не знать проблем Б, В, Г.

И как это сделать получив СП в варианте А, потом выдать в варианте Б???

Наверное никак. Я как-то рабирался с этим вопросом. По ЕСКД принцип назначения номеров позиций в спецификации по вар. А и Б различен, в общем случае. Но может я уже что-то и подзабыл. А посмотреть нет времни.

Если делать не по ЕСКД, то нет смысла говорить про варианты. Так как варианты спецификаций - это понятия ЕСКД.

А начальство требует перевести формат Б в формат А без изменения чертежей!!!

Это проблемы начальства, а не конструктора.

Кто сможет???

Програама Таип делает спецификации по вар. А и Б. С неограниченным количествм исполнений в обоих вариантах.

Не понимаю, с какой целью заниматься перегонкой из одного варианта в другой. Такое впечатление, что заняться просто нечем... ))

И еще. Подавляющее число программистов (может и все), считают, что спецификация - это отчет. И это главная их ошибка.

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

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

[Sergey___1978 34]

Не понял проблемы перевода спецификаций из одного варианта в другой.

Там вего лишь внешний вид таблицы меняется, а номера позиций остаются преждними.

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

Спецификация - это отчет!!!!!!!!!

За рубежом давно это поняли.

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

Вот и мучаются люди, приводя все к ЕСКД.

На это уходит больше времени, чем на само проектирование.

[GOLF_stream 293]

По сути спецификация - это именно отчёт. Она отражает комплектацию изделия.

Сама комплектация изделия должна создаваться в соответствующих программах (PDM на уровне изделия, CAD на уровне сборок).

В какой форме этот отчёт оформляется - это самый противный вопрос, пока существует ЕСКД, нацеленная на выпуск бумажных документов.

[Kolesov 4]

В корне не согласен с тем, что спецификация это отчет. А как быть если в спецификации имеются в наименовании формулы (например Провод L=h*n) и в количестве формулы (Z), плюс примечание в котором указано от чего зависит L,n и Z.

[brigval 690]

Не понял проблемы перевода спецификаций из одного варианта в другой.

Там вего лишь внешний вид таблицы меняется, а номера позиций остаются преждними.

А где об этом сказано в ЕСКД?

Спецификация - это отчет!!!!!!!!!

Отчет, это законченный документ. Полностью полученный на основании других документов.

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

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

Содержание раздела "Комплекты" откуда возьмется? Из какого другого документа?

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

Спецификация ни какой не отчет, а самостоятельный документ. 3D-модели только помогают составлять часть спецификации. Не более того.

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

Ни какой спецификация не отчет.

За рубежом давно это поняли.

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

В корне не согласен с тем, что спецификация это отчет. А как быть если в спецификации имеются в наименовании формулы (например Провод L=h*n) и в количестве формулы (Z), плюс примечание в котором указано от чего зависит L,n и Z.

Вы правы. А примечание к спецификации в целом это вообще отдельная песня

[VOleg 228]

В какой форме этот отчёт оформляется - это самый противный вопрос, пока существует ЕСКД, нацеленная на выпуск бумажных документов.

Вот я и хочу найти альтернативу, которая решит этот ПРОТИВНЫЙ вопрос...

Первым шагом я считаю отказ от вариантов оформления СП и внедрение единого формата.

Есть другие предложения?

[VOleg 228]

Причем тут компьютер, кусок железа?

К сожалению, на этом куске железа стоит SolidWorks и оформляет мне чертежи и спецификации. Да еще и плюет на наши ГОСТы...

Это проблемы начальства, а не конструктора.

Обмен мнениями - это когда заходишь к начальнику со своим мнением, а выходишь с его!

[brigval 690]

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

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

Обмен мнениями - это когда заходишь к начальнику со своим мнением, а выходишь с его!

Бывает и так, а бывает и наоборот. Начальник к тебе подходит со своим мнением, а уходит с твоим.

И все-таки, чем руководство мотивирует смену оформления спецификаций с варианта А на вариант Б? Ежели не секрет.

[Greets 6]

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

Позиции имхо тоже анахронизм при электронном оформлении.

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

На его же основе делаем штрихкод для логистики и тп