BiTel

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

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




Начать новую тему Ответить на тему  [ Сообщений: 90 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: 28 янв 2015, 13:27 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
Сабж, можно ли как то сделать тариф, в котором абонка будет списываться с абонента с месяцем привязанным к абоненту а не к календарю, тоесть с 15 февраля по 15 марта, а не с 15 по 28 и с 1 по 15

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 янв 2015, 13:40 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
вроде бы модуль subcription для этого, но там нет возможности переобсчета. Можно еще расходами вешать в скриптах. Если если это интернет, то можно привязать это учетному периоду inet.


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

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
А ручной режим есть? как то в тарифах расписать периоды чтоль

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


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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июл 2015, 00:26 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
stark писал(а):
Если если это интернет, то можно привязать это учетному периоду inet

Как привязать npay абонентку к периодам inet?


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

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
snark писал(а):
stark писал(а):
Если если это интернет, то можно привязать это учетному периоду inet

Как привязать npay абонентку к периодам inet?


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июл 2015, 16:28 
Не в сети
Клиент

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

Подобные советы очень увеличивают необходимость npay и поднимают его продажи.

Честно говоря глядя на "развитие" npay, особенно если посмотреть на inet, то меня уже давно терзают смутные сомнения в необходимости у себя npay. Зачем он нужен, если все можно сделать скриптами и, что самое удивительное, этот метод предлагают сами разработчики, поэтому я, невольно, делаю вывод о том, у npay нет будущего, ведь его не хотят развивать. Последней глобальной доработкой npay были дебетовые абонентки, да и то они как были заточены строго под определенные алгоритмы начисления, так и остались таковыми.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июл 2015, 16:37 
Не в сети
Разработчик

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


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
skn писал(а):
npay задумывался и реализован под конкретные задачи, (месячные списания)
другие виды списаний добавлять в него не вижу смысла, для этого есть другие модули.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июл 2015, 17:25 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
А если мы натаскаем для этого модуль RSCM ? Если мы сделаем возможность на различные события ( активация учетного периода в inet и т.п) добавлять услугу rscm . Цена на нее в тарифе есть, пересчеты возможны . Или именно npay надо ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июл 2015, 17:26 
Не в сети
Разработчик

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


о каком статусе речь и о какой интеграции?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 23 июл 2015, 16:12 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
skn писал(а):
npay задумывался и реализован под конкретные задачи, (месячные списания)
другие виды списаний добавлять в него не вижу смысла

Какие еще другие виды списаний?! Абонентки, о которых здесь идет речь, прекрасно вписываются в понятие ежемесячных списаний и их регулярно просят уже много лет. Для примера возьмем эту тему от 07.07.2010 (5 лет, Карл!)
m2pod писал(а):
подключился абонент 15 числа месяца, заплатил полную сумму за тариф, и может пользоваться до 15 числа след месяца(грубо говоря 30 дней)

Вопрос подымался пять лет назад и, повторюсь, регулярно подымается до сих пор, но в Бител до сих пор считают, что такие абонентки не существуют, их никто не использует и они никому не нужны :facepalm:
Господа разработчики, пожалуйста, очень прошу, снимитесь с ручника, выйдите из своего выдуманного мира и посмотрите на реальность не зашоренными глазами.


Кстати о скорости. Два года назад писал
snark писал(а):
Дебетовые абонплаты не приостанавливают договор, т.к. не видят стоимости абонентки "обернутой" условием начисления на основе объема услуги. Приостанавливать договор скриптом тоже не получается, т.к. Calculator, предсказуемо, так же не видит подобных абонплат.

Вангую, что воз и ныне там, а ведь дебетовые абонентки и начисление в зависимости от объема - это стандартный функционал npay.



skn писал(а):
есть другие модули

Для простого, тупо-в-лоб списания/начисления можно, как вы и советуете, использовать скрипты и ни npay, ни subscription, ни rscm не нужны.



stark писал(а):
если мы натаскаем для этого модуль RSCM ? Если мы сделаем возможность на различные события ( активация учетного периода в inet и т.п) добавлять услугу rscm . Цена на нее в тарифе есть, пересчеты возможны

Побрейтесь бритвой Оккама.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 23 июл 2015, 16:53 
Не в сети
Разработчик

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

перечитайте темы на которые вы ссылаетесь, и попробуйте составить ПОЛНОЕ тех. задание на так называемые "абоненки с 15 по 15 число"...
хотят действительно многие, но как только доходит до ТЗ и начинаешь задавать вопросы, а что делать когда это, или то... то обсуждение быстро затухает,
начинаются ответы типа "ну как нибудь", "не знаю..", "у нас такого не может быть..." и т.д.
или одни описывают какую то одну узко специализированную схему, другие другую, в итоге легче каждому накостылить скрипты, чем изобретать "единственную", супер конфигурируемую схему...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 23 июл 2015, 17:29 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
snark писал(а):


Кстати о скорости. Два года назад писал
snark писал(а):
Дебетовые абонплаты не приостанавливают договор, т.к. не видят стоимости абонентки "обернутой" условием начисления на основе объема услуги. Приостанавливать договор скриптом тоже не получается, т.к. Calculator, предсказуемо, так же не видит подобных абонплат.

Вангую, что воз и ныне там, а ведь дебетовые абонентки и начисление в зависимости от объема - это стандартный функционал npay.


Перечитал, там костыль предложили сделать . Там еще почему-то утверждается что калькулятор и задача закрытия статусов работают по разному, хотя они оба доходят только до первого узла и получают 0 . т.е по факту одинаково. там нет логических противоречий как раз. А вы же хотите как раз по разному сделать , чтобы задача закрытия статуса шла пока не найдет цену .. Насколько я понял по итогам обсуждения Амир предложил сделать отдельный узел чтобы при задача блокировки работало по другому.. Т.е по факту вам там нужно как бы 2 тарифа - один для начисления, второй для блокировки. Второй тариф как бы с одном узлом цена и все, а для начисления 2 узла .


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

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
skn писал(а):
попробуйте составить ПОЛНОЕ тех. задание на так называемые "абоненки с 15 по 15 число"

Не знаю, как насчет ТЗ, но общую идею, наверное не очень сложную в доработке и, пожалуй, достаточно для всех подходящую, я могу предложить.

Зная, что в inet есть такое понятие как учетный период, можно, по аналогии с абонентками зависящими от наработки по объёму добавить поддержку модулем npay учетных периодов других модулей, например как-то так:
Код:
module.accounting.period.<id>.mid=<mid>
module.accounting.period.<id>.class=<class_name>
Например
Код:
module.accounting.period.1.mid=1
module.accounting.period.1.class=ru.bitel.bgbilling.modules.inet.npay.InetAccountingPeriod
Ну или нечто аналогичное.

Основная мысль в том, что благодаря подобной конструкции у npay в ветке появится "За учетный период модуля "<module.title>"" и абонентка будет учитываться на основе учетного периода модуля указанного в module.accounting.period.mid, а учетный период, если его реализовать скриптом, может быть произвольной величины.

Само собой разумеется, что для того чтобы это работало учетный период обязан быть проставлен.

Так же подразумевается, что module.accounting.period.mid == module.amount.mid и было бы неплохо, если бы можно было делать как-то так:
Код:
module.accounting.period.1.mid=1
module.accounting.period.1.class=ru.bitel.bgbilling.modules.inet.npay.InetAccountingPeriod

module.amount.1.title=Входящий трафик
module.amount.1.mid=1
module.amount.1.class=ru.bitel.bgbilling.modules.inet.npay.InetModuleAmount
module.amount.1.sids=2

Собственно если сделать нечто подобное, то подобная конструкция, наверное, может кому-то полностью заменить ежемесячные или даже ежегодные абонентки :)


stark писал(а):
калькулятор и задача закрытия статусов доходят только до первого узла и получают 0
вы же хотите, чтобы задача закрытия статуса шла пока не найдет цену

npay так устроен, что для определения цены в зависимости от объема у него должно быть больше одного узла (1-й узел - "от 0 до Х", 2-й узел - "от Х до бесконечности"), поэтому я считаю, что калькулятор обязан брать цену не из первого узла, а из последнего, т.к. там всегда последняя, финальная цена. Разумеется речь идет только про узлы с зависимостью от наработки.


stark писал(а):
по итогам обсуждения Амир предложил сделать отдельный узел чтобы при задача блокировки работала по другому.. Т.е по факту вам там нужно как бы 2 тарифа - один для начисления, второй для блокировки. Второй тариф как бы с одном узлом цена и все, а для начисления 2 узла

Но ведь это натуральный костыль с нагромождением излишних сущностей.
Впрочем, если это самый простой выход из сложившейся ситуации, то почему бы и нет? Соответственно возникает вопрос: когда ждать? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 23 июл 2015, 21:59 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
теперь вопросы:

наработка npay в какой месяц должна попадать? в месяц когда начался учетный период, или в месяц когда закончился период, или размазать на оба месяца?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 23 июл 2015, 22:17 
Не в сети
Разработчик

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

npay так устроен, что для определения цены в зависимости от объема у него должно быть больше одного узла (1-й узел - "от 0 до Х", 2-й узел - "от Х до бесконечности"), поэтому я считаю, что калькулятор обязан брать цену не из первого узла, а из последнего, т.к. там всегда последняя, финальная цена. Разумеется речь идет только про узлы с зависимостью от наработки.


не совсем понятно когда и как у вас происходит блокировка и снятия абонплаты
на 1 число мы не знаем какая наработка будет у клиента, поэтому блокировать его на основание того, что на начало месяца у него нет МАКСИМАЛЬНОЙ суммы абонплаты за месяц, как то не правильно...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июл 2015, 00:15 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
snark писал(а):
skn писал(а):
stark писал(а):
калькулятор и задача закрытия статусов доходят только до первого узла и получают 0
вы же хотите, чтобы задача закрытия статуса шла пока не найдет цену

npay так устроен, что для определения цены в зависимости от объема у него должно быть больше одного узла (1-й узел - "от 0 до Х", 2-й узел - "от Х до бесконечности"), поэтому я считаю, что калькулятор обязан брать цену не из первого узла, а из последнего, т.к. там всегда последняя, финальная цена. Разумеется речь идет только про узлы с зависимостью от наработки.




Ну я понял как это можно сделать, только не надо путать это с калькулятором..Калькулятор зайдет в первый узел
и если его там все удовлетворит, дальше не идет. Есть второй процесс(задача закрытия статуса), назовем его блокиратор(закрыватель, погонщик статуса :D ) ..Вот его запрос в тариф должен дойти до вашего по максимального значения.И чтобы он сделал нужно ему передать не реальную наработку в байтах, а какое-то очень большое значение, например 2^64 байт, тогда он всегда попадет в ваш последний узел. Т.е нужно чтобы в случае запроса из блокиратора не пытались например вызывать класс
Код:
module.amount.1.class=bitel.billing.server.npay.bean.DialUpModuleAmount

чтобы получить значение наработки, а сразу туда ставили условную бесконечность(2^64 байт ).

И это естественно надо сделать опционально, иначе многие удивятся. Или глобально..или сам узел "Условие по объёму услуги" там какой-то галкой включить такое поведение в случае если запрос идет для выяснения цены для закрытия статуса. вот такой вижу вариант для реализации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июл 2015, 02:23 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
skyb писал(а):
Сабж, можно ли как то сделать тариф, в котором абонка будет списываться с абонента с месяцем привязанным к абоненту а не к календарю, тоесть с 15 февраля по 15 марта, а не с 15 по 28 и с 1 по 15


А чем не устраивает схема с подневными абонплатами и разблокировкой только при при внесении на баланс суммы равной 30 дневным абонплатам?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июл 2015, 12:00 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
skn писал(а):
А чем не устраивает схема с подневными абонплатами и разблокировкой только при при внесении на баланс суммы равной 30 дневным абонплатам?

А есть такая схема из каропки? )

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июл 2015, 13:24 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
Phricker писал(а):
skn писал(а):
А чем не устраивает схема с подневными абонплатами и разблокировкой только при при внесении на баланс суммы равной 30 дневным абонплатам?

А есть такая схема из каропки? )


в данный момент нет, но можно сделать если есть необходимость


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 июл 2015, 16:29 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
skn писал(а):
наработка npay в какой месяц должна попадать? в месяц когда начался учетный период, или в месяц когда закончился период, или размазать на оба месяца?

В принципе достаточно оставлять всю наработку в месяце начала учетного периода, ведь сейчас те кто скриптом заносят расходы/наработки так и делают, но если говорить о схеме, которая бы устроила чуть ли не всех (бухгалтерия и вот это вот все), то можно сделать какую-то такую опцию
Код:
# месяц учета наработки на основе учетного периода (например сентябрь, октябрь и ноябрь)
# 0 - первый месяц (сентябрь)
# 1 - последний месяц (ноябрь)
# 2 - равномерное разделение наработки на кол-во месяцев (1/3 наработки будет в сентябре, 1/3 в октябре и 1/3 в ноябре)
module.accounting.period.<id>.money=
Если используется вариант 2 и из-за деления цены возникает остаток, то остаток всегда заносится на 1-й месяц.
Почему именно 1-й месяц? Потому что он 1-й :) Он - начало отсчета и, пожалуй, проще ориентироваться именно на начало. "Есть у революции начало, нет у революции конца"(с)


stark писал(а):
Есть второй процесс(задача закрытия статуса), назовем его блокиратор(закрыватель, погонщик статуса :D ) ..Вот его запрос в тариф должен дойти до вашего по максимального значения.И чтобы он сделал нужно ему передать не реальную наработку в байтах, а какое-то очень большое значение, например 2^64 байт, тогда он всегда попадет в ваш последний узел.

Для того чтобы научить дебетовые абонентки "видеть" подобные тарифы - это вполне годная схема и без всяких доп. узлов в тарифе :)


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

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
snark писал(а):
skn писал(а):
наработка npay в какой месяц должна попадать? в месяц когда начался учетный период, или в месяц когда закончился период, или размазать на оба месяца?

В принципе достаточно оставлять всю наработку в месяце начала учетного периода, ведь сейчас те кто скриптом заносят расходы/наработки так и делают, но если говорить о схеме, которая бы устроила чуть ли не всех (бухгалтерия и вот это вот все), то можно сделать какую-то такую опцию
Код:
# месяц учета наработки на основе учетного периода (например сентябрь, октябрь и ноябрь)
# 0 - первый месяц (сентябрь)
# 1 - последний месяц (ноябрь)
# 2 - равномерное разделение наработки на кол-во месяцев (1/3 наработки будет в сентябре, 1/3 в октябре и 1/3 в ноябре)
module.accounting.period.<id>.money=
Если используется вариант 2 и из-за деления цены возникает остаток, то остаток всегда заносится на 1-й месяц.
Почему именно 1-й месяц? Потому что он 1-й :) Он - начало отсчета и, пожалуй, проще ориентироваться именно на начало. "Есть у революции начало, нет у революции конца"(с)



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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июл 2015, 18:16 
Не в сети
Разработчик

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

В принципе достаточно оставлять всю наработку в месяце начала учетного периода, ведь сейчас те кто скриптом заносят расходы/наработки так и делают, но если говорить о схеме, которая бы устроила чуть ли не всех (бухгалтерия и вот это вот все), то можно сделать какую-то такую опцию
Код:
# месяц учета наработки на основе учетного периода (например сентябрь, октябрь и ноябрь)
# 0 - первый месяц (сентябрь)
# 1 - последний месяц (ноябрь)
# 2 - равномерное разделение наработки на кол-во месяцев (1/3 наработки будет в сентябре, 1/3 в октябре и 1/3 в ноябре)
module.accounting.period.<id>.money=
Если используется вариант 2 и из-за деления цены возникает остаток, то остаток всегда заносится на 1-й месяц.
Почему именно 1-й месяц? Потому что он 1-й :) Он - начало отсчета и, пожалуй, проще ориентироваться именно на начало. "Есть у революции начало, нет у революции конца"(с)


с режимом 1 и 2 есть такой нюанс, например у нас на 14 число у клиента на балансе 300 руб и у него с 15 числа активируется абонплата на 30 дней за 300 руб,, при этом 150 руб. попадает в наработку этого месяца, а 150 руб в наработку следующего, при этом придется создать баланс следующего месяца, с входящим остатком в 150 руб и наработкой 150 руб. Таким образом в текущем месяце на 16 число у клиента будет на счете +150 руб и он их теоретически может потратить на другие услуги, при этом будет меняться входящий остаток следующего месяца и у клиента в следующем месяце баланс уйдет в минус.... Что делать с этим?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июл 2015, 20:40 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
stark писал(а):
переобсчет за какой месяц будете запускать ? За 1-ый ? У одного абонента это месяц 1-ый, а у другого это уже 2-ой. Тогда допустим вы узнали что в каком -то месяце n изменилась цена задним числом. Чтобы все исправить вам нужно переобсчитывать с n-1 месяца до текущего ( если он больше n). А если вы потом захотите учетный период больше месяца сделать? Тогда пересчитываем с n-3 месяца?

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

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


skn писал(а):
snark писал(а):
Код:
# месяц учета наработки на основе учетного периода (например сентябрь, октябрь и ноябрь)
# 0 - первый месяц (сентябрь)
# 1 - последний месяц (ноябрь)
# 2 - равномерное разделение наработки на кол-во месяцев (1/3 наработки будет в сентябре, 1/3 в октябре и 1/3 в ноябре)

с режимом 1 и 2 есть такой нюанс, например у нас на 14 число у клиента на балансе 300 руб и у него с 15 числа активируется абонплата на 30 дней за 300 руб,, при этом 150 руб. попадает в наработку этого месяца, а 150 руб в наработку следующего, при этом придется создать баланс следующего месяца, с входящим остатком в 150 руб и наработкой 150 руб. Таким образом в текущем месяце на 16 число у клиента будет на счете +150 руб и он их теоретически может потратить на другие услуги, при этом будет меняться входящий остаток следующего месяца и у клиента в следующем месяце баланс уйдет в минус.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 июл 2015, 01:45 
Не в сети
Разработчик

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 июл 2015, 02:16 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
snark писал(а):
stark писал(а):
переобсчет за какой месяц будете запускать ? За 1-ый ? У одного абонента это месяц 1-ый, а у другого это уже 2-ой. Тогда допустим вы узнали что в каком -то месяце n изменилась цена задним числом. Чтобы все исправить вам нужно переобсчитывать с n-1 месяца до текущего ( если он больше n). А если вы потом захотите учетный период больше месяца сделать? Тогда пересчитываем с n-3 месяца?

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


Это исключительно ваше личное убеждение, подтвержденное лично вашей многолетней практикой. :roll:

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 июл 2015, 11:45 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
snark писал(а):
Честно говоря я еще не придумал, как именно можно зарезервировать деньги так, чтобы они были недоступны для списания со счета другими модулями :(


У нас есть для этого понятие резерв ( c 6.1 кажется).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 июл 2015, 14:28 
Не в сети
Клиент

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

Но ведь "подневные абонентки с разблокировкой только при при внесении на баланс полной суммы" искаропки не работают.


vdd писал(а):
система, считающая деньги, не способная воспроизвести собственные вычисления за любой указанный период - это граната в переднем кармане брюк, взрыв которой не выдержат гениталии из любого материала

Уважаемый vdd, я не буду спорить с вашим, бесспорно, правильным утверждением, но все же, давайте не будем отвлекаться от темы.

Пожалуй стоит сказать, что я, в обозримом будущем, вообще не планирую использовать абонентки о которых говорит ТС. Я всего лишь дискутирую с нашими уважаемыми разработчиками на предмет возможного развития нашего с вами БГБ. У меня появились идеи (хорошие или плохие - это другой вопрос) и я их предлагаю. Даже если мои идеи не будут приняты разработчиками, то, возможно, это натолкнет их на какое-то свое, более правильно, с точки зрения архитектуры, решение и от этого мы все будем только в плюсе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 28 июл 2015, 15:46 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Стоило отвлечься, что бы поныть неподалеку, как тут же обвинили в уклонении от темы. :roll:

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

Так же прошу объяснить, откуда в нашей стране, использующей григорианский календарь (7 месяцев по 31 день, 4 месяца по 30 дней, 1 месяц в 28-29 дней), с завиднейшим упорством вылезает тема "период действия услуги с 16 числа по 16 число следующего месяца". :shock:


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

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


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

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


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

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