BOM

Привет Alex!

13 Jan 05 12:05, Alex Kouznetsov -> All:

Тема в общем-то для rus.pcad..

Также послано в RUS.PCAD

 AK> Кто чем пользуется для составления bill of materials (BOM)?
 AK> Или, в терминах ГОСТ - перечня элементов и спецификации?
Большинство пакетов его генерит само в том или ином виде, не претендующем
на полноту - минимум для составления ПЭ3, но не ведомости покупных,
используемых конструкционных, оперативного расчета себестоимости по
комплектации и тп.

Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
версиезависимы - с P2001, к примеру, не живут, да и не решают
вышеозначенных задач.

 AK> Соответствие ГОСТ меня не интересует,зато интересует привязка к
 AK> базам данных.
Можно использовать Orcad CIS, внутренние возможности которой весьма убоги.
Hо, если думать о внешних, то никто не мешает SQL-запросом связать уже
сгенеренный BOM c полями произвольной БД, как и использовать средства
генерации отчетов DBMS или сторонние, например, тот-же Crystal Report,
что и Orcad.

Vitaly Polikarpov, vitvp[эt]mail.ru

Sat Jan 22 2005 10:31, Vitaly Polikarpov wrote to Alex Kouznetsov:

 VP> Тема в общем-то для rus.pcad..

Я думал, что  rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.

 AK>> Кто чем пользуется для составления bill of materials (BOM)?
 AK>> Или, в терминах ГОСТ - перечня элементов и спецификации?

 VP> Большинство пакетов его генерит само в том или ином виде, не претендующем
 VP> на полноту - минимум для составления ПЭ3, но не ведомости покупных,
 VP> используемых конструкционных, оперативного расчета себестоимости по
 VP> комплектации и тп.

 VP> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
 VP> версиезависимы - с P2001, к примеру, не живут, да и не решают
 VP> вышеозначенных задач.

Правильно ли я понял, что эти тулзы:
-- Привязаны к конкретному пакету (ПКАД), даже еще хуже - к версии пакета
-- Делают не все, что хотелось бы, так что после них все равно приходится
править ручками
 
 AK>> Соответствие ГОСТ меня не интересует,зато интересует привязка к
 AK>> базам данных.

 VP> Можно использовать Orcad CIS, внутренние возможности которой весьма
 VP> убоги.  Hо, если думать о внешних, то никто не мешает SQL-запросом
 VP> связать уже  сгенеренный BOM c полями произвольной БД, как и использовать
 VP> средства  генерации отчетов DBMS или сторонние, например, тот-же Crystal
 VP> Report, что и Orcad.

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

Я пока больше склонен копать в сторону Context Management System. Что-нибудь
на основе PHP+MySQL, типа eGroupWare. Если бы к этому добавить PHP скрипты,
заточенные на обслуживание специфических баз данных (т.е. ведение стока,
библиотека компонентов, и т.п), и на генерацию доки (включая BOM), то могла бы
получиться икебана.

Пока,                                 Алексей

Hi Oleksandr!

25 янваpя 2005 01:12, Oleksandr Redchuk писал "Alex Kouznetsov":

AK>> В пpинципе монотоннyю нетвоpческyю pаботy комп сделает лyчше и
AK>> дешевле.
OR>  А "более младешмy" я это за паpy минyт излагаю и он сначала
OR> pисyет нyжнyю табличкy на полях схемы (пикад сам это всё pавно не
OR> сделает),

Есть отечественный схемный pедактоp (Schematism ?), yмеет делать BOM в виде
классической ГОСТовской спецификации и pазмещать ее, пpи необходимости, на
одном листе со схемой. По фоpматy тайла совместим с пикадом. Есть на
www.gaw.ru.

P.S. С yдивлением обнаpyжил там пpогpаммy теpмического анализа электpонных
плат, pазpаботаннyю в pодном инститyте (КГТУ) 8-(        ).

Best regard, Roman Gubaev!              [Team Beer - rulez forever!]
e-mail: rgubaev[собака]yandex.ru

... РАО "ЕЭС России", Хакасэнеpго, Энеpгосбыт, гpyппа АСКУЭ

Привет Alex!

24 Jan 05 00:23, Alex Kouznetsov -> Vitaly Polikarpov:

 VP>> Тема в общем-то для rus.pcad..
 AK> Я думал, что  rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.

не только - другие EDA/eCAD/eCAM тоже. Каким?

 VP>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
 VP>> версиезависимы - с P2001, к примеру, не живут, да и не решают
 VP>> вышеозначенных задач.
 AK> Правильно ли я понял, что эти тулзы:
 AK> -- Привязаны к конкретному пакету (ПКАД),
 AK> даже еще хуже - к версии пакета

И мне так кажется (детально не проверял, но работает лишь с открытым
проектом),
с использованием OLE, а не DBX, спецификация на который не менялась (afaik)
со времен Аccel v14. Hо, все еще хуже :) включая глюкавую проверку
его лицензионности (при идентичных инсталляшках на одной машине идет,
на другой - нет), введенную, по всей видимости, согласно пожеланиям местных
дристрибьюторов k$ глюкодромов.

Вообще, ставя с содроганием очередной пакет с тупым менеджером лицензий
под мастдай, у которого в свою очередь глючит version control management
user interface (одни только MSVCRT, MSVCIRT чего стоят), гадаешь, что из
ранее установленного прижмурится на сей раз...

В, общем, не IDE, а конструктор "Собери сам", который (PDM/TDM/CRM/..),
если-уж создавать, то на несколько иной, более стабильной и "прозрачной"
(в плане интерфейсирования) основе, как вариант, ODBC/DBMS.

 AK> -- Делают не все, что хотелось бы, так что после них все равно
 AK> приходится править ручками

ПЭ3 в траурной рамке, дабы унасекомить нормоконтроль, оно (если захочет :)
в Ёксель передаст, а иного никто и не обещал :)

 AK>>> Соответствие ГОСТ меня не интересует,зато интересует привязка к
 AK>>> базам данных.
 VP>> Можно использовать Orcad CIS, внутренние возможности которой весьма
 VP>> убоги.  Hо, если думать о внешних, то никто не мешает SQL-запросом
 VP>> связать уже  сгенеренный BOM c полями произвольной БД, как и использовать
 VP>> средства  генерации отчетов DBMS или сторонние, например, тот-же Crystal
 VP>> Report, что и Orcad.
 AK> Спасибо за отклик. Поскольку ты единственный, кто ответил, можно
 AK> предположить,что в основном все делают доку врукопашную.

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

 AK> Я пока больше склонен копать в сторону Context Management System.
 AK> Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому
 AK> добавить PHP скрипты, заточенные на обслуживание специфических баз
 AK> данных (т.е. ведение стока, библиотека компонентов, и т.п), и на
 AK> генерацию доки (включая BOM), то могла быполучиться икебана.
Для принятия решений о месте web-технологий мне хватило копирования
одного CD (кажется, OnSemi) c ~20000 .htm в одной директрии DN-ном
(который ее перечитывает, перед копированием очередного) :)

Vitaly Polikarpov, vitvp[эt]mail.ru

Wed Jan 26 2005 23:26, Vitaly Polikarpov wrote to Alex Kouznetsov:

 VP>>> Тема в общем-то для rus.pcad..
 AK>> Я думал, что  rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.

 VP> не только - другие EDA/eCAD/eCAM тоже. Каким?

EasyPC

 VP>>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
 VP>>> версиезависимы - с P2001, к примеру, не живут, да и не решают
 VP>>> вышеозначенных задач.
 AK>> Правильно ли я понял, что эти тулзы:
 AK>> -- Привязаны к конкретному пакету (ПКАД),
 AK>> даже еще хуже - к версии пакета

 VP> И мне так кажется (детально не проверял, но работает лишь с открытым
 VP> проектом),
 VP> с использованием OLE, а не DBX, спецификация на который не менялась
 VP> (afaik)
 VP> со времен Аccel v14. Hо, все еще хуже :) включая глюкавую проверку
 VP> его лицензионности (при идентичных инсталляшках на одной машине идет,
 VP> на другой - нет), введенную, по всей видимости, согласно пожеланиям
 VP> местных дристрибьюторов k$ глюкодромов.

 VP> Вообще, ставя с содроганием очередной пакет с тупым менеджером лицензий
 VP> под мастдай, у которого в свою очередь глючит version control management
 VP> user interface (одни только MSVCRT, MSVCIRT чего стоят), гадаешь, что из
 VP> ранее установленного прижмурится на сей раз...

 VP> В, общем, не IDE, а конструктор "Собери сам", который (PDM/TDM/CRM/..),
 VP> если-уж создавать, то на несколько иной, более стабильной и "прозрачной"
 VP> (в плане интерфейсирования) основе, как вариант, ODBC/DBMS.

 AK>> -- Делают не все, что хотелось бы, так что после них все равно
 AK>> приходится править ручками

 VP> ПЭ3 в траурной рамке, дабы унасекомить нормоконтроль, оно (если захочет
 VP> :)  в Ёксель передаст, а иного никто и не обещал :)

 AK>>>> Соответствие ГОСТ меня не интересует,зато интересует привязка к
 AK>>>> базам данных.
 VP>>> Можно использовать Orcad CIS, внутренние возможности которой весьма
 VP>>> убоги.  Hо, если думать о внешних, то никто не мешает SQL-запросом
 VP>>> связать уже  сгенеренный BOM c полями произвольной БД, как и
 VP>>> использовать  средства  генерации отчетов DBMS или сторонние, например,
 VP>>> тот-же Crystal  Report, что и Orcad.
 AK>> Спасибо за отклик. Поскольку ты единственный, кто ответил, можно
 AK>> предположить,что в основном все делают доку врукопашную.

 VP> Я - не исключение, хотя с БД и работаю с 93го.
 VP> Если для конструктора, автоматизация этого потока может и стоит на первом
 VP> месте, то для схемотехника, важнее параметический подбор компонентов,
 VP> на который тратиться значительно больше времени, чем на его
 VP> квинтэссенцию.

Хотелось бы решать все в комплексе. Для подбора элементов по минимуму нужны
три вещи:
-- БД элементов, имеющихся в стоке
-- Интернет для поиска новых
-- Е-мэйл для общения с поставщиками
Меня напрягает разнородность этих инструментов. Слишком много приходится
держать в голове. Сейчас я _частично_ решаю эту проблему при помощи dokuWiki,
но это решение явно промежуточное.

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

 AK>> Я пока больше склонен копать в сторону Content Management System.
 AK>> Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому
 AK>> добавить PHP скрипты, заточенные на обслуживание специфических баз
 AK>> данных (т.е. ведение стока, библиотека компонентов, и т.п), и на
 AK>> генерацию доки (включая BOM), то могла бы получиться икебана.

 VP> Для принятия решений о месте web-технологий мне хватило копирования
 VP> одного CD (кажется, OnSemi) c ~20000 .htm в одной директрии DN-ном
 VP> (который ее перечитывает, перед копированием очередного) :)

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

Пока,                                 Алексей

23-Jan-05 21:23 Alex Kouznetsov wrote to Vitaly Polikarpov:

AK> Правильно ли я понял, что эти тулзы:
[...]

AK> -- Делают не все, что хотелось бы, так что после них все равно приходится
AK> править ручками
 "Так отож".
У меня больше половины схем в итоге имеют несколько вариантов исполнения,
это забито в табличке на полях схемы.
Может и можно как-то хитро сделать табличку и через DBX и это вытащить в
соответствующий документ, но...

Проще оказывается
AK> в основном все делают доку врукопашную.
причём руками "более младшего конструктора" ;-)

wbr,

Mon Jan 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 OR> Проще оказывается

 AK>> в основном все делают доку врукопашную.

 OR> причём руками "более младшего конструктора" ;-)

В принципе монотонную нетворческую работу комп сделает лучше и дешевле. А
так-то, конечно, и Беломорканал лопатами копали...

Пока,                                 Алексей

24-Jan-05 08:58 Alex Kouznetsov wrote to Oleksandr Redchuk:

 OR>> Проще оказывается

 AK>>> в основном все делают доку врукопашную.

 OR>> причём руками "более младшего конструктора" ;-)

AK> В принципе монотонную нетворческую работу комп сделает лучше и дешевле.
 Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта вот
схема имеет 3 варианта исполнения, в двух из которых вон_то не паяется,
а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
паяется вон_то, а вот_эти резисторы не паяются.
 Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это
довёл :-)
 А "более младешму" я это за пару минут излагаю и он сначала
рисует нужную табличку на полях схемы (пикад сам это всё равно не сделает),
а потом делает ПЭ3 с вариантами исполнения и нужное количество вариантов Э7.
 При этом самую монотонную работу - подсчёт сколько чего есть - делает всё
равно компьютер, а выдаст он это в виде стандартного пикадовского report-а
или сразу в виде вордовского, к примеру, файла - разница невелика
на фоне остальной работы "младшего".

wbr,

Tue Jan 25 2005 01:12, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 AK>>>> в основном все делают доку врукопашную.

 OR>>> причём руками "более младшего конструктора" ;-)

 AK>> В принципе монотонную нетворческую работу комп сделает лучше и дешевле.

 OR>  Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта
 OR> вот схема имеет 3 варианта исполнения, в двух из которых вон_то не
 OR> паяется,

Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута
"исполнение".

 OR> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
 OR> паяется вон_то, а вот_эти резисторы не паяются.

Это можно описать в виде внешней таблицы. Например, xls

 OR>  Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это
 OR> довёл :-)

Импорт в BOM наверняка ведь есть, в том или ином виде. Задача состоит в том,
чтобы взять импорт, скрестить его с xls табличкой, с результатом пошарить по
базе данных, и сгенерировать сам BОM. Выглядить это как весьма посильная
работа для php скрипта.

 OR>  А "более младешму" я это за пару минут излагаю и он сначала
 OR> рисует нужную табличку на полях схемы (пикад сам это всё равно не
 OR> сделает), а потом делает ПЭ3 с вариантами исполнения и нужное количество
 OR> вариантов Э7.
 OR>  При этом самую монотонную работу - подсчёт сколько чего есть - делает
 OR> всё равно компьютер, а выдаст он это в виде стандартного пикадовского
 OR> report-а
 OR> или сразу в виде вордовского, к примеру, файла - разница невелика
 OR> на фоне остальной работы "младшего".

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

Пока,                                 Алексей

25-Jan-05 09:24 Alex Kouznetsov wrote to Oleksandr Redchuk:

OR>>  Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта
OR>> вот схема имеет 3 варианта исполнения, в двух из которых вон_то не
OR>> паяется,

AK> Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута
AK> "исполнение".
 Для BOM-а да, можно что-то придумать.Какие-то value01 value02 и т.д.
(у непаяющегося в данном исполнении элемента можно дать соответствующий
аттрибут).
 После этого выброшенный из пикада BOM уже поддаётся осмысленной обработке.
Но что-то не припомню, чтобы пикад мог включать/выключать элемент при печати
в зависимости от того, есть ли у него определённые аттрибуты и от их
значения.

OR>> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
OR>> паяется вон_то, а вот_эти резисторы не паяются.

AK> Это можно описать в виде внешней таблицы. Например, xls
 На схеме табличка всё равно нужна, её хоть так, хоть так рисовать.

OR>>  А "более младешму" я это за пару минут излагаю и он сначала
OR>> рисует нужную табличку на полях схемы (пикад сам это всё равно не
OR>> сделает), а потом делает ПЭ3 с вариантами исполнения и нужное количество
OR>> вариантов Э7.
OR>>  При этом самую монотонную работу - подсчёт сколько чего есть - делает
OR>> всё равно компьютер, а выдаст он это в виде стандартного пикадовского
OR>> report-а
OR>> или сразу в виде вордовского, к примеру, файла - разница невелика
OR>> на фоне остальной работы "младшего".

AK> А при внесении изменеий в схему - все по новой?
 А опка это "полумакет" - то полная документация всё равно не выпускается,
а "макетный" монтажник по почёрканному карандашиком пикадовскому отчёту
паять умеет. А если это уже в производстве, то внесение изменений в
существующий перечень элементов и спецификацию немного весит на общем
фоне.

AK> Идеально-теретицки все это должно бы делаться одним нажатием кнопки.
AK> Регулярно
AK> и рутинно, как "ежедневный билд софт проекта". Потому что, в сущности,
AK> какая разница, описывается в проекте железо или прога...

Дык я не спорю, что всё, что *имеет смысл* автоматизировать - надо
автоматизировать. В моём случае *эта* автоматизация (которой буду
заниматься я) как своего рода "процесс разработки" нескоро окупится
за счёт сэкномленного времени "младшего конструктора" (при нынешнем
потоке схем).
Хотя я уже сам иногда из любопытства поглядываю в эту сторону,
выходным форматом скрипта, пожалуй, должен быть TeX :-)

wbr,

Tue Jan 25 2005 23:39, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 OR> Hо что-то не припомню, чтобы пикад мог включать/выключать элемент при
 OR> печати в зависимости от того, есть ли у него определённые аттрибуты
 OR> и от их значения.

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

 OR>>> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
 OR>>> паяется вон_то, а вот_эти резисторы не паяются.

 AK>> Это можно описать в виде внешней таблицы. Hапример, xls

 OR>  Hа схеме табличка всё равно нужна, её хоть так, хоть так рисовать.

В принципе скрипт мог бы на основе xls таблички сгенерить макрос, который
прорисовал бы такую же табличку в схеме

 AK>> Идеально-теретицки все это должно бы делаться одним нажатием кнопки.
 AK>> Регулярно
 AK>> и рутинно, как "ежедневный билд софт проекта". Потому что, в сущности,
 AK>> какая разница, описывается в проекте железо или прога...

 OR> Дык я не спорю, что всё, что *имеет смысл* автоматизировать - надо
 OR> автоматизировать. В моём случае *эта* автоматизация (которой буду
 OR> заниматься я) как своего рода "процесс разработки" нескоро окупится
 OR> за счёт сэкномленного времени "младшего конструктора" (при нынешнем
 OR> потоке схем).
 OR> Хотя я уже сам иногда из любопытства поглядываю в эту сторону,
 OR> выходным форматом скрипта, пожалуй, должен быть TeX :-)

Я как-то не могу проникнуться прелестю ТеХ-а. Ну, если формулы писать, то
понятно, а так-то зачем? Универсальным форматом данных может быть XML, а уж из
него легко преобразовать во что угодно, в том числе и в ТеХ.

Пока,                                 Алексей

25-Jan-05 21:39 Alex Kouznetsov wrote to Oleksandr Redchuk:

OR>> Hо что-то не припомню, чтобы пикад мог включать/выключать элемент при
OR>> печати в зависимости от того, есть ли у него определённые аттрибуты
OR>> и от их значения.

AK> А оно надо? Имхо, схема может быть одной, все исполнения могут описываться
AK> в ВОМ-е.
 Я не про схему, я про печатку, "сборочный".

AK> В принципе скрипт мог бы на основе xls таблички сгенерить макрос,
AK> который прорисовал бы такую же табличку в схеме
 Только этот скрипт писать мне, а это

OR>> нескоро окупится
OR>> за счёт сэкномленного времени "младшего конструктора" (при нынешнем
OR>> потоке схем).


OR>> Хотя я уже сам иногда из любопытства поглядываю в эту сторону,
OR>> выходным форматом скрипта, пожалуй, должен быть TeX :-)

AK> Я как-то не могу проникнуться прелестю ТеХ-а. Ну, если формулы писать,
AK> то
AK> понятно, а так-то зачем? Универсальным форматом данных может быть XML, а
AK> уж из него легко преобразовать во что угодно, в том числе и в ТеХ.
 От BOM-а мне надо одно единственное - напечатать в нужном виде со всеми
рамочками/полями для подписей и т.п. Зачем мне он в XML-е? Если
автоматизировать насквозь всё, через суммирование комплектации по разным
изделиям и разделение этого по отдельным спискам для каждого поставщика
(см. выше про окупаемость этого у нас на фирме сейчас), то тогда логичнее
вбросить в нормальную базу, а не в XML. Я понимаю, что и в XML можно
нарисовать все нужные рамки, но чем он для данной задачи лучше TeX?

wbr,

AK>> Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута
AK>> "исполнение".
OR>  Для BOM-а да, можно что-то придумать.Какие-то value01 value02 и т.д.
OR> (у непаяющегося в данном исполнении элемента можно дать соответствующий
OR> аттрибут).

       Можно проще: $(путь_к_каду)/utils/variants..

26-Jan-05 12:37 Boris Popov wrote to Oleksandr Redchuk:


BP>        Можно проще: $(путь_к_каду)/utils/variants..
Спасибо, не знал.
Рылся по тому каталогу, но не всё перерыл значит (в работу только
refdesud.exe пошло).

wbr,

   Alex, ты ещё здесь сидишь?


Понедельник Январь 24 2005 00:23, Alex Kouznetsov wrote to Vitaly Polikarpov:

 VP>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
 VP>> версиезависимы - с P2001, к примеру, не живут, да и не решают
 VP>> вышеозначенных задач.
 AK> Правильно ли я понял, что эти тулзы:
 AK> -- Привязаны к конкретному пакету (ПКАД), даже еще хуже - к версии
 AK> пакета

 А что поделать, если версии пакета несовместимы между собой? :-\

 AK>  -- Делают не все, что хотелось бы, так что после них все равно
 AK> приходится править ручками

 Се ля ви. Всё, что хотелось бы, оч-чень редко бывает ;)


                                                   Георгий

Привет Oleksandr!

Monday January 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 AK>> в основном все делают доку врукопашную.
 OR>
 OR> причём руками "более младшего конструктора" ;-)

 А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net

Hello Alexander.

24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:

 AT>  А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....

Хотя бы этy веткy не загаживай, энypезник.

Alexey

Привет Alexey!

Tuesday January 25 2005 09:52, Alexey Musin wrote to Alexander Torres:

 AM> Hello Alexander.
 AM>
 AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:
 AM>
 AT>>  А Жора Шепелев потом спросит - почему доки и платы "девочки"
 AT>> делают.....
 AM>
 AM> Хотя бы этy веткy не загаживай, энypезник.


Дак и не загаживай, вонючка.

    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net

25-Jan-05 09:52 Alexey Musin wrote to Alexander Torres:

AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:

AT>>  А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....

AM> Хотя бы этy веткy не загаживай, энypезник.

Зря ты, ведь только хуже будет :-(

Wbr,