BiTel

Описание от Cromeshnic.

http://forum.bitel.ru/viewtopic.php?f=1&t=7555

Сейчас вот опять встала проблема: на субдоговоре есть пара десятков телефонных номеров (или сервисов Inet). Каждому из них соответствует абонплата. Клиент пишет заявление на приостановление услуг по одному из них на определённый период.
Приходится руками закрывать статусом сервис (а в случае phone вообще отключать руками на оборудовании) и закрывать датой соответствующую абонплату.
Затем отдельно в день включения обратно руками же включать сервис/телефон и ещё раз добавлять ту же абонплату с даты для того же номера.

В результате имеем кусочно-заданные абонплаты и много ручной работы.

Очень надо. чтобы уже уйти от понятия зависимый субдоговор и все услуги и тарифы клиента были в одном месте. Тариф привязывается к услуге (или наоборот !?), а если таковой привязки нет, то работает всё как обычно. Все обратно совместимо получается.

+++++

+1

+10

_________________
Интернет и телефония оптом со склада, или в розницу

Может к объектам добавить возможность указания тарифов? Или это ещё одно деление должно быть?

Возможно.

Однако лично для меня не совсем удобно следующее в объектах.
Когда удаляется объект - привязанные к нему абонплаты, поинты модуля Phone и т.п. - остаются.
Приходится затем ручками вычищать. Плюс если меняется дата действия объекта - так же не меняются привязанные сущности. Тоже много действий ручками/скриптами (которые выискивают привязанные сущности и проводят с ними изменения).
Может стоит и это продумать как то?

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

+100. Мне бы тоже хотелось уйти от субдоговоров. Все просто когда у вас всегда на одном договоре 1 тариф и одна услуга, а как только появляется несколько одинаковых услуг и надо разные параметры задать (стоимость, цена) - начинаются пляски с бубнами. А чтобы скрипты работали приходится везде все однотипно делать, даже для тех у кого реально 1 тариф и одна услуга - делать субдоговор и тд.

Если для объекта сделаем возможность установки тарифа привязанных логинов/телефонов + при закрытии объекта закрытие их периода - это достаточно будет?

эх, надо подумать и покурить эту тему опять, да некогда

Не торопитесь делать пока, нужно всё обдумать.

А то получится, как с тарифными опциями

Когда это мы торопились. Обдумываем вот. Я всего лишь предложил пока.

Бухтун.

Для простоты представим БГБ так:

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

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

• адрес по которому он предоставляется
• тариф по которому он обсчитывается

Т.е., в общем, упрощенном, виде это можно представить так:

В чем же засада текущего БГБ? Прежде всего в том, что редактор тарифов договора совершенно не знает о том, что мы должны на каждый отдельно взятый сервис иметь свой тариф, т.е., дабы сильно много не переделывать, необходимо изменить редактор тарифов таким образом, чтобы там можно было указать не столько порядковый номер тарифа, но и его привязанность к тому или иному сервису договора.

Что касается объектов, то да, я знаю, что они существуют, но, пожалуйста, давайте будем отделять мух от котлет, т.е. объекты штука, конечно, хорошая, но, IMHO, больше справочная/поясняющая и делать их непосредственным участником тарификации - это плодить сущности, т.е. чтобы указать как необходимо что-либо считать будет недостаточно создать сервис и навесить на него тариф, надо будет еще зайти в объекты и там что-то указать, а ведь еще можно зайти в редактор услуг и там проставить их кол-во ... Вот эта вот мышиная возня, в эпоху, когда народ массово покупает телефон всего с одной кнопкой - это же так замечательно.

"будет недостаточно создать сервис и навесить на него тариф, надо будет еще зайти в объекты и там что-то указать"
У объекта есть период, набор атрибутов настраиваемый и к нему привязываются сущности модулей. Если наделить его функцией "сервиса", то что будет?
Сервис это обычно что? Адрес с набором услуг?

Бритва Оккама будет. Зачем объект наделять каким-то функционалом, который уже есть в сервисе?


В некоем общем виде - да.



Дабы говорить более приземленно, давайте представим ситуацию:

Есть некий оператор, который использует БГБ и его модуль inet (пока обойдемся без телефонии).

Бител заключает с этим оператором договор на:
1. Предоставление инета в офисе (адрес "офис"), по цене 100 руб/мес. Инет будет выдан через VLAN 100
2. Предоставление 3-м сотрудникам, назовем их ААА (адрес "А1"), БББ (адрес "Б1") и ВВВ (адрес "В1"), локалки между собой с доступом в офис через VLAN 200, по цене 5 руб/мес за порт для ААА и 3 руб/мес за порт для БББ и ВВВ.

Пожалуйста, опишите пошагово ваши действия как оператора биллинга, которому необходимо это все посчитать при текущем положении дел в БГБ.

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

Все же давайте разговаривать более конкретно, а именно:

Это позволит вам лучше понять нас

Модуль тут зря, имхо.
"Услуга" - это, как правило, комплексная штука. Обычно состоит из абонплат и сервиса(ов) Inet/пойнта(ов) телефонии.

Нужно подумать, какие параметры услуги нужны:
- тариф
- статус
- свой баланс? (вряд ли, баланс лучше учитывать на договоре, если для улуги нужен свой баланс - делаем отдельный (суб)договор)
- справочные параметры

что бы уйти от субдоговора свой баланс нужен
тариф +
статус - зачем? мне кажется не надо (вешать не используемые услуги)
справочные параметры +

А куда вы уйдёте от субдоговора и зачем?


А как вы будете отключать за долги только одну услугу, если у неё отдельный баланс, но нет своего статуса?

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

А в чём тогда разница между субдоговором и услугой для вас?

субдоговор в первую очередь договор но фактически его не существует. А услуга это место где учитываем виды работ/услуг выполняемые на договоре но не использующие его баланс

Именно в текущем положении или если добавить возможность установки тарифа на объект?

То что ты называешь "услугой" я обозвал "сервисом"



Желательно в обоих вариантах - так будет проще увидеть разницу и понять и простить что вы предлагаете.

С одной стороны вроде всё сходится. Из объекта делаем "Услугу". Добавляем к ней тариф и статус. При закрытии объекта по периоду - закрываем все сущности. Если тариф не установлен - берутся из глобальных/персональных как обычно.

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

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

Я говорил, что объекты очень хороши как некий справочник.


Согласен. Нужно нечто что мы будем "продавать", т.е. как считать у нас уже есть - это тарифы, нам теперь нужна возможность указать то, что мы продаем, а в этой "услуге" уже будут сервисы того или иного модуля, например inet.
В данный момент БГБ позволяет нам продавать воду в виде химической формулы Н2О, а хотелось бы, чтобы мы продавали бутылки с водой.

Я наверное не ошибусь если скажу что главный недочет сейчас это то что услуга является подмножеством модуля, а должно быть наоборот!
И ещё я думаю что не только у нас используются следующая система:
1. Контрагент:
1.1. Реквизиты

1.2. Договор интернет
1.2.1 Номер договора
1.2.2 Период
1.2.3 Бланк заказа (привязывается к адресу или объекту)
1.2.3.1. Номер бланка заказа
1.2.3.2. Период
1.2.3.3 Услуга доступ и интернет (сервис)
1.2.3.3.1 Кол-во
1.2.3.3.2 Цена (тариф)
1.2.3.3.3 Описание
1.2.3.3.4 Сетевые реквизиты (IP)
1.2.4 Бланк заказа (привязывается к адресу или объекту)
1.2.4.1 Номер бланка заказа
1.2.4.2 Период
1.2.4.3 Услуга ВПН (сервис)
1.2.4.3.1 Кол-во
1.2.4.3.2 Цена (тариф)
1.2.4.3.3 Описание
1.2.4.3.4 Сетевые реквизиты (Порты на коммутаторе)

1.3. Договор телефония
1.3.1 Номер договора
1.3.2 Период
1.3.3 Бланк заказа (привязывается к адресу или объекту)
1.3.3.1 Номер бланка заказа
1.3.3.2 Период
1.3.3.3 Услуга местная телефония (сервис)
1.3.3.3.1 Кол-во
1.3.3.3.2 Цена (тариф)
1.3.3.3.3 Описание
1.3.3.3.4 Сетевые реквизиты (Поинты)
1.3.3.4 Услуга ЗОНОВАЯ телефоония (сервис)
1.3.3.4.1 Кол-во
1.3.3.4.2 Цена (тариф)
1.3.3.4.3 Описание

И вот сейчас действительно приходится изголяться.

И собственно нужно наверное начать с того что сделать справочник услуг (сервисов), и уже модули привязывать к ним, а не на оборот!

_________________
Интернет и телефония оптом со склада, или в розницу

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

Заказы мы автоматизировали через MS CRM своим кодом: в CRM заводится xml-конфигурация для продуктов, в которой прописываются:
абонплаты, тарифы, сервисы, объекты договора и т.п., которые потом уходят через http и ws в BG

Т.е. услуга заказа размазана минимум по 2 модулям, а также содержит другие сущности.

У нас разные договоры потому что разные юр лица оказываю разные услуги.
Что по модулям не понятно?

_________________
Интернет и телефония оптом со склада, или в розницу