Учет заявок

[myth]

Всем привет. Решили перенести учет заявок(подключения, неисправности, итд) с тетрадки в какую-то программу. Кто чем пользуется для этого?

[wildmoon]

Если нет модуля у биллинга, то гуглодок.

[saaremaa]

Мы себе сами писали на Laravel с интеграцией Google map и SOAP Lanbilling. Именно того что Вам надо - врядли найдете из коробки.

[lodgic]

Мы используем сами собственную систему Gerp, эта система в которой работает аутсорсер Горсвязь. Ее уже на рынке поставили несколько крупных операторов. Тотальный контроль всем мастеров, очень круто. Вот один из отзывов

https://www.facebook.com/yasya.nazarova/posts/1801017933302868

 

Пишите в личку

[vop]

Модуль к биллингу. Учет заявок и ведение нарядов.

[FATHER_FBI]

Для ведения тикетов есть который продукт под названием osTicket

[Andriuxa]

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

[pppoetest]

1 час назад, Andriuxa сказал:

У нас самописное - полета для мысли больше.

+1

[myth]

Все тикет системы, что нахожу - излишне громоздкие и перегруженные. Не надо нам столько функционала. Опять же - чем проще тем лучше.

[default_vlan]

48 минут назад, myth сказал:

Не надо нам столько функционала. Опять же - чем проще тем лучше.

Так пиши своё. Можешь даже с биллингом обобщить. Берешь из БД всех абонов, и лепишь к ним заявки. Новое подключение - берешь список домов. Хочешь в БД биллинга таблицу заведи, хочешь в отдельную БД складывай, только основу из биллинга вырви (адреса, клиенты). Там даже форма будет проще простого - Адрес, тип заявки, описание, когда дома будут, телефон и статус.

Раздаешь права доступа - операторам на создание и редактирование, исполнителям на чтение и установку статуса исполнения . Систему "из коробки" ты не найдешь. Это как без фантика конфета. Либо не по назначению юзать, либо трети функционала использовать не будешь.

 

Хоть контору по изготовлению такого софта открывай.

Edited August 28, 2017 by default_vlan

[vop]

4 часа назад, default_vlan сказал:

Берешь из БД всех абонов

И опять вопрос отсутствия сколь-нибудь унифицированного API доступа к базе.

[myth]

Еще есть ктв dvb-c. Думаю писать свое, но не очень уверен в своих силах

[default_vlan]

14 часов назад, vop сказал:

И опять вопрос отсутствия сколь-нибудь унифицированного API доступа к базе.

Ну да, чтобы сделать "отщепенца" от общей БД или использовать уже существующую БД надо API писать, а еще лучше 2 MVC: 1 со стороны БД и 2 MVC со стороны клиента, и завернуть на это все kerberos, ssl и AAA. Парень не решается к БД подойти и хотя бы попробовать, а вы еще предлагаете API. PHP5-PDO - вот его API. KISS метод рулит.

 

2 часа назад, myth сказал:

Еще есть ктв dvb-c. Думаю писать свое, но не очень уверен в своих силах

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

[vop]

7 часов назад, default_vlan сказал:

Ну да, чтобы сделать "отщепенца" от общей БД или использовать уже существующую БД надо API писать, а еще лучше 2 MVC: 1 со стороны БД и 2 MVC со стороны клиента, и завернуть на это все kerberos, ssl и AAA. Парень не решается к БД подойти и хотя бы попробовать, а вы еще предлагаете API. PHP5-PDO - вот его API. KISS метод рулит.

Приходят ребята от UserSide, предлагают продукт.  Одному биллингу, другому. Задолбались писать сопряжение к очередному биллингу. Придумали собственный универсальный API для обмена данными с биллингом. И тут же натыкаемся на проблему, что собственный API создан "по мотивам" одного из знакомых биллингов, без абстракции данных. В результате, сопряжение с очередным биллингом по "универсальному API" просто теряет кучу данных. Это не считая других вопросов по этому универсальному API.

 

OK! Приходят другие ребята. Говорят - у нас просто ахрнененная апликуха под дроид и ифон - кабинет клиента провайдера. Хотите? Хотим, говорит великое начальство. Что надо для интеграции? Дайте на доступ к вашему MySQL.... Но у нас нет MySQL, говорит начальство.... Кино на этом заканчивается...

 

Не думаю, что надо рассказывать, зачем нужны унифицированные API,

[default_vlan]

7 часов назад, vop сказал:

Дайте на доступ к вашему MySQL.... Но у нас нет MySQL, говорит начальство.... Кино на этом заканчивается...

Что вы мне частные случаи приводите? MySQL, pgsql, Oracle, mdb, да хоть на чем, хоть в xml, sqlite или firebird даже ms-access будет бд. Любой разработчик должен предложить как это будет интегрироваться и какими методами. Либо это миграция на новый продукт с новой СУБД, либо это допиливание продукта под нужды клиента с минимальными изменениями. А нет - нахрен таких программеров. 
У биллингов Гидра, нетап, abills, моего самописного и т.д. разные структуры БД, не говоря уже о самих СУБД, а вы про единый API. Повод нейросеть написать, чтобы она анализировала к кому лучше запись прикрутить - к пользователю или к дому, а может дропнуть устаревшие записи. Ну а что, вложим $2000 минимум, через полгода ООО "Рога и копыта" если не закроется, то это нечто рандомное отдаст.

Тут по факту предлагаю человеку завести таблицу и делать связь один ко многим, ан нет, мы будем API писать полгода, потом его тестировать, а потом просто поменяем биллинг, потому что "Чет API не API'шный, не работает он тут." А это всё, насколько я понимаю, уважаемому myth надо было еще вчера, если не полгода как уже должно работать.

[vop]

22 минуты назад, default_vlan сказал:

Что вы мне частные случаи приводите?

....

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

 

Мне пришлось к своему билилнгу писать разные API. Их сейчас три полных (включая юзерсайдовский), и один - клиентский.  Куда дальше двигаться будем? :)

[default_vlan]

17 минут назад, vop сказал:

к своему билилнгу

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

[spdtv]

Мы используем программу MapMessagesGS от ГрадоСервис уже 2 года. Все отлично работает и есть и мобильная версия для монтеров. 

[ichthyandr]

В 27.08.2017 в 00:20, myth сказал:

Всем привет. Решили перенести учет заявок(подключения, неисправности, итд) с тетрадки в какую-то программу. Кто чем пользуется для этого?

redmine, бесплатный, полет ровный 1 год

Edited September 1, 2017 by ichthyandr
дополнено

[rdc]

В 29.08.2017 в 22:12, default_vlan сказал:

У биллингов Гидра, нетап, abills, моего самописного и т.д. разные структуры БД, не говоря уже о самих СУБД,

Причём тут вообще СУБД?

Это на уровне API решается.

 

Пример, как сделано у меня:

в биллинге в учётной карточке абонента добавлена кнопка "заявки".

нажимаем её - в тикетницу уходит POST-запрос с номером договора, названием и контактами абонента.

в итоге, тикетнице не надо лазить в БД биллинга - по мере появления заявок юзербаза заполняется сама, по мере закрытия чистится.

как результат, тикетница была успешно интегрирована как с моим биллингом, так и с биллингами партнёров, с которыми мы делали совместную техподдержку.

[YuryD]

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

[rdc]

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

[default_vlan]

16 часов назад, rdc сказал:

Причём тут вообще СУБД?

Это на уровне API решается.

При том, что человеку нужно унифицированное решение под любой биллинг и любую структуру базы данных и как следствие любую СУБД.

[rdc]

знание структуры базы данных для этого вообще не требуется.

нужна лишь элементарная доработка админки биллинга

[vop]

Опять про базы заговорили. Ребята, есть такое волшебное слово, как API. Если этого API до сих пор нет, то это говорит только о проблемах рынка биллингов.

 

1 час назад, rdc сказал:

нужна лишь элементарная доработка админки биллинга

Т.е. вставить вызов API каким-то образом.  Было бы API унифицированным или формализованным, то такую кнопку вставляли бы сами разрабы биллингов.