BiTel

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

ну та же схема, самая простая
кроме ухода в минус есть, кстати, еще одна бяка: если поставить съем абон платы авансом за месяц или помесячный пропорциональный режим т/п то все совсем хрениво получится
пример: у абонента +100р, абонка за месяц 400р, безлимит по трафику, списываем абонку за месяц, получаем -300р, блочим абонента, статус с завтрашнего дня блочим, после пересчета у него получится +87р
а должно была получится неделя работы и нулевой баланс

хотя, конечно, для классического дебета такие абонки изврат, но тот же www.stream.ru использует пропорциональные месячные абонки проявляется это при смене тарифного плана, идет пересчет последнего списания с учетом реального кол-ва дней отработанного по старому т/п

кстати, на счет разблокировки шлюза при активном статусе договора и "положительном" балансе, решение принято ? сделаете ?

недостатков два как минимум
1) он должник хотя таковым не является
2) если выставляются фактуры, то выставляются они вероятнее всего по наработке, вы их выставите, а абонент никогда не заплатит

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

Данный пример некорректен. У него месячная абонплата, соответственно у него снимается полная абонплата за месяц, и он уходит в минус а значит работать не может, ни неделю, ни день, ни секунды (остаток на счете во внимание не принимаем). Пропорциональный месячный период вообще то предполагает, что абонплату нужно внести ПОЛНУЮ в начале отчетного периода(или неполную если клиент подключается не сначала месяца), поэтому никаких недоразумений в логике списания тут нет. Тот пример что вы привели, для этого случая подходит ежедневное снятие абонплаты.
Не усложняйте пожалуйста и без того сложные моменты, исходим из определений тарифных опций абонплат, и не смешиваем их логику.
Далее, в случае если он оплатил через неделю, и хочет чтобы ему восстановили денежные средства за непотреблённые услуги, клиент пишет заявление и ему пересчитывают абонентку задним числом с корректировкой в 1с. Если такая логика Вас не устраивает, присмотритесь к ежедневному снятию абонплат. Очевидно она вам больше подходит, во всяком случае для данного примера.

Это все IMHO

PS
Продолжая рассматривать этот пример: В конце концов если клиенту сильно надо пользоваться услугой, может позвонить и попросить понизить лимит! Либо сказать предоставьте мне услуги на 100 рублей и переведите на тариф без месячной абонплаты. Приведенный пример может решить сам клиент разным способом. Далее этот пример скорее исключение чем правило при месячном снятии абонплаты, и при предоплате.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Согласно ответу выше, с этими недостатками также не согласен.
1) Почему не является должником? По договору клиент пользуется услугами по предоплате. Значит для клиента не должно быть неожиданным его уход в минус в начале месяца. Не оплатил - стал должником. Если не хочет пользоваться, разрывает договор. И этот минус с него можно спросить, либо можно простить, это по желанию. Опять же, если клиент через какоето время начинает пользоваться услугами, пусть пишет заявление, и ему пересчитают абонентку. (По предложенной логике пересчета задним числом, наработка должна корректно пересчитываться)
2) см 1

Теперь железные положительные моменты:
1) Данная логика проста, и понятна как клиентам, так и самому провайдеру.
2) Её достаточно просто реализовать и добавить без значительных изменений в биллинге.

Вопрос к Jimson
Вам надо просто принять как данное что клиент в дебетном режиме с предоплатой уходит в минус, и это нормальное стандартное поведение. Вы его не хотите пускать в минус. Почему? Приведите железные аргументы. Меня один раз в минус вполне устраивает, и как писал уже, считаю это правильным. Мы работаем по такой схеме (предоплата/в начале месяца в минус/по заявлению клиента пересчет абонплаты, т.к. это клиента косяк). Неудобств никаких.
Да, и приведите пожалуйста, ваше окончательное решение. Почитал в кратце тему сначала, там куча размышлений сложных. Суть уловил - не пускать клиента в минус. Логику решения не осилил.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

я объясню тебе суть в двух словах, раз читать влом

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

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

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

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

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

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

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

Касаемо фактур, мы их не выставляем. А тем кому они нужны, у них система такая: Если на договоре абонплата 1000 р. то ставим ему лимит -1000, и на начало месяца он работать может, и фактура формируется на основе реально потребленных услуг за месяц.
Позже отпишусь касательно фактур ещё после того как переговорю с бухгалтером.

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


Вот это без комментариев... Если против сам автор решения, зачем тогда обсуждаем?

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

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

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

2 vdd
1) Согласен, оператор не имеет права брать деньги за не предоставленные услуги, это своеобразный технический минус который клиент видит. но какой функционал имеем такой имеем.
2)
2.1) Почти работает. Абонплата может сниматься при минусе.
2.2) Абонентка не приостанавливается. и при начислении задним числом корректно не начисляет автоматически

Давайте снова рассмотрим задачу.
Итак дано
дебетная схема оплаты услуг ЗА МЕСЯЦ.
Условие: хотим получать ПОЛНУЮ МЕСЯЧНУЮ оплату за услуги вперед.
Решения:
1)Технический минус, в размере требуемой оплаты (НЕ ДОЛГ). Соответсвенно признак минуса отключает услуги
2) Требование минимального обязательного платежа, после которого предоставляем услуги.

Если не устраивает технический минус, давайте рассмотрим обязательный минимальный платёж?
т.е. в таблицу contract добавить поле min_complusary_prepayment. Который устанавливается для каждого договора в сумму которую оператор желает получать от клиента вперед. А БГ не разрешает пользоваться услугами если нет платежей на такую сумму? Как вам?

Меня не устраивает предложение Jimson-а не изза того что оно плохое, а изза того что надо обязательно периодически запускать процессы проверялки, и т.д. Против периодических проверок. Хочу чтобы была простое условие.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

Как-то не очень текст звучит. Я вроде ничего плохого разработчикам не делал.
А костыльная - потому что для того биллинга, что есть сейчас. Все доработки - один единственный event.
Если бы модуль абонплат умел рассчитывать "виртуальное начисление", то никакого отката не надо было.

2 Akhmat я вообще не понял зачем нужен какой -то минимальный павтеж ..При чем здесь платеж вообще ? нельзя платить 10 раз по 10 рублей и набрать абонку 100 ?

у клиента вначале месяца 5 рублей . абонка 100..списываем ..становтся -95..все блокируем и не даем интернет весь месяц..так ?

Читаем внимательнее. Мы хотим получить ПОЛНУЮ предоплату с клиента за месяц. Вернемся к определению: ЕЖЕМЕСЯЧНОЕ снятие абонплаты при дебете предполагает соответсвенно полную МЕСЯЧНУЮ предоплату. Не вижу проблем никаких

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Да! Но вообщето ничего не блокируем, уже все заблокировано по идее изза минуса. Пополнит баланс, вышел в плюс, и все работает. Только метки надо бы ещё проставить, чтобы при возможном переначисление все было корректно.
Меня так устраивает.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

а расходы ваша схема с минимальным платежом учитывает ?

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

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

Да, точно, есть такой момент ещё. Решаем этот момент в пользу клиента. В таком случае клиент должен работать. Значит правильнее вот так:


Суть думаю Вы поняли. Надо чтобы на счету у клиента вначале было достаточно средств для работы в указанный месяц.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

Точнее говоря, все отличие между кредитным и дебетным режимом - это ручная и автоматическая блокировка услуг (услуг как services, а не как ipn gates). Когда в кредином режиме блокируется договор, то блокируется и шлюз, а в дебетном, с какой-то неведомой целью, блокировку шлюза оставили, а блокировку договора - нет.

А "Минимальный платеж", "рекомендованный платеж", "допустимый минус - это уже личная специфика оператора.

неа, никакой разницы подневное это списание или помесячное

23:59:59 баланс 1 копейка, на договоре безлимит, одна услуга - абонплата, одна наработка по этой услуге = 80 рублей
00:00:00 пересчиталась абонка с учетом +1 день, в результате наработка по абон плате выросла на 20 рублей
00:00:00 наработка по абон плате 100 рублей, баланс -19 рублей 99 копеек

абонент должен и если выставить акт за этот месяц то в нем будет 100 рублей, и при расчете акта никак требуемых 80 рублей не получить

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

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

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

2 Akhmat: обсуждаем что бы найти правильное решение, то что первое предположение было неверным не означает что надо забить на идею

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

элементарный пример договора с одной услугой NPAY с подневным снятием, что не ясно то ?

Пример. Вычисления из 1 копейки, наработка абонплаты = 80 р. трансформируется в -19,99 . По какой формуле?

Далее, ежедневные абонплаты лично мне не интересны особо. Один ежедневный минус, это допустимо

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

на 23:59:59 на догворе висит наработка в 80 рублей и текущий баланс 1 копейка
ручник справа

Знаю с какой стороны ручник. Все равно не понял
1 копейка и начисление ежедневной наработки в 80р, это должно быть -79,99 стать баланс. Или меня не той математике обучали? Я же попросил формулу!
В общем напиши в виде
0,01 -80р +100р = -19,99
ты так имеешь ввиду? Почему тогда у тебя все суммы наработками называются? По твоим словам понял так
0,01 - 80 - 100 = -179,99

Да... и ручник для тебя с той же стороны

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/