BiTel

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

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




Начать новую тему Ответить на тему  [ Сообщений: 90 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: 13 авг 2015, 15:19 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
vdd писал(а):
Попробуйте сесть или встать не сгибая ноги в коленях...
Тоже самое происходит при внедрениях схем 15-15 в биллинге с помесячным балансом.
...
распишу чуть позже в разделе форума "Вопросы и предложения"


Расписываю:
http://forum.bitel.ru/viewtopic.php?f=1&t=10789


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
а (CRM) все нет.

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


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

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Phricker писал(а):
а (CRM) все нет.

Отписались бы лучше по предлагаемому функционалу...


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
vdd писал(а):
Phricker писал(а):
а (CRM) все нет.

Отписались бы лучше по предлагаемому функционалу...

Я читал ту тему.
И за меня уже ответили
Цитата:
Больше на ядро похоже, чем на модуль. Учетные периоды логичнее наверное было бы в ядро добавить. А вот Управленческий баланс , тут пока не ясно. 2 разных баланса в ядре чтоли хранить.


Если судить по скорости запиливания новых фич, то даже если планеты удачно сойдутся, то ваше предложение будет не раньше чем через года 3-4. По сути то что вы предложили - есть отдельное ядро, в котором надо переделывать всю логику работы с балансом и услугами. И все модули которые работают с балансом. Точнее пилить два варианта. Один без модуля другой с модулем. И отражать его в договоре без всяких дополнительных менюшек.
Я кажется был даже оптимистичным в прогнозе 3-4 лет.


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

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

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


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

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Phricker писал(а):
По сути то что вы предложили - есть отдельное ядро, в котором надо переделывать всю логику работы с балансом и услугами. И все модули которые работают с балансом. Точнее пилить два варианта. Один без модуля другой с модулем. И отражать его в договоре без всяких дополнительных менюшек.
Я кажется был даже оптимистичным в прогнозе 3-4 лет.

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


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


Для данной темы это оффтопик. Часто ловите рыбу в жидком бетоне?

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

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


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

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

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


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


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

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
да нет тут противоречий, просто предлагается вариант когда вместо трудно реализуемого варианта "15-15", предлагается вариант с подневными абонплатой и своеобразным штрафом за блокировку договора по нехватке средств на балансе (вот для расчета этого штрафа и требуется тарификация вперед на N дней).


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

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


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


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

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


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

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


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


не понял...
1) в чем противоречия с ваше точки зрения?
2) что бы говорить о "частях" не плохо было бы составить список задач, а то сдается у нас с вами эти списки сильно отличаются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 авг 2015, 18:41 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Ясно.
Задействован План "Б". Он же - императив "лыко-мочало-начинай-сначала".


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


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

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


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


ознакомился, к сожалению ответов на свои вопросы я там не нашел....


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

Зарегистрирован: 07 мар 2012, 15:02
Сообщения: 932
Откуда: Воронеж
Карма: 35
Мне кажется, что разработчикам нужно просто реализовать схему "15-15" по своему усмотрению. В таком случае новые клиенты биллинга сразу получат работающую схему и не нужно писать никаких костылей. Если хотелки клиента отличаются от стандартной схемы, то вполне вероятно, что клиент согласится использовать стандартную схему и откажется от своих хотелок. Выбрать уже готовую схему значительно легче, чем полностью писать ТЗ и с нуля всё придумывать.

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

А если ждать, пока текущие пользователи биллинга напишут ТЗ и потом пытаться объединить все хотелки, то соответствующий функционал можно ещё пять лет прождать. Текущим пользователям биллинга, возможно, будем мало пользы, но для будущих польза будет... и тему закроем, наконец-то.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91


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

Зарегистрирован: 01 май 2015, 11:16
Сообщения: 9
Карма: 0
Проблема на самом деле актуальная
Потому что хоть продажники придумывают не думаю о возможностях биллинга, но, в первую очередь
учет (биллинг) должен подстраиваться под бизнес-процессы, а не бизнесс-процессы под биллинг
Так как конкуренция, желание получить бОльшую выгоду требуют этого

Продублирую пост в этой теме
Тему поднял в соседней ветке Subscription http://forum.bitel.ru/viewtopic.php?f=60&t=10803
Цитата:
Привет всем.

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

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

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

Спасибо


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

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


конкурентны не те кто придумает "самую хитрожопую схему", а то у кого лучше качество и ниже себестоимость,
только большенству "продажников" это не ведомо, у них обычно другие критерии на первом месте.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 авг 2015, 17:33 
Не в сети
Клиент

Зарегистрирован: 07 мар 2012, 15:02
Сообщения: 932
Откуда: Воронеж
Карма: 35
orunbekk писал(а):
Проблема на самом деле актуальная
Потому что хоть продажники придумывают не думаю о возможностях биллинга, но, в первую очередь
учет (биллинг) должен подстраиваться под бизнес-процессы, а не бизнесс-процессы под биллинг
Так как конкуренция, желание получить бОльшую выгоду требуют этого


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

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

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91


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

Зарегистрирован: 07 мар 2012, 15:02
Сообщения: 932
Откуда: Воронеж
Карма: 35
Ещё пример, модуль Bill.

У нас компания маленькая, всегда идём навстречу клиентам (юрикам прежде всего). Благодаря этому мы можем предложить более удобные условия оплаты, выставления и доставки счетов (например). Бизнес-процессы, в результате, получаются очень разветвлённые. Когда встала задача автоматизации процесса, то оказалось, что текущие бизнес-процессы невозможно натянуть на логику модуля Bill. Что делать? Писать приложение, которое будет генерировать счета как нам нужно. При этом модуль Bill нам в этом сильно помогает, т. к. уже есть готовые сущности и интерфейсы для работы со счетами. Просить разработчиков, чтобы наши бизнес-процессы работали из коробки - безумие. Но то, что есть основа - замечательно.

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91


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

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


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

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
stark писал(а):
Пока самый простой вариант. Готовы обсудить если нужно что-то сложнее.

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 май 2016, 14:12 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
stark писал(а):
Есть вот такое решение
Пока самый простой вариант. Готовы обсудить если нужно что-то сложнее.

Добавить в вики свой реализованный вариант с метками что ли :lupa:

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


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

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Jimson писал(а):
stark писал(а):
Пока самый простой вариант. Готовы обсудить если нужно что-то сложнее.

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


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

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


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

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
stark писал(а):
Ограничение по объему трафика и доп. услуги - это уже отдельный случай. А как мы их должны учитывать ?
Предположить худший случай, что клиент скачает бесконечно трафика и потребит 100500 услуг дополнительных? Как это предположить, какая эвристика ? Или тут имеется ввиду некоторый фиксированный пакет (трафик + услуги) на определенный период за определенную цену ?

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


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

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Jimson писал(а):
stark писал(а):
Ограничение по объему трафика и доп. услуги - это уже отдельный случай. А как мы их должны учитывать ?
Предположить худший случай, что клиент скачает бесконечно трафика и потребит 100500 услуг дополнительных? Как это предположить, какая эвристика ? Или тут имеется ввиду некоторый фиксированный пакет (трафик + услуги) на определенный период за определенную цену ?

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


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


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

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
stark писал(а):
В таком варианте это сейчас реализуется в модуле inet с помощью учетного периода и расхода за активацию учетного периода. Но вы хотите еще добавить 100 звонков в модуле phone в этот пакет. Если в каждом из модулей будет учетный период, то по идее можно из одного места добавлять эти учетный периоды для каждого модуля. Или вынести учетный период в ядро и учитывать его во всех модулях. Это имелось ввиду?

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


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

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Jimson писал(а):
stark писал(а):
В таком варианте это сейчас реализуется в модуле inet с помощью учетного периода и расхода за активацию учетного периода. Но вы хотите еще добавить 100 звонков в модуле phone в этот пакет. Если в каждом из модулей будет учетный период, то по идее можно из одного места добавлять эти учетный периоды для каждого модуля. Или вынести учетный период в ядро и учитывать его во всех модулях. Это имелось ввиду?

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


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


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

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
stark писал(а):
Про финансовом период писал, кажется, vdd. Даже отдельную тему про это создал. Это чтобы балансы хранить не помесячно. а произвольными периодами . Если я конечно правильно понял понятие финансовый период. Для бухгалтерии все равно нужен календарный баланс . Нужно хранить оба. И под это много надо менять.

Да, и я вроде там предлагал реализовать финансовые периоды не как диапазон дат, а как сдвиг относительно начала месяца. Т.е. "трафик за март", данные по которому достаются/складываются в таблицы _201603, это не трафик с 1.03 по 31.03, а с 1.03+сдвиг по 31.03+сдвиг, ну и соответственно "сдвиг" это core параметр договора. Ну как вариант, что бы меньше менять. Хотя кто то может захотеть потом квартальные периоды, годовые и так далее.

На счет бухгалтерии не уверен, надо уточнять, возможно нет никаких ограничений на выставление инвойсов и актов не календарными месяцами. Я так понимаю что невозможно реализовать выставление актов по календарным месяцам если финансовый период не календарный, на договоре может быть доводящая абонплата, например. Тогда получается что в акт выставляемый "за март" должна попасть наработка последнего периода - с 15.02 по 15.03, а все что с 15.03 наработалось попадет только в акт "за апрель". И вот тут вопрос еще возникает, если реализовывать любые финансовые периоды (квартальные, годовые), то как выставлять помесячные инвойсы и акты?


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

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


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

Зарегистрирован: 07 май 2008, 13:34
Сообщения: 594
Откуда: Москва
Карма: 27
skn писал(а):
а налоговой бухгалтеры будут данные сдавать тоже в произвольные периоды (или со сдвигом ;-) )?

Я пообщался с знающими людьми. Юридически можно выставлять инвойс и акт за любой период, но, как все у нас в стране, по факту так делать не получится из-за налоговой отчетности. У нас, например, она поквартальная, а следовательно когда сдается отчетность то нужно закрыть период. Получается что акты и инвойсы надо выставлять календарным месяцем (или кварталом). С другой стороны речь идет только про Россию, я точно знаю что у загнивающих инвойсы можно выставлять произвольно и никаких проблем не будет.
С одной стороны выходит что не в любой ситуации (в BGB) можно иметь "двинутый" финансовый период на договоре, если надо выставлять бухгалтерские документы, то на таких договорах не должно быть услуг которые могут измениться задним числом (доводящие абон платы и тп), с другой стороны инвойсы физикам не выставляют, а именно в этом сегменте наиболее востребованы некалендарные фин. периоды.

P.S. на самом деле даже если наработка может изменится задним числом (я про период с 15 по 31 при фин периоде 15-15 и инвойсе выставленным 31го числа), то это можно скорректировать при выставлении следующего инвойса, я такое делал для авансовых счетов на bgb 4.x


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Добавил свой частный вариант на вики :)
Заодно и скрипт причесал :D

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


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Допричесывался на вики.
Файлы
http://wiki.bitel.ru/index.php/%D0%A4%D ... Charge.png
и
http://wiki.bitel.ru/index.php/%D0%A4%D ... Charge.png
почему то посчитались
Код:
MIME-тип: application/x-php

А прав на удаление у меня нету. Чо оно хочет я понятия не имею :D

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


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

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Чот щас подумал что можно ж в моем скрипте использовать
Код:
BigDecimal balance = event.getCurrentBalance();
        BigDecimal limit  = event.getLimit();       

ЕМНИП раньше их не было :lupa:
Надо будет добраться и еще причесать

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


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

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


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

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


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

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