несколько идей

1) Было бы шикарно для системы электронной очереди иметь возможность предварительной записи через интернет.

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

3) отчет строить кроме html,pdf,rtf форматов ещё и в каком-нибудь табличном... ods, например

4) чтобы оператору в разные дни отвечать по различным спискам услуг, ему придётся заводить несколько учёток... этого можно было бы избежать, если можно было привязывать услуги не к операторам, а к номерам окон

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

6) в пункте регистрации сделать возможным отключение возврата в корень по истечении времени (или сделать возможным менять это время), но добавить кнопку возврата в корень (а если вложенность >=2 , то и кнопку возвращающую на родительскую ветку)

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

1. Через интернет вещь удобная. Есть API для этого. Если у организации есть сайт, то она без проблем может доделать его для предварительной записи в свою очередь.

2. А на сколько удобен такой автовызов? Чем оправдан? Оператор после завершения работы с клинтом может заняться много чем, например вызвать отложенного клиента. При этом автовызов будет мешать, про него нужно будет помнить. Тут нужно пояснение.

3. Про табличный формат интересно, нужно будет посмотреть.

4. Очень хорошая штука для гибкости. Давно висит этот вопрос. Постепенно будем реализовывать.

5. Тоже не плохо, будет время, то можно заняться.

6. Есть такая настройка, называется delay_back.

7. Запуск стороннего приложения выглядит не лучшей идеей. Что толку запустить документооборот? Клиент не авторизован и о себе не сможет ничего увидеть. К тому же такие приложения не адаптированы под управление пальцем. Интеграция на уровне простого запуска не возможна.

1. А где можно почитать про эти API?
2. При откладывании клиента сделать возможным выбора времени, на которое клиент откладывается (количество минут или пока не вызовут), чтоб клиент через указанный промежуток времени автоматом возвращался в очередь с прежним номером и с повышенным приоритетом. И я говорил об отключаемом автовызове (на кнопке "Вызвать" сделать квадратик для галочки, поставил галочку - клиент вызывается автоматом, убрал - вручную; если нужно обслужить кого-то из отложенных или просто пофилонить между обслуживаниями клиентов, то просто убрать галочку).
3,4,5,6. ок
7. авторизацию клиента и возврат в СУО оставить на совесть сторонней программы.
Допустим, авторизация клиентов у сторонней программы происходит путём считывания штрихкода. Интерфейс сторонней программы для терминала выглядит просто пустым окном, развёрнутым на весь экран, с одной единственной кнопкой - возврат в СУО (или вообще без неё, если возврат осуществляется исключительно по таймингу); подошёл посетитель к терминалу, открыл стороннюю прогу, поднёс к специальному считывателю штрихкод раннее выданной ему карточки, и увидел на экране инфу, которую предоставляет сторонняя прога, прочитал, нажал на кнопку Возврат в СУО, ну, или ушёл, тогда кнопку нажимает следующий посетитель (или администратор) или возврат в СУО происходит по истечению времени.

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

Раз уж зашла речь о предварительной записи через интернет, хотел бы немного рассказать, как я это реализовал. Когда я устроился на работу в МФЦ, почти 2 года назад, тут уже стояла СУО QSystem версии 0.16. Только она была от компании "ККС". Это была та же QSystem, только вместо "Apertum Projects" везде было написано "ККС". Тогда я почти сразу стал задумываться о возможности записи через интернет. Тогда я еще не знал, что это open source продукт и про API тоже не знал. Только потом, спустя какое то время, погуглив я нашел этот сайт. Изучив получше СУО и схему бд я решил написать собственно веб-приложение, которое будет использовать ту же бд, что и электронная очередь. Писал на Java, работает это все под сервером приложений Glassfish v3.1. Сервер находится в нашем МФЦ. Приложение использует настройки QSystem, такие как расписание услуг и пр. Берет их из бд. QSystem сразу "видит" все записи сделанные через интернет, и наоборот. Т.е. время будет занято и в интернете и в СУО. Естественно были сделаны специфические настройки для приложения, такие, например, как время обеденного перерыва (это время будет неактивным для записи), редактирование шаблона письма и др. Потом я попросил разработчиков нашего сайта придумать какую нибудь ссылку на данный сервис. Они прилепили слева баннер на сайте МФЦ Липецкого района (сайт нашего МФЦ) http://lipetsk.mfc48.ru , который ссылается на наш сервер. Правда открывается это все в новом окне размером 800х600. Забываю им сказать, чтобы изменили это. Собственно вот так это работает у меня. Решение конечно не идеальное, лучше все таки интегрировать это в сайт с использованием API, но люди активно пользуются данным сервисом, все довольны.

Удобно сделано. А как люди подтверждают предварительную запись? Т.е. им на почту приходит код регистрации, а дальше их забота чтоб его запомнить или записать?

По поводу пункта 4.
У нас гибкий выбор услуг реализован через систему приоритетов.
Всем операторам выданы все услуги. На все услуги у всех пользователей установлен гибкий приоритет.
А дальше - они сами, в операторской части Qsystem, назначают себе приоритеты. Те услуги, которые они сегодня обслуживают - высокий. побочным услугам - нормальный. а тем услугам, которые они не обрабатывают - низкий.
И все. а дальше смотрят периодически на количество людей в очереди. Если они обработали все услуги с высоким приоритетом, то может быть начнут вызывать с нормальным. И если совсем никого не будет на высокий и нормальный, тогда они подключаться на услуги с низким.
У другого оператора - соответственно услуги выставлены с другим приоритетом.

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

Evgenic пишет: Удобно сделано. А как люди подтверждают предварительную запись? Т.е. им на почту приходит код регистрации, а дальше их забота чтоб его запомнить или записать?

После того, как пользователь подтверждает введенные данные, он попадает на страницу с информацией о его записи, где написано когда и куда ему надо подойти, наименование услуги, код активации и пр. На этой же странице он может распечатать себе талон, если у него есть дома принтер. На нем будет наименование услуги, дата, время, код активации и ФИО клиента, которую он ввел вначале. Если он ввел e-mail, то информация о записи автоматически так же приходит на этот адрес. В основном люди приходят с распечатанными талонами. Ну у кого нет нет принтера приходят с листочком, на котором они ручкой написали код и пр.

маленькая ремарка. в 1.2.5 будет ODS, возможность операторам логиниться в разных окнах/кабинетах/стойках и при этом номер окна не будет сбиваться на прежний жестко зашитый в БД( это настройка операторской проги). по п.6. если задержка менее 1000мсек, то возврат будет отключаться вообще. Еще интересная штука на пункте регистрации - если кнопок на одном уровне очень много, то они будут листаться по странично(появятся кнопки вперед/назад), а не уползать вниз.

по п.5
в 1.2.5 при выборе услуги для редиректа, услуга будет выбираться не из простого списка, а в виде дерева.