Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Лифт-Комплекс ДС _ Программное обеспечение _ Система обработки заявок

Автор: Андрей Ефименко 20.6.2018, 18:07

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

Опять же хорошо бы отделить SPult от самой системы обработки заявок, так как может использоваться уже готовая система (какая-то CRM), либо организация, обслуживающая лифты, имеет возможность создать свою систему. Ну и "Лифт-комплекс ДС" мог бы попытаться разработать отчуждаемую систему обработки заявок.

Современные веяния - это использование распределённых вычислительных систем и WEB интерфейсов. Таким образом, SPult мог бы сформировать, например, HTML POST запрос с телом в виде XML строки, содержащей параметры заявки и получить какой-то ответ о статусе этой заявки. Этот запрос может быть передан от SPult в систему обработки заявок по протоколу http или https. В настройках SPult носится URL (возможно с портом), куда и отправляется запрос. На этом функции SPult, в части работы с заявками, заканчиваются.

Вся дальнейшая работа с введённой заявкой производится уже в системе обработки заявок, имеющей, например, WEB интерфейс.

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

Автор: revit 21.6.2018, 14:19

Не совсем понимаю о какой заявке формируемой в СПульт идет речь? Система ОБЬ и программа Спульт в частности используется для контроля, получения данных с лифтов и осуществления ГГС и информация полученная из нее анализируется сначала персоналом (диспечтером) и только после анализа принимается решение оформлять завку или нет. ИМХО нельзя однозначно интерпретировать данные полученные с лифтов .

Автор: sergey57949 21.6.2018, 16:08

Я так понимаю, диспетчер жмет кнопку "оформить заявку" и формируется первая часть заявки - Адрес, время, причина /допустим многократный реверс/
А потом ручками дописывает что сделал механик и время устранения.
В идеале лучше чтоб механик с Аспульта закрывал заявку.
Мечты, мечты

Автор: revit 21.6.2018, 17:31

Но тогда нужна синхронизация базы адресов Спульт и программы обработки заявок т.к. вбивают адреса лифтов и идентификаторы их местоположения кому как понравится в разных программах. У нас допустим это самодельная прога на базе MySQL и там своя база адресов и бывают накладки и несовпадения с адресами в Спульт. В планах реализовать ее на базе платформы 1С

Автор: Андрей Ефименко 22.6.2018, 9:19

Цитата(sergey57949 @ 21.6.2018, 17:08) *

Я так понимаю, диспетчер жмет кнопку "оформить заявку" и формируется первая часть заявки - Адрес, время, причина /допустим многократный реверс/
А потом ручками дописывает что сделал механик и время устранения.
В идеале лучше чтоб механик с Аспульта закрывал заявку.
Мечты, мечты

Действительно, диспетчер в SPult формирует саму заявку на ремонт лифта. Как уже писал, SPult передаёт заявку другой системе - системе контроля обработки заявки, которая уже дальше ведёт контроль исполнения этой заявки. Хорошо бы, что бы система обработки заявки имела WEB интерфейс и механики дописывали со смартфонов и компьютеров любого типа в браузере (не в ASPult) свои действия.

Автор: sergey57949 22.6.2018, 9:27

Идея хороша.
Но я за то чтобы прога исходила от ЛКДС.
Не то чтоб им не чем занятся, просто я за единообразие.

Автор: Андрей Ефименко 22.6.2018, 9:30

Цитата(revit @ 21.6.2018, 18:31) *

Но тогда нужна синхронизация базы адресов Спульт и программы обработки заявок т.к. вбивают адреса лифтов и идентификаторы их местоположения кому как понравится в разных программах. У нас допустим это самодельная прога на базе MySQL и там своя база адресов и бывают накладки и несовпадения с адресами в Спульт. В планах реализовать ее на базе платформы 1С

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

И конечно нужна синхронизация баз данных LKDSDisp и системы обработки заявок, например, по какому-то уникальному полю записи лифта. Опять же и это нужно обсуждать

Автор: revit 22.6.2018, 11:35

Цитата(Андрей Ефименко @ 22.6.2018, 6:19) *

... Хорошо бы, что бы система обработки заявки имела WEB интерфейс и механики дописывали со смартфонов и компьютеров любого типа в браузере (не в ASPult) свои действия.
Может коненчо и круто, но на практике как будет -вопрос.... Диспетчер -главное звено в этой цепи "поломка/аварийная остановка-освобождение пассажира-устранение неисправности-запуск лифта в НР". Он должен и открыть заявку и проконтролировать ее выполнение и закрыть ее , либо передать (и открыть ее заново) другому персоналу и повторно проконтролировать. Если заявку будет закрывать механик своей записью, то диспечтер потеряет контроль выполнения этой зявки т.е не будет знать когда ее закрыли. Теоретически можно сделать оповещение диспечтера о закрытии заявки, но это уже ИМХО не нужные навороты т.к механики будут забывать это делать да и все правильно оформить-это тоже не про них. А просто дописывать что-то- тоже зачем оно им надо, время тратить? тем более и смартфонами еще не каждый пользуется... В данный момент при закрытии заявки диспечтер уточняет выполненные работы (чаще всего звонком по своей инициативе) и вписывает их.

Автор: Kranch 22.6.2018, 12:49

Цитата(revit @ 22.6.2018, 8:35) *

Может коненчо и круто, но на практике как будет -вопрос.... Диспетчер -главное звено в этой цепи "поломка/аварийная остановка-освобождение пассажира-устранение неисправности-запуск лифта в НР". Он должен и открыть заявку и проконтролировать ее выполнение и закрыть ее , либо передать (и открыть ее заново) другому персоналу и повторно проконтролировать. Если заявку будет закрывать механик своей записью, то диспечтер потеряет контроль выполнения этой зявки т.е не будет знать когда ее закрыли. Теоретически можно сделать оповещение диспечтера о закрытии заявки, но это уже ИМХО не нужные навороты т.к механики будут забывать это делать да и все правильно оформить-это тоже не про них. А просто дописывать что-то- тоже зачем оно им надо, время тратить? тем более и смартфонами еще не каждый пользуется... В данный момент при закрытии заявки диспечтер уточняет выполненные работы (чаще всего звонком по своей инициативе) и вписывает их.

Можно сделать, что бы механик мог поставить промежуточный статус заявки "Выполнено", но закрывает окончательно диспетчер. А вот диспетчеру нужно будет дополнительно её открыть, проверить по Spult и если все нормально закрыть, если нет, то пустить обратно в работу.

Автор: sergey57949 22.6.2018, 12:55

revit, а пиз бить механиков не пробовали, за то что не отзваниваются по заявкам?
Понятно что диспетчер главный и если мех сам отпишет заявку, хоть немного облегчит им жизнь.
Но закрыть заявку должен только диспетчер
А то был у меня юморист, синхрофазатрон у него сломался )))

Автор: Андрей Ефименко 22.6.2018, 13:02

Цитата(sergey57949 @ 22.6.2018, 10:27) *

Идея хороша.
Но я за то чтобы прога исходила от ЛКДС.
Не то чтоб им не чем занятся, просто я за единообразие.

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

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


Цитата(revit @ 22.6.2018, 12:35) *

Может коненчо и круто, но на практике как будет -вопрос.... Диспетчер -главное звено в этой цепи "поломка/аварийная остановка-освобождение пассажира-устранение неисправности-запуск лифта в НР". Он должен и открыть заявку и проконтролировать ее выполнение и закрыть ее , либо передать (и открыть ее заново) другому персоналу и повторно проконтролировать. Если заявку будет закрывать механик своей записью, то диспечтер потеряет контроль выполнения этой зявки т.е не будет знать когда ее закрыли. Теоретически можно сделать оповещение диспечтера о закрытии заявки, но это уже ИМХО не нужные навороты т.к механики будут забывать это делать да и все правильно оформить-это тоже не про них. А просто дописывать что-то- тоже зачем оно им надо, время тратить? тем более и смартфонами еще не каждый пользуется... В данный момент при закрытии заявки диспечтер уточняет выполненные работы (чаще всего звонком по своей инициативе) и вписывает их.

Именно в связи с многообразием подходов и предлагается сделать в SPult диспетчеру только помощь в формировании заявки, а все остальное уже обеспечит своя (или купленная) система, удовлетворяющая именно своим требованиям.

Автор: Kranch 22.6.2018, 13:19

Цитата(Андрей Ефименко @ 22.6.2018, 6:30) *

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

И конечно нужна синхронизация баз данных LKDSDisp и системы обработки заявок, например, по какому-то уникальному полю записи лифта. Опять же и это нужно обсуждать

Если говорить про набор параметров, то тут надо смотреть какие параметры требуется в сторонней системе, и какие можно выбирать. А если в общем, то передавать нужно ID(вся синхронизация привязана к данному параметру, так как все остальные параметры могут изменяться), Адрес, Справочные параметры(по которым в системе формируется список персонала кому можно передать заявку), можно ввести настраиваемый пункт"Передавать дополнительную информацию" если выбран, то дополнительно в теле Описания заявки приписывается информация, которая указана в панели управления лифтом на момент нажатия кнопки создать заявку(типа: +Аварийная блокировка +43 Неисправна цепь блокировок)

Автор: StAlex 28.6.2018, 11:22

Цитата(Андрей Ефименко @ 20.6.2018, 15:07) *

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


Вполне рабочий подход (поддерживаю). Давно мечтал.
Поля заявки: дата, время, номер заявки, кто принял, кому передана, тип заявки, комментарий, фио заявителя, адрес с подъездом, телефон. Хотя поля заявки я бы сделал настраиваемыми - требования у разных организаций разные.

Автор: revit 28.6.2018, 15:13

Цитата(StAlex @ 28.6.2018, 8:22) *

Хотя поля заявки я бы сделал настраиваемыми - требования у разных организаций разные.
:-) И сколько таких организаций? И скольок различных программ? И вообще как совместить несовместимое?

Автор: sergey57949 28.6.2018, 16:53

Вот поэтому я за то, чтоб была прога от ЛКДС.
Насчет требований тоже не вижу предмета спора.
Дата, время, адрес и причина остановки берется с Спульта, остается добавить время устранения и причину вызвавшую остановку и ФИО устранившего.
Это базовые поля.
А вот дальше желательно бы иметь возможность добавлять поля, хотя вышеперечисленные поля меня вполне устраивают, но тут уж все от разработчиков зависит

Автор: revit 28.6.2018, 22:36

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

Автор: Андрей Ефименко 29.6.2018, 8:54

Цитата(revit @ 28.6.2018, 23:36) *

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

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

Выбор транспорта (http) и формата данных ("XML") для передачи заявки определяется широким их распространением в распределённых сетях, ну и промышленная система обработки заявок должна понимать этот транспорт, этот формат и позволять адаптацию для приема подобных данных.

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

Автор: Михеев Виталий 3.7.2018, 15:48

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

Автор: Pro100A1ex 3.7.2018, 21:31

Цитата(sergey57949 @ 28.6.2018, 16:53) *

Вот поэтому я за то, чтоб была прога от ЛКДС.

Поддерживаю, за это решение отдельно и заплатить даже можно
Цитата(revit @ 28.6.2018, 22:36) *

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

Вот поэтому и нужно, чтобы программа была от ЛКДС как дополнение к СПульту, с возможностью привязки к карте города с расположением лифтов и местонахождением обслуживающего персонала (с помощью GPS контроля), вот тогда действительно будет рациональное принятие решения по обработке и распределению заявок на устранение сбоев в работе лифтов.
Если данная концепция приемлема для разработчика, то готов изложить мысли по этому поводу smile.gif

Автор: sergey57949 4.7.2018, 10:43

Pro100A1ex, эй полегче, не спугни.
Пусчай журнал сделают, gps потом просить будем biggrin.gif biggrin.gif biggrin.gif


Цитата(Pro100A1ex @ 3.7.2018, 21:31) *

Поддерживаю, за это решение отдельно и заплатить даже можно

Куда деньги переводить?

Автор: Pro100A1ex 4.7.2018, 21:02

Цитата(sergey57949 @ 4.7.2018, 10:43) *

Куда деньги переводить?

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

biggrin.gif biggrin.gif biggrin.gif

Автор: kurilka 18.7.2018, 10:18

Я полностью поддерживаю это

Цитата(Андрей Ефименко @ 20.6.2018, 19:07) *
отделить SPult от самой системы обработки заявок, так как может использоваться уже готовая система...
А так как большинство систем учета заявок имеют встроенный почтовый парсер, то достаточно сформировать и отправить письмо с необходимой информацией из SPult, чтобы было так
Цитата(Андрей Ефименко @ 20.6.2018, 19:07) *
Вся дальнейшая работа с введённой заявкой производится уже в системе обработки заявок...


Автор: revit 18.7.2018, 11:22

Цитата(kurilka @ 18.7.2018, 7:18) *
А так как большинство систем учета заявок имеют встроенный почтовый парсер, ....
Это откуда такая статистика?

Автор: sergey57949 18.7.2018, 13:20

У меня такая система учета biggrin.gif biggrin.gif biggrin.gif
Поэтому и жду систему от разработчиков


Эскизы прикрепленных изображений
Прикрепленное изображение

Автор: kurilka 19.7.2018, 10:58

Цитата(revit @ 18.7.2018, 12:22) *
Это откуда такая статистика?
Из тех, что нами были рассмотрены.

Цитата(sergey57949 @ 18.7.2018, 14:20) *
Поэтому и жду систему от разработчиков
Чтобы не ждать, можно попробовать систему от сторонних разработчиков. Готовых проектов много, в том числе opensource.

Автор: sergey57949 19.7.2018, 12:22

Скиньте ссылочку на готовый проект, если не трудно

Автор: kurilka 19.7.2018, 15:43

sergey57949 из того, что помню:
trellis desk, freehelpdesk, osTicket, Reguest Tracker, hesk, itop, redmine, otrs, glpi.
Поиск по словам help desk, service desk, тикет система.

Автор: sergey57949 19.7.2018, 17:30

Благодарствую.
Побуду назойливым. А какой из них вы пользуетесь?
Я так понимаю, вы выбрали приемлемую для себя.
Мне чтоб не перебирать все подряд.

Автор: kurilka 19.7.2018, 20:45

osTicket - чем он мне не понравился уже не помню, но посмотреть стоит.
hesk - не плох, легкий интерфейс, база знаний, настраиваемые поля... Для меня был кандидатом №1.
otrs - монстр в плане интерфейса, для меня слишком перегружен. Не пошел, хоть и очень гибко настраиваемый.
redmine - очень круто, но из коробки пользоваться сложно. Если с программированием дружба, есть свободное время и не лень этим заниматься, то рекомендую, может получиться очень мощная система. Мне лень, у меня не прижился.
glpi - определяющим фактором, помимо активности проекта, для меня стала встроенная система инвентаризации. Внес туда все оборудование, контакты, поставщиков, договора, настроил автоматические уведомления. В общем с ней и живу 2+ года. НО! К интерфейсу надо привыкнуть, как то французы немного не логичны, что ли.
В общем, проект должен быть активным. Это главное. Если последнее обновление было год назад и форум в спячке, то смотреть на такие проекты не стоит. Если нужна просто тикет-система - hesk, osTicket и им подобные. Выбор по дружелюбности интерфейса.
Кстати, у некоторых проектов есть demo-сайты. Можно без установки посмотреть и "пощупать" интерфейс. Точно есть у trellis desk, itop, otrs, glpi, hesk.

Автор: ВячеславK 21.11.2018, 12:12

Цитата(Андрей Ефименко @ 20.6.2018, 19:07) *

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

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

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

Автор: Андрей Ефименко 22.11.2018, 8:21

Цитата(ВячеславK @ 21.11.2018, 13:12) *

Вставлю свои пять копеек... Возможность связи 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 это возможно.


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

Автор: Андрей Ефименко 13.12.2018, 14:56

Цитата(Андрей Ефименко @ 22.11.2018, 9:21) *

Именно, что бы не плодить сущности и было предложено передавать заявку в виде 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 это возможно.
Опять же, что бы не плодить сущности, как альтернатива формированию предложенного файла, можно использовать возможность вывода оператором в журнал специальной записи Прикрепленное изображение, которую оператор может сформировать по своей инициативе. Приложение, которое должно было обрабатывать файл, может читать записи журнала в базе данных, извлекать сообщения оператора и обрабатывать записи оператора, так же, как обрабатывало бы файлы.

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

Описание доработок в https://lkds.ru/soft/unpacked/LKDSDrv_Beta/SPult/SPultServiceRequest.xps

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

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

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

Автор: sergey57949 13.12.2018, 17:27

У меня не запускается


Эскизы прикрепленных изображений
Прикрепленное изображение

Автор: Андрей Ефименко 14.12.2018, 8:15

Цитата(sergey57949 @ 13.12.2018, 18:27) *

У меня не запускается

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

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

Либо перепишите файл BoODLL.dll из установленного дистрибутива в папку на своём компьютере, из которой запускаете SPult.

Автор: ВячеславK 19.12.2018, 10:39

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


Эскизы прикрепленных изображений
Прикрепленное изображение

Автор: Андрей Ефименко 19.12.2018, 15:13

Цитата(ВячеславK @ 19.12.2018, 11:39) *

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

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

Прикрепленное изображение

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

Прикрепленное изображение

Автор: Андрей Ефименко 20.12.2018, 7:52

Цитата(ВячеславK @ 19.12.2018, 11:39) *

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

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

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

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

SPult выложен в штатное обновление ПО

Автор: sergey57949 27.1.2019, 14:43

Наткнулся вот на такое- https://play.google.com/store/apps/details?id=com.onisoft.lmonitor
Правда за неделю так ни кто и не откликнулся, чтоб попробовать этот продукт.
Но идея не плоха.

Автор: sergey57949 1.2.2019, 11:17

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




Эскизы прикрепленных изображений
Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение

Автор: oleg 1.3.2019, 8:24

Цитата(Сергей Русанов @ 27.2.2019, 8:45) *

Добрый день, коллеги. Хотим познакомить вас с новой программой мониторинга техобслуживания лифтов "Лифт Мониторинг 2.0."

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

Обсуждение стороннего коммерческого продукта "Лифт Мониторинг 2.0." перенесено в раздел "Куплю-Продам". https://forum.lkds.ru/index.php?showtopic=3602

Автор: sergey57949 14.3.2019, 13:09

Цитата(Андрей Ефименко @ 13.12.2018, 14:56) *

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

Описание доработок в https://lkds.ru/soft/unpacked/LKDSDrv_Beta/SPult/SPultServiceRequest.xps

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

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

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


А можно к "формированию заявки..." чтоб автоматом посылалось состояние лифта и этаж на котором стоит кабина?

Автор: Андрей Ефименко 14.3.2019, 13:33

Цитата(sergey57949 @ 14.3.2019, 14:09) *

А можно к "формированию заявки..." чтоб автоматом посылалось состояние лифта и этаж на котором стоит кабина?

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

Автор: sergey57949 14.3.2019, 14:03

Да есть.
Сейчас с Лифтмониторинг испытываем.
Работает, но для полноты картины, желательно бы иметь эти данные.
Держать 2 приложения (спульт и лифтмониторинг) наверное нецелесообразно, батарею вмиг посадишь.
Тестирую сейчас на пару механиков.

Автор: Андрей Ефименко 14.3.2019, 15:36

Цитата(sergey57949 @ 14.3.2019, 15:03) *

Да есть.
Сейчас с Лифтмониторинг испытываем.
Работает, но для полноты картины, желательно бы иметь эти данные.
Держать 2 приложения (спульт и лифтмониторинг) наверное нецелесообразно, батарею вмиг посадишь.
Тестирую сейчас на пару механиков.

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

Автор: Андрей Ефименко 16.3.2019, 7:49

Некоторые работы по интеграции с https://forum.lkds.ru/index.php?s=&showtopic=3602&view=findpost&p=25485 проведены.

По результатам в папку https://lkds.ru/soft/unpacked/LKDSDrv_Beta/SPult/ выложен SPult и https://lkds.ru/soft/unpacked/LKDSDrv_Beta/SPult/SPultServiceRequest.xps по взаимодействию.


Автор: sergey57949 11.4.2019, 10:04

Наверное настало время сделать небольшой отчет о работе Лифтмониторинг с Спульт.

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

Минусы: 1.Есть места где нет интернета, приходиться перезванивать (это просто минус, без претензии к обоим организациям)
2.Все таки необходимо, что бы Спульт выдавал неисправности формируемые системой Обь (возможно даже другим цветом, чтоб не путать с сообщением от диспетчера)
3. Нужно все привести в порядок, т.е. ФИО механиков не должны дублироваться (ну это ко мне претензия, как к админу)

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

Вообщем система работает и этим нужно пользоваться

Автор: Андрей Ефименко 17.4.2019, 9:15

Цитата(sergey57949 @ 11.4.2019, 11:04) *

2.Все таки необходимо, что бы Спульт выдавал неисправности формируемые системой Обь (возможно даже другим цветом, чтоб не путать с сообщением от диспетчера)

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

Автор: sergey57949 17.4.2019, 9:49

Полезность несомненно есть и очень большая.
Ведется электронный журнал, что очень упрощает работу диспетчеров.
Автоматом вписывается дата/время заявки.
Тут бы ни мне одному тестить, а еще бы пару человек, мнение было бы более обьективно.

Автор: revit 17.4.2019, 11:40

Цитата(sergey57949 @ 17.4.2019, 6:49) *
Ведется электронный журнал, что очень упрощает работу диспетчеров.
Упрощает если других журналов вести не нужно. Но т.к. у каждой фирмы есть свои программы электронных журналов заявок, то чтобы не дублировать заявки, нужно либо полностью переходить на вашу, либо использовать ее только как мониторинг (это не для диспетчеров).

Автор: sergey57949 17.4.2019, 12:08

24-м сообщением я показывал какой у меня электронный журнал biggrin.gif
Так другие можно не вести, по крайней мере ПП 331 о аварийно-диспетчерской службе от 01.03.19 позволяет вести электронный журнал.
Ребята совместили контроль за выполнением ТО, местонахождение механика, выполнение заявок.
Разве это плохо???
Продукт немного сыроват, но довести до ума вполне можно.
Ну и если интересно, то сотрудничество с ними на платной основе у нас не задалось, поэтому занимаюсь тестами безвозмездно. Трачу свое время, т.к. считаю что за такими системами будущее.
Но это мое мнение, ни кому не навязываю

Автор: Nikolaj76 28.9.2021, 23:12

Добрый вечер. Есть несколько пожеланий по системе отправки сообщений:
1. На не контролируемом лифте добавить возможность формирования заявки диспетчером.
2. Хотелось бы в отправляемом сообщении видить данные об учётной записи с которой отправлено сообщение.
3. Добавить возможность администратору редактировать выпадающий список частых неисправностей.
Возможно ли это реализовать в дальнейших версиях Spult?

Автор: Андрей Ефименко 29.9.2021, 8:29

Цитата(Nikolaj76 @ 29.9.2021, 0:12) *

Добрый вечер. Есть несколько пожеланий по системе отправки сообщений:
1. На не контролируемом лифте добавить возможность формирования заявки диспетчером.

Это будет добавлено.

Цитата(Nikolaj76 @ 29.9.2021, 0:12) *

2. Хотелось бы в отправляемом сообщении видить данные об учётной записи с которой отправлено сообщение.

Имеется в виду имя пользователя, под которым подключился диспетчер ?

Цитата(Nikolaj76 @ 29.9.2021, 0:12) *

3. Добавить возможность администратору редактировать выпадающий список частых неисправностей.
Возможно ли это реализовать в дальнейших версиях Spult?

Это можно будет сделать в настройках самого SPult, т.е. на конкретном компьютере диспетчера.


Хотел обратить внимание, что в отправляемую заявку добавлен список текущих состояний лифта Прикрепленное изображение

Автор: Nikolaj76 29.9.2021, 9:00

Цитата(Андрей Ефименко @ 29.9.2021, 5:29) *

Имеется в виду имя пользователя, под которым подключился диспетчер ?
да именно это.

Автор: Андрей Ефименко 4.10.2021, 8:37

Сегодня в обновление ПО выложен SPult, в котором:

Цитата(Nikolaj76 @ 29.9.2021, 0:12) *

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

По меню правой кнопки мыши в панели структуры и в панели состояний можно послать заявку на обслуживание, в том числе неконтролируемых лифтов Прикрепленное изображение

Цитата(Nikolaj76 @ 29.9.2021, 0:12) *

2. Хотелось бы в отправляемом сообщении видить данные об учётной записи с которой отправлено сообщение.

в тег <Lift> заявки на обслуживание лифта добавлен параметр User="<имя_подключившегося_пользователя>":

<?xml version="1.0"?>
<PULT ContentType="request" Name="Exampl" GUID="B963B703D5AC421EA221C908E2041C96" IdDB="18">
<DISP Name="Диспетчерская" IdDB="27">
<STREET Name="ул. LKDSPro_" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="4" GUID="A8960FEDC7984F949B7F158D3C1B0AB6" IDPro="21" InsContr="1" IdDB="11" Note="4.Устранение неисправностей диспетчерского оборудования" User="Chief">
<ListStatus>
<Status Name="КЗ цепи безопасности"/>
<Status Name="Авария привода дверей"/>
<Status Name="Открыто МП"/>
<Status Name="Главный привод включен"/>
<Status Name="Кабина в движении"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>

Автор: Nikolaj76 4.10.2021, 14:37

Спасибо за оперативность и Ваши труды. Все работает

Автор: anatoliy 12.1.2022, 2:00

Добрый день .
Когда лет 6 назад, тоже писал (точнее переделывал) вэб версию электронного журнала регистрации заявок.
Вариант - черновик, но работает, проверял локально на Денвере . Кто захочет https://disk.yandex.ru/d/EgB9WAspzUYbJw. Используется PHP5 (проверил на PHP 7) + MySQL. Решил по мере наличия времени доделать.
Сейчас прикрутил возможность приема заявок из SPult. В общем возникли две "хотелки":
1. придумать какой то способ (ну типа ключа) для однозначной идентификации на стороне сервера XML данных от spult.
2. При формировании заявки - добавить поле с выбором сотрудника из списка зарегистрированных сервисных ключей, что бы можно было его автоматически назначить ответственным. В выпадающем списке показывать владельца (обычно туда ФИО заносят), а в XML передавать номер сервисного ключа. Но или фамилию тоже.
Пункт 2 думаю будет полезен многим.

Автор: Андрей Ефименко 12.1.2022, 9:05

Цитата(anatoliy @ 12.1.2022, 3:00) *

1. придумать какой то способ (ну типа ключа) для однозначной идентификации на стороне сервера XML данных от spult.

Не понятно, что такое "однозначная идентификация на стороне сервера XML данных от spult" и для чего она нужна. Заявка на строне клиента (SPult) не хранится. Вся работа с заявкой производится на стороннем сервере.

Как бы могла выглядеть эта идентификация в теле самой заявки ?:

POST /lkds HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 372
Connection: keep-alive
Cache-Control: no-cache

<?xml version="1.0"?>
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>

Автор: anatoliy 12.1.2022, 11:39

Цитата(Андрей Ефименко @ 12.1.2022, 9:05) *

Не понятно, что такое "однозначная идентификация на стороне сервера XML данных от spult" и для чего она нужна. Заявка на строне клиента (SPult) не хранится. Вся работа с заявкой производится на стороннем сервере.

Как бы могла выглядеть эта идентификация в теле самой заявки ?:




Ключ вводить в настройках подключения SPult , и передавать например так:

POST /lkds HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 372
Connection: keep-alive
Cache-Control: no-cache

<?xml version="1.0"?>

<APIKEY ="Ключ введеный в настройках подключения SPult">
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>


Автор: Андрей Ефименко 12.1.2022, 15:56

Цитата(anatoliy @ 12.1.2022, 12:39) *

Ключ вводить в настройках подключения SPult , и передавать например так:

POST /lkds HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 372
Connection: keep-alive
Cache-Control: no-cache

<?xml version="1.0"?>

<APIKEY ="Ключ введеный в настройках подключения SPult">
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>


Т.е. это идентификация установки SPult ?
И во всех заявках, сформированным SPult на данном компьютере это поле одинаково ?


Автор: anatoliy 12.1.2022, 21:21

Цитата(Андрей Ефименко @ 12.1.2022, 15:56) *

Т.е. это идентификация установки SPult ?
И во всех заявках, сформированным SPult на данном компьютере это поле одинаково ?

Скорее установки организации. Что бы можно было с нескольких установок SPult отправлять заявки в одну базу . И что бы можно было однозначно понять что это данные именно наши, а не кто-то пытается подсунуть левый XML, и если ключ не соответствует, то просто игнорируем данные и выдаем 404 ошибку.

Автор: Андрей Ефименко 13.1.2022, 8:32

Цитата(anatoliy @ 12.1.2022, 22:21) *

Скорее установки организации. Что бы можно было с нескольких установок SPult отправлять заявки в одну базу . И что бы можно было однозначно понять что это данные именно наши, а не кто-то пытается подсунуть левый XML, и если ключ не соответствует, то просто игнорируем данные и выдаем 404 ошибку.


Тогда это следующий параметр:

POST /lkds HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 372
Connection: keep-alive
Cache-Control: no-cache

<?xml version="1.0"?>
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>

Данный параметр однозначно определяет одну организацию в LKDSCloud и LKDSDomain
И одну установку LKDSDisp

Автор: anatoliy 14.1.2022, 1:21

Цитата(Андрей Ефименко @ 13.1.2022, 8:32) *

Тогда это следующий параметр:

...
<?xml version="1.0"?>
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
.....
Данный параметр однозначно определяет одну организацию в LKDSCloud и LKDSDomain
И одну установку LKDSDisp

Т.е. это не идентификатор установки SPult? И он останется неизменным, даже если установлю SPult на другой компьютер? Естественно подключение будет к тому-же lkdsdisp или Domain!

А что по поводу выбора ответственного из формы формирования заявки, возможно такое ?

Автор: Андрей Ефименко 14.1.2022, 15:51

Цитата(anatoliy @ 14.1.2022, 2:21) *

Т.е. это не идентификатор установки SPult? И он останется неизменным, даже если установлю SPult на другой компьютер? Естественно подключение будет к тому-же lkdsdisp или Domain!

Да так.

В базе данных LKDSDISP это поле Прикрепленное изображение
В базе данных LKDSDOMAIN это поле Прикрепленное изображение

Цитата(anatoliy @ 14.1.2022, 2:21) *

А что по поводу выбора ответственного из формы формирования заявки, возможно такое ?

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

Автор: anatoliy 14.1.2022, 22:37

Цитата(Андрей Ефименко @ 14.1.2022, 15:51) *

Да так.

Ну тогда это то что надо!
Цитата(Андрей Ефименко @ 14.1.2022, 15:51) *


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

Прикрепленное изображение
Нижнее поле же есть, и оно не активно. Его и использовать, только первым пунктом, (по умолчанию) будет 0 , т.е.выбор пустой. Или это поле зарезервировано для каких-то других целей?
Ну или давайте подождем мнение других.

Автор: Nikolaj76 12.2.2022, 20:49

Цитата(Андрей Ефименко @ 14.1.2022, 12:51) *

Да так.

В базе данных LKDSDISP это поле Прикрепленное изображение
В базе данных LKDSDOMAIN это поле Прикрепленное изображение
Технически, конечно, можно в форме сделать выбор из выпадающего списка обладателя сервисного ключа с номером сервисного ключа и передать эту информацию в POST запросе.
Сделать только это нужно так, что бы не сильно напрячь других пользователей изменением формы заявки.

Лично мое скромное мнение ни на что не претендующие: в запросе есть вся необходимая информация для выполнения заявки. Более детальная и подробная информация есть в основной базе SQL Spult. Единственное пожелание диспетчеров на которых сейчас мы это обкатываем, увеличить количество вводимых символов в форме Spult . Им приходится часто прибегать к сокращениям слов.
По поводу XML - не хотелось бы чтобы он поменял свою структуру внезапно. Т.К в нашем случае данные из него автоматом обрабатываются, записываются в базу и уже от туда формируется заявка, после чего диспетчеру остается только закрыть заявку написав комментарий и время пуска, когда механик доложит о выполнении.

Автор: Андрей Ефименко 13.2.2022, 9:44

Цитата(Nikolaj76 @ 12.2.2022, 21:49) *

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

Имеется в виду увеличить ширину поля Прикрепленное изображение?

Цитата(Nikolaj76 @ 12.2.2022, 21:49) *

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

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

Автор: Nikolaj76 13.2.2022, 12:31

Цитата(Андрей Ефименко @ 13.2.2022, 6:44) *

Имеется в виду увеличить ширину поля Прикрепленное изображение?

Сам размер поля устраивает, количество вводимых символов не хватает. Сейчас можно ввести не более 61 символ.
Цитата(Андрей Ефименко @ 13.2.2022, 6:44) *

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

У нас данные из SPult обрабатываются с помощью PHP на сервере. Преобразуются в многомерный массив и от туда нужные данные раскладываются в базу SQL. Например имя диспетчерской выглядит так - ["DISP"]["@attributes"]["Name"] Сделано это потому что данный файлик Spult не на чистом XML. Его структура отличается от классического построения. При изменении структуры файла (изменении количества либо наименования тегов) массив тоже измениться. По этой же причине сейчас проблематично для меня обработать неисправности переданные в данном файле. Дело в том что они идут под одним и тем же тегом:
<ListStatus>
<Status Name="Пожарная опасность"/>
<Status Name="Кабина стоит"/>
</ListStatus>

и их количество меняется постоянно ( от 1 и до бесконечности). Можно конечно к ним обратиться с помощью функции foreach, но на мой взгляд удобнее было бы если данная информация шла под одним тегом
<Status> Name="Пожарная опасность. Кабина стоит" </Status>

Автор: Андрей Ефименко 13.2.2022, 15:25

Цитата(Nikolaj76 @ 13.2.2022, 13:31) *

Сделано это потому что данный файлик Spult не на чистом XML. Его структура отличается от классического построения.

Хотелось бы узнать подробнее в чем "нечистость" и отличие от классического построения строки XML, которую SPult передаёт в качестве заявки на обслуживание.

Автор: Nikolaj76 13.2.2022, 21:06

В моем понимании( возможно не совпадающем с Вашим)
пример XML:
<?xml version="1.0"?>
<CAT>
<NAME>Izzy</NAME>
<BREED>Siamese</BREED>
<AGE>6</AGE>
<ALTERED>yes</ALTERED>
<DECLAWED>no</DECLAWED>
<LICENSE>Izz138bod</LICENSE>
<OWNER>Colin Wilcox</OWNER>
</CAT>

И Ваш код:
<?xml version="1.0"?>
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>
Вопрос (Без каких либо упреков, недовольства либо сарказма в Ваш адрес): Как обработать данный файл тег <Status> если он не один, его количество неизвестно и в каждом запросе отличается? цель обработки- формирование таблички в базе данных где каждый тег это своя ячейка.

P/S: еще раз не воспринимайте это как критику. Вы проделали огромный фронт работ и система Обь востребована в сфере лифтового хозяйства. Вы разработчик и мы в любом случае можем лишь подстраиваться под Ваше программное обеспечение. Но человек по своей натуре лентяй ( и я не исключение) поэтому хотелось бы при взаимодействие с Вашим оборудованием и программным обеспечением совершать как можно меньше лишних телодвижений rolleyes.gif

Автор: Андрей Ефименко 14.2.2022, 8:23

Цитата(Nikolaj76 @ 13.2.2022, 22:06) *

В моем понимании( возможно не совпадающем с Вашим)
пример XML:
<?xml version="1.0"?>
<CAT>
<NAME>Izzy</NAME>
<BREED>Siamese</BREED>
<AGE>6</AGE>
<ALTERED>yes</ALTERED>
<DECLAWED>no</DECLAWED>
<LICENSE>Izz138bod</LICENSE>
<OWNER>Colin Wilcox</OWNER>
</CAT>

И Ваш код:
<?xml version="1.0"?>
<PULT ContentType="request" Name="Test" GUID="E91AF61B9F2E47AA82A23310ECB01D85" IdDB="1">
<DISP Name="Диспетчерская" IdDB="1">
<STREET Name="ул. Pro" IdDB="3">
<HOME Name="д. Pro" IdDB="3">
<LIFT Name="п. 1" ID="3" GUID="C3AE5B687D17410FB52953E84D793F2B" IDPro="1" IdDB="5" Note="Не работает"
<ListStatus>
<Status Name="Открыто МП"/>
<Status Name="Кабина стоит"/>
</ListStatus>
</LIFT>
</HOME>
</STREET>
</DISP>
</PULT>
Вопрос (Без каких либо упреков, недовольства либо сарказма в Ваш адрес): Как обработать данный файл тег <Status> если он не один, его количество неизвестно и в каждом запросе отличается? цель обработки- формирование таблички в базе данных где каждый тег это своя ячейка.

P/S: еще раз не воспринимайте это как критику. Вы проделали огромный фронт работ и система Обь востребована в сфере лифтового хозяйства. Вы разработчик и мы в любом случае можем лишь подстраиваться под Ваше программное обеспечение. Но человек по своей натуре лентяй ( и я не исключение) поэтому хотелось бы при взаимодействие с Вашим оборудованием и программным обеспечением совершать как можно меньше лишних телодвижений rolleyes.gif

Язык XML https://ru.wikipedia.org/wiki/XML
И важно понять соответствует ли XML строка заявки стандарту на язык.
Если есть какие-то сомнения, то хотел бы их получить со ссылками на стандарт.

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

Конфигурационные файлы ДК "Обь" используют XML. Большие массивы данных передаются между модулями в виде XML.

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

Формируются и читаются XML данных штатными процедурами C++, C#, Java, Swift

Вот пример реального XML описания экранной формы универсального приложения Microsoft:

<Page
x:Class="WSPult.BatteryPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:WSPult"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" SizeChanged="Page_SizeChanged">

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
<TextBlock x:Name="Address" Margin="0,0,0,0" Grid.Row="0" TextWrapping="Wrap" Text="TextBlock" VerticalAlignment="Top" FontSize="18" FontStyle="Italic"/>
<StackPanel Grid.Row="1" Orientation="Horizontal">
<TextBlock x:Uid="BatteryPageStatus" FontSize="18" />
<TextBlock x:Name="Status" x:Uid="BatteryPageStatusGood" Margin="10,0,0,0" FontSize="18" />
</StackPanel>
<StackPanel Grid.Row="2" Orientation="Horizontal">
<TextBlock x:Uid="BatteryPageNextTest" FontSize="18" />
<TextBlock x:Name="Next" x:Uid="BatteryPageTimeTest" Margin="10,0,0,0" FontSize="18" />
</StackPanel>
<StackPanel Grid.Row="3" Orientation="Horizontal">
<TextBlock Text="Uzar:" FontSize="18" />
<TextBlock x:Name="UZar" Text="UZar" Margin="10,0,0,0" FontSize="18" />
<TextBlock Text="Ustart:" Margin="10,0,0,0" FontSize="18" />
<TextBlock x:Name="Ustart" Text="Ustart" Margin="10,0,0,0" FontSize="18" />
<TextBlock Text="Ufinish:" Margin="10,0,0,0" FontSize="18" />
<TextBlock x:Name="Ufinish" Text="Ufinish" Margin="10,0,0,0" FontSize="18" />
</StackPanel>
<Canvas x:Name="PanelGraph" Grid.Row="4">
<Line x:Name="BegVert" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="2"/>
<TextBlock x:Name="BegVertNum" Text="" FontSize="18" />
<Line x:Name="BegGoriz" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="2"/>
<TextBlock x:Name="BegGorizNum" Text="" FontSize="18" />
<Line x:Name="Line1" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num1" Text="" FontSize="18" />
<Line x:Name="Line2" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num2" Text="" FontSize="18" />
<Line x:Name="Line3" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num3" Text="" FontSize="18" />
<Line x:Name="Line4" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num4" Text="" FontSize="18" />
<Line x:Name="Line5" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num5" Text="" FontSize="18" />
<Line x:Name="Line6" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num6" Text="" FontSize="18" />
<Line x:Name="Line7" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num7" Text="" FontSize="18" />
<Line x:Name="Line8" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num8" Text="" FontSize="18" />
<Line x:Name="Line9" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num9" Text="" FontSize="18" />
<Line x:Name="Line10" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num10" Text="" FontSize="18" />
<Line x:Name="Line11" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num11" Text="" FontSize="18" />
<Line x:Name="Line12" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num12" Text="" FontSize="18" />
<Line x:Name="Line13" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num13" Text="" FontSize="18" />
<Line x:Name="Line14" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num14" Text="" FontSize="18" />
<Line x:Name="Line15" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="1"/>
<TextBlock x:Name="Num15" Text="" FontSize="18" />
<Path Stroke="Blue" StrokeThickness="4" >
<Path.Data>
<PathGeometry>
<PathGeometry.Figures>
<PathFigure x:Name="Graph">
</PathFigure>
</PathGeometry.Figures>
</PathGeometry>
</Path.Data>
</Path>
<TextBlock x:Name="CurU" Text="" FontSize="18" />
<TextBlock x:Name="TimEnd" Text="" FontSize="18" />
<Line x:Name="EndTestLine" Stroke="{ThemeResource ApplicationForegroundThemeBrush}" StrokeThickness="2"/>
<TextBlock x:Name="EndTestTime" Text="" FontSize="18" />
</Canvas>
</Grid>
</Page>








Автор: anatoliy 30.3.2022, 20:22

Цитата
Сделано это потому что данный файлик Spult не на чистом XML. Его структура отличается от классического построения. При изменении структуры файла (изменении количества либо наименования тегов) массив тоже измениться. По этой же причине сейчас проблематично для меня обработать неисправности переданные в данном файле. Дело в том что они идут под одним и тем же тегом:
<ListStatus>
<Status Name="Пожарная опасность"/>
<Status Name="Кабина стоит"/>
</ListStatus>

и их количество меняется постоянно ( от 1 и до бесконечности). Можно конечно к ним обратиться с помощью функции foreach, но на мой взгляд удобнее было бы если данная информация шла под одним тегом
<Status> Name="Пожарная опасность. Кабина стоит" </Status>

Вы возможно путаете с JSON? там немного другая структура. У ЛКДС XML вроде соответствует требованиям Мелкософта.
И я лично не совсем понимаю зачем каждую Status Name раскидывать в массив. Я их собираю в одну строку и кладу в ячейку базы с описанием неисправности.

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)