Немедленная смена тар. плана

[maxxxx]

а в чем заключается баг?

[banec]

До выхода 007 даже не думайте, там в логике блокировок биллинга баг, скрипт применять нельзя.

007 когда? будет, а то собрался с 004 обновлятся

[agach]

чо за баг с блокировками ?
у меня после обновления с 4 до 6 сборки перестали сгорать платежи
карточные, хотя там срок - 30 дней указан.
пришлось сторонний скрипт писать, чтоб проверять и "сжигать" платежи. может быть у меня проявление того же бага ?

[Magnum72]

чо за баг с блокировками ?
у меня после обновления с 4 до 6 сборки перестали сгорать платежи
карточные, хотя там срок - 30 дней указан.
пришлось сторонний скрипт писать, чтоб проверять и "сжигать" платежи. может быть у меня проявление того же бага ?

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

>> 1) создаем юзера testtest (В моем случаем получился id аккаунта 37956)
>> 2) Добавляем к нему периодическую услугу с равномерным списанием
>>    стоимостью 0 (у меня в биллинге id услуги 332)
>>    В связке выставляем текущий расчетный период, дата начала текущая,
>>    остальное не трогаем.
>> 3) Смотрим ID связки она равна в моем случае 200817
>> 4) Делаем выборку из базы:
>>      SELECT `unabon_period` , `unprepay_period` , `start_block_unabon` ,
>> `start_block_unprepay`
>>      FROM `periodic_service_links`
>>      WHERE `id` =200817
>> 5) Получаем:
>>    unabon_period =0
>>    unprepay_period =0
>>    start_block_unabon =0
>>    start_block_unprepay =0
>> 6) Ставим админскую блокировку (Да,да)
>> 7) Повторяем предыдущий запрос к базе и получаем:
>>    unabon_period =0
>>    unprepay_period =0
>>    start_block_unabon =1225266599
>>    start_block_unprepay =1225266599
>> 8) Ставим пользователю кредит размером в -1000 рублей
>> 9) Повторяем предыдущий запрос к базе и получаем:
>>    unabon_period =119
>>    unprepay_period =119
>>    start_block_unabon =0
>>    start_block_unprepay =0
>> 10)Ставим пользователю кредит размером в 0 рублей
>> 11)Повторяем предыдущий запрос к базе и получаем:
>>    unabon_period =2469234
>>    unprepay_period =119
>>    start_block_unabon =1225266834
>>    start_block_unprepay =1225266834
>> 12)Все собственно уже понятно но для чистоты эксперимента снимаем
>>    админскую блокировку
>> 13)Повторяем предыдущий запрос к базе и получаем:
>>    unabon_period =2469314
>>    unprepay_period =199
>>    start_block_unabon =0
>>    start_block_unprepay =0
>> В итоге 2469314 секунды это 28,58 дня, поэтому биллинг считает что он
>> уже списал достаточно по данной сервичной связки и больше списывать
>> не желает.


Подготовил SQL запрос по данной проблеме, проверьте пожалуйста на
> правильность:
> 
> UPDATE service_links as sl, periodic_service_links as psl SET
> psl.unabon_period = (
>    SELECT SUM(bi.expire_date - IF(bi.start_date >
> UNIX_TIMESTAMP('2008-10-01'), bi.start_date, UNIX_TIMESTAMP('2008-10-01')))
>    FROM blocks_info as bi
>    WHERE bi.account_id = sl.account_id
>    AND bi.is_deleted = '1'
>    AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2008-10-01') AND
> UNIX_TIMESTAMP())
>    AND bi.unabon = '1'
>    GROUP BY bi.account_id
> )
> WHERE sl.id = psl.id
> AND psl.is_deleted = '0'
> AND sl.is_deleted = '0'
> AND psl.unabon_period > (
>    SELECT SUM(bi.expire_date - IF(bi.start_date >
> UNIX_TIMESTAMP('2008-10-01'), bi.start_date, UNIX_TIMESTAMP('2008-10-01')))
>    FROM blocks_info as bi
>    WHERE bi.account_id = sl.account_id
>    AND bi.is_deleted = '1'
>    AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2008-10-01') AND
> UNIX_TIMESTAMP())
>    AND bi.unabon = '1'
>    GROUP BY bi.account_id
> )

[Pulse]

в changelog описание устранения такой проблемы не нашлось... либо забыли, либо забили уважаемый Magnum72, поделитесь скриптиком?

[Magnum72]

в changelog описание устранения такой проблемы не нашлось... либо забыли, либо забили уважаемый Magnum72, поделитесь скриптиком?

Чем SQL не устраивает приведенный?

Это для посмотреть и поржать: (в датах надо указать начало текущего месяца)

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

SELECT sl.account_id, psl.unabon_period, (
   SELECT SUM(bi.expire_date - IF(bi.start_date > UNIX_TIMESTAMP('2009-04-01'), bi.start_date, UNIX_TIMESTAMP('2009-04-01')))
   FROM blocks_info as bi
   WHERE bi.account_id = sl.account_id
   AND bi.is_deleted = '1'
   AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2009-04-01') AND UNIX_TIMESTAMP())
   AND bi.unabon = '1'
   GROUP BY bi.account_id
) as 'r_unabon_period'
FROM service_links as sl, periodic_service_links as psl
WHERE sl.id = psl.id
AND psl.is_deleted = '0'
AND sl.is_deleted = '0'
AND psl.unabon_period > (
   SELECT SUM(bi.expire_date - IF(bi.start_date > UNIX_TIMESTAMP('2009-04-01'), bi.start_date, UNIX_TIMESTAMP('2009-04-01')))
   FROM blocks_info as bi
   WHERE bi.account_id = sl.account_id
   AND bi.is_deleted = '1'
   AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2009-04-01') AND UNIX_TIMESTAMP())
   AND bi.unabon = '1'
   GROUP BY bi.account_id
)

Этот для поправить и поплакать: (в датах надо указать начало текущего месяца)

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

UPDATE service_links as sl, periodic_service_links as psl SET
psl.unabon_period = (
   SELECT SUM(bi.expire_date - IF(bi.start_date > UNIX_TIMESTAMP('2009-04-01'), bi.start_date, UNIX_TIMESTAMP('2009-04-01')))
   FROM blocks_info as bi
   WHERE bi.account_id = sl.account_id
   AND bi.is_deleted = '1'
   AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2009-04-01') AND UNIX_TIMESTAMP())
   AND bi.unabon = '1'
   GROUP BY bi.account_id
)
WHERE sl.id = psl.id
AND psl.is_deleted = '0'
AND sl.is_deleted = '0'
AND psl.unabon_period > (
   SELECT SUM(bi.expire_date - IF(bi.start_date > UNIX_TIMESTAMP('2009-04-01'), bi.start_date, UNIX_TIMESTAMP('2009-04-01')))
   FROM blocks_info as bi
   WHERE bi.account_id = sl.account_id
   AND bi.is_deleted = '1'
   AND (bi.expire_date BETWEEN UNIX_TIMESTAMP('2009-04-01') AND UNIX_TIMESTAMP())
   AND bi.unabon = '1'
   GROUP BY bi.account_id)

[Pulse]

я про тот скриптик, который под urfa и переводит моментально на другой тариф... я тут сам начал писать в принципе... но если не жалко