Перейти к публикации
forum-okna.ru

dvim

Участник
  • Публикации

    681
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем dvim

  1. Есть каталог этой чудной системы.

    Нужно бы где -нибудь найти пример расчета ПВХ двери и ПВХ портала HS. (Просто в каталоге моем нет даже секции пример расчетов.)
    Если  у кого есть пример спецификации изделий - буду очень благодарен.


     

  2. Периодически приходится писать знакомым сложные отчеты ... давно хотел такую вещь и наконец нашел и дописал.
    Очень надеюсь, что она поможет не только мне.

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

    Те, кто реально писал отчеты, знает что найти нетривиальную информацию в "схеме"  очень и очень непросто.
    Первый раз что то подобное мне понадобилось на моей основной работе, там используем MS SQL.
    В результате   был написан скрипт, который выполняет эту задачу.
    После этого, захотелось что то "эдакое"  и для Firebird .
    В результате достаточно долго искал "идею", тем более что комьюнити fb несколько своеобразно :ph34r:.
    Но вот и итог - идея найдена на просторах интернета и процедура капитально доработана.

    Кому она станет интересна - тем, кто пользуется ibexpert и любит(или не любит но надо) делать нестандартные отчеты.
    Привожу код процедуры и  видео ее использования.
    По тестам работает на FB 2.1, 2.5   (её можно использовать далеко не только для ПС4 )

    Код процедуры
    character_set_id <> 4 - тут отрезаем юникодные поля.  При поиске по ним русских символов была ошибка.
    Текст не ищем  по служебным таблицам с $
    Также прилагаю видео  https://www.youtube.com/watch?v=h_93UU8jWQI

    Очень надеюсь, что данная идея будет полезной

    Код процедуры , можно скачать текстом...
     

    SET TERM ^ ;
    
    create or alter procedure dvim_SEARCH (
    SEARCHPARAM varchar(100))
    returns (
    RESULT varchar(2000))
    as
    declare variable SQL varchar(1000);
    declare variable TNAME varchar(32);
    declare variable FNAME varchar(32);
    declare variable FTYPE smallint;
    begin
    for select rdb$relations.rdb$relation_name from rdb$relations
    where not rdb$relations.rdb$relation_name like '%$%'
    into :tname
    do begin
    for select rdb$relation_fields.rdb$field_name,rdb$fields.rdb$field_type
    from rdb$relation_fields
    join rdb$fields on (rdb$relation_fields.rdb$field_source=rdb$fields.rdb$field_name)
    where rdb$relation_fields.rdb$relation_name=:tname and rdb$fields.rdb$field_type in (35,37) /char and varchar/
    and rdb$fields.rdb$character_set_id <> 4
    into :fname,:ftype
    do begin
    SQL='SELECT ' || FNAME || ' || '' table ' || TNAME || ' column ' || FNAME ||''' FROM '||TNAME||' WHERE '||FNAME||' LIKE ''%' || SEARCHPARAM || '%''';
    for execute statement SQL into :RESULT
    --- RESULT = sql || ' union all' ;
    
        do
    
            suspend;
         end
    end
    
    end^
    
    SET TERM ; ^
    

     

    • Like 1
  3. Количество Q=L/8? - не выставить для профилей

     

    Получите в итоге хлыст длиной в 1/8 от длины прижима.

    И как потом объяснить заказчику, получившему в комплекте для сборки не 10*100 мм кусочков, а палку в 1235мм, что это нормально, и он ее пилить должен сам, хотя купил готовое.

     

    "Переводить в штучные" - теряем раскрой.

     

    Решение-то понятно - делать цепочку вставок для разных длин профиля с константными количествами.

    Да, трудоемко... но, похоже, другого выхода нет.

     

    Удивительно, что убрали - в ПС2 это было и прекрасно работало.

  4. Жутко туплю.

     

    В Пс2 в составах было для основного профиля куски прижимов

    Длина = 100мм, Шаг установки = 700мм

     

    Сейчас база, наконец-таки, переносится на ПС4 ... и такого параметра как "Шаг установки" нет.

    А как сделать такое?

  5. MB-Cad - было дело, работал.

     

    Удобная, в принципе похожа на логикаль, но более простая и понятная.

    Но с доработками - тоскливо. (Так как можно пользоваться только конструктивом завода).

  6. Совет - поставить регуляторы на батареи.

    Снизив приток избыточного тепла можно существенно улучшить микроклимат.

     

    Все так зимой нормальное положение окон - закрытое/микропроветривание.

  7. Уважаемые коллеги, есть такой вопрос.

    Делается оптимизация раскрой профиля. При этом идет распределение заготовок по телегам.

    Где это хранится в базе? (номер телеги и ячейки)

     

    Просто пока найти никак не смог.

    Идея у производственников - печатать просто эту всю информацию (http://help.profsegment.ru/?id=1086) в своем формате.

     

    Если напишу все-таки этот отчет, обещаю поделиться.

  8. Посмотрите Закавказье - там и не такое увидите.

    У нас подобным промышляют в Дагестане. :megalol:

     

    То что "это" незаконно - факт.

    А насколько у вас работает закон.... "на севере Подмосковья" я бы не рисковал.

  9. Когда-то попалась информация - в США из 100 человек, ушедших из науки в бизнес, осталось там около 5%.

    Это разные сферы деятельности

    Не путайте.

    "Ушли из науки в бизнес" - это просто сменили работу на работу в коммерческих фирмах.

    В Штатах схема такая, что это предстоит сделать большей части молодых ученых. (Временные контракты и сложность + конкурсы в получении тенюр).

     

    А вот "основать бизнес" - это совсем другое.

    А еще есть пункт "удержать".

     

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

    Второй пример - из малого бизнеса владелец ушел руководителем конструкторов в одну из фирм-лидеров.

  10. Вопрос работающим. После обновления ie (может windows?) "Просмотр отчета" не показывает отчет.

    При этом при экспорте в word/excel и при сохранении отчета кнопкой - все ок.

     

    Что может быть и что делать?

     

    Win 7 32bit + ie10

  11. Небольшой вопрос.

    Для загрузки Excel есть возможность в генераторе отчетов сделать запрос пути файла у пользователя.

    (Работает и в пс3, и в пс4)

     

    Теперь мне надо грузить XML - как запросить у пользователя путь к файлу. В документации что-то никак не нашел.

  12. Тут было немного свободного времени - и я решил попробовать написать "что надо". Текст - скорее это просто полет мысли, но мало ли кому будет интересно. :unsure:

     

     

     

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

    По роду «приработков» приходится достаточно регулярно общаться со многими участниками рынка. Результатом этого общения стало свое видение рынка, того «что есть» и того, что долго быть.

    В паре статей я попытаюсь это сформулировать.

    Почему же я пишу эту статью? Ответ очень прост – мне это интересно.

    На проблему я хочу взглянуть со стороны участников рынка. Ибо поняв их мотивацию можно сформулировать идею «как должно быть».

    Первый раздел будет посвящен алюминию, второй раздел – ПВХ.

    Раздел 1

    Участники: Производители ПО (в дальнейшем просто ПО), Производители профиля (Профилисты и профилисты). Крупные компании мы будем писать с большой буквы, небольшие с маленькой. Хочу отметить небольших профилистов – их часто забывают, но, тем не менее, они являются заметными на рынке. Чаще всего они продают клоны Проведаля, и системы для холодного остекления балконов. Иногда – делают фасадку.

    Также участниками рынка являются Переработчики и Дилеры.

    Желания участников

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

    Так что получаем требование номер 1 – разработчик по должен получать деньги от существующих пользователей.

    Многие производители ПО пытаются решать это выпуском новых версий и принудительным платным обновлениям на них, а также с помощью игр с ключами. Мотивы этих действий понятны, однако они несут в себе существенные риски. Переработчик получает не только финансовые проблемы, но и проблемы внедрения - притом, зачастую, изменения в продукте не приносят ему никакой пользы. Часто это приводит его в сторону торрентов и прочих нелегальных путей. Увы, но за осень лично общался с несколькими переработчиками, решившими сократить затраты на поддержку продукта именно таким образом. Основной их аргумент – «у нас все работает, но с новым морочиться не хотим, нам работать надо, а не перенастраивать и перевнедрять систему».

    Отсюда мне видится вывод, что деньги не должны быть привязаны к новой версии. Обновление это всегда стресс в корпоративном мире, платное обновление – стресс вдвойне.

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

     

    Профилисты

    Многим переработчикам жизнь профилиста кажется раем. Выпуск стандартных профилей, не очень сложный техпроцесс, отсутствие «неопределенности стройки».

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

    Что же хочет профилист (напомню эта статья – про алюминий, про ПВХ будет сведущая статья)?

    Профилист хочет, чтобы максимальное количество переработчиков могло рассчитать конструкции на его системе.

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

    Что сейчас делают профилисты, и что им не нравится?

    Огромное число профилистов вкладывает в каталог (размещает на сайте) свою базу на ПрофОкнах с дистрибутивом. У многих на сайтах есть базы к ПС3 и иногда к ПС4.

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

    Что не нравится.

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

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

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

    Стеклопакетчики тоже горят желанием высылать списки пакетов плюс наценок на них.

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

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

    Как обеспечить финансирование – через подписку и шифрование подобного обмена, видимо…

    Плюс данного подхода – возможность сделать свое ПО отраслевым стандартом.

    Переработчики.

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

    Рынок алюминия развивается по другим правилам. Производство, в общем-то, вторично - главное расчет (логистика), конструирование, монтаж.

    С ростом размеров компании не начинают показывать большую эффективность, скорее она снижается. (Т.к. основатели отдаляются от каждого конкретного процесса). Это позволяет небольшим компаниям на рынке жить и здравствовать.

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

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

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

    Конструктивная часть – переработчик хотел бы видеть экспорт в Автокад сечений, визуального рисования пяток и опорных пластин...

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

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

    (Сейчас очень популярно делать особые цены для рекламных размеров, типа двери 1000*2000).

    При этом очень важный вопрос – контроль ценообразования. То есть по любому изделию и заказу необходимо получать ответ «почему цена такая». (На мой взгляд, тут лучше всего дать возможность скрипту выводить отладочную информацию на консоль вывода).

    Производители. У крупных производителей появляются свои пожелания. Я бы выделил три основных пожелания.

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

    Решением может стать разделение расчетных и СРМ механизмов с явно заданными стандартами.

    На первом этапе вполне достаточно крупным клиентам дать возможность полностью править слой СРМ. Это позволит и сохранить единый стандарт для обмена конструкторской документацией и настройками и дать возможность каждой компании реализовать свою уникальность через ПО.

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

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

     

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

     

    Дилеры.

    Для дилеров в свою очередь важна возможность продавать изделия в программе.

    Дилер зачастую покупает у производителя только конструкции, и то без стеклопакетов.

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

    Небольшие «дилеры» чаще всего нуждаются в простоте. Хорошо бы иметь для них и веб систему, где используется то же ядро, и цены вычисляются ровно также. Просто вместо сложного (и дорогого в случае Html5) веб построителя используется обычная параметризация. Но после ввода параметров изделия строятся и рассчитываются уже по единым правилам в системе.

    Это может мимоходом решить и одну из мечт Производителей – честный и точный калькулятор на сайте, так как нечестных море - честный калькулятор - это преимущество.

     

     

    • Upvote 1
  13. вообще - FireBird не хуже и не лучше остальных БД со своими особенностями, преимуществами и недостатками. Это современный сервер, и утверждать, что он что-то не тянет мягко сказано не совсем корректно.

    Только его преимущества хороши для ембеддед решений или для неадминистрируемых приложений.

    Для приложений "вокруг СУБД" он , имхо, плох.

     

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

     

     

     

    Просто опять же, исходя из опыта, 90% компаний, которые занимаются окнами, не имеют нормальной Т инфраструктуры, и админ там даже если и есть, то чисто номинальный, что при их подходе к бизнесу неудивительно.

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

    Ровно то же самое - и про программы.

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

    А увеличение ценности ПО - как раз очень затратно. Все, что можно было сделать "просто" - уже сделали, далее надо идти другим путем.

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

     

     

    А все равно Вам программистам технолога не заменить

     

    Что такое технолог в вашем понимании.

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

    Заодно печатал всякие "групповые" отчеты - типа заказов на пакеты, заявок на завоз фурнитуры и т.д.

    Сами же технологи прочерчивали только явный нестандарт, который в программе был настроен только "для цены" (хотя есть компании, которые 99% ПВХ делают из программы, тут вопрос приоритетов).

  14. Добрый день!

    Делаю, что-то не получается, а мне не верится что так нельзя.

    Дано: Есть параметры фурнитуры, выбираемые пользователем. Пусть, к примеру, будет марка доводчика.

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

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

    Ан нет - создается типовое изделие со своими сохраненными параметрами, менеджер должен лезть в створку (к примеру) и устанавливать там параметры этой створки.

    P.S.

    Просто сегодня обратили внимание на эту особенность и ее неудобство для столпов ПС - профилистов, у который 10 вариантов петель + 5 доводчиков + варианты исполнения = и все это должно рисоваться, желательно в 1 клик.

    Делать на все типовики - их будет сотня на систему.

    (В ПС3 поведение системы такое же).

  15. Для интересующихся.

    Одним людям "очень нужно" было расширить возможности Профокон.

    Менять софт они не готовы, существующая связка очень активно работает и приносит доход.

    Цель решения - добавлять "наценку" по площади изделия.

    Еще им было сделано похожее решение, добавляющее ("вставки") по длине некоторых второстепенных профилей.

    Читайте, смотрите и используйте :))

  16. Советую также сделать прайс по ремонту ПВХ понятнее.

    "Ремонт, регулировка и смазка фурнитуры" - понятно.

    Но есть пункт "доставка комплектующих".

     

    Так человек без звонка не понимает, что именно включено в ремонт, включены ли запчасти (если нет - то примерные цены).

×
×
  • Создать...

Важная информация

Условия и правила использования форума Правила.