Windows Система обработки заявок

  • Автор темы Автор темы Andi
  • Дата начала Дата начала
sergey57949 написал(а):
Куда деньги переводить?

Банк получателя
НОВОСИБИРСКИЙ ФИЛИАЛ ПАО БАНКА "ФК ОТКРЫТИЕ" г.Новосибирск
БИК 045004839 Сч. № 30101810550040000839
ИНН 5401144062 КПП 540101001 Сч. № 40702810340000001004
Получатель ООО "Лифт-Комплекс ДС"

:D :D :D
 
Последнее редактирование модератором:
Я полностью поддерживаю это
Андрей Ефименко написал(а):
отделить SPult от самой системы обработки заявок, так как может использоваться уже готовая система...
А так как большинство систем учета заявок имеют встроенный почтовый парсер, то достаточно сформировать и отправить письмо с необходимой информацией из SPult, чтобы было так
Андрей Ефименко написал(а):
Вся дальнейшая работа с введённой заявкой производится уже в системе обработки заявок...
 
У меня такая система учета :D :D :D
Поэтому и жду систему от разработчиков
 

Вложения

  • __.jpg
    __.jpg
    65 KB · Просмотры: 1
Последнее редактирование модератором:
revit написал(а):
Это откуда такая статистика?
Из тех, что нами были рассмотрены.

sergey57949 написал(а):
Поэтому и жду систему от разработчиков
Чтобы не ждать, можно попробовать систему от сторонних разработчиков. Готовых проектов много, в том числе opensource.
 
sergey57949 из того, что помню:
trellis desk, freehelpdesk, osTicket, Reguest Tracker, hesk, itop, redmine, otrs, glpi.
Поиск по словам help desk, service desk, тикет система.
 
Благодарствую.
Побуду назойливым. А какой из них вы пользуетесь?
Я так понимаю, вы выбрали приемлемую для себя.
Мне чтоб не перебирать все подряд.
 
osTicket - чем он мне не понравился уже не помню, но посмотреть стоит.
hesk - не плох, легкий интерфейс, база знаний, настраиваемые поля... Для меня был кандидатом №1.
otrs - монстр в плане интерфейса, для меня слишком перегружен. Не пошел, хоть и очень гибко настраиваемый.
redmine - очень круто, но из коробки пользоваться сложно. Если с программированием дружба, есть свободное время и не лень этим заниматься, то рекомендую, может получиться очень мощная система. Мне лень, у меня не прижился.
glpi - определяющим фактором, помимо активности проекта, для меня стала встроенная система инвентаризации. Внес туда все оборудование, контакты, поставщиков, договора, настроил автоматические уведомления. В общем с ней и живу 2+ года. НО! К интерфейсу надо привыкнуть, как то французы немного не логичны, что ли.
В общем, проект должен быть активным. Это главное. Если последнее обновление было год назад и форум в спячке, то смотреть на такие проекты не стоит. Если нужна просто тикет-система - hesk, osTicket и им подобные. Выбор по дружелюбности интерфейса.
Кстати, у некоторых проектов есть demo-сайты. Можно без установки посмотреть и "пощупать" интерфейс. Точно есть у trellis desk, itop, otrs, glpi, hesk.
 
Андрей Ефименко написал(а):
Хотелось бы получить мнения по такому подходу, а так же уточнить перечень информации, которую должна содержать заявка, формируемая в SPult.

Вставлю свои пять копеек... Возможность связи SPult по инициативе диспетчера с сторонними программами очень даже нужна и интересна! Лично я за локальную обработку данных по нескольким причинам:
1) Не всегда есть возможность "тонко" настроить логику сторонней программы (очевидно, что заявки на освобождение застрявшего пассажира, ремонт двигателя, проверку/восстановление связи и мытье в лифте обрабатываются по совершенно разной логике)!
2) В случае необходимости получить дополнительную (обновленную) информацию из БД SPult придется опять же городить костыли на "чужой" площадке + необходимо будет дать доступ к БД третьей стороне, что не лучшим образом скажется на безопасности...
3) Если организация в силах создать и/или подключить систему обработки заявок, то я думаю создать локальный демон для промежуточной обработки не должно составить труда, а вот вернуться с удаленного сервиса в локальную систему уже может быть очень сложно. Имею в виду в том числе и то, что есть ведь еще и MPult, а у него все лежит локально...
По поводу состава информации, то, в случае самостоятельной обработки считаю, что полностью достаточно будет адреса на локальной шине и логина диспетчера. Все остальное легко берется из БД и конфигов.
Против XML ни чего не имею, но лично мне будет достаточно и плоского файла и даже пустого файла в названии которого будет "зашито" имя пользователя и адрес на локальной шине (типа kudryavtsev.0.4.6.21.lft). Я буду раз в секунду проверять наличие таких файлов и дальше уже делать с ними ВСЕ что придумает мое больное воображение, не дожидаясь пока LKDS, osTicket или glpi че-то там специально для меня допилят... )))

UPD: Вспомнил еще вот что - практически во всех онлайн системах обработки запросов (хоть тикет системах, хоть CRM) в теле запроса присутствует секретный ключ безопасности, дискредитация которого может дорого обойтись... А в большинстве случаев придется формировать и хранить эти ключи на КАЖДОГО пользователя (каждого диспетчера как минимум)... Готов ЛифтКомплексДС плодить сущности?
 
Последнее редактирование модератором:
ВячеславK написал(а):
Вставлю свои пять копеек... Возможность связи SPult по инициативе диспетчера с сторонними программами очень даже нужна и интересна! Лично я за локальную обработку данных по нескольким причинам:
1) Не всегда есть возможность "тонко" настроить логику сторонней программы (очевидно, что заявки на освобождение застрявшего пассажира, ремонт двигателя, проверку/восстановление связи и мытье в лифте обрабатываются по совершенно разной логике)!
2) В случае необходимости получить дополнительную (обновленную) информацию из БД SPult придется опять же городить костыли на "чужой" площадке + необходимо будет дать доступ к БД третьей стороне, что не лучшим образом скажется на безопасности...
3) Если организация в силах создать и/или подключить систему обработки заявок, то я думаю создать локальный демон для промежуточной обработки не должно составить труда, а вот вернуться с удаленного сервиса в локальную систему уже может быть очень сложно. Имею в виду в том числе и то, что есть ведь еще и MPult, а у него все лежит локально...
По поводу состава информации, то, в случае самостоятельной обработки считаю, что полностью достаточно будет адреса на локальной шине и логина диспетчера. Все остальное легко берется из БД и конфигов.
Против XML ни чего не имею, но лично мне будет достаточно и плоского файла и даже пустого файла в названии которого будет "зашито" имя пользователя и адрес на локальной шине (типа kudryavtsev.0.4.6.21.lft). Я буду раз в секунду проверять наличие таких файлов и дальше уже делать с ними ВСЕ что придумает мое больное воображение, не дожидаясь пока LKDS, osTicket или glpi че-то там специально для меня допилят... )))

UPD: Вспомнил еще вот что - практически во всех онлайн системах обработки запросов (хоть тикет системах, хоть CRM) в теле запроса присутствует секретный ключ безопасности, дискредитация которого может дорого обойтись... А в большинстве случаев придется формировать и хранить эти ключи на КАЖДОГО пользователя (каждого диспетчера как минимум)... Готов ЛифтКомплексДС плодить сущности?

Именно, что бы не плодить сущности и было предложено передавать заявку в виде http(s) запроса post с телом в виде XML строк. Использование протокола http позволяет обработать заявку как на том же компьютере, на котором запущен SPult, так и на другом компьютере (компьютере-сервере), доступном по сети. Использование https позволяет защитить передаваемую информацию, если информация критична.
Запустить http(s) сервер сейчас не представляет трудностей. В принципе, этот сервер может сформировать предложенный файл после разбора полученного http запроса, хотя логичнее было бы все-таки сразу его и обработать.

Замечания конкретно по предложенному подходу:

1. Сейчас, для однозначной идентификации ЛБ, используется не только адрес на локальной шине (адрес в сети «Обь», т.е. в LKDSDrv), но и индекс ЛБPro в службе поддержки ЛБPro (LKDSPro), а так же идентификатор (ID) ЛБPro в «облаке» (LKDSCloud) и LKDSDomain.

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

3. ASPult ограниченно, но все-таки используется для реальной работы, поэтому и ASPult должен иметь возможность сформировать заявку. При использовании http это возможно.


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

Вложения

  • UserMsg.png
    UserMsg.png
    19.3 KB · Просмотры: 1
Андрей Ефименко написал(а):
Именно, что бы не плодить сущности и было предложено передавать заявку в виде http(s) запроса post с телом в виде XML строк. Использование протокола http позволяет обработать заявку как на том же компьютере, на котором запущен SPult, так и на другом компьютере (компьютере-сервере), доступном по сети. Использование https позволяет защитить передаваемую информацию, если информация критична.
Запустить http(s) сервер сейчас не представляет трудностей. В принципе, этот сервер может сформировать предложенный файл после разбора полученного http запроса, хотя логичнее было бы все-таки сразу его и обработать.

Замечания конкретно по предложенному подходу:

1. Сейчас, для однозначной идентификации ЛБ, используется не только адрес на локальной шине (адрес в сети «Обь», т.е. в LKDSDrv), но и индекс ЛБPro в службе поддержки ЛБPro (LKDSPro), а так же идентификатор (ID) ЛБPro в «облаке» (LKDSCloud) и LKDSDomain.

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

3. ASPult ограниченно, но все-таки используется для реальной работы, поэтому и ASPult должен иметь возможность сформировать заявку. При использовании http это возможно.
Опять же, что бы не плодить сущности, как альтернатива формированию предложенного файла, можно использовать возможность вывода оператором в журнал специальной записи Вложение IPB #1775, которую оператор может сформировать по своей инициативе. Приложение, которое должно было обрабатывать файл, может читать записи журнала в базе данных, извлекать сообщения оператора и обрабатывать записи оператора, так же, как обрабатывало бы файлы.

Выложена экспериментальная версия SPult , в котором реализована посылка заявки обслуживания лифта. 18.12.18 SPult выложен в штатное обновление ПО

Описание доработок в Документе

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

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

Главное все-таки, что бы эти внешние системы обработки заявок были адаптированы к приёму заявок от SPult, либо разработаны самостоятельно, сейчас это не представляет особых проблем.
 
Последнее редактирование модератором:
sergey57949 написал(а):
У меня не запускается

По ссылке нельзя запускать SPult

Выложенный для тестирования SPult нужно заменить в установленном дистрибутиве.

Либо перепишите файл BoODLL.dll из установленного дистрибутива в папку на своём компьютере, из которой запускаете SPult.
 
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение."
В настройках подключения указала https://localhost/spz Фактически сервер на localhost не запущен (симулировал ситуацию).
Сразу хочу сказать - я категорически против формулировок в журнал типа "Запись на обслуживание успешно послана..." Это мы, технари, будем читать, что да, мол, диспетчер нажал кнопочку, а те, для кого этот журнал собственно и нужен будут читать, что вот же заявка успешно послана и ПРИНЯТА!!! Успешно же!
 

Вложения

  • _________2018_12_19_10.57.45.png
    _________2018_12_19_10.57.45.png
    18.2 KB · Просмотры: 2
ВячеславK написал(а):
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение."
В настройках подключения указала https://localhost/spz Фактически сервер на localhost не запущен (симулировал ситуацию).
Сразу хочу сказать - я категорически против формулировок в журнал типа "Запись на обслуживание успешно послана..." Это мы, технари, будем читать, что да, мол, диспетчер нажал кнопочку, а те, для кого этот журнал собственно и нужен будут читать, что вот же заявка успешно послана и ПРИНЯТА!!! Успешно же!

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

ErrSend.png

SPult считает, что заявка принята:

ErrSend2.png
 

Вложения

  • ErrSend.png
    ErrSend.png
    4 KB · Просмотры: 1
  • ErrSend2.png
    ErrSend2.png
    30.6 KB · Просмотры: 1
Последнее редактирование модератором:
ВячеславK написал(а):
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение."
Фактически сервер на localhost не запущен (симулировал ситуацию).

Доработан SPult, что бы и при ошибках подключения к серверу обработки заявок в лог SPult записывался POST запрос.

SPult доступен в папке по ссылке

Текст заявки и текст ответа выводится в лог в кодировке utf-8

SPult выложен в штатное обновление ПО
 
Последнее редактирование модератором:
Попробовал все таки пробничек.
Мне понравилось. Надо ЛКДС что то подобное замутить.
Прикололо, что нельзя заявку выполнить не находясь возле дома, отслеживает местоположение :D
 

Вложения

  • 1.png
    1.png
    56.6 KB · Просмотры: 1
  • 2.png
    2.png
    66.6 KB · Просмотры: 1
  • 3.png
    3.png
    53.5 KB · Просмотры: 2
  • Screenshot_2019_01_30_14_23_59.png
    Screenshot_2019_01_30_14_23_59.png
    83.5 KB · Просмотры: 2
  • Screenshot_2019_01_30_14_24_56.png
    Screenshot_2019_01_30_14_24_56.png
    155.8 KB · Просмотры: 1
  • Screenshot_2019_01_30_14_49_14.png
    Screenshot_2019_01_30_14_49_14.png
    102.9 KB · Просмотры: 2
  • Screenshot_2019_01_30_14_49_21.png
    Screenshot_2019_01_30_14_49_21.png
    111.2 KB · Просмотры: 0
  • Screenshot_2019_01_30_15_21_31.png
    Screenshot_2019_01_30_15_21_31.png
    58.2 KB · Просмотры: 1
Сергей Русанов написал(а):
Добрый день, коллеги. Хотим познакомить вас с новой программой мониторинга техобслуживания лифтов "Лифт Мониторинг 2.0."

Состав продукта:
Диспетчерская с web-интерфейсом
Мобильное приложение электромеханика
. . . . .

Обсуждение стороннего коммерческого продукта "Лифт Мониторинг 2.0." перенесено в раздел "Куплю-Продам". Лифт Мониторинг 2.0.
 
Последнее редактирование модератором:
Назад
Сверху