BiTel

Как-то так в набросках это выглядит.

_________________
I'm clever. I've got a computer.

короче, доступно в следующем билде 5.1 и 5.2

_________________
I'm clever. I've got a computer.

Я вот что подумал. Предположим, клиент устанавливает себе приостановление с 1.08 по 10.08. Но 25.07 он закрывается механизмом дебетовых абонплат и его запланированное приостановление теряется.
Мы хотим брать деньги за приостановление в виде расходов и/или абонплаты, поэтому нам критично не терять эту информацию. Вообще, уже давно поднимался вопрос о перетирании будущих статусов в биллинге. Однозначно нужен какой-то объект - запланированный статус, который нельзя было бы просто перетереть.

То есть надо, чтобы не перетиралось? И как это в описанном случае будет выглядеть? Что должно стать со статусом 1.08 ? Какой начать действовать должен?

_________________
I'm clever. I've got a computer.

Видимо нужен механизм приоритетов при определении статуса в будущем времени.

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

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

Реализовал свой вебэкшен с блекджеком и шлюхами:
http://wiki.bgbilling.ru/index.php/WebA ... tomSuspend

Работает только в 5.0!
В 4.6 возможно тоже, в 5.1 - точно нет.



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

В этом экшене также не учитываются перетирания статусов итд. Это же переписанный наш код с некими конкретными прописанными действиями вместо скриптов?

_________________
I'm clever. I've got a computer.

Да. В вики так и указано:

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

Так суть была в том, что плохо давать менять статус 1 августа, а не в том, что до 1 августа может перетереться? Ну так это можно сделать скриптом запросто - вернуть просто список двух дат -- дату "сегодня" и дату "завтра" в событии "запрос дат на смену статуса", юзеру дастся на выбор две даты. 4 строчки кода скрипта. И всё.

_________________
I'm clever. I've got a computer.

Да.
Но мне ещё нужна куча мелочей:
- обязательно указывать дату, до которой приостанавливаем. Нельзя приостанавливать с открытым периодом.
- занесение/удаление расхода
- проверка условий по времени приостановления
- более "красивый" список статусов

И всё это в 5.0 и сегодня. Решил, что быстрее сделать самому.


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

Ок, посмотрю попозже код подробнее. А если после приостановки до конца лета юзер придёт и захочет активировать досрочно? Как будет списано? 20 рублей списывается или как?

_________________
I'm clever. I've got a computer.

Да, у нас так и заявлено изначально. Расход 20р. вносится датой начала приостановления. При активации просто удаляются все расходы такого типа, внесенные датой >=date1 активации.

Поправил код:

Заменил на:

Добавил +1, т.к. daysDelta

вот тут :
viewtopic.php?f=16&t=3927
недавно тоже обсуждали статусы . Пока вроде сошлись на том , чтобы сделать еще один режим когда , статус приостановлен остаётся, а остальные заменяются или перетираются