BiTel

Добрый день разработчики! Это у меня глюк, или так задуманно. Раньше, при смене тарифа, до его вступления в силу, была кнопка отменить, сейчас ее нет.

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

Жаль, очень не удобно. Если случайно не тот договор выбрал, отменить уже нельзя. Нужно бежать в офис провайдера. ((

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

А "дополнительными действиями" (http://www.bgbilling.ru/v4.6/doc/ch01s18s12.html) вопрос отмены не удается решить?

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

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

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

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

Я в TODO занёс, попробуем обдумать возможность отмены.

Видимо TODO очень длинный

У меня кажется есть простое решение этой проблемы:
нужно просто при формировании xml добавлять параметр group не только для активных тарифов, но и для будущих уже запланированных смен. Тогда напротив них появится форма для смены тарифа. Отменить смену будет нельзя, но можно будет перетереть будущую смену тарифа.

Проведем эксперимент (с)
v 4.6

Пусть есть группа тарифов с еженедельной сменой: Тариф1, Тариф2, Тариф3.
В текущий момент стоит Тариф1 с открытым периодом действия

1) Заходим в web-статистику, открываем страницу смены тарифов - видим форму выбора тарифов для смены. Даты: 01.02.10, 08.02.10 и т.д.
2) Заходим в клиент биллинга, открываем тот же договор, закрываем Тариф1 датой 07.02.10, добавляем Тариф2 датой 08.02.10 и открытой второй датой. Т.е. делаем всё так, как если бы мы сейчас сменили тариф на Тариф2 из web-статистики с 08.02.10.
3) В веб статистике не обновляя страницы меняем тариф на Тариф3 с даты 08.02.10.
4) Работает!

При этом сменить тариф таким образом можно только с даты не раньше последнего открытого тарифа из этой группы.

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


Можете это добавить?

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

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

Cromeshnic, Ваш способ немного нелогичный для юзера, мне кажется, нет? Кроме того, как быть, если на смены тарифа повешены действия какие-нибудь?

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

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


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

1) Разумеется, что уже начавший действовать тариф не нужно разрешать отменять. Это явно лишнее.
2) Но ведь событие срабатывает в момент переключения тарифа, в том числе и будущим числом, а не в момент собственно перевода с тарифа на тариф. Или я не так что-то понял?

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

это похоже я что-то не так понял ...
здесь есть всего 2 события: "Запрос дат с которых разрешена смена тарифа через Web" и "Смена тарифа по заданию пользователя", а в клиенте еще есть: "Изменение тарифа договора" и "Удаление тарифа договора"
говоря о смене юзером тарифа можно сказать что есть есть 2 действия (не события):
1. заказ юзером тарифа через веб
2. смена тарифа биллингом для того чтобы заказанный в п.1 тариф начал действовать
какое именно событие биллинга и где срабатывает? куда Вы думаете повесить новое?

Здесь вообще совершенно никакого события не происходит, даже внутреннего! В том то и дело...
Раньше были задания на смену, то есть при заказе смены добавлялось задание, а при наступлении времени смены оно выполнялось.
Сейчас же сразу добавляется строка "действие тарифа с ...<дата>" и в дальнейшем ничего вообще не происходит, при переобсчёте после наступления новой даты возьмётся тариф согласно соответствующему текущему временному промежутку.

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

Опять же главный вопрос: что делать с теми действиями, которые мы сделали в скрипте на событии при переходе с тарифа на тариф. Вот мы сменили тариф, скрипт обработался. А потом, при смене тарифа который ещё не начинал действовать что делать?
1) игнорировать и не генерировать событие? неправильно - скрипт обработался для одного тарифа, а в итоге вскоре начнёт действовать совсем другой.
2) генерировать событие смены тарифа? но ведь оно не начало ещё действовать? И если мы натыкаем туда-сюда тарифы, и остановимся пусть даже на том же самом, то что в скриптах делать будем? Навыполняем действия, как узнать где была на самом деле не новая смена тарифа, а отмена?

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

Сейчас сделал костыль на этот счёт, не придумал как оформить события. И разрешать ли именно ПЕРЕТИРАТЬ тарифы,а не отменять (переводя обратно на предварительно запомненный предыдущий тариф).

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

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

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

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

Планируется, что функционал будет доступен в 5.1.

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

А релиз 5.1 когда планируется примерно?

В течение месяца предположительно...

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

Сделал так:
1) при смене тарифа сохраняется информация с какого тарифадоговора перешло (id строки из contract_tariff)
2) на будущих тарифах есть кнопка отмены перехода на тариф (и указано для удобства на какой тариф откатится)
3) при нажатии на неё (после проверок на хаки) генерируется синхронное событие отмены перехода на тариф (новое событие)
4) там можно обработать что угодно имея ContractTariff "до" и "после".
5) там же можно установить processed (аналогично смене тарифа), чтобы штатно не обрабатывалось
6) штатная обработка: удаляем второй тариф и обновляем предыдущий продляя дату до бесконечности
7) генерируются сразу два асинхронных (уже существующих) события ContractTariffUpdateEvent и ContractTariffDeleteEvent для соответствующих потревоженных тарифдоговоров. на всякий случай. вот такая хитрость.

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