Nick

Почитайте условие задачи. Еще раз. Внимательно.

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

Да будет Вам известно, заготовки рамы и створки вырезаются пилами с двух сторон. И в резе между заготовками участвует две пилы. А уже программисты в параметрах сделали, как себе будет удобней (ввод толщины двойного реза + перенос реза первой пилы к последней заготовке). От перестановки слагаемых сумма не меняется. Взяв Ваш тест, размер заготовок: 1836 + 1396 + 1166 + 866 + 868 = 5950. Согласно условиям задачи на резы должно было уйти не менее 60 мм. Т.е. Вам нужно установить размер заготовки 5980, так как Ваша программа считает последний рез не обязательным (также как и WinCalc, например, для того, чтобы соблюсти условия ЗАДАЧИ, кромка была установлена в 20 мм). Вы бы лучше себе объяснили, что 1 = 2 5(в начале) + 5 (в конце) = 0 (в начале) + 10 (в конце) Еще раз повторю, что от перестановки слагаемых сумма не меняется. 10 (кромка) + 1266 + 10 (первый рез) + 2346 + 10 (второй рез) + 2346 + 10 (третий рез) = 5998 Сами определите, откуда взялось 2 мм? В данном случае условия теста были изменены в пользу программы, что никак не помогло им с результатами. Так как сами разработчики не участвовали в процессе, не было смысла что-то менять, результаты будут только хуже. А Ваши результаты от какой программы? При текущем состоянии дел с размером 5990 Ваша программа остается в выигрышном положении по отношению к лидерам теста.

Участвовала. Ее результаты оказались еще хуже, чем 6 версии. Читайте тему до конца, там есть обсуждение этого.

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

Тут в корне не согласен. В Ecxel или OpenOffice легко редактировать данные, опять же сверка по количеству или площади. В текстовом варианте это можно сказать нереально. 1. Делали выгрузки на bystronic (в том числе фигуры), lisec (только файлы для контроллера, с родным форматом программы не смогли разобраться), bottero, intermac, hegla (опять же файлы din для контроллера). Вообще у нас выгрузка реализуется скриптом на FastReport, где исходные данные - карты раскроя, а выходной файл - формат стола. Т.е. просто пишется программа на паскале как внешний отчет, которая и оформляет выгрузку (порядок резов уже оптимизирован самой программой, нужно только в файл положить в нужном виде). Единственное экспорт в формат r01 Оптивея (есть клиенты, которые используют нашу программу, но на стол пускают через OptyWay) сделан в ядре, в fastReport тяжеловато работать с бинарными данными. 2. В самой PaneCut такой возможности нет. Некоторые клиенты просто берут чертежи PDF и отображают на экране, также есть своя программа для отображения Fp3 файлов (отчет FastReport) и листания по нажатию любой клавиши. 3. У нас все продукты сетевые. Но кроить одновременно нельзя, так как остатки могут одновременно взяться для нескольких рабочих мест.

По сравнению с PaneCut: 1. OptyWay более чем в 2 раза дороже. 2. OptyWay хуже кроит (результаты тут: http://forum-okna.ru...showtopic=35038 ) 3. Как указал MaxNVKZ (а также можно почитать в теме OptyWay) у OptyWay примитивный редактор отчета (по сравнению с FastReport в PaneCut), который не позволит сделать нормально этикетки и наряды. 4. Импорт в OptyWay возможен из екселя с достаточно жесткими настройками, в отличии от PaneCut, в которой импорт возможен из любого читаемого формата. А так да, программа OptyWay рекомендуется к покупке. Отличная программа!

Сейчас сделано на самом простом уровне: Был заказ 12.125-08: стали 12.125-08-стандарт, 12.125-08-ламинация, 12.125-08-двери. Если логист видит любую приставку к номеру заказа, он понимает, что это есть один из нескольких заказов. На этом сейчас остановились, заказчиков пока устраивает такая система. Контроль для групповой отгрузки пока не делали, не было нужды. В оптимизации в любом случае разные цвета не перемешиваются. Если для каждого цвета своя позиция, то само собой крой отдельный, если цвет считается на базе белого профиля (в спецификации белый + пленки/порошки и т.д.), то номенклатура помечается как "учитывать остатки по цветам", и в оптимизации делится на разные позиции.

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

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

Управленческий. Регистрация заказа + принятие денег + запуск в работу - планирование - закупки - выпуск продукции и т.д. Взяли 1С 8 УТ + доделали весь производственный процесс + планирование. Модераторы, не сочтите за наглую рекламу: http://www.vsgroup.ua/vsgroup1c/ 50К изделий в год, в среднем до 200 окон в день. Для WinCalc достаточно обычного i5 с 8ГБ RAM чтобы год отработать. Я бы сказал среднее предприятие по объему, особо ничего выдумывать не приходится. База WinCalc будет до 2ГБ, 1С до 4 ГБ максимум.

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

Может проще найти нормальную программу оптимизации, которая сразу будет печатать этикетки к картам раскроя в нужном виде и нужном порядке?

Добрый день. Невнимательно прочитал первое сообщение в теме о раскрое из 1С. Наша программа PaneCut позволяет кроить в режиме OLE, т.е. полное внешнее автоматическое управление. Учетная система формирует задание, передает посредством OLE программе PaneCut, ждет окончания раскроя и получает результаты. Данное решение используется на трех крупных предприятиях (имеется в ввиду режим OLE).

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

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

Как оказывается у вас все сложно....

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

Если уж на то пошло, то траверс не гарантирует удобство разлома, от листа может быть отрезано 200 по X, остальные 2900 уже по Y. У нас проблема решалась именно со стороны удобства ломки, данные параметры уже задают необходимость делать траверсный рез.

Оптимизация - это опция. Мы никогда не используем оптимизацию на оборудовании, давать этикетки (не те, что идут с пилы, а нормальные) и использовать склад обрезков в таком случае невозможно. Что касается тестов на 30 конструкций тут вопрос мотивации и желания, оконных программ не так уж и много, с Вашей стороны достаточно только тест сделать, а разработчики сами дадут результаты раскроя своих программ.

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

Разговор ни о чем. Этот текст можно применить к любому ПО любой категории, особенно если это говорит автор этого ПО.

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

Посмотрел карты раскроя OptyWay7, 4 тест, лист 10. Горизонтальный рез 2740. Данную карту считаете расположенной нормально? Какие тогда критерии при ручной ломке должны еще присутствовать? Максимальная длина слома 3000мм? 2800? У нас данные параметры задаются, можно переделать карты раскроя. Вы бы лучше предоставили результаты раскроя без данного ограничения, а потом "хвалились" бы данной функцией. Пусть люди сами выбирают, актуально для них такое или нет. P.S. Но в данном тестировании данное ограничение считаю некорректным. Потому что: 1. На автоматическом оборудовании не имеет значения, какой рез идет первым. 2. Если взять размер стекла меньше, данный критерий только качество раскроя ухудшит. 3. Многие программы так не умеют делать вообще, доп. функции оптимизации не стоит добавлять к качеству раскроя. Например, PaneCut может докраивать неликвид вторым проходом. Теперь она лучше всех остальных программ?

А чем для тестирвоания качества раскроя стекла не устраивают озвученые параметры? Можете предложить свои критерии?