BiTel

да, NPay - это то как с него списываются деньги. А диалап для комутации доступа посредством PPP

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

RSCM - разовые услуги с указанной в тарифном плане ценой.
Для обычных разовых начислений мы используем расходы. Скажем, расход "подключение" - он в каждом случае может быть индивидуальный. Или "оборудование". Сумма расхода указывается прямо при добавлении на договор. В случае с RSCM нужно будет ещё тариф делать и вешать на договор. RSCM для более стандартизованных вещей.

зы. skyb опередил, я уже скриншот тарифа сделал для безлимита

Ага, понял, спасибо. А расходы - это где? В каком модуле такое понятие?

Чуть ниже платежей в договоре.
Заносятся аналогично платежам.
Описываются в Справочники - Другие - Расходы

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

Да, в те справочники я внес инфу, но до платежей в договоре еще не добрался в процессе тестов. Пока вообще не вижу, где там платежи

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

где приход, там вверху на плюсик нажать

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Коллеги, прошу помощи опять: как теперь сделать тариф с предоплаченным трафиком?
Картинки и названия в документации отличаются от таких же в версии 5.2.

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


P.S. Кстати, если цены все указывать без НДС, то потом в счете Bill сам начислит же его?

Спасибо.

По трафику viewtopic.php?f=5&t=6401

Да и если поковырять в подфоруме DialUp там много примеров тарифов

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

В тему о иерархии. Сейчас бурно обсуждаем этот же вопрос.

Пока представляем такую схему:
Супердоговор - хранит данные о клиенте(при пожелании клиента общий лицевой счет для всех субдоговоров - реализуемо?)
Субдоговор - хранит в себе все модули услуг, в объектах хранится адрес подключения

По сути тем самым полагаю удастся сделать независимые друг от друга договора, в первую очередь для возможности учета разных точек подключений, а именно адресов, у одного абонента. Но тут же возникает несколько вопросов:
1. Можно ли считывать данные Супердоговора из Субдоговора клиента(в первую очередь мне кажется это вызовет затруднения в карточках), или же лучше(теоретически для более быстрых запросов, но опять же при поиске будет находить не один Супердоговор, а все его Субдоговоры) хранить копии данных Супердоговора в Субдоговоре? Если второе, то как правильно организовать автозаполнение данных из Супердоговора?
2. Можно ли делать независимый счет модуля услуги от счета Субдоговора, или же на один адрес для независимости услуги придется создавать дополнительный субдоговор?
3. Есть ли еще какие то подводные камни в данной иерархии?

Идея нормальная. Мы сейчас пришли к такому: супердоговор - объединяет субы, не содержит модулей услуг; субдоговор - разбиение по точкам подключения и услугам. Т.е. услуги телефонии в точке подключеня - один субдоговор (модули Phone, NPay), интернет - другой, впн - третий. Счёт выставляем общий по супердоговору. Если нужно отдельный счёт по субдоговору - делаем суб с независимым балансом. Но такое редко нужно - в основном для агентской телефонии. По каким договорам выставлять счета рулится группой договора "выставление счетов" - висит только на супердоговорах и на независимых субах. Удобно тем, что можно легко отключить/приостановить конкретную услугу в точке. Неудобно некоторым клиентам, которые в детализации счёта не видят удобной группировки по точкам.

1. А где именно получать данные с супердоговора? Скриптами всё можно. В карточках - сомневаюсь. Там xml формируется, можно проверить, что в ней есть. Для автозаполнения есть какая-то фича, чтобы при создании суба копировались параметры с супердоговора.
2. Уже написал выше про услуги. Счёт выставляется только на договор (или суб). Кроме того, "услуга" - это такая абстрактная штука, которой в биллинге нет. Модуль - не услуга, т.к. как правило услуги размазаны по 2-3 модулям. Как минимум - модуль трафика (Inet/IPN/Dialup) или звонков (Phone/VoiceIP) + абонплаты (NPay). Кроме того, управление "услугой" - это не только выставление счетов. Но и, например, приостановление, отключение, переезд, вот это всё...
У нас осталась куча договоров, оформленных "по точкам подключения" - когда все услуги в одной точке висят на одном субдоговоре. Потом приходит заявка "приостановить клиенту услугу телефонии в точке А, интернет оставить". Если бы телефония была на отдельном субе, то мы бы поставили статус "приостановлен" и всё. А так - приходится закрывать датой каждую абонплату, связанную с телефонией, закрывать шлюз Phone и т.п. Потом так же открывать. Ужас.
3. см выше

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

В карточках можно использовать запросы в MySQL, подключать java библиотеки, поэтому теоретически полагаю что реализовать скриптами и запросами вполне реально.

Ясно значит моя изначальная задумка ошибочна в корне - в модулях.

У нас тогда будет 2 супердоговора логически в биллинге не связанных между собой. Ну тут нужно сказать, что мы используем внешнюю CRM систему для работы с информацией о клиенте. Т.е. сущности "клиент" в биллинге в явном виде тоже нет. И всю инфу, не касающуюся тарификации, мы из параметров договора выносим в CRM. Туда же карточки клиетна и т.п. Даже информацию для печати счетов утащили в 1С, чтобы туда из биллинга уходила только XML с наработкой по услугам.