BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 29 апр 2024, 00:01

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 83 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: 11 апр 2011, 05:41 
Не в сети
Аватара пользователя

Зарегистрирован: 19 июн 2009, 14:57
Сообщения: 62
Откуда: Камчатка
Карма: 5
Здравствуйте.
Есть такая проблема. Допустим в договоре №2222 на счету лежит 100 рублей. Первого апреля у него должна списаться абонплата в размере 150р. но у него недостаточно денег на счету и договор приобретает статус "закрыт" и напротив модуля npay в договоре высвечивается сумма 50р, которую абонент должен доплатить. Абонплата списывается пропорционально периоду. И если человек пополнит счет - договор разблокируется. НО. Если наступит 10е апреля, то абонплата абонента будет составлять уже 100р, а не 150 (т.к. пропорционально периоду), напротив модуля npay в договоре нарисуется сумма 0, необходимая для доплаты. Денег для списания абонентки достаточно. Но смены статуса договора не происходит. Он так и остается заблокированным!
В планировщике задания на списание абонплат и изменение статусов договоров стоят ежедневно.
Как решить данную проблему?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 апр 2011, 06:21 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Либо перейти на подневное списание абонплат, либо писать скрипт, который раз в день будет искать таких клиентов и открывать их (например, начилсять платёж в 0р., либо тупо статусом).

А вообще, насколько это правильно с точки зрения абонента - включать услуги в таких ситуациях?
Например, абоненту не хватает денег, договор закрывается статусом, абонент думает "ок, пока не буду пользоваться, когда нужно будет - закину". После этого у него неожиданно в середине месяца договор снова открывается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 апр 2011, 08:22 
Не в сети
Аватара пользователя

Зарегистрирован: 19 июн 2009, 14:57
Сообщения: 62
Откуда: Камчатка
Карма: 5
Я считаю, что включать абонентов правильно. Даже если сам абонент пойдет и заплатит 10 рублей у него все заработает. А пока он найдет на это время и желание - пользоваться нашими услугами он не будет.
Интересна сама логика блокировки/разблокировки договоров. Выходит, что стандартными средствами договор не разблокируется даже при достаточном кол-ве средств.. Вот и начисляем 0р на счет таким абонентам. По мнению разработчиков такие договоры могут быть разблокированы только при зачислении платежа?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 апр 2011, 08:38 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Ну эта схема просто задумывалась для подневных абонплат - там она работает отлично.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 апр 2011, 14:19 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
странная схема, получается с 1 по 10 апреля ему нельзя работать а с 10 по 30 можно...
логичнее пока есть деньги пусть работает с 1 по 20 а как кончились - отключать....


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 апр 2011, 04:37 
Не в сети
Аватара пользователя

Зарегистрирован: 19 июн 2009, 14:57
Сообщения: 62
Откуда: Камчатка
Карма: 5
Цитата:
логичнее пока есть деньги пусть работает с 1 по 20 а как кончились - отключать....


Да, так логичнее. Но как это организовать при помесячном режиме снятия абонплаты? Если 1го должна списываться полная сумма, и из-за недостатка средств договор блокируется до лучших времен..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 апр 2011, 08:20 
Не в сети
Аватара пользователя

Зарегистрирован: 19 июн 2009, 14:57
Сообщения: 62
Откуда: Камчатка
Карма: 5
Поговорив с начальством, пришли к такому выводу:
Просто по наступлению момента, когда сумма на счете стала достаточной для списания абонплаты разблокировку производить нельзя. (человек может быть в отъезде, просто не пользоваться интернетом. зачем ему все деньги на счете тратить на абонентку тогда).
Списание должно происходить при наличии активности договора. Т.е. когда человек уже начнет подключаться к сети. Чтобы у него не вылазило лишних сообщений о закрытом договоре (у нас в этом случае при заходе на какой то сайт срабатывает перенаправление на сообщение о балансе и закрытии) . Должно происходить открытие договора.
Ну и главный вопрос, как это организовать? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 апр 2011, 12:46 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
если я вас правильно понял, Вы хотите, чтобы
1) 1 числа проверялся баланс и если у человека денег достаточно для списания полной абонплаты она у него списывается
2) если денег не достаточно то блокировать статус договора
3) по приходу платежа разблокировать статус договора
4) по первому входу клиента после разблокировки списовать абонку.. (полностью или пропорционально периоду?)

P.S. Страно выходит если у человека есть достаточно средств на начало месяца с него будет списана абонтка, даже если он не был активен не разу за месяц.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 апр 2011, 20:14 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Evil писал(а):
Допустим в договоре №2222 на счету лежит 100 рублей.
Первого апреля у него должна списаться абонплата в размере 150р. но у него недостаточно денег на счету и договор приобретает статус "закрыт"
Абонплата списывается пропорционально периоду.
если человек пополнит счет - договор разблокируется.
Если наступит 10е апреля, то абонплата абонента будет составлять уже 100р, а не 150 (т.к. пропорционально периоду)
Денег для списания абонентки достаточно. Но смены статуса договора не происходит. Он так и остается заблокированным!
В планировщике задания на списание абонплат и изменение статусов договоров стоят ежедневно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 апр 2011, 06:30 
Не в сети
Аватара пользователя

Зарегистрирован: 19 июн 2009, 14:57
Сообщения: 62
Откуда: Камчатка
Карма: 5
Цитата:
P.S. Страно выходит если у человека есть достаточно средств на начало месяца с него будет списана абонтка, даже если он не был активен не разу за месяц.

Странно - не странно, а начальство хочет так :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 май 2011, 13:32 
Не в сети
Клиент

Зарегистрирован: 23 сен 2010, 10:37
Сообщения: 208
Откуда: Снежинск
Карма: 0
Ситуация следующая

для работы абоненту не хватает суммы N

если я через программу ему закину эту сумму - договор разблокируется автоматом..
но если деньги поступают из MPS то договор остается закрытым - и напротив модуля абонплат висит 0.00

можно как нибудь поправить?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 май 2011, 21:52 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
Kostiksnz писал(а):
Ситуация следующая

для работы абоненту не хватает суммы N

если я через программу ему закину эту сумму - договор разблокируется автоматом..
но если деньги поступают из MPS то договор остается закрытым - и напротив модуля абонплат висит 0.00

можно как нибудь поправить?

слейв базы нет? у меня была такая проблема из-за нее

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 май 2011, 11:00 
Не в сети
Клиент

Зарегистрирован: 23 сен 2010, 10:37
Сообщения: 208
Откуда: Снежинск
Карма: 0
skyb писал(а):
Kostiksnz писал(а):
Ситуация следующая

для работы абоненту не хватает суммы N

если я через программу ему закину эту сумму - договор разблокируется автоматом..
но если деньги поступают из MPS то договор остается закрытым - и напротив модуля абонплат висит 0.00

можно как нибудь поправить?

слейв базы нет? у меня была такая проблема из-за нее


платеж проходит следующим образом

терминал щлет запрос на мой старый скрипт - который зачисляет деньги на старый биллинг
в старом биллинге ищет признаки переведен ли человек на новый - если да то скрипт редиректит запрос на bgbilling


денюжка приходит - ответ к осмп уходит...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 май 2011, 13:30 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
Kostiksnz писал(а):
skyb писал(а):
Kostiksnz писал(а):
Ситуация следующая

для работы абоненту не хватает суммы N

если я через программу ему закину эту сумму - договор разблокируется автоматом..
но если деньги поступают из MPS то договор остается закрытым - и напротив модуля абонплат висит 0.00

можно как нибудь поправить?

слейв базы нет? у меня была такая проблема из-за нее


платеж проходит следующим образом

терминал щлет запрос на мой старый скрипт - который зачисляет деньги на старый биллинг
в старом биллинге ищет признаки переведен ли человек на новый - если да то скрипт редиректит запрос на bgbilling


денюжка приходит - ответ к осмп уходит...

вы не отвечаете на мой ответ(с):-D
Слейв база то есть? у боевого и как я понял старого бллинга.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 май 2011, 23:07 
Не в сети
Клиент

Зарегистрирован: 23 сен 2010, 10:37
Сообщения: 208
Откуда: Снежинск
Карма: 0
skyb писал(а):
Kostiksnz писал(а):
skyb писал(а):
Kostiksnz писал(а):
Ситуация следующая

для работы абоненту не хватает суммы N

если я через программу ему закину эту сумму - договор разблокируется автоматом..
но если деньги поступают из MPS то договор остается закрытым - и напротив модуля абонплат висит 0.00

можно как нибудь поправить?

слейв базы нет? у меня была такая проблема из-за нее


платеж проходит следующим образом

терминал щлет запрос на мой старый скрипт - который зачисляет деньги на старый биллинг
в старом биллинге ищет признаки переведен ли человек на новый - если да то скрипт редиректит запрос на bgbilling


денюжка приходит - ответ к осмп уходит...

вы не отвечаете на мой ответ(с):-D
Слейв база то есть? у боевого и как я понял старого бллинга.


нету... про старый можно забыть...

bgbilling весь на одной машине, одна БД, никаких слейв баз

все как по инструкции по установке :roll:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 май 2011, 18:39 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
skn писал(а):
странная схема, получается с 1 по 10 апреля ему нельзя работать а с 10 по 30 можно...
логичнее пока есть деньги пусть работает с 1 по 20 а как кончились - отключать....

Логичнее, а теперь покажите-ка, пожалуйста, пример ТП под Ваше столь логичное заключение.
Мы тут можем долго фантазировать и рассуждать о том правильная логика заложена в тарифы или нет, но факт остается фактом - в большинстве случаев тарифы рисуются именно под логику работы БГБ, а она, если верить Вашему высказыванию, получается совершенно нелогичной )))

По сабжу - вопрос:
snark писал(а):
как будут работать дебетовые абонплаты с режимом "пропорционально периоду"?

так и остается открытым :(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 май 2011, 21:29 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
snark писал(а):
skn писал(а):
странная схема, получается с 1 по 10 апреля ему нельзя работать а с 10 по 30 можно...
логичнее пока есть деньги пусть работает с 1 по 20 а как кончились - отключать....

Логичнее, а теперь покажите-ка, пожалуйста, пример ТП под Ваше столь логичное заключение.


Подневная абонплата, не прокатит?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 май 2011, 21:45 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
skn писал(а):
Подневная абонплата, не прокатит?

В том то и дело что нет :(
Если б это было реально - я бы давно уже стал ее использовать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 май 2011, 23:57 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
snark писал(а):
skn писал(а):
Подневная абонплата, не прокатит?

В том то и дело что нет :(
Если б это было реально - я бы давно уже стал ее использовать.


и почему? Ограничения БГБ или заморочки комерческого?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 16:44 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Тут скорее клиенты и стремящиеся им угодить коммерсанты, а не БГБ.

Говоря по совести БГБ тоже хорош - функционал есть, он работает, но нормально работает только с одним видом абон. плат, хотя оных в БГБ - на любой вкус есть (за что его и любят). Почему то что работает для одной разновидности абонплат не работает для другой(их) - загадка. Если уж делать - то делать для всего спектра абон. плат, Вы не находите?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 17:37 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Я уже не раз высказывал свое мнение по поводу, что можно считать абонплатой, а что таковой не является. Я под абонплатой понимаю, периодическое списание, не зависящее от текущего балана. Списание средств зависящее от баланса, это надо относить к случаю разового списание за услугу на определенный срок, с возможностью автоматического продления на новый срок. Вообщем это совсем другой модуль с другой логикой (и эта логика должна основываться на событийной модели, а не на календаре).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 19:04 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Нам дали инструмент с заранее заложенной логикой (БГБ), а в его модуль для работы с абон. платами заложен функционал под названием "Дебетовые абонплаты" который
мануал писал(а):
позволяет закрывать статус дебетовых договоров в случае, если начисление им абонентской платы может привести к опусканию остатка меньше лимита.

Так же этот модуль, заметьте, специально сделанный именно для работы с абон. платами, обладает массой, без вского сомнениния, очень полезных и удобных вариантов снятия оной абон. платы, но почему-то, по какой-то совершенно непонятной и необъяснимой причине ("внезапно!(тм)"?), функционал под названием "Дебетовые абонплаты" работает только с одним (sic!) из всех возможных вариантов снятия абон. платы.
Повторюсь, мы все тут, придумываем свои тарифы на основе того что заложено в БГБ, а раз функционал есть - он, обязан работать, т.е. он либо работает для всех видов абон. плат либо не работает вовсе - 3-го варианта тут не дано. Разве не так?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 21:18 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Я отношу "функционал под названием "Дебетовые абонплаты"" к разряду "костылей" сделаного для ОДНОГО ЧАСТНОГО случая и расширять его на все случаи жизни не стоит. Проблема в том, что это задача не имеет четкого алгоритма (по крайней мере в тех терминах и объектах, что реализованы в этом модуле ), а следовательно и нет полной реализации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 23:27 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Тогда почему нельзя написать в мануале нечто в духе:
Код:
Функционал дебетовых абонплат работает только с подневными абонплатами и никакие другие режимы снятия абонентских плат с дебетовыми абонплатами работать не будут!

И все! Больше никто не будет себе голову ломать вопросом "почему же дебетовые абонплаты не работают?", более того - даже не будет думать их использовать.

Взять меня - я хотел перейти от использования своего достаточно костыльно-примитивного, но тем не менее работающего скрипта, который определял пускать юзера в инторнеты или не пускать на основании его баланса и тарифа, к использованию дебетовых абонплат, и что? И получается что мои абонентки "пропорционально периоду", пусть постепенно умирающие, просто не будут работать, равно как и "безусловно" к которым они переходят. Грустно :(

BTW, не мешало бы описать как работают "как выгоднее" и т.п. абонплаты. Если это есть и я просто не нашел - ткните, пожалуйста, в линк.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 май 2011, 23:57 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Что бы что либо советовать нужно знать какую задачу Вы решаете. Опишите ваш алгоритм, когда и за, что Вы берете плату, и было бы неплохо описать почему именно такой режим используется, а не другой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2011, 01:44 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
У меня 2 основных используемых типа абонплаты:
1. пропорционально периоду - используется только для тарифов с учетом трафика, трафик так же предоставлется проп. периоду.
2. безусловно - используется для безлимитных тарифов.

Чтобы механизм "пропорционально периоду" работал как задумано (он же от даты услуги "пляшет"?) - на событие "запрос учетного периода" висит скрипт, который при первом подключении в текущем месяце берет баланс юзера на момент оного подключения и на основе его тарифа оценивает, хватает у него денег на инет или нет - если хватает - скрипт проставляет даты нужным услугам и создает период, если денег не хватает - событие запроса учетного периода не обрабатывается, т.е. даты не проставляются и период не создается. Тот же самый механизм действует и для абоненток "безусловно", т.к. нет нужны писать 2 части кода, да и юзер может, по заявлению (тарифы меняются только с 1-го числа, а если надо посреди месяца - необходимо заявление), перейти с одного типа абонентки на другой.
Так получается полный онлайн, в плане проверки денег, хотя я думаю что это все же использование скрипта дает излишняюю нагрузку на мускул.

Использование "пропорционально периоду" очень удобно и мне и юзеру - чем ближе к концу месяца - тем меньше абон. плата (удобно юзеру), но и меньше объем трафика (удобно мне).

Использование "безусловно" очень удобно для меня, т.к. деньги снимаются полностью вне зависимости от даты, и не очень удобно для юзера, т.к. даже за пару дней пользования интернетом ему приходится платить всю сумму, но я не могу, в зависимости от даты, пойти на уменьшение абон. платы, а юзеры 100% не пойдут на уменьшение скорости.

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

Упрощенно скрипт выглядит так:
Код:
event.setProcessed(true);

npaySumm = new BigDecimal(tariffPrice); // первоначальная стоимость услуг npay = стоимость тарифа

if (priceByPeriod)
{
    daysNow   = new BigDecimal(calendar.get(Calendar.DAY_OF_MONTH));
    daysTotal = new BigDecimal(calendar.getActualMaximum(Calendar.DAY_OF_MONTH));
    daysGone  = daysNow.subtract(new BigDecimal("1"));

    daysNow   = daysNow.setScale(2, BigDecimal.ROUND_HALF_UP);
    daysTotal = daysTotal.setScale(2, BigDecimal.ROUND_HALF_UP);
    daysGone  = daysGone.setScale(2, BigDecimal.ROUND_HALF_UP);

    // размер абон. платы / кол-во дней в текущем месяце * (кол-во дней в текущем месяце — кол-во полных прошедших дней текущего месяца)
    npaySumm = npaySumm.divide(daysTotal, 6, BigDecimal.ROUND_HALF_UP).multiply(daysTotal.subtract(daysGone));
    npaySumm = npaySumm.setScale(2, BigDecimal.ROUND_HALF_UP);

}

npaySumm = npaySumm.add(npayServiceSumm); // получаем полную сумму услуг npay добавляя стоимость доп. услуг

// если баланс >= 0 - обрабатываем запрос учетного периода
if (balance.compareTo(npaySumm) >= 0)
{
    ...
}
else
{
    return;
}

Из за того что это выполянется в контексте радиуса стоимость тарифов приходится обрабатывать так:
Код:
tariffId = сontractTariffManager.getContractTariff(cid, calendar).getTariffPlanID();

int tariffPrice   = 0;
boolean priceByPeriod = false;

switch (tariffId)
{
    case 1:
        tariffPrice   = 100;
        priceByPeriod = true;
        break;
    case 2:
        tariffPrice   = 200;
        break;
    case 3:
        tariffPrice   = 300;
        priceByPeriod = true;
        break;
    case 4:
        tariffPrice   = 400;
        break;
...
    default:
        break;
}

Правда я почему-то считаю что это будет быстрее чем что-то более гибкое, но регулярно лазающее в БД.
Есть идея переписать это все под событие таймера, но это пока голая идея и неизвестно рабочая ли вообще.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2011, 03:20 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Помоему основная сложность с Вашими схемами - привязка к календарному месяцу, если бы по каждой схеме можно было бы просто активировать период на n дней (1, 3, 5, 10, 30), то и расчеты бы упростились и клиенты бы ли бы довольны.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2011, 11:03 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
С этого места, пожалуйста, поподробнее!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2011, 16:17 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Многие сложности в биллинги связаны с необходимости проводить переобсчеты, и что бы не переобсчитывать за всю историю с начала существования договора, делаются переодические срезки баланса, в данный момент они привязаны к началу календарного месяца. Это удобно с точки зрения юридических лиц, так как взаиморасчеты с ними обычно привязаны к календарным месяцам, а вот в случае с физическими лицами это скорее недостаток. Если бы срезы баланса можно было бы делать в произвольные промежутки времени, например в момент активации услуги, это было удобнее. Правда возможно возникли бы проблемы с построением отчетов, да и придеться переделывать многие части биллинга.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2011, 17:39 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Слава б-гу я не занимаюсь регулярными перерасчетами.

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

P.S. Скажите, пожалуйста, дебетовые абонплаты будут работать для абонплат "безусловно"? Или все же только с подневными?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 83 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 1.491s | 78 Queries | GZIP : On ]