BiTel

Попробуйте сесть или встать не сгибая ноги в коленях...
Тоже самое происходит при внедрениях схем 15-15 в биллинге с помесячным балансом.
...
распишу чуть позже в разделе форума "Вопросы и предложения"

А от данной темы меня больше даже интересует не периоды с 15-15 и т.п.
А быстрое получение цены тарифного плана для модуля NPAY Может оно все таки будет из коробки
А то сейчас приходится извращаться с начислением в следующем месяце.

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

Тут противоречие:
если тарифный план подневной, то "вся сумма тарифа сразу" и есть сумма за сутки.
Поэтому по логике нужно хотеть какой-то другой тариф, но не "подневной". Например, некий "попериодный" тариф.
Или хотеть какую-то примочку к тарифу типа "указание суммы_прихода/величины_баланса для изменения статуса договора"

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

Это схема в принципе решает те же задачи что и схема "15-15", но при этом нет проблем с балансами и перерасчетами.

Не, конечно же, никакого противоречия, абсолютно!



Эта схема решает часть задач из разнообразия под названием "схема "15-15"". Очевидно это уже только из того, что используется понятие "штраф за блокировку договора по нехватке средств на балансе ".

Ясно.
Задействован План "Б". Он же - императив "лыко-мочало-начинай-сначала".

Я свое видение функционала, закрывающее максимальное количество схем "15-15", изложил в соответствущем разделе форума.

Привет всем.

Начали использовать BG недавно только, с BG пока сильно "на вы", поэтому прошу помощи или направления у разработчиков и опытных пользователей данного продукта.
Первоначально учет абонплаты был настроен по предоплате и ежемесячного начисления, т.е. с 1го числа начисляется абонка, если у клиента (договора) нехватает средств договор закрывается, т.е. классическая схема работы, все это решалось возможностями модуля NPay.
Но, так как маркетинг не стоит на месте, решено было сделать возможность учета абонплаты с дату на дату в зависимости от даты оплаты.
Т.е. абонентская оплата по тарифу стоит в размере X у.е., и если клиент оплатил 15го числа в этом месяце, он пользуется инетом до 15го числа следующего месяца.
И 16го числа в следующем месяце, если остаток баланса не будет больше или равно стоимости его тарифа, его договор закрывается.
В следующем месяце, клиент не оплачивает, его договор закрывается, через 2 дня, т.е. 18го оплачивает, учет идет уже с 18го по 18ое.
Исключение составляют 30-31 числа, т.е. если он оплатил 31го числа августа месяца, он отключается 30го числа следующего месяца.
Если он оплатил 30го января, то 28го февраля или 29го февраля, если это високосный год, договор закрывается.
Т.е. при каждой оплате нужно фиксировать дату оплату для договора и закрывать в тот же день за исключением 30-31 числа и февраля.

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

Прошу дать направление так сказать, в решении данной задачи.

Спасибо

Проблема на самом деле актуальная
Потому что хоть продажники придумывают не думаю о возможностях биллинга, но, в первую очередь
учет (биллинг) должен подстраиваться под бизнес-процессы, а не бизнесс-процессы под биллинг
Так как конкуренция, желание получить бОльшую выгоду требуют этого

Проблема на самом деле актуальная
Потому что хоть продажники придумывают не думаю о возможностях биллинга, но, в первую очередь
учет (биллинг) должен подстраиваться под бизнес-процессы, а не бизнесс-процессы под биллинг
Так как конкуренция, желание получить бОльшую выгоду требуют этого

Пока самый простой вариант. Готовы обсудить если нужно что-то сложнее.

Это скорее не "простой вариант", а частный случай. Случай когда продается безлимитный (совсем безлимитный) инет за фиксированную абонплату, и тариф всего один, и никогда меняться не будет. Добавляем ограничение по объему трафика или группу тарифных планов или дополнительные услуги, например, телефонию и этот вариант уже не работает. Мое мнение, вы рано или поздно, но согласитесь что нужна полноценная поддержка периодов.

Ограничение по объему трафика и доп. услуги - это уже отдельный случай. А как мы их должны учитывать ?
Предположить худший случай, что клиент скачает бесконечно трафика и потребит 100500 услуг дополнительных? Как это предположить, какая эвристика ? Или тут имеется ввиду некоторый фиксированный пакет (трафик + услуги) на определенный период за определенную цену ?

Не совсем понял вопроса. Обычные договора, абонка с включенным трафиком, например, 600 рублей, включено 20 гигабайт, превышение 100 рублей за гигабайт. Абонент подключился 15го числа и ожидается период "15-15" в рамках которых учитывается "включено" и "превышение".

В таком варианте это сейчас реализуется в модуле inet с помощью учетного периода и расхода за активацию учетного периода. Но вы хотите еще добавить 100 звонков в модуле phone в этот пакет. Если в каждом из модулей будет учетный период, то по идее можно из одного места добавлять эти учетный периоды для каждого модуля. Или вынести учетный период в ядро и учитывать его во всех модулях. Это имелось ввиду?

В модуле инет, на сколько я понял, можно еще попытаться это реализовать через тарифные опции, но да, я имел в виду что реализацию "финансовых периодов" лучше сделать в ядре. Проблема то формулируется достаточно просто: в BGB поддерживается один финансовый период для всех договоров и его нельзя изменить - календарный месяц, осложняется все на уровне хранения данных (сплит таблиц по месяцам). Можно попытаться для каждого конкретного случая придумывать варианты скриптования, но поддержки финансовых периодов в биллинг это не добавит.
P.S. Кстати, а как формулировалась задача для которой реализовывались учетные периоды в inet? Почему они реализовывались для одного модуля?

Про финансовом период писал, кажется, vdd. Даже отдельную тему про это создал. Это чтобы балансы хранить не помесячно. а произвольными периодами . Если я конечно правильно понял понятие финансовый период. Для бухгалтерии все равно нужен календарный баланс . Нужно хранить оба. И под это много надо менять.

а налоговой бухгалтеры будут данные сдавать тоже в произвольные периоды (или со сдвигом )?