BiTel

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

Исходная мотивация: http://forum.bitel.ru/viewtopic.php?f=16&t=10122&start=30#p91169

Рабочее название: Manag или, например, Period. Далее по тексту - просто "модуль".

Термины:
Учетный период - аналог бухгалтерского (календарного) периода из договора, но с произвольными датами открытия-закрытия;
Управленческий баланс - баланс учетного периода.

Задачи, решаемые модулем:

Формирование учетных периодов;
Выдача другим модулям информации о периодах;
Прием от других модулей наработки;
Трансляция управленческих балансов в бухгалтерские (календарные) балансы;
Отображение уже сформированных периодов и их данных - даты открытия-закрытия, баланс, факты трансляции в бухгалтерский баланс, наработка, расходы, приходы и т.п.

Влияние на работу других модулей и ядра:

При наличии данного модуля на договоре изменяется поведение других модулей при тарификации:

Модули, использующие "помесячные" диапазоны дат, должны получать диапазоны от данного модуля;
Модули, формирующие наработку, должны передавать ее в данный модуль;

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

Возможная реализация:

Формирование учетных периодов:

"Из коробки":

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

Скриптом.

Трансляция управленческого баланса в бухгалтерский:

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

бухгалтерский баланс равен сумме управленческих балансов за месяц;
бухгалтерский баланс равен сумме управленческих балансов за месяц плюс величина управленческой наработки на конец месяца минус величина управленческой наработки на начало месяца;

Скриптом.

Замечания, предложения?

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

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

Учетные периоды в ядре и сейчас есть - календарные.

Календарный период - частный случай произвольного. Поэтому если делать универсально (хочу календарные периоды на договоре, хочу - произвольные), то получается либо отдельный модуль "Баланс", либо доработка в ядре.

Модуль предлагается для того, что бы не мешать тем, кому достаточно существующего, календарного, варианта.


Поэтому и модуль.



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

.

Переименовал тему. А то что-то странно - такое количество требующих костылей в NPay под "15-15", а в теме про нормальное решение - никого.

прошу прощения, случайно отредактировал вместо цитирования .

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

Отчетный период для договора реализуется в виде сдвига относительно начала месяца. Например, период начинающийся с 5го числа это сдвиг +4. При этом при просмотре наработки, детализации или финансовых документов при выборе, например, марта, мы получаем фактический период не [1.03.xxxx, 1.04.xxxx), а [1.03.xxxx + 4, 1.04.xxxx + 4). Что бы меньше возникало путаницы сдвиг может быть как положительным, так и отрицательным, например для периода с 30го числа сдвиг будет -2, тогда "февраль" (не високосный год) это [30.01, 27.02), а "март" соответственно [27.02, 30.03).

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

Полноценная реализация не сложнее "упрощенных" вариантов. Так что дело только в "воле Вселенной".

вроде речь идет про ПРОИЗВОЛЬНЫЕ учетные периоды, т.е. он может быть и пару минут и пару лет, не совсем понятно как они должны коррелировать с бухгалтерскими месячными периодами...

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

а здесь сразу предлагается начать с конкретного решения....

Лично я только за произвольный учетный период в тарифных опциях.

Доведение до абсурда - обычный прием. Но пост вроде не во Флейме...


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

Мне же всего навсего хочется, что бы конфиг модуля NPay "не обогатился" десятком-другим параметров типа


Поэтому я предложил общее решение. Обладателей частных случаев оно не заинтересовало. Бывает.

сначала должны быть - не не обязательно, как бы... По всякому бывает...

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

Это вот сейчас к чему было написано?

к тому, что у вас есть свое решение, у меня свое, у других разработчиков свои, какое лучше нельзя сказать пока ТОЧНО не определена задача
и пока это не определено глупо браться за реализацию...

Произвольный это в оригинальном сообщении, я в этом вопросе не на столько силен, но на сколько я знаю финансовый (отчетный) период не может быть абстрактным. Он точно бывает месяц, квартал, полгода, год, возможно еще неделя.
То о чем я писал это не "произвольный" период, а месячный финансовый (отчетный) период договора не совпадающий с календарным месяцем. Это совершенно нормальная практика и не противоречит никаким законам. Вот я плачу абонку за мобильный инет (айпадец) мегафону, она выставляется мне 8 числа, потому что я купил/активировал SIM карту 8 числа, и мои предоплаченные 3 гигабайта даются мне на период с "8го по 8е".

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

я подобное скриптами реализовал, впринципе вполне удобно

_________________

Код:

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

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

В смысле вместо диапазонов трафика что вроде "пакетов" через тарифные опции скриптами активируешь?
Мне, если такое такое понадобится реализовать, придется делать это для модулей телефонии.

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

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

_________________

Код:

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

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

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

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

P.S. мне до сих пор так и не понятно на фига такие сложности....

Ну тут не поспоришь, вам априори должно быть виднее. Мне со стороны показалось что логика изменений достаточна проста: дельта в сутках везде где учитывается период, ну и костыли при перерасчетах.


Только для месячного финансового периода, да. В любом другом случае переписывать придется половину биллинга.


В первую очередь это нормальная схема работы с физиками по услугам с абонентской платой. Т.е. если я пришел купил сим карту и с меня списали 10 рублей за первый финансовый период и дали мне 100 мегабайт предоплаченного трафика, то выглядеть это будет дико (я подключался по тарифу 300 рублей абонплаты с предоплаченными 3G, но делал я это 31 января). Ну не привычно это. С корпоративщиками такая схема устроит, на этом рынке вообще все что угодно устроит, а с физиками должно быть все предельно просто и логично.
Операторы домашнего интернета вполне могут работать по схеме посуточного списания абонплаты, но это не всегда устраивает оператора, спутниковые и GSM операторы отличный пример.

Кстати, мой пример с подключением 31 января, в случае когда при подключении оплачивается первый период, в принципе не приемлем, так как списав 10 рублей, на счету останется 290, а следовательно завтра на списание абонплаты за следующий финансовый период уже денег не хватит. Т.е. или оператор должен отказаться от взнимания абонплаты авансом, хоть он и считает это выгодной схемой продаж, или он не сможет найти приемлемую схему продаж физлицам, ну я не могу придумать.

а чем не устраивает вариант подневного списания с внесением на договор суммы не менее чем за 30 дневных абонплат?

ну так 30 дней это же не месяц, или я чего то не понимаю?

а это принципиально?
какая цель? что бы клиент работал без перерыва или чтобы клиент работал ровно с 15 по 15?

Тут еще не учтен момент с диапазоном трафика, предоплаченными минутами и т.п. Можно вместо диапазонов, если речь только о трафике (inet), сгородить пакеты трафика. Но тогда и абонка раз в 30 дней не нужна, можно ее скриптом помесячно заводить. Только это выходит все услуги на скриптах и с "предоплаченными минутами", подозреваю, проблемы будут.


Это смотря для кого, для меня, сидящего за тремя мониторами с толпой терминалов и intellij, не принципиально, а для генерального директора принципиально, конечно.
Как, например, объяснить автоплатежу сбербанка, что надо платить раз в 30 дней, а не раз в месяц определенного числа?

А директор почему хочет 15-15? Он же как то это мотивирует???
Так же как автоплатеж за квартиру с разными суммами каждый месяц...
Или автоплатеж по балансу за сотовый при балансе меньше заданого...

Директор ни чем не мотивирует, он просто про себя заметит что предложение бредовое (ну как минимум с его точки зрения) и на этом обсуждение закончится. Ну не будет ни он, ни финансовые директор, ни менеджеры, ни маркетинг вникать в то почему абон плата сдвигается за год на 5-6 дней.

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

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