Смена тарифного плана / Перевод расчетного периода

[banec]

Коллеги,
столкнулись с проблемой при проведении акции. Прошу помощи!

Задача:

• - Провести акицю длительностью 3 месяца. 01.08.2014 - 01.11.2014.
  - Производить подключение новых пользователей к тарифу "Акционный 40 Мбит" в период действия акции.
  - Подключение к акционному тарифу только новых пользователей.
  - Осуществить автоматический перевод пользователей по окончанию акционного периода на тарифный план "Обычный 10 Мбит".

Вопрос

• - Кто сталкивался с подобной проблемой?
  - Как она решается?
  - Как выбрать следующий РП?
  - Какие обходные пути для корректного создания Акций (на несколько месяцев) имеются?

Задача стоит почти аналогичная. А проблема в том что НеТАП посчитал функцию включения ТП(услуг) в будущем не нужной в 5.3 и убрал.
Но заморочкой с удалением РП и т.д что-то меня не прельщает.
Моё виденье - использовать пхпурфу - которой вполне под силу перевести, подключить ТП(услугу) в определённый период времени.
Соответственно ночью выбирать дату подключения абонента если >3 месецев перевести(подключить) ТП(услугу).
Надеюсь в ближайшее время написать скрипт - если что выложу сюда.

[Dmitry P.]

У меня сборка 5.3-001. Какая у Вас?
Чем Вас не устраивает вариант проведения акций описанный мною ранее
viewtopic.php?p=65974#65974
Пункт 2.

Та ничего вручную писать не нужно. Пользователь спокойно сидит 2.5 месяца (если акция 3 месяца) на акционном тарифе с Ежемесячным РП. Затем вручную через админку выгребаете пользователей на акционном ТП и каждому меняете следующий ТП.
Соответственно по окончанию РП в месяц произойдете переключение на стандартный ТП.

Или у Вас не такая ситуация? Может Вы сможете без самописного скрипта обойтись?

[banec]

5.3.-002 up9. - по моему именно в 002 и убрали установку услуг в будущем - мысль только одна, что-то сломали в логике и решили чтоб голову не ломать просто убрать.
Основное = "в ручную"
именно это можно сделать автоматизировано через пхпурфу.
задача у меня в подключении услуги "абонплата за порт" через 3 месяца.
(её тоже можно реализовать двумя методами - есть процентная стоимость услуг - вот её можно выставить в 0% потом сделать 100%)

[Dmitry P.]

5.3.-002 up9. - по моему именно в 002 и убрали установку услуг в будущем - мысль только одна, что-то сломали в логике и решили чтоб голову не ломать просто убрать.

Значит обновляться не будем! ))

Основное = "в ручную"
именно это можно сделать автоматизировано через пхпурфу.

Что такое phpurf? Это типа API у UTM5 под php?

задача у меня в подключении услуги "абонплата за порт" через 3 месяца.
(её тоже можно реализовать двумя методами - есть процентная стоимость услуг - вот её можно выставить в 0% потом сделать 100%)

А какой второй метод?

[banec]

phpurfa viewtopic.php?t=6402&postdays=0&postorder=asc&start=990
это аналог платной от нетапа. не всё реализовано - ну и понимать нужно что делаешь.

зы это второй, первый стандартный в подключении услуги.

[uptels]

Доброе время суток.
Хотелось бы уточнить для себя некоторые детали из обсуждения.

1. Фразу "убрали установку услуг в будущем" понимать как наследование услуги подключенной к тарифу при смене его на тариф с иной периодической составляющей? Или как смену тарифа на тариф с аналогичной периодической составляющей?

2. Согласно документации, есть возможность подключать к тарифу дополнительные услуги любого формата и стоимости. Кто мешает сформировать необходимый пакет и корректно перевести абонентов через админку, используя возможность изменения тарифа следующего отчетного периода для группы? Да, текущие услуги отключатся, но новый тариф можно сформировать с необходимыми услугами в комплекте. Или я что-то недопонимаю?

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

[Dmitry P.]

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

Ни в коем случае и не решайте через БД. Это крайний метод, когда уже накосячишь )) Как у меня.
Кстати, 1 числа перевод на новый РП произошел успешно. Описанная мною методика выполнения данных манипуляций через БД корректно функционирует.

[kirush]

Пытаюсь перевести пользователя с одного расчетного(31558) периода на другой (31555), абонент один на расчетном периоде.

Код: Выделить всё

2. Получить список всех номеров лицевых счетов, с которыми будут произведены нижеописанные манипуляции 
Код:
select account_id from account_tariff_link where is_deleted=0 and discount_period_id<>ID_требуемого_РП order by account_id;

select account_id from account_tariff_link where is_deleted=0 and discount_period_id<>31558 order by account_id;
Точно здесь "<>"? Разве не должно быть "="?

При вводе по Вашей инструкции имеем вывод всех лицевых счетом кроме данного абонента с этим РП.

Если же:

Код: Выделить всё

mysql> select account_id from account_tariff_link where is_deleted=0 and discount_period_id=31558 order by account_id;
+------------+
| account_id |
+------------+
|       2726 |
+------------+

то выходит правильно. Также смотрю у Вас дальше ошибки по инструкции - исправьте...
правильные запросы в моем случае:
mysql> update account_tariff_link set discount_period_id=31555 where
mysql> update periodic_service_links set discount_period_id=31555 where discount_period_id=31558 and is_deleted=0;
У Вас в инструкции делается update в обоих случаях в таблицу account_tariff_link, понимаю, что copy/paste не тот сработал, но новичкам можно сильно навредить

[uptels]

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

[Dmitry P.]

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

Зачастую затык не только в $ на оборудование, но и во времени на эксперимент (если нет уже развернутой копии). А если перерыв сервиса до 10 минут не критичен (например в часы наименьшей нагрузки), то можно забэкапить базу, провести эксперимент, а если что восстановить.
Но тут уж решение каждого. Я не советую лезть в базу, но в моем случае других вариантов не было. Сейчас уже сформирована методика проведения акций без манипуляций с БД.
Что меня удивило, так это то, что пришлось доходить до всего самому. Я предполагал, что на форуме с этим уже сталкивались.

[kirush]

Исправления не были сделаны
Верные запросы:

Выводим все account_id с которыми будем осуществлять перевод:

Код: Выделить всё

select account_id from account_tariff_link where is_deleted=0 and discount_period_id=ID_текущего_РП order by account_id;

Останавливаем ядро. Вносим изменения:

Код: Выделить всё

update periodic_service_links set discount_period_id=ID_нового_РП  where discount_period_id=ID_старого_РП and is_deleted=0; 

Код: Выделить всё

update account_tariff_link set discount_period_id=ID_нового_РП  where discount_period_id=ID_старого_РП  and is_deleted=0; 

Запускаем ядро.

[Dmitry P.]

Исправления не были сделаны

Исправлено тут (первоначально сделал 2 одинаковых UPDATE одной таблицы. Просто я сначала делал на боевом сервере, а затем писал отчет о проделанной работе):
viewtopic.php?p=65985#65985

Сейчас инструкция по ссылке выше полностью функциональна.