Перейти к содержимому
Калькуляторы

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Изменено пользователем default_vlan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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,

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

....

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем ichthyandr
дополнено

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.