forum.bitel.ru http://forum.bitel.ru/ |
|
BGBilling: Услуги http://forum.bitel.ru/viewtopic.php?f=66&t=9718 |
Страница 2 из 2 |
Автор: | stark [ 12 фев 2015, 17:05 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Надо ту услугу, которую Cromeshnic называет мета-услуга, назвать продуктом. Чтобы не путаться. А услуги оставит как есть сейчас . |
Автор: | max [ 02 мар 2015, 22:06 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Цитата: Про модули не понял. А что не понял то? Сейчас услуга - это подмножество модуля. А я считаю что гораздо правильней, что бы список услуг был отдельным справочником, и уже в нём можно было привязывать различные модули. Цитата: Делаем зависимыми субдоговорами. Не считаете что это очень не удобно? Цитата: которые потом уходят через http и ws в BG Мега жесть! Простым смертным такая магия недоступна. |
Автор: | max [ 02 мар 2015, 22:08 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
stark писал(а): Надо ту услугу, которую Cromeshnic называет мета-услуга, назвать продуктом. Чтобы не путаться. А услуги оставит как есть сейчас . не нашёл нигде в теме упоминания про "мета-услугу" И чем ваши продукты будут отличаться от услуги? |
Автор: | stark [ 05 мар 2015, 13:34 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
max писал(а): stark писал(а): Надо ту услугу, которую Cromeshnic называет мета-услуга, назвать продуктом. Чтобы не путаться. А услуги оставит как есть сейчас . не нашёл нигде в теме упоминания про "мета-услугу" И чем ваши продукты будут отличаться от услуги? Ссылка в первом сообщении темы была: viewtopic.php?f=1&t=7555 Слово услуга в биллинге уже занято и имеет другой смысл сейчас. |
Автор: | madmax [ 23 апр 2015, 01:16 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Нужно наделить объекты возможностью привязки отдельных тарифных планов, ну и для полного счастья наделить их статусами чтобы если клиент например попросил временно приостановить услуги на объекте (подключении, точке как удобно кому называть) сменить статус и не начислять услуги чтобы не закрывать а потом опять открывать все привязанные сущности на данном объекте Сейчас нам приходится для каждого отдельно подключения одного и того же клиента создавать субдоговора с зависимым балансом и на них вешать разные тарифы. А субдоговора использовать для прочих вещей (независимые лимиты, единая точка входа через веб для управления всеми lдоговорами что сейчас делают в BGCRM, перенос средств между разными договорами и т.д) |
Автор: | vdd [ 10 июл 2015, 12:55 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Решили что нибудь? Есть возможность назначить тариф на объект? (в документации 6.2 не нашел, но вдруг просто не добавили ) Или вторую точку подключения к интернет с собственным тарифом по-прежнему можно завести только субдоговором? |
Автор: | skyb [ 10 июл 2015, 14:43 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
оппа, я в теме, есть че?)))) у меня как раз 6.2 |
Автор: | vdd [ 10 июл 2015, 14:55 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
skyb писал(а): оппа, я в теме, есть че?)))) у меня как раз 6.2 Ну вот я и пытаюсь выяснить - есть ли "че". Ибо актуально как никогда. Если ничего не решили, то выскажу свое видение вопроса. Но лучше бы уже решили. Потому как ну очень актуально. |
Автор: | max [ 14 июл 2015, 04:17 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
2015 год на дворе, а у нас в бгб попрежнему каменный век |
Автор: | Lionela [ 28 июл 2015, 01:32 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
До каменного века нам еще далеко |
Автор: | vdd [ 28 июл 2015, 15:30 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Я тоже поною, раз никто не возражает. <нытье> Для начала несколько общеизвестных фактов, что бы придать тоскливым завываниям некоторую стройность: По требованию государства отношения между Оператором и Абонентом регулируются Договором. Договор состоит из юридически значимых идентификаторов сторон, текста различных пугалок и страшилок (обычно предвзято выборочно перепечатанных из "закона о связи" и "правил оказания услуг связи") и описания того, ради чего все затевается - Предмета договора. Предмет договора содержит перечень чего-то, что Оператор обязуется выполнять и список того, что должен ему за это Абонент. В вакуумно-сферической информационной системе Договор распределяется следующим образом:
Предмет договора транслируется:
Потребление ресурсов - в правила системы учета ресурсов; Что должен Абонент - в правила системы, конвертирующей что угодно в деньги, то есть в АСР (биллинговую систему); Правила соблюдения баланса "обязан-должен" - в систему учета денежных средств. В текущем БГБиллинге Договор представлен в виде:
Предмета договора, транслированного в условные "подсистемы":
Потребление ресурсов - в параметры соответствующих модулей (Phone, Inet); Что должен Абонент - в комбинацию бгбТарифов и бгбУслуг т.е правила конвертации чего-то в деньги, реализованные в соответствующих модулях (Phone, Inet, NPay); Правила соблюдения баланса "обязан-должен" - в бгбБаланс бгбДоговора, режимы кредит/дебет бгбДоговора, временные лимиты. Связь бгбДоговора, бгбТарифов, бгбБаланса, бгбСтатуса и модулей монолитна. (исключение в связке бгбТариф-бгбДоговор - Phone, но это из разряда "а налево живой человек стоит, а чем живет и как туда попал - тоже неизвестно", поэтому игнорируем). Пока Предмет договора транслируется "один в один" в фиксированную связь бгбДоговора, бгбТарифов, бгбБаланса, бгбСтатуса и модулей - этот монолит незаметен и воспринимается как естественный и удобный: есть Договор, есть его операционализированная копия - бгбДоговор. Как только Предмет договора требует некоторой, порой незаметной для простых смертных, гибкости, например, Абонент возжелал по одному Договору получать доступ к сети Интернет в 15 географически распределенных точках с индивидуальными абонентскими платами и возможностью независимой приостановки оказания услуг в любой из точек, то начинаются самодеятельные маневры по обходу, подкопу и другому надковыриванию глыбы бгбДоговора. Один городит субдоговора, получая неуправляемую избыточность, другой противоестественно мучает персональный тариф, третий пробивает и оплачивает безсистемную доработку (наверное так и появилась возможность назначать тариф на поинт ). В результате, либо разрушается связь Договор - бгбДоговор, либо Предмет договора реализуется сущностями БГБиллинга настолько неочевидно, что оказывается закопан так же как орех белкой - найти без собаки-ищейки невозможно, попытка выкопать приводит к глобальной катастрофе. Исходя из этих общеизвестных фактов идеальная деглыболизация бгбДоговора ощущается следующим очевидным образом:
2. бгбЮнит состоит из набора параметров, бгбТарифов, назначений "юнитовых" или "калькуляционных" модулей (NPay, Inet, Phone) (и бгбУслуг соответственно) и привязан к определенному бгбБалансу; 3. бгбБаланс имеет приоритет, определяющий его очередность при распределении прихода, режим дебет/кредит, лимиты. К одному бгбБалансу могут быть привязаны несколько бгбЮнит; 4. Связь бгбСтатус - бгбБаланс: "многие ко многим". Более реальные варианты:
б) бгбСтатус - свойство бгбБаланса, режим дебет/кредит, лимиты - на бгбДоговор. в) бгбБаланс один на бгбДоговор. </нытье> Дополнение: для реализации агентских схем в пределах одного бгбДоговора необходима и достаточна возможность "наследования" или "построения иерархии" юнитов. Процедура "наследования" предполагает выставление "птичек" - что доступно "наследнику", что "наследник" может заменить. |
Автор: | Cromeshnic [ 28 июл 2015, 16:05 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Автор: | snark [ 28 июл 2015, 16:47 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
@ vdd |
Автор: | Администратор [ 13 авг 2015, 01:55 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Vdd, отличное описание. Можете описать, как в эту схему ложится телефония? Местная - МГМН - номер и абонплата? Номер соотносится в два юнита с разными тарифами и балансами? И производится попытка тарификации сначала как местного звонка а потом как МГМН? Где будет производится непосредственно добавление номера с периодом? |
Автор: | vdd [ 13 авг 2015, 13:19 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Администратор писал(а): Vdd, отличное описание. Можете описать, как в эту схему ложится телефония? Местная - МГМН - номер и абонплата? Номер соотносится в два юнита с разными тарифами и балансами? И производится попытка тарификации сначала как местного звонка а потом как МГМН? Где будет производится непосредственно добавление номера с периодом? Внутри юнита все работает так, как сейчас на договоре. Если нужен разный баланс по местной и ВЗМГМН, то пользователь делает два юнита: на одном местные тарифы и услуги, на другом - ВЗМГМН. Абонплату за линию логично отнести к местной. Обычно так все и делают. Тарификация последовательная. Ошибка "не найден тариф" формируется только после обработки всех юнитов договора. Если делать в лоб, то в модуле телефонии на каждом таком юните будут дублироваться поинты, что однозначно будет создавать проблемы при сопровождении договора. Поэтому можно нафантазировать что-то вроде наследования - поинты вешаются на договор, а в юнитах можно только "птичку" поставить: используется поинт в данном юните или нет. Вот как-то так. Но! Мое предложение мотивировано правилом - один Договор с абонентом - один бгбДоговор. Юниты нужны для того, что бы (для телефонии) из пятнадцати номеров Договора пять продавать на одних условиях (не только тарифы, но и дебет/кредит и т.п.), а десять - на других. ВЗМГМН - это отдельный Договор или даже Договора с абонентом. Если реализовывать их юнитами, получится каша "наоборот", поэтому я никак и не выделял эти особенности оказания услуг телефонии. Грубо говоря, предлагаемые юниты не предназначены для агентских схем. |
Автор: | vdd [ 13 авг 2015, 14:43 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Мысль: для реализации агентских схем в пределах одного бгбДоговора необходима и достаточна возможность "наследования" или "построения иерархии" юнитов. Процедура "наследования" предполагает выставление "птичек" - что доступно "наследнику", что "наследник" может заменить. Хоть это и позволит реализовывать схемы, не вписывающиеся в концепцию "один Договор - один бгбДоговор", но репутацию БГБиллинга как конструктора в хорошем смысле слова надо же поддерживать : Дописал к исходному посту. |
Автор: | Администратор [ 14 авг 2015, 02:01 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Я думаю, не стоит жёстко ставить соответствие договор с абонентом = договор бгбиллинг. Первое - юридический термин, второе - техническая абстракция, специфичная для нашего продукта. Рассмотрим фундаментальные понятия, как будто договора биллинга и нет. Что требуется для гибкого учёта. А после подумаем, как это вписать в текущую схему. 1) Балансы - куда заносятся приходы и списываются средства, может быть режим кредит / дебет. 2) Тарифы - стоимость и правила/ограничения предоставления услуг, также с периодами. 3) Ресурсы - логины, адреса, телефонные номера с периодами. 4) Статусы - глобальные состояния, тоже с периодами. Начать, думаю, нужно с ресурсов. Для каждого Ресурса соотносится: 1) один глобальный Статус, определяющий его состояние; 2) один или несколько Тарифов с указанием порядка с привязанным Балансами (для телефонии). Далее нужен некий группирующий признак. Чтобы настраивать однотипные ресурсы. Например, на одном адресе. Либо телефонные номера по одной схеме операторов (местный + какой-то МГМН). В юните можно установит Тарифы с порядком + Балансы, также определить глобальный статус. Ресурсы помещаются в юнит либо непосредственно соотносятся со статусом и тарифами + балансами. Всё ли я учёл? |
Автор: | vdd [ 14 авг 2015, 11:21 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Администратор писал(а): Я думаю, не стоит жёстко ставить соответствие договор с абонентом = договор бгбиллинг. Первое - юридический термин, второе - техническая абстракция, специфичная для нашего продукта. "Жестко" - "это другая газета". Есть типовые схемы (и не типовые...) трансляции терминов предметной области в технические абстракции БГБиллинга. И чем точнее транслируются термины в технические абстракции, тем проще эти схемы сопровождаются. Предложенные юниты никак не запрещали пользователю свалить любое количество договоров с абонентом в один бгбДоговор. Один Договор - один бгбДоговор: типовая схема трансляции, от которой я отталкивался. Администратор писал(а): Рассмотрим фундаментальные понятия, как будто договора биллинга и нет. Что требуется для гибкого учёта. А после подумаем, как это вписать в текущую схему. 1) Балансы - куда заносятся приходы и списываются средства, может быть режим кредит / дебет. 2) Тарифы - стоимость и правила/ограничения предоставления услуг, также с периодами. 3) Ресурсы - логины, адреса, телефонные номера с периодами. 4) Статусы - глобальные состояния, тоже с периодами. Начать, думаю, нужно с ресурсов. Для каждого Ресурса соотносится: 1) один глобальный Статус, определяющий его состояние; 2) один или несколько Тарифов с указанием порядка с привязанным Балансами (для телефонии). Далее нужен некий группирующий признак. Чтобы настраивать однотипные ресурсы. Например, на одном адресе. Либо телефонные номера по одной схеме операторов (местный + какой-то МГМН). В юните можно установит Тарифы с порядком + Балансы, также определить глобальный статус. Ресурсы помещаются в юнит либо непосредственно соотносятся со статусом и тарифами + балансами. Всё ли я учёл? Похоже. Не указано, как будут задаваться телефонные номера для схемы "(местный + какой-то МГМН)". Вопрос: Модуль VoIP сливается с модулем Phone. Зачем выделять схему "местные+МГМН" вместо поддержки агентских схем вообще? |
Автор: | Администратор [ 16 авг 2015, 04:05 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Цитата: Есть типовые схемы (и не типовые...) трансляции терминов предметной области в технические абстракции БГБиллинга. Ну.. наверное, есть. Только наш текущий договор уже соединяет в себе баланс - тарифы - статус. Для необходимой гибкости эти вещи необходимо иметь возможность объединять более гибко. Цитата: Не указано, как будут задаваться телефонные номера для схемы "(местный + какой-то МГМН)". Один ресурс-номер привязан к - местный тариф позиция один - баланс 1 - МГМН тариф позиция два - баланс 2 Либо создаётся юнит в котором уже есть - местный тариф позиция один - баланс 1 - местный тариф позиция два - баланс 2 А в юнит просто добавляются номера, обсчитываемые по этой схеме. Задачи отдельных тарифов на отдельные точки такая схема тоже решает. Цитата: Вопрос: Модуль VoIP сливается с модулем Phone. Зачем выделять схему "местные+МГМН" вместо поддержки агентских схем вообще? А что такое "агентская схема вообще"? Возможность тарификации по двум тарифам одновременно (операторский и клиентский)? На мой дремучий взгляд все эти "агентские" схемы придуманы, для того чтобы законодательные изыски в области регулирования почему-то именно _проводной_ телефонии применить в грешной реальности. Как было раньше с телефонией? Да так же как сейчас с мобильной свзью, ПД и прочими услугами, не познавшими радость регулирования. Оператор покупал угслугу где-то и перепродавал с наценкой. Затем пришёл закон о связи и понеслось. Оператор может оказывать только ту услугу, на которую он имеет лицензию. Оператор местный обязан пропустить МГМН оператора к клиенту. Хотчойсы и прочие радости. Но как МГМН будет подписывать договора, разносить счета, работать с должникам, отключать-подключать и т.п. мало кто подумал. И ИДЕЯ! Местный оператор становится "агентом" МГМН оператора. Т.е. с некими костылями возвращается примерно к тому, что было раньше но с большим количеством бумаги. |
Автор: | vdd [ 17 авг 2015, 13:12 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Администратор писал(а): А что такое "агентская схема вообще"? Возможность тарификации по двум тарифам одновременно (операторский и клиентский)? Продажа чужого. С различными схемами распределения обязанностей и с использованием своих ресурсов, или без. При продаже чужой ВЗМГМН оператор использует свои ресурсы. Поэтому и возникает потребность псевдо-дублирования поинтов (текущая схема с телефонным субдоговором с незавизимым балансом). "Наследование" юнитов позволит псевдо-дублировать, а так же ссылаться на любые ресурсы модулей. Например, при продаже доступа в интернет и СПД через одни и те же подключения. Вопрос "по скольким тарифам считать" перестанет быть актуальным: хоть по 15. |
Автор: | vdd [ 29 янв 2016, 12:25 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Тут вот http://forum.bitel.ru/viewtopic.php?f=42&t=11279#p95623 альтернативное решение обсуждается. |
Автор: | barguzin2 [ 29 апр 2016, 19:33 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Как продвигаются дела? Будет ли в договоре СуперУслуга со своим тарифом и статусом. Или хотя бы для начала привязка тарифа к объекту |
Автор: | Администратор [ 02 июн 2016, 02:22 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Пока никак. Нет понимания, что должно быть. |
Автор: | Jimson [ 02 июн 2016, 19:21 ] |
Заголовок сообщения: | Re: BGBilling: Услуги |
Может просто реализовать дизайн договора (gui) из логики лицевой счет = субдоговор, это не изменит в самом биллинге ничего, только повышение удобства работы в клиенте. Правда может понадобится на договоре два лицевых счета (субдоговора с независимым балансом), при этом на одном из лицевых счетов две одинаковые услуги с разными тарифами, тогда надо еще допилить поддержку дерева супердоговор-договор, чего сейчас, на сколько я понимаю, нет. |
Страница 2 из 2 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |