Извините за долгое молчание. Информация по текущему ходу работ и срокам следующая:
Было обнаружено большое количество багов, с которыми не хотелось выпускать даже beta-версию. Так же праздники сказались на сроках.
В данный момент большинство проблем устранено, доделываем мелочи, собираем дистрибутивы. Так же к выходу сборки должна успеть первая версия документации.
В beta-версию войдут:
- Описанный выше функционал (блокировки, пересчет, возврат, политики списания)
- DHCP сервер + оборудование + option 82 (статическая выдача адресов, динамическая выдача из пулов + привязка адресов в биллинге)
Не войдут (в работе):
- Интеллектуальный конвертер старого функционала блокировок и списаний (с 5.2.1-007 по 5.3-001)
Здесь надо отметить, что автоматическая конвертация производится при первом запуске ядра, но в результате нее все сервисные связки получат тип пересчета по умолчанию (для действующих блокировок сохранится текущее состояние пересчета у соответствующих сервисных связок)
- Коррекция счетов и периодических списания в закрытых расчетных периодах (имеется в виду возможность корректно изменить сумму средств, списанных по сервисной связке в закрытом расчетном периоде, с обновлением выставленных счетов, баланса на текущий момент и т.д.)
- Разные мелочи (например, динамическое обновление в DHCP сервере профилей оборудования при их изменении в ядре)
Обсуждения изменения функционала блокировок.
Пара предложений накопилось для включения в todo:
1) Флаг агрегации счетов в периоде в один, сейчас каждое разовое списание выставляется отдельным счетом, предлагаю ввести флаг при котором любые услуги выставленные в предела периода, выставляются единым счетом.
2) в URFA ввести понятие функций и процедур, хранящиеся в отдельном файле, можно даже совсем просто: файл в котором сложены часто используемые куски кода. Сейчас приходится править один и тот же код в нескольких файлах.
3) с округлением до копеек надо что-то решить, при абон. плате в 100 рублей в месяц, не нормально списывать с абонента подключившегося 20 числа сумму в 33.33333333333333333333, пожалуйста округлите до 33.30
4) Уже писал: легализовать подключение нескольких услуг входящих в состав ТП с одинаковой родительской.
5) Телефонный пулы номеров ввести, по подобию IP зон, сейчас приходится вести учет номеров в отдельной таблице. (У номеров обязательно категорию, у категории стоимость, возможность заблокировать к выдаче конкретные номера из пула, выдавать номера в порядке даты освобождения)
6) При редактировании телефонной или IP связки в rfw не передаются как удаленные те номера или ip адреса, которые были удалены при редактировании, например в телефонной связке было 3 номера, от одного абонент отказался, мы удаляем номер путем редактирования связки, при этом в rfw улетает информация по двум номерам, а третий номер на атс остается висеть как активный хотя в биллинге его уже нет.
7) Добавить штатный функционал смены ТП в середине расчетного периода.
В админке добавить (можно вынести в настройки подобно параметру CSV Separator) выбор кодировки в которой сохранять CSV файлы.
1) Флаг агрегации счетов в периоде в один, сейчас каждое разовое списание выставляется отдельным счетом, предлагаю ввести флаг при котором любые услуги выставленные в предела периода, выставляются единым счетом.
2) в URFA ввести понятие функций и процедур, хранящиеся в отдельном файле, можно даже совсем просто: файл в котором сложены часто используемые куски кода. Сейчас приходится править один и тот же код в нескольких файлах.
3) с округлением до копеек надо что-то решить, при абон. плате в 100 рублей в месяц, не нормально списывать с абонента подключившегося 20 числа сумму в 33.33333333333333333333, пожалуйста округлите до 33.30
4) Уже писал: легализовать подключение нескольких услуг входящих в состав ТП с одинаковой родительской.
5) Телефонный пулы номеров ввести, по подобию IP зон, сейчас приходится вести учет номеров в отдельной таблице. (У номеров обязательно категорию, у категории стоимость, возможность заблокировать к выдаче конкретные номера из пула, выдавать номера в порядке даты освобождения)
6) При редактировании телефонной или IP связки в rfw не передаются как удаленные те номера или ip адреса, которые были удалены при редактировании, например в телефонной связке было 3 номера, от одного абонент отказался, мы удаляем номер путем редактирования связки, при этом в rfw улетает информация по двум номерам, а третий номер на атс остается висеть как активный хотя в биллинге его уже нет.
7) Добавить штатный функционал смены ТП в середине расчетного периода.
В админке добавить (можно вынести в настройки подобно параметру CSV Separator) выбор кодировки в которой сохранять CSV файлы.Вчера сборки 5.3-beta были выложены в личный кабинет. По представленному списку учтем пожелания. На вскидку функционал:
1) Флаг агрегации счетов в периоде в один, сейчас каждое разовое списание выставляется отдельным счетом, предлагаю ввести флаг при котором любые услуги выставленные в предела периода, выставляются единым счетом.
4) Уже писал: легализовать подключение нескольких услуг входящих в состав ТП с одинаковой родительской.
5) Телефонный пулы номеров ввести, по подобию IP зон, сейчас приходится вести учет номеров в отдельной таблице. (У номеров обязательно категорию, у категории стоимость, возможность заблокировать к выдаче конкретные номера из пула, выдавать номера в порядке даты освобождения)
6) При редактировании телефонной или IP связки в rfw не передаются как удаленные те номера или ip адреса, которые были удалены при редактировании, например в телефонной связке было 3 номера, от одного абонент отказался, мы удаляем номер путем редактирования связки, при этом в rfw улетает информация по двум номерам, а третий номер на атс остается висеть как активный хотя в биллинге его уже нет.
7) Добавить штатный функционал смены ТП в середине расчетного периода.
выглядит интересным для многих операторов. Над остальным можно подумать. Спасибо.
1) Флаг агрегации счетов в периоде в один, сейчас каждое разовое списание выставляется отдельным счетом, предлагаю ввести флаг при котором любые услуги выставленные в предела периода, выставляются единым счетом.
4) Уже писал: легализовать подключение нескольких услуг входящих в состав ТП с одинаковой родительской.
5) Телефонный пулы номеров ввести, по подобию IP зон, сейчас приходится вести учет номеров в отдельной таблице. (У номеров обязательно категорию, у категории стоимость, возможность заблокировать к выдаче конкретные номера из пула, выдавать номера в порядке даты освобождения)
6) При редактировании телефонной или IP связки в rfw не передаются как удаленные те номера или ip адреса, которые были удалены при редактировании, например в телефонной связке было 3 номера, от одного абонент отказался, мы удаляем номер путем редактирования связки, при этом в rfw улетает информация по двум номерам, а третий номер на атс остается висеть как активный хотя в биллинге его уже нет.
7) Добавить штатный функционал смены ТП в середине расчетного периода.
выглядит интересным для многих операторов. Над остальным можно подумать. Спасибо.