BiTel

Зачем?

Зачем нужен биллинг:
1. Считет ежемесячную наработку по услугам и отдаёт её бухгалтерии
2. Принимает платежи по электронным платёжным системам и отдаёт их бухгалтерии
3. Управляет доступом клиета к услугам в режиме online

Для выполнения п.3 BGBilling ведёт текущий баланс договора параллельно с бухгалтерской системой (1С). Две одинаковые сущности в разных системах - это всегда плохо, т.к. приходится следить за их синхронизацией. Проблема с синхронизацией балансов уже поднималась и решать её предлагается с помощью закрытого периода.

Мы используем закрытый период уже более полугода, но проблемы с расхождениями всё равно возникают.
Обычно такое получается по следующей схеме:
1. Меняются настройки модулей, тарифных планов и т.п. без учёта периодов, в результате чего, если пересчитать договоры, наработка изменится
2. Открывается период для пересчета одного договора, но по ошибке пересчитываются все договоры, либо у того же договора плывёт наработка по услугам из п.1.
Примеры:
- Изменена карта зон ТСПРИ. В самой карте зон нет периодов у вхождений, при изменении нужно создавать копию карты и включать её в тариф с периодом, что неочевидно.
- Добавлен service link в модуле dialup (netflow.service.link.<id>=...) В конфиге модуля привязка подсетей к услугам указывается без периода, поэтому при пересчете старых данных может сползти баланс.
- Просто кто-то изменил тарифный план, не использовав узел "период".

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

Что?

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

Как?

Насколько я понимаю, сделать это проще, чем было сделать глобальный период, т.к. есть одна функция, задающая наработку после переобсчета - BalanceUtils.setAccount(). Соответственно, можно проверять дату заморозки наработки договора в ней. Для договора завести дополнительный атрибут, скажем, freezeContractAccountUpTo, тип date, по факту - месяц, до которого включительно запрещёно изменять наработку. Внутри setAccount, если начисление сделать нельзя из-за freezeContractAccountUpTo, то писать об этом в лог, с указанием расхождений по наработке.

Discuss?

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

Стоп, стоп, стоп. Как минимум в 5ой версии давно уже нельзя производить пересчеты ранее закрытой даты.



Здесь везде упоминаются ошибки в настройке со стороны самих пользователей\администраторов, невозможно оградить систему от внешних ошибок и человеческого фактора на все сто. Просто к подобным вещам не стоит допускать "кого-то, кто изменит тарифный план, не использовав узел "период"". Более того (это же и service link касается) опять же, пересчет "старых данных" в версии 5.0 и выше невозможен.




Во-первых, управлять всем этим безобразием станет просто ужасно - влияние человеческого фактора возрастет в N раз. Как массово устанавливать период? Допустим, через групповые операции. Затем Вы решите, что для такой-то группы мы его устанавливаем сегодня, а для такой-то - через неделю. Кто-нибудь все перепутает и сделает наоборот и т.п. Я не вижу нормальных методов управления этим безобразием. Все сведется к тому, что устанавливаться период будет также - единожды и для всех (просто будет сделано лишних 100500 запросов к базе), а для отдельных уникумов он будет переноситься для переобсчета. А теперь представим, что переобсчитать задним числом нужно не 1, а 10 договоров из одной группы. Неужели вручную всем 10 выставите период пораньше, переобсчитаете - и вернете обратно? Да я уверен, что будет такой же "массовый" откат, хоть и в пределах группы, и также можно будет вместо указания 10 договоров переобсчитать все. Профита от индивидуального ведения периода, который будет в 99.99999% случаев одинаков для всех - я не вижу.
Во-вторых, Вы заблуждаетесь в том, что наработки устанавливаются исключительно через setAccount в BalanceUtils. Это метод установки балансов исключительно после переобсчетов, а есть несколько других случаев, когда переобсчета как такового (через шедулер) нет. Дилерские платежи, например. Да мало ли где и как. При этом, опять же, фактически Вы разрешаете невозбранно менять всякие сущности задним числом. Кто-то поменял ради забавы, потом оказалось, что этот договор нужно переобсчитать и .. далее Вы знаете.

Да, но менять конфиги и тарифные планы - можно. Т.е. всё равно возникает такое подвисшее состояние, когда пересчет повлечет изменения наработки. Оно может висеть годами, прежде чем выстрелит. Закрытый период - не панацея.


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


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


Можно и так, но массово период устанавливается мной 1 раз в месяц после выставления счетов.

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

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


Дилерские платежи - это ведь не наработка? Речь идёт именно о процедуре внесения изменений в contract_account, а не об установке баланса. Вообще, если "мало ли где и как" - значит, у вас архитектурная проблема - цепочка "данные модулей" -> "наработка" -> "баланс" размыта, недостаточно абстрагирована.


А для этого уже обычный закрытый период

Пожалуй, проблема реально существует только с текстовыми конфигами, ибо там действительно невозможно сделать "срез" так, чтобы вот этот конфиг действовал с 01.01 по 31.05, а вот этот с 01.06. По поводу тарифных планов. А насколько правомочно вообще в таком случае редактирование тарифного плана? У нас есть возможность отмечать ТП как "не используемый", так пожалуйста. Если Вы грубо говоря вместо 1 руб\мб стали брать 0.8 руб\мб, то разве это тот же самый ТП? Закрываете старый, открываете новый и вуаля. Либо же внутри используете узел "период", опять же.


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


К дилеру возможно прикрепление договора. Каждый платеж становится наработкой дилера.
По поводу функции - я перепутал немного, есть конечно единая функция для работы с БД (точнее занесением и инкрементом наработки в contract_account) - это setContractAccount и addContractAccount в BalanceUtils. Это для единичных изменений. Для массовых же есть setAccount, которая активно используется калькуляторами - она просто тупо гораздо быстрее единичных обращений.

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

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

Эм, а даты конфигов разве учитываются при тарификации предыдущих месяцев? По-моему, это всего лишь дата последнего изменения конфига.

Насчет остального - знатоки берут дополнительное время...

даты конфигов скорее всего не учитываются, но их же можно прикрутить

Ох, если бы все было так просто...

А при каждом переобсчете старым месяцем туда-сюда передергивать конфиги? Можно, конечно, но опасно.

опасно, но пока что это единственная возможность сделать тот самый "срез" конфигов

Да, но это всплывёт сразу же, и только для него одного, а не во время сверки балансов.
Кроме того, в некоторых случаях нельзя пересчитать услуги только для одного договора: переобработка логов телефонии, netflow, максимальные трафики.

Проблема не в ошибке как таковой. Эта ошибка просто самая распространенная.
Мне не нравится вот это:

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

По крайней мере, в 5.0 это так.
Выглядит не особо надёжно.

Вообще, на биллинг навешано много посторонних функций: CRM, Helpdesk, выставление счетов, плагин Documents, ... . Это хорошо - для маленьких компаний проще работать в одной системе, если задачи и масштабы небольшие. Потом от этих функций более-менее легко отказаться, отключив соответствующие плагины в BGBilling и перенеся функционал во внешнюю систему. Но, выходит, один функционал перенести нельзя - это функционал учетной системы. Функционал ведения баланса клиента. Мне не нужно тащить баланс клиента с предыдущих месяцев в биллинге, мне нужен только текущий, операционный баланс для принятия решения о доступе к услугам. Остальное - дело 1С, от биллинга требуется только раз в месяц выгружать наработку, платежи mps и принимать из 1С остальные платежи.

Родилось другое предложение: сделать функционал автоматического трансфера баланса по месяцам опциональным - чтобы можно было глобально выключить эту функцию. Тогда при пересчете конкретного месяца изменяется contract_balance только для него. Если нужно протащить изменения до текущего месяца - нажимаем специальную кнопку для этого. Для протаскивания баланса при переходе месяца делаем задачу планировщика, которую настраиваем на 1 число каждого месяца, после выполнения пересчетов. Затем, после выгрузки данных в 1С, выставления счетов и закрытия бухгалтерского периода, явно устанавливаем входящий баланс текущего месяца, взятый из 1С как внешней учетной системы. Это делают уже свои внутренние скрипты.
Единственная возникающая проблема - это возможное расхождение между исходящим остатком одного месяца и входящим - другого. Но это нормально при такой реализации, т.к. мы сознательно отказались от функций учетной системы - биллингу важно правильно посчитать и отдать только текущую наработку. В крайнем случае, можно сделать отчет по таким расхождениям и искать косяки уже по нему. Также логично отключить в ЛК пункт меню "просмотр баланса" и вместо него интегрировать этот функционал из внешней учетной системы.
При такой реализации мы будем начинать месяц с чистого листа. Внутри компании обсудили схему с бухгалтерией и IT-отделом, всем нравится.

discuss?

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

может как вариант функции переобсчета договора вынести в сам договор, а в модуле оставить только функции глобального перерасчета.
и там же добавить блок выбора периода пересчёта который будет участвовать в перерасчете (без учета ГЛОБАЛЬНОЙ даты закрытого периода)

А что если опционально ввести следующее:
1) По прошлым месяцам переобсчет не будет сразу изменять баланс. Вместо этого, в случае, если в результате переобсчета наработка по услуге составила не X руб, а X + d рублей, то вместо изменения таблицы contract_balance мы кладем это изменение в какую-нибудь стороннюю помесячную таблицу. Соответственно, изменения в балансе не произойдут.
2) Далее какая-нибудь задача раз в N ед. времени просматривает эту таблицу и по найденным расхождениям рапортует на емайл\кидает события\делает что-нибудь еще.
3) ???
4) PROFIT!!

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

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

Т.е. при начислении по договору:
1. Пересчитываем, заносим новую наработку в промежуточную таблицу.
2. Руками применяем промежуточную таблицу, если это согласовано с бухгалтерией, либо вносим разницу корректировкой в текущем месяце.
?

Тут нужно подумать, как сделать массовое начисление, т.к. в начале месяца перед выставлением счетов мы окончательно пересчитываем предыдущий - тогда начисление нужно выполнять.
Можно так же - в два шага.

Разнесение действий глобального начисления и начисления по договору - тоже не лишняя фича. На вики уже было про это.

А не кажется ли Вам, что это более усложняет процесс обсчета договора.
Один раз БГ посчитал наработку. Эту наработку кто-как передал в бухгалтерию. Бухгалтера учли у себя эту сумму, у этого контрагента.
У бухгалтеров учетная система. Баланс договора по сути ведут они.
Далее выставили клиенту счет на оплату.
После БГ у учетной системы должен взять баланс договора для дальнейшей работы. И уже переданный от учетной системы баланс использовать для логики включения/отключения.
То что сейчас предлагают разработчики это оставить биллингу функцию учетной системы, которая ему в общем и не нужна.
По мне лучшим решением было то, что позволит нам самостоятельно устанавливать баланс на начало месяца и это бы не отражалось автоматом на балансах следующих месяцев.

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

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

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

UPD: "старые" месяцы можно определять как раз датой закрытого периода, и тогда все встает на свои места.

Проверка будет ручная. Соответственно сотруднику понадобится кнопка типа "принять изменения".

Речь идет только о табличке с балансами или и же о табличке с балансами и табличке с наработкой ?


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

На первый взгляд схема с отдельной таблицей перерасчетов выглядит более сложной, чем отключение переноса баланса.
+1

Мм, не вижу проблемы. Даже с отключенным автоматическим переносом баланса можно вести учёт, просто после пересчетов задним числом выполнять все переносы вручную (сделать отдельную кнопку в разделе баланс: "пересчитать баланс договора с даты ...", которая делает BalanceUtils.transitBalance(cid, date),+проверка даты на закрытый период).
А штатный массовый перенос баланса на границе месяца будет выполняться задачей планировщика.

Я так понял, что focus предлагает вообще не начислять наработку в биллинге автоматически.

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

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


А как так может произойти, что вдруг исходящий остаток одного месяца станет неравен входящему другого?
Как объяснять это пользователю, который видит это в личном кабинете? Хорошо, уберете Вы личный кабинет и подставите туда информацию из внешнего источника - тогда Вам позвонит юзер и спросит: "а вот у меня на счету 100 рублей написано, а в интернет не пускает", просто потому, что Вашей системе забыли сказать, что в биллинге произошло списание абонплаты.
Даже если случилось что-то вне нашей системы, что повлияло на баланс на договоре, почему не уведомить об этом биллинг? Просто напросто нарушается целостность системы - вот и все, я даже не знаю, как еще объяснить. Плюс к тому, опять же некий нерадивый сотрудник будет тыкать во все кнопки подряд, в том числе и на ту, что ответственна за перенос баланса...

Проблему я вижу такую: есть случаи, когда задним числом происходят перерасчеты, и оказывается, что некое лицо N должно не X рублей, а Y рублей. Это на данный момент приводит к перерасчету наработки за некий месяц, что приводит к перерасчету всех балансов, начиная с данного месяца, и как следствие все это безобразие перестает согласоваться с бухгалтерией.

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

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

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

Значит, нужно будет вернуть пересчет "обратно"

А если серьезно: сходимость баланса в биллинге с бухгалтерскими отчетами гораздо важнее, чем несовпадение детализации и баланса.

Как вам такой вариант - при расхождении наработки до и после переобсчета задним числом дельта кладется в дату переобсчета, то есть в текущий месяц.

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

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