Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2] 3 4  Все   Вниз
  Печать  
Автор Тема: Cистема управления полиграфическим предприятием PressTrack (ранее DupSystem) - старые обсуждения.  (Прочитано 95280 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #30 : 02-09-2008 15:38 » 

Цитата: Finch
Чем хорош Веб. Тем что все скрипты сидят централизовано на одном или нескольких серверах. Тут не нужен даже Интернет. Достаточно внутреней сетки предприятия. У клиента простой браузер (IE, Firefox, Opera). Строится все очень просто. Клиент дает запрос, сервер формирует веб страницу и отсылает клиенту. При этом тут платформо независимое приложение получается. Не важно что у клиента. Когда последний раз он обновлял свою систему и апликацию.
С другой стороны, чем плох Web. Если понадобится для каких-либо нужд графический редактор (а при развитии такой системы скорее всего он где-нибудь понадобится для работы с макетами или документирования ошибок печати (проблемы с краской, печатным устройством, марашки, смещения, сгибы бумаги и т.п.)), то программировать эту задачу под Web будет уже сложнее. Можно, конечно, Java-апплет или ActiveX-компонент включить, реализовать во Flash или как SVG-графику но при этом теряется простота использования, поскольку от пользователя требуются уже определённые настройки безопасности, установка дополнительных плагинов и т.п.

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

Лично я за web-интерфейс, но в каждом конкретном случае нужно взвешивать все "за" и "против".

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

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

P.S. По своему опыту скажу, что самыми сложными в такой системе являются модули планирования и прогнозирования: составление расписания печати заказов на печатных машинах, оптимальная логистика, прогнозирование исполнения заказов с учётом статистики по технологическим сбоям, времени ремонта, переналадки оборудования, транспортных проблем. А самым трудоёмким - сопровождение и поддержка пожеланий пользователей Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #31 : 03-09-2008 07:30 » 

Готов попробовать составить Т.З., Думаю, что если несколько типографии составит Т.З., то будет понятно, что собственно нужно реально...

Для начала нужен модуль ведения заказов (память заказов) и выписывание нарядов.
Нужно понимать, что наряд всегда бумажный (к сожалению), если печать теоретически ещё как-то может в электронном виде потянуть, то послепечатка... С бабушками пенсионного возраста...
И в том же модуле расчёт тиражей (ручной, обязательно ручной).

И есть жирные траблы с предпечаткой, тоже хотелось бы подумать.

Привет! Спасибо за предложение о ТЗ. Если есть на это время - будем очень признательны. Именно для этого в принципе и было принято решение выложить демку на столь ранней стадии разработки (к вопросу о том что значит демка - в данном случае прототип, макет). Про бумажный наряд - понимаем. В данном модуле менеджера, кстати, возможность печати есть - после нажатия на кнопку save, она превращается в кнопку print) В планах, так же, есть разработка редактора техкарт.
Про расчет тиражей и траблы с поспечаткой - хотелось бы услышать подробнее. Особенно про первое (как раз приступил к работе над калькулятором). В планах - будет общий прайс, привязанный к оборудованию; будет возможность на страницах клиентов задавать скидки/наценки; после задания всех параметров заказа, на вкладке калькулятор будет отображаться таблица рассчета по общему прайсу с учетом скидок/наценок по конкретному клиенту и с возможностью редактирования табличных полей. Кстати, было бы очень интересно узнать, как рассчитывается заказ в вашей типографии. Можно без конкретный цифр, главное - от чего строится ваш прайс, т.е. привязывается ли он к оборудованию, или как-то иначе?
Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #32 : 03-09-2008 08:06 » 

Лично я за web-интерфейс, но в каждом конкретном случае нужно взвешивать все "за" и "против".

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


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

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

кстати, интересно, а ваша система как называлась? )
« Последнее редактирование: 03-09-2008 09:31 от bebabo » Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #33 : 03-09-2008 19:19 » 

Цитата: bebabo
кстати, интересно, а ваша система как называлась? )
Никак Улыбаюсь. Это заказное индивидуальное АСУ под конкретную печатную фабрику, части которого (в основном, связанные с контролем качества и обслуживанием тех.процесса) потом были перенесены ещё на пару фабрик в рамках компании. Поскольку это не рыночный продукт, то и название смысла не имеет Улыбаюсь

Правда, следует учитывать, что Amcor Rentsch имеет специфическое направление деятельности - выпускает упаковки, поэтому полных параллелей с другими типографиями я бы проводить не стал, хотя общие моменты, несомненно, есть.

У нас были полностью охвачены:
- Отдел продаж,
- Отдел контроля качества,
- Отдел логистики,
- Субподрядчики, оказывающие транспортные услуги.

Частично охвачены:
- Отдел планирования производства,
- Склад,

Совсем неохвачены:
- Снабжение,
- Финансы.

Плюс интеграция с ERP-системой (BAAN) головного предприятия.

И всё это (с перерывами и по частям) разрабатывалось с 2001 по 2008 год небольшой командой. Обращаю внимание на трудоёмкость задачи Улыбаюсь При этом главным тормозом являлось отсутствие концептуальной целостности и стратегии развития проекта. Система росла как кактус.

Поэтому твоё намерение не идти на уступки и не приносить в жертву пожеланиям концептуальную целостность я одобряю, но, с другой стороны, это же может стать препятствием в использовании системы конкретным пользователем, у которого свои представления о правильном и неправильном Улыбаюсь Встанет вопрос об обучении и перестройке бизнес-процессов при запуске системы в эксплуатацию. А кто им будет заниматься? Впрочем, это вопрос не программирования, а жизненного цикла программного изделия, так что пропустим Улыбаюсь.
« Последнее редактирование: 03-09-2008 19:32 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #34 : 04-09-2008 07:27 » 

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

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #35 : 04-09-2008 10:47 » 

Цитата: bebabo
кстати, если не секрет, было бы очень интересно узнать каким образом у вас было реализовано планирование. не подробности, а в общих чертах, если можно)
Производства? Вручную Улыбаюсь Операторы сами составляли расписание в MS Project, мы же только выгружали эти данные, поэтому охват частичный Улыбаюсь

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

Зато был разработан модуль прогнозирования процесса производства: когда какие партии будут завершены. Обычная линейная регрессия с предварительным фильтром невалидных данных (в случае сбоев и с учётом особенностей системы ввода данных).

Вот тут старая тема про фильтры, там я, правда, не говорил, для какой системы это нужно Улыбаюсь
https://forum.shelek.ru/index.php/topic,10619.0.html
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #36 : 04-09-2008 13:30 » 

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

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

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

Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #37 : 04-09-2008 13:53 » 

в общем, подбираюсь к базам данных. хочу отойти от хранения заказов в xml и прикрутитть что-нибудь по-серъезнее. и тут нужен  совет - как лучше это дело организовать с учетом следующих моментов:
1. как я уже говорил, часть модулей должны иметь возможность работать автономно, т.е. без установки всей системы. в частности, это относится к модулю менеджера. в маленькой типографии с одной-двумя машинами (а таких не мало)) необходимости во всей системе нет (у них как правило даже локальной сети нету) и достаточно одного только модуля для ведения базы заказов и базы клиентов, т.е. того, что реализованно в модуле менеджера. интуиция подсказывает, что делать в последнем локальную базу + выход в глобальную базу - не есть гуд) тем более, что глобальная база на сервере - по сути - база текущих заказов и заполнять ее по идее должны не менеджеры, а технолог с учетом плана печати (т.е. за какой машиной на какое время закрепляется определенный заказ). т.е. верно скорее всего будет сделать связку менеджер->технолог->база текущих заказов на сервере.
2. в тоже время в рамках системы менеджерам важно получать информацию из базы текущих заказов о том, на какой стадии находится в данный момент их заказы.
3. + надо реализовать возможность связи отдельных модулей менеджеров, к примеру для формирования сборных заказов (когда на один печатный лист раскладывается несколько изделей - зачастую от разных менеджеров), т.е. когда один заказ формируется из разных заказов.
вот,  с учетом всего этого нужны мысли и советы, как оптимальнее все это организовать )
Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #38 : 04-09-2008 15:31 » 

bebabo, в переводе с твоего языка пользователей на язык программистов стоит 3 задачи:

1) инкапсуляция всей логики работы с хранилищем данных в отдельном модуле / уровне архитектуры, чтобы система одинаково работала как с XML-файлами, так и с БД.

2) решение проблемы согласованности распределённого хранилища данных.

3) подсистема управления конфигурацией.

По-моему, для твоей разработки ответы на эти вопросы:

1) Да, нужно сделать.

2) В сложной многопользовательской конфигурации использовать единое хранилище (на базе СУБД), в простой однопользовательской конфигурации оно и так единое (даже при работе с XML-файлами). Учитывая небольшой масштаб системы, возиться с распределёнными хранилищами явно избыточно. Проблема подобного рода может возникнуть только при интеграции системы с каким-то другим сторонним продуктом. Что же касается того, что разные пользователи не должны обращаться к не своим данным, то это решается на уровне разграничения прав пользователей на таблицы и хранимые процедуры внутри СУБД.

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

Или, как Microsoft нынче делает, собрать полную версию, а при установке, в зависимости от лицензии, часть модулей или функций заблокировать Улыбаюсь
« Последнее редактирование: 04-09-2008 15:33 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #39 : 04-09-2008 15:37 » 

bebabo, а вот такие идеи (варианты):
1. Работать с базой через какой-нибудь стандартный интерфейс (напр. - ODBC) и, соотв., SQL-запросы тогда должны использовать только возможности в рамках распространенного стандарта (напр. SQL-92).
2. Сделать внешние модули работы с базой и загружать нужный согласно конфигу, SQL-запросы можно поместить в XML-файл и выбирать по из соотв. файла по имени или id (т.е. для каждого DB-модуля свой набор запросов).

Например, полезна была бы поддержка: для больших контор - Oracle, MS SQL, MySQL и т.п., для малых - файловые - Access (не кроссплатформенно...), SQLite, DB3 и т.п.

Т.е. база одна, но может быть отдельным сервером (или процессом) или локальной (файловой).
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #40 : 25-09-2008 10:28 » 

всем привет!
обновил исходники и демку.
http://svn.shelek.su/public/dupsystem/
основные изменения - перевел раздел заказчики на sqlite. освоил такие волшебные штуки как QDataWidgetMapper и QSortFilterProxyModel.
в форме заказа добавил возможность отправки файлов на проверку от менеджера - дизайнеру
если кому интересно про QtSQL - описал как все работает тут - http://dup-system.blogspot.com/
« Последнее редактирование: 25-09-2008 10:33 от bebabo » Записан

Cyb
Гость
« Ответ #41 : 23-10-2008 08:30 » 

Улыбаюсь интересно было бы сотрудничать, делаю схожий проект (тоже open source).

 cyberspirit [ at ] mail [ dot ] ru, icq 428998462
Записан
ApuktaChehov
Гость
« Ответ #42 : 23-02-2009 13:10 » 

Здравствуйте!
Я работаю в типографии системным администратором. И так сложилось, что мне в голову пришла идея создать приложение, которое бы автоматизировало большинство(если не все) процессы на полиграфическом производстве.
Я знаком с PHP, HTML, CSS, JavaScript(Ajax), а вот языки типа C++, C#, Java и т.д. я совершено не знаю. В связи с этим пршила идея, создать это приложение как WEB сервис. Сейчас имеется бетта версия, по которой несколько подразделений нашей типографии работают уже пол года.

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

Есть демка.

http://81.211.62.244/tk/

Пользователи:
user-mngr (менеджеры)
user-diz (дизанеры, верстака)
user-buh (бухгалтеры)

для всех пользователей пароль один: "pass".

Милости прошу. 

P.S. Защиты никакой я не делал. Можно, без особых усилий, внедрить SQL-иньекцию. Работа над этим приложение все еще продолжаются. На то она и бетта версия.
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #43 : 23-02-2009 13:15 » 

ApuktaChehov, не работает демка:)
ни для одного пользвоателя ни пароль ни логин не играют
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #44 : 23-02-2009 13:56 » 

Sla, только что попробовал - зашел как менеджер. работает
ApuktaChehov впечатляет! молодец! думаю, не только стоит попытаться реализовать это в вебе, но обязательно стоит) рекомендую списаться с Cyb. он делает подобную систему во Flex - вместе у вас может получиться очень интересный проект.
Записан

RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #45 : 23-02-2009 14:26 » 

ApuktaChehov, сразу критика: огромное количество ошибок JavaScript и CSS. Прогони CSS валидатором и проверяй доступность объектов перед использованием. Рекомендую четко указать формат страницы в DOCTYPE. Пока код совместим с HTML 3.2 и хуже, что дает сильно разное поведение для различных браузеров и их версий. Также богат код ляпами. Например, id=2 - должно быть id="2" и id должен быть уникальным для страницы. Еще грубая ошибка: href="#". Это прокатит в IE, но не в FF. Нужно так: href="javascript:void(0);". В общем, похоже, что обкатка была только для IE одной версии, что не возбраняется, но не есть хорошо.

Сразу скажу, что осмотрел лишь создание заказа в интерфейсе менеджера.

Примеры ошибок CSS:
Цитата
Предупреждение: Ожидается селектор.  Правило проигнорировано из-за плохого селектора.
Источник: http://81.211.62.244/tk/stl.css
Строка: 23

Предупреждение: Ошибка при анализе значения свойства «FONT-WEIGHT».  Потерянное объявление.
Источник: http://81.211.62.244/tk/stl.css
Строка: 56

Предупреждение: Ожидался конец значения свойства, но найдено «pt».  Ошибка при анализе значения свойства «font-size».  Потерянное объявление.
Источник: http://81.211.62.244/tk/stl.css
Строка: 177

Некоторые механизмы не работают. Например, в создании заказа не работает выбор заказчика.

Цитата
Ошибка: document.getElementById("zakname") is null
Источник: http://81.211.62.244/tk/dvju.php?prog_mode=bl_zak#
Строка: 1

Также не все гладко с GUI: выпадающие списки стоит поместить на другой слой - это ужасно, когда они раздвигают страницу.

Некоторые решения мне кажутся неверными. Например, в "Послепечатные работы" задан список работ. Если этот список будет в будущем расширен - он сам встанет на свое место по занесению в БД?

Думаю, что если копать глубоко и придирчиво, то ошибок можно найти еще много.
Зато молодец!
« Последнее редактирование: 23-02-2009 14:28 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #46 : 23-02-2009 14:36 » 

RXL, как внтурикорпоративная вещь может проконать со всеми ошипками. чтобы дать рекомендации - нужно глубже вникнуть в прооцесс...
На первый взгляд получился такой - 1С-ный подход.
Сыровата с точки зрения юзабилити, но при обкатке, утяжелится, как со стороны js-скриптов, так и возможно со стороны оформления.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
ApuktaChehov
Гость
« Ответ #47 : 23-02-2009 14:47 » 

Спасибо большое! Краснею
Ошибок там гораздо больше! Я в курсе.
Сами знаете. Начальник сказал "надо!". А времени нет. Нужно же быстрее!!! Вот и получается... Про PHP код я вообще молчу. Здесь была моя ладья...
Это уже третье перерождение этой системы.
Сейчас занимаюсь четверторй.
Вот демка интерфейса:
http://81.211.62.244/rm/dvju.php
А это пример Ajax:
http://81.211.62.244/rm/dvju1.php

Внимание! Работает только под IE
Записан
ApuktaChehov
Гость
« Ответ #48 : 23-02-2009 14:51 » 

Да и еще. Про Ajax. В полях "заказчик","Продукция" и "Исполнитель" ведется поиск по базе при вводе данных в поле.

Я разрабатывал ее только под IE. Про кросбраузерность я еще и не думал. Ajax тоже только под IE.
Записан
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #49 : 23-02-2009 14:56 » new

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

ApuktaChehov
Гость
« Ответ #50 : 23-02-2009 15:06 » 

Все просто:

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

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

>>Если этот список будет в будущем расширен - он сам встанет на свое место по занесению в БД?<<

Нет не встанет. Мне нужно будет переписывать код. Пока, что все вот так...
Я много чего делаю у нас в типографии, времени нет совершенно. Беру работу на дом.
Записан
ApuktaChehov
Гость
« Ответ #51 : 23-02-2009 15:09 » 

Блин забыл.

Планируют все менеджеры + ген. директор.
Они же и расчитывают все заказы.
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #52 : 23-02-2009 15:19 » 

Мое видение
Менеджер принимает заказ
Отправляет на утверждение Гл. технологу, который распределяет по технологам задачу. для равномерной (ли?) нагрузки. - Гл. технологу приходит по почте сообщение (поступил заказ)
Технолог отдает заказ начпроизводства - сообщение поступил заказ.
Или нач производства ( а возможно технолог(и) ) заполняет(ют) занятость производственных мощностей.
Основная идея - обратная связь. (принял в работу, отказал в работе, принял на завтра/послезавтра
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #53 : 23-02-2009 15:23 » 

ApuktaChehov, спасибо за ответ! по поводу списка постпечатки - чуть позже сброшу как исправил подобный косяк у себя.
"Планируют все менеджеры + ген. директор" - идилия))) видел бы что творится с этим в той типографии, где работаю я...
Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #54 : 23-02-2009 16:14 » 

в общем, после долгих исканий, остановился вот на таком варианте - все операции постпечати отображаются в таблице, которая описывается xml-файлом: название операции, значение по умолчанию и параметры - имя параметра, его значение (если значений много - это комбо-бокс, если одно - чекбокс, если пусто - лайнэдит). единственное - не хватает стоимости операций.
Код:
<operation>
        <name>УФ-лак</name>
        <default_value>глянцевый, 1+0, сплошной</default_value>
        <param>
  <name>тип</name>
<value>глянцевый, матовый</value>
</param>
        <param>
  <name>красочность</name>
<value>1+0, 1+1, 0+1</value>
</param>
        <param>
  <name>вид</name>
<value>сплошной, выборочный</value>
</param>
</operation>
<operation>
        <name>каширование</name>
        <default_value>да</default_value>
</operation>

в реальности это выглядит вот так

Записан

ApuktaChehov
Гость
« Ответ #55 : 23-02-2009 17:14 » 

Сервер сейчас недоступен, у меня VPN упал. Как починят, все опять будет онлайн.

А как же все это происходит в типографии, в которой вы работаете?

Списки постпечатки, это очень хорошо. А еще лучше, если эти списки можно будет фармировать пользователям.
Ну собственно, на этом и спроится управляемая система. Типа CMS для сайтов.
Записан
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #56 : 25-02-2009 12:32 » 

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

RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #57 : 25-02-2009 13:17 » 

bebabo, что на Гугле лучше, чем у нас? Колись Улыбаюсь
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
ApuktaChehov
Гость
« Ответ #58 : 25-02-2009 20:50 » 

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

ru
Offline Offline

WWW
« Ответ #59 : 25-02-2009 21:19 » 

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

ApuktaChehov, толи я не так понял твой вопрос, толи ты - мой ответ. в заказе менеджер может выбрать любой из параметров постпечати в списке этих параметров. т.е. если он активирует строку вырубка - значит есть вырубка (у меня еще сделано так, что в модуле менеджера можно просматривать либо только активированные опции, либо все целиком). но менеджер может только ВЫБИРАТЬ нужные опции из общего списка. а вот ФОРМИРОВАТЬ этот список, т.е. все возможные операции, должен именно тот, кто знает специфику производства.
в общем, если согласен про общий портал - на котором будут представлены странички по системам - пиши описание своей системы ) а я соберу остальной народ и от себя тоже подготовлю )
Записан

Страниц: 1 [2] 3 4  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines