Cистема управления полиграфическим предприятием PressTrack (ранее DupSystem) - старые обсуждения.

[bebabo]

Тема была разделена. Начало тут: https://forum.shelek.ru/index.php/topic,15360.0.html


коммерческие варианты подобных систем:

1) 1С:Полиграфия 8 (известная также, как Армекс) http://1cpoly.ru/ - разработка компаний 1С и Армекс.
2) Apler Quick Print - http://www.apler.ru/component/option,com_frontpage/Itemid,1/ - от компании Аплер
3)  ASystem - http://www.monorhythm.ru/ - от Моноритм
4) PrintEffect - http://www.printeffect.ru/ - тоже от Моноритм
5) ИИСУПП «ЛИМ-КОРПОРАЦИЯ» - http://asup.pechatnick.com/system.phtml?id=14 - пазработчик ЗАО Лим

это пять основных игроков на сегодняшний день.
а тут - http://forum.pechatnick.com/viewforum.php?id=57 - форум, где эти системы вяло, но обсуждаются полиграфистами

[bebabo]

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

1) Менеджеры получают от клиента заказ на печать, оформляют техкарту, в которой описывают параметры заказа (бумага, постпечатная обработка, тираж, красочность и прочее) и определяют стоимость заказа по прайсам типографии. При оформлении техкарты каждый менеджер использует свою собственную терминологию и свой собственный стиль оформления техкарты (кто как привык), что уже вносит риск возникновения ошибки.
Далее техкарта распечатывается в нескольких экземплярах, которые передаются технологу, на склад, логисту и в бухгалтерию.
2) Если технолог вносит какое либо изменение в техкарту, последняя вновь распечатывается и снова передается в перечисленные отделы. После утверждения техкарты технологом,  последний рисует (как правило, от руки) макет формирования изделий на печатном листе (макет спуска), заказ вносится в план печати и передается в отдел допечатной подготовки с макетом спуска.
3) В отделе допечатной подготовки файлы заказчика формируются в соответствии с макетом спуска - т.е. программными средствами раскладываются в формат печатного листа, в соответствии с теми требованиями, что указаны в техкарте. Данный этап довольно трудоемкий (может занимать как 15 минут, так и нескольких часов), и допущенные в техкарте ошибки (если они будут выявлены) приводят к увеличению времени формирования спуска.
4) После того, как спуск сформирован, файлы уходят на вывод форм, которые передаются в печатный цех.
5) В это же время склад, в соответствии со своим экземпляром техкарты выдает бумагу, которую еще надо подрезать под формат печати (т.е. бумага закупается большего формата и потом разрезается на доли под форматы спусков). И тут может возникнуть очень неприятная ситуация: технолог, утверждая техкарту, часто исправляет формат печати, исходя из экономической выгоды, на складе экземпляры техкарты путаются (или просто новый вариант не успел дойти, или вообще потерялся в дороге) и в итоге - бумага порезана не под нужный формат. Очень распространенный косяк)
6) Формирование очереди на печатную машину определяется срочностью заказа и сложностью его постпечатной обработки. Здесь важна роль мастера печатного цеха, в обязанности которого входит определить печатникам приоритет заказов. Под каждый заказ машина требует определенной настройки - "приладки". Если приоритетность перепутана (к примеру, из-за пресловутого человеческого фактора), то снятие заказа и перенастройка машины под новые параметры чревато большой потерей времени и сил. 
7) Отпечатав заказ, печатники забывают про него и приступают к следующему. И далее начинается самый трудоемкий и непредсказуемый процесс - постпечатная обработка. Большая часть постпечатных операций выполняется вручную, или на аппаратах, требующих долгой настройки, и здесь также очень важно планирование очереди заказов. Любая потеря времени на данном участке приводит к срыву сроков, а время теряется очень просто - заказ отпечатан, но никто никому об этом не сообщил, мастер постпечатного цеха не заметил, не подсуетился и т.п.
8) Получив в момент подписания техкарты данные по отгрузке (сроки и адреса), логист должен выстроить оптимальный маршрут для водителей. Распределить их таким образом, чтобы водитель не мотался по всему городу, но был загружен заказами, которые необходимо развести в одном направлении. Если сроки заказа по тем или иным причинам срываются, логист, зачастую, узнает об этом в день, когда все уже нужно сдать. В итоге - маршрут водителей корректируется, и нарушается оптимальное планирование.

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

[bebabo]

схема основных задач, выполняемых менеджером (в качестве примера анализа предметной области)

0. Получение от заказчика заявки на заказ.
1. Оформление предварительной техкарты и определение предварительной стоимости заказа (через прайс для обычных и корпоративных заказчиков).
2. Проверка файлов заказчика и согласование параметров заказа с технологом.
3. По результату пункта 2 стоимость заказа корректируется и согласуется с заказчиком.
4. Заказ передается в производство. Параметры по бумаге и тиражу уходят на склад, параметры по отгрузке - логисту, стоимость для выставления счета - в бухгалетрию, а отдел допечатной подготовки получает уже через технолога "добро" на работу с файлами.

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

[Алексей++]

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

[bebabo]

Алексей1153++, ага, это я и собираюсь реализовать в модуле логиста)

[bebabo]

выложил на гугле экзешник модуля менеджера (прототип).
http://code.google.com/p/dup-sistem/
многого, из того что задумал, там еще нет (или не работает, или буду переделывать), но общая идея уже проявляется)
модуль будет состоят из четырех основных разделов:
1) заказы - а) титульная страница с таблицей текущих заказов, всех заказов, избранных заказов и инструментами управления ими, б) мастер создания обычного заказа - от одного заказчика, в) мастер создания сборника (не реализован), когда один заказ включает в себя несколько заказов от разных заказчиков, в) мастер быстрого создания заказа (не реализован) - когда заказ формируется из его общего описания (что-то вроде интерпретатора);
2) база заказчиков;
3) мониторы загруженности участков и инструменты планирования (не реализовано).
4) настройки (не реализовано).

p.s. -  после того, как заказ сохранен, кнопка Save меняется на Print - просмотр + печать

[RXL]

bebabo, пара вопросов:
1. Хочешь open source проект сделать? (ты же на гугле его выложил) Не будет траблов с работодателем?
2. Можно у нас открыть svn-репозиторий. Если интересно - пиши в ЛС.

[bebabo]

RXL, привет!
1. Да, именно open source. Траблов не будет - так как идея написать эту систему моя, а что касается работодателя - я ведь там не программистом работаю, а допечатником, т.е. деньги они мне платят не за кодинг. Когда узнали, что я взялся за написание этой системы, сначала предложили оплатить, но я отказался. Во-первых, потому что сумма была маленькой), а во-вторых, чтобы потом в итоге не возникло проблем с тем, кому все это  принадлежит - тому кто за заплатил за разработку, или тому, кто все сделал. Ну, и еще - и это наверное было главным аргументом отказаться от денег - чтобы избежать вмешательство в разработку тех, кто платит. Т.е. хочется работать над этим проектом без компромисов, уступок ради денег, сроков и т.п. В общем, договорились, что использую типографию как одну из площадок для тестирования (у меня очень много знакомых в полиграфии - директоров типографий, мастеров, технологов и проектируя модули использую опыт сразу нескольких типографий).

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

[RXL]

Отлично!
(надо будет почитать эту тему подробно )

[bebabo]

выложил на гугле демку (http://code.google.com/p/dup-sistem/downloads/list). в ближайшее время в svn-репозитории форума будут доступны исходники

[Finch]

bebabo, такай вопрос, как примерно ты собираешся синхронизировать? XML это конечно хорошо, но они хранятся локально. Худо бедно, значит нужно также применять базу данных. И естественно серверную часть, чтобы не было прямого доступа к базе. Может перевести данный проект сразу на Web?

[bebabo]

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

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

[Finch]

Чем хорош Веб. Тем что все скрипты сидят централизовано на одном или нескольких серверах. Тут не нужен даже Интернет. Достаточно внутреней сетки предприятия. У клиента простой браузер (IE, Firefox, Opera). Строится все очень просто. Клиент дает запрос, сервер формирует веб страницу и отсылает клиенту. При этом тут платформо независимое приложение получается. Не важно что у клиента. Когда последний раз он обновлял свою систему и апликацию.

[Sla]

Finch, согласен процентов на 80, тем более учитывая, иногда территориальную разнесенность менеджеров, технологов, бухгалтерию
20% - можно оставить для... в случае отсутствия веб-сервера - обмен происходит xml файлами.
Но тогда... затруднена возможность обновлений ПО, т.е. необходим сервер приложений, а это почти - веб-сервер.

Кроме того, используя веб-технология и хранение информации в базе даст возможность "глобального" слежения за движением заказа.

И это все к чему?
Отладка модели  - локально
Внедрение - веб.

[bebabo]

Finch, надо будет это обдумать. но пока все равно хочу доделать прототип на Qt. бросаться туда-сюда - плохо)
залил исходники http://svn.shelek.su/public/dupsystem/
а тут - http://code.google.com/p/dup-sistem/w/list - инструкция по установке Qt и Eclipse

[RXL]

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

[bebabo]

RXL, сделаю) как раз готовлю все это вместе с докой. кстати, тестовая сборка есть на гугле (http://code.google.com/p/dup-sistem/downloads/list)

[RXL]

Только там описания нет. Я бы никогда не стал качать и запускать что-то, не узнав, что это из себя представляет. Сперва нужно заинтересовать.

Извиняюсь, минимальное описание есть - на другой странице.

[Алексей++]

(я исправил очепятку в названии темы)

[bebabo]

Алексей1153++, спасибо) я еще очепятнулся на гугле. вместо system написал sistem. к сожалению, чтобы там поправить надо все удалить и создать заново.

[Алексей++]

bebabo, между прочим, если system - это не часть пути где то, то пусть будет фишка твоего проекта Что мешает ?

[bebabo]

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

[bebabo]

1) "глобальная база оборудования".  включает в себя:
а) список оборудования типографии (который определяет сферу услуг типографии) и параметры оборудования, из которых формируется прайс типографии.
пример для печатной машиины SM-74-4:
Переналадка 30 минут
Скорость 10000/час
Стоимость 10000р./час
Бумага на приладку 250 листов
Техотходы 5%.
Печатник 250р./час
б) список сотрудников, где каждому присваивается определенный статус, определяющий уровень доступа к системе (технолог, менеджер, допечатник, печатник, постпечать и т.д.).
в) статистику по работе оборудования (время прохождения заказов по участкам).

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

3) "глобальная база оборудования"
- стек текущих заказов.

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

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

6) "модуль логиста" (отдел отгрузки)
а) принимает из "глобальной базы текущих заказов" информацию по отгрузке заказов
б) отслеживает их текущие статусы
в) планирование отгрузок
г) извлечение заказа из "глобальной базы текущих заказов"


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

[bebabo]

в общем, основная задача на данный момент - максимально реализовать модуль менеджера (автономную версию, т.е. без привязки ко всей системе), выложить его и послушать критику)
тикеты, которые осталось добить -
1. Реализовать поиск по локальной базе заказов менеджеров по следующим параметрам:
по номеру, заказчику, срокам, типам изделий - таким образом, чтобы параметры поиска не задавались пользователем, а определялись автоматически - по строке поискового запроса (уже делаю).
2. Упростить раздел "параметры печати" в форме создания техкарты, т.е. уменьшить кол-во комбобоксов, иначе организовать выбор бумаги и форматов.
3. Реализовать отдельный класс и форму для создания "сборных" тиражей - когда один заказ включает в себя несколько уже оформленных заказов.
4. Самое сложное - редактор техкарт - отдельный модуль для создания и редактирования шаблона, по которому будет отображаться на превью и распечатываться техкарта. 
Если кто-нибудь захочет взять что-то на себя - буду адско рад)

[bebabo]

обновил на http://svn.shelek.su/public/dupsystem/ исходники и добавил демку. из нового - поиск в заказах (по номеру, заказчику, печатным машинам, типам изделий - визитки, буклеты и т.д.), изменил форму заполнения параметров печати - избавился от нескольких комбо-боксов - получилось несколько кривовато, но вроде лучше, чем было. если есть мысли-предложения как еще можно улучшить юзабельность - давайте)

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

[bebabo]

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

[JAW]

Тема очень интересная.
К списку аналогов могу добавить Heidelberg Prinect Prinancy
(Это не оригинальная разработка Heidelberg, прикупили у кого-то).

Тема весьма серьёзная и востребованная. Ни одна коммерческая система не обладает достаточной универсальностью и гибкостью, чтобы жить на нашем рынке.

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

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

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

[JAW]

P.S. Тема пошла в закладки
Вы попали

[JAW]

P.P.S. Подскажите, как ответить на сообщение в полном формате...
Что-то не врубаюсь в движок. Слишком много нужно цитировать, в быстром ответе не катит.

[Алексей++]

JAW, цитирование несколько неудобно, это точно. Копируй через буфер и обрамляй цитату тегом
 [quote]..[/quote]