Jump to content
Калькуляторы

Учет заявок

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 час назад, Andriuxa сказал:

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

+1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
48 минут назад, myth сказал:

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

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

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

 

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

Edited by default_vlan

Share this post


Link to post
Share on other sites
4 часа назад, default_vlan сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
14 часов назад, vop сказал:

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
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,

Share this post


Link to post
Share on other sites
7 часов назад, vop сказал:

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

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

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

Share this post


Link to post
Share on other sites
22 минуты назад, default_vlan сказал:

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

....

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

 

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

Share this post


Link to post
Share on other sites
17 минут назад, vop сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 27.08.2017 в 00:20, myth сказал:

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

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

Edited by ichthyandr
дополнено

Share this post


Link to post
Share on other sites
В 29.08.2017 в 22:12, default_vlan сказал:

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

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

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
16 часов назад, rdc сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now