BiTel

Подскажите пожалуйста на каком этапе находится данная разработка. Можно ли её потестировать в работе с Совинтелом?
Когда можно ожидать окончательного релиза?

Да-да... вопрос очень насущный... мы, например имеем дело с АСР ОНИМА, там реализована данная функция... но очень замороченных биллинг... очень... и еще оракл...

_________________
God Bless Linux! and blessings to FreeBSD!

Релиз уже вышел. МГМН реализовано.
Считать уже можно, вот отчетность в формате конкретного оператора будем еще доделывать. Совинтел первый на очереди, надеемся в течении месяца выложить апдейт. Там уже что-то есть, доделать нужно и задокументировать. Пока только из базы самим выбирать можно.

а этот функционал только в 4.6 или в 4.5 - так же возможно?

_________________
God Bless Linux! and blessings to FreeBSD!

В 4.5 нет такого.

Есть ли какие-то новости? Очень хочется создавать отчеты для билайна с помощью BGBilling.

Присоединяюсь! Т.к. очень актуальная тема... Может хоть какой-то информацией поделитесь, уважаемые разработчики...

_________________
God Bless Linux! and blessings to FreeBSD!

В данный момент идет доработка отчета для МТТ, так же доделываем модуль телефонии в плане работы с операторами.

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

Так получилось, что МТТ вырвался вперед Клиент с Совинтелом тормозит с внедрением агентской схемы.

Здравствуйте. Хотим реализовать агентскую схему (ТТК, РТ), возникли трудности. Многие клиенты имеют структуру субдоговоров с зависимым балансом, где каждый субдоговор - это отдельная точка подключения (например, филиал или точка продаж) со своим набором услуг, в т.ч. телефонией. Сделано это для удобства - клиент может посмотреть наработку по отдельной точке, а мы сразу видим, какие услуги он по ней получает. Вопрос, как при такой схеме реализовать агентские субдоговора? Переносить все номера на основной договор не хочется, через клиент трехуровневую иерархию договоров завести нельзя.
Можно ли завести независимые субдоговора для зависимого субдоговора, явно указав в базе scid? Будет ли корректно обсчитываться наработка по агентской телефонии, не появятся ли другие проблемы?

Возможен ещё более неудобный случай - у клиента 2 номера, каждый тарифицируется по своему тарифу (например безлимитный и повременной тарифы), при этом он имеет один договор по агентской схеме. Т.к. нужна разная тарификация - приходится разносить поинты по разным договорам => реализовать один агентский субдоговор не получится.

Упс. В последнем случае можно привязать тарифные планы к поинтам. Правда могут быть ещё персональные тарифные планы...

Господа разработчики, когда можно ждать агентской схемы с Совинтелом?

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

В TODO записано.

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

Как там прогресс?

Пока особо никак, к 5.0, наверное, сделаем.

хотел реализовать схему: создается супердоговор, на нем имеется модуль Phone c поинтом и создается еще три субдоговора с независимым балансом. На первом субдоговоре ТП "телефония местная", на втором субдоговоре ТП "телефония зоновая", на третьем субдоговоре ТП "телефония МН-МГ".

1 случай. Если произвести загрузку и обработать логи в модуле Phone, то в случае, когда на основном договоре отсутствуют ТП (Тарифные Планы), ни на один из субдоговоров звонки этого поинта не упадут.
2 случай. Если на основной договор занести любой из этих ТП и оставить два субдоговора, то после обработки логов звонки на супердоговор и субдоговора упадут.

Из документации "В модуле телефонии (Phone) субдоговора с независимым балансом несут дополнительную функцию организации тарификации по агентской схеме, когда звонки и наработка по одному и тому же поинту, добавленному в супердоговор, относятся либо к супердоговору либо к одному из его независимых субдоговоров."

В 1 случае должно работать?

Добрый день!
В настоящий момент мы работаем с Совинтелом.
Отчеты необходимые для отправки Совинтелу готовим при помощи запросов. Но все равно много ручной работы.
Если Вы еще ведете работу по созданию межоператорских отчетов (в частности Совинтел), то мы можем предоставить все необходимые данные и схему работы с оператором.

Согласно документации на супердоговоре создается местная связь и прочие тарифы, по которым не нужны агентские отчеты, а на субдоговора - Внутризон, МГ, МН по операторам. ( например 1-й субдоговор - Зоновая, МГ, МН Совинтел, 2-й субдоговор - Зоновая, МГ, МН Ростелеком и т.д.).
Такая схема у меня работает, на супер- и субдоговорах все прекрассно считается.
Сейчас парюсь с подключением модуля бехгалтерии и созданием счетов, после чего, по идее, должен сформироваться отчет для Совинтела...

_________________
Клиент: вер. 7.1.102 / 20.04.2018 19:02:09
os: Windows 8.1; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_172
Сервер: вер. 7.1.970 / 20.04.2018 19:04:17
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_162

Из документации "В модуле телефонии (Phone) субдоговора с независимым балансом несут дополнительную функцию организации тарификации по агентской схеме, когда звонки и наработка по одному и тому же поинту, добавленному в супердоговор, относятся либо к супердоговору, либо к одному из его независимых субдоговоров."

Все таки в документации не оговаривается четко, обязательно ли наличие тарифного плана на основном договоре!?

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

Так вот, проблема: параметры округления времени сессии для оператора не учитываются - в oper_round_session_time пишется просто session_time, а oper_cost соответственно считается пропорционально.

Поэтому для самопальных отчетов приходится пользоваться конструкцией вида:
sum(round_session_time*oper_cost/oper_round_session_time), отчего теряется небольшая сумма на коротких сессиях.

Можно как-то поправить это?

Скажите, зачем вообще эти "стоимость минуты у оператора"?
Мы года два выгружаемся в Совинтел без всего этого. Может у нас отчетность какая-та не такая?

Мы с ТТК работаем, у них определено 2 цены - по которой мы платим им, и по которой мы выставляем счет клиенту. Сверяемся по первой.

Ну так и у нас две цены. Но мы для сверки ориентируемся на минуты, посчитаные на стыке с оператором. Если минуты расходятся, то начинаем разбираться.

А это что? В биллинге есть session_time, round_session_time и oper_round_session_time. Как бы то ни было, oper_round_session_time сейчас считается неверно (=session_time). Явно какой-то косяк, хотелось бы, чтобы поправили.

Минуты посчитанные на портах ЦК в сторону оператора МГ/МН/ВЗ с помощью "правил". Прям как в документации написано.

Какая версия? Билд последний стоит?
В 5.0 насколько помню сделали ветки цена оператора и округление для оператора устаревшими. Вместо них используется ветка Тарифицировать оператора (и карта цен), в которой указывается тарифный план, по которому нужно узнать цену оператора.