BiTel

Вероятнее всего система с Web-интерфейсом, плагин BGCRM, позволяющая проводить учёт оборудования и топологии сети.

А вот это большой плюс!!! нада, да

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Мы живём в эпоху и в стране нанотехнологий. Если нана - сверху звёздочку жмите.

Вот и надо их учитывать +1

Что хотелось бы видеть:

• Некий "склад" ТМЦ из которого мы сможем "брать" оборудование для дерева inet (лучше всего сразу связать напрямую с типом устр-ва из inet - тогда в inet его даже указывать не надо будет). "Склад" даст нам учет оборудования, а inet - учет портов.
• Учет линий и волокон ВОЛС.
• Карту сети с абонентами, ВОЛС и оборудованием.

Если сделаете что-то аналогичное юзерсайду, то это будет 10 из 10.
Юзерсайд пока единственное приложение на рынке за разумные деньги умеющее в учет ТМЦ и ВОЛС. Если БГБ сможет в ВОЛС, то клиентов резко прибавится, т.к. это самая насущная проблема

Добрый день!
с 20 сен 2014 много времени утекло!


Что касается "Карты абонентов, оборудования, ВОЛС" - то я рекомендую The Dude от MikroTik, такое повторить в БГБ реально -"НЕ реально", у разработчиков лет 15 ушло.

А вот СКЛАД ТМЦ катастрофически не хватает.
- приход на склад партии оборудования (маршрутизаторы, коммутаторы, абонентские роутеры, оптоприемники ТВ, усилители, ТВ тюнера, и многое другое)
- товар сохраняется с Наименованием, с серийником, с МАС-ом, Кто взял, Куда взял, Когда взял, Когда вернул.
- необходимо ввести сущности в виде ящика который привязывается к адресу дома и туда складывается со склада то что Мастер отнес и поставил
- дерево это будет схоже с Inet-деревом только тут ТМЦ с ссылками для перехода на свои модули (Inet в частности) или договора.

И остается только поиск по складу и через склад сделать и все!

_________________
BGBilling 7.1.xxxx+BGCRM, update от ВЧЕРА, Ubuntu 17.04 64bit, JAVA 1.8.xxxx

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

BGCRM поддерживает работу с несколькими биллингами и соответственно HD

сейчас смотрим в сторону BGCRM... именно что бы hd появился со связной базой... но так мало описания возможностей... хочется прям сервисдеск.... SLA... и т д

Если есть вопросы - поднимите тему в форуме. Сейчас как раз документацию мигрируем и одновременно пополняем, чистим.
https://forum.bitel.ru/viewforum.php?f=49

ну по CRM ERP и HD ответили... но тема топика Учёт оборудования и топологии сети (BGCRM или bgbilling - пофиг)
надеяться или не стоит? вот бы иметь базу узлов связи к примеру в биллинге и от туда апи подтягивать в забикс дабы иметь одну базу с адресами))))
по теме +1 ждем)

Надеяться стоит. Занёс в план: https://forum.bitel.ru/viewtopic.php?f=52&t=11897
Тема уж больно большая, но и спрашивают тоже часто..

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

Уважаемые коллеги, а чем вас не устраивает Система zabbix? В ней можно вести не только учёт оборудования и топологии сети, но и мониторинг. Может есть пользователи zabbix которые хотят интеграции с bgcrm?

Да я ленивый человек...
Вот задача: как выдавать порты с коммутаторам клиентам? Иными словами как вести учет ресурса "порты устройств"? У меня сейчас куча свитчей с портами нарисована в файле ексель и там если клинт подключается я отмечаю на порту 5 что это ИП Пупкин..... 21 век..... а так же эта самая куча коммутаторов находится и в заббиксе... две базы...
и я использую заббикс... мониторинг на ура...

во дополню.. не знаю сколько здесь таких как я....
мы провайдер с девизом "подключим везде, главное плати" (b2b b2c b2o егменты)
и по мимо оптики у нас очень развита радио сеть точка-точка, точка-многоточка... (infinet mikrotik cambium ubiquiti итд)

Порты отлично можно учитывать в биллинге средствами модуля inet. Смотреть на свитче какие свободные а какие занятые. Или вы прям с договора можете через сервис увидеть куда клиент подключен

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

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

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

*подскажете (прошу прощения)

Создается один или несколько служебных договоров, которые служат для:

1. Учета служебных, транзитных портов;
2. Настройки портов типа trunk (да, БГБ может сам зайти на железо и отконфигурить вам порт прописав "switchport mode trunk").

На этот договор(ы) навешиваются соответствующие сервисы модуля inet, предоставляющие "услугу" trunk, после чего, глядя на занятые порты вы видите свой служебный договор(ы) и понимаете кем он занят, а зайдя в договор(ы) вы можете увидеть все транковые/транзитные порты занятые этим договором(ами).

Например вы создаете договоры "mng Базовая станция", "mng Свич" (слово "mng" (managment) - чтобы проще искать меньше набивая в поиске ) и навешиваете на эти договора специально созданные сервисы, после чего заходите в использование портов свича и видите что-то типа такого:

1. Юзер Q
2. Юзер W
3. Юзер E
4. mng Базовая станция
5. Юзер R
6. Юзер T
7. Юзер Y
8. mng Свич

Вот у вас все и учтено, нет?

Мы в принципе так и предполагали. НО не получится ли, что после очередного обновления, что-то в политике Биллинге (касаемого этого вопроса) поменяется, и сейчас получится так, что мы будем заниматься "пустой" работой. Всё-таки сеть не такая уж и маленькая, если переносить ее руками..(

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

Э-э-э... Что именно должно поменяться в БГБ, чтобы у вас и у всех остальных (!!!) все накрылось медным тазом?

Да не накрылось конечно) имею ввиду,что разработчики сделают какой-нибудь "красивый" способ всё это учитывать. Например занимать интерфейс другим устройством в том же дереве, а не договором. Получается так, что в дереве будет виден общий договор "базовые станции", а в нем например 100 сервисов с конкретными базовыми и их ip-адресами. И чтобы понять, какой именно сервис относится к моему интерфейсу в дереве, надо будет перелопачивать руками все.

С учётом в биллинге вижу следующие преимущества:
1) В Inete устройства уже учитываются, также структура в некотором виде.

И недостатки:
1) Каждому пользователю необходимо установить Java клиент.
2) Экземпляров модуля Inet может быть несколько и на нескольких серверах.

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

Мы у себя используем Userside для учёта структуры сети. И очень большое желание скрестить это с CRM (уже пара функций работает: создание Node, указание координат, просмотр их состояния), но там такой велосипед в плане API(как то избирательно они подошли к вопросу ее функций), что большинство функций надо реализовывать через прямой запрос к БД, которая живёт своей жизнью и все решения какие то индивидуальные получились. Как руки дойдут - можно будет обсудить.
Но как минимум склада точно не хватает, с него то по идее эта инвентаризации и начинается. Куда дальше улетит эта конфигурационная единица вопрос следующего порядка и каждый сможет решить его сам, а вот учёт ресурсов которые необходимы для выполнения процессов должен лежать в CRM

Не берут наверное потому что CAD системы такие же дорогие как и обширность самой темы учёта структуры

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

Вот из недавнего запроса:


Я предполагаю, что адреса в юзерсайд текстовые и мало связанны со справочником ЦРМ и биллинга.
Но поиск по параметрам и создание ссылки на устройство в процессе разве невозможно?

Для учёта ТМЦ часто используют 1С.