Исторически так сложилось, что больше половины пользователей имеют персональный расчетный период. В итоге их уже накопилась туева хуча.
Существуют ли средства корректной смены текущего расчетного периода на какой-то другой уже существующий?
Хочется узнать о возможности реализации следующих схема:
1. Приведение всех пользователей к единому расчетному периоду с 1 числа месяца длиной в месяц;
2. Объединение всех пользователей имеющих одинаковую дату начала и окончания расчетного периода в один общий (практически все начинаются такого-то числа в 00.00 и имеют длительность в месяц),получив в итоге 31 расчетный период длительностью в месяц с началом в 00.00 каждого числа.
В базе нашел вот что:
в таблице discount_periods есть поле next_discount_period_id. У работающих расчетных периодов оно имеет значение 0. У закончившихся - ID расчетного периода, который стал "преемственным".
Можно ли использовать это поле для установления следующего расчетного периода в работающем расчетном периоде и реализации нужных мне "финтов"?
Смена расчетного периода
Re: Смена расчетного периода
можно проще помоему, на всякий случай в начале месяца стопай биллинг и меняй неправильные периоодны на номер правильного, но только чтобы сроки начала и завершения а так же длина совпадала.Lelik85 писал(а):Исторически так сложилось, что больше половины пользователей имеют персональный расчетный период. В итоге их уже накопилась туева хуча.
Существуют ли средства корректной смены текущего расчетного периода на какой-то другой уже существующий?
Хочется узнать о возможности реализации следующих схема:
1. Приведение всех пользователей к единому расчетному периоду с 1 числа месяца длиной в месяц;
2. Объединение всех пользователей имеющих одинаковую дату начала и окончания расчетного периода в один общий (практически все начинаются такого-то числа в 00.00 и имеют длительность в месяц),получив в итоге 31 расчетный период длительностью в месяц с началом в 00.00 каждого числа.
В базе нашел вот что:
в таблице discount_periods есть поле next_discount_period_id. У работающих расчетных периодов оно имеет значение 0. У закончившихся - ID расчетного периода, который стал "преемственным".
Можно ли использовать это поле для установления следующего расчетного периода в работающем расчетном периоде и реализации нужных мне "финтов"?
Поле discount_period_id я нашел в следующих таблицах:
- accounts
- account_tariff_link
- discount_transactions_all
- discount_transactions_iptraffic_all
- periodic_service_links
Подменять его нужно во всех перечисленых таблицах? Или же достаточто будет поменять в accounts, а по наступлении следующего расчетного периода и все связки перенесутся на правильный?
- accounts
- account_tariff_link
- discount_transactions_all
- discount_transactions_iptraffic_all
- periodic_service_links
Подменять его нужно во всех перечисленых таблицах? Или же достаточто будет поменять в accounts, а по наступлении следующего расчетного периода и все связки перенесутся на правильный?
Попробуй создать период длинной в месяц и в discount_periods повесить его следующим на все существующие переоды привязанные к работающим тарифам.
Залей всё это на тестовую машину и поменяй дату на машине на дату самого длинного из твоих расчетных периодов.
По идее все твои тарифы должны съехать на правельный период и подключенные на них услуги то же.
Залей всё это на тестовую машину и поменяй дату на машине на дату самого длинного из твоих расчетных периодов.
По идее все твои тарифы должны съехать на правельный период и подключенные на них услуги то же.
Lelik85 писал(а):Поле discount_period_id я нашел в следующих таблицах:
- accounts
- account_tariff_link
- discount_transactions_all
- discount_transactions_iptraffic_all
- periodic_service_links
- accounts - тут не надо он не используется
- account_tariff_link - тут надо
- discount_transactions_all - тут можно потом, главное успеть пока новый период не кончился, иначе с отчетами и счетами фигня получится
- discount_transactions_iptraffic_all - тут можно потом, главное успеть пока новый период не кончился, иначе с отчетами и счетами фигня получится
- periodic_service_links - тут надо
на тестовой машинке проверь только сначала.
Получилась похожая ситуация.
УТМ при переводе абонентов на новый расчетный период "грохнулся" и перезапустился.
В итоге получилось 2 расчетных периода. 1-й правильный (1934), 2-й - неправильный (он начался в 1:50) (1935).
На тестовой машине при остановленном ядре было сделано:
После запуска ядра всё заработало и расчетный период остался нужный (1934).
Решили пойти дальше. Перевели часы на 31 марта 23:55 и решили подождать, что будет. УТМ перевел все на новый расчетный период (1936), при этом все нормально посчиталось.
И вот тут одно НО! После перезапуска ядра (просто так, решил попробовать), УТМ вообще не стартует, грузит проц на 100% и всё!
Чего делать?
В хотлайне был задан вопрос "Как правильно перевести абонентов с одного расчетного периода на другой" - он не отвечает уже больше суток.
УТМ при переводе абонентов на новый расчетный период "грохнулся" и перезапустился.
В итоге получилось 2 расчетных периода. 1-й правильный (1934), 2-й - неправильный (он начался в 1:50) (1935).
На тестовой машине при остановленном ядре было сделано:
Код: Выделить всё
UPDATE account_tariff_link SET discount_period_id=1934 WHERE discount_period_id=1935;
UPDATE periodic_service_links SET discount_period_id=1934 WHERE discount_period_id=1935;
UPDATE discount_transactions_all SET discount_period_id=1934 WHERE discount_period_id=1935;
UPDATE discount_transactions_iptraffic_all SET discount_period_id=1934 WHERE discount_period_id=1935;Решили пойти дальше. Перевели часы на 31 марта 23:55 и решили подождать, что будет. УТМ перевел все на новый расчетный период (1936), при этом все нормально посчиталось.
И вот тут одно НО! После перезапуска ядра (просто так, решил попробовать), УТМ вообще не стартует, грузит проц на 100% и всё!
Чего делать?
В хотлайне был задан вопрос "Как правильно перевести абонентов с одного расчетного периода на другой" - он не отвечает уже больше суток.
Это моя тема =)Voronok писал(а):viewtopic.php?p=54963#54963
MaxDM писал(а):Получилась похожая ситуация.
УТМ при переводе абонентов на новый расчетный период "грохнулся" и перезапустился.
В итоге получилось 2 расчетных периода. 1-й правильный (1934), 2-й - неправильный (он начался в 1:50) (1935).
На тестовой машине при остановленном ядре было сделано:После запуска ядра всё заработало и расчетный период остался нужный (1934).Код: Выделить всё
UPDATE account_tariff_link SET discount_period_id=1934 WHERE discount_period_id=1935; UPDATE periodic_service_links SET discount_period_id=1934 WHERE discount_period_id=1935; UPDATE discount_transactions_all SET discount_period_id=1934 WHERE discount_period_id=1935; UPDATE discount_transactions_iptraffic_all SET discount_period_id=1934 WHERE discount_period_id=1935;
Решили пойти дальше. Перевели часы на 31 марта 23:55 и решили подождать, что будет. УТМ перевел все на новый расчетный период (1936), при этом все нормально посчиталось.
И вот тут одно НО! После перезапуска ядра (просто так, решил попробовать), УТМ вообще не стартует, грузит проц на 100% и всё!
Чего делать?
В хотлайне был задан вопрос "Как правильно перевести абонентов с одного расчетного периода на другой" - он не отвечает уже больше суток.
В итоге у кого-нибудь получилось?Pei0t писал(а):Ну что, кто-то менял массово РП?