Понятно. Очевидно, что у них у всех ещё и префиксы разные.. Тогда запрос на продление срока действия купонов будет таким:
UPDATE trm_coupon_data SET date_to='2014-04-20',version=0 WHERE date_to='2014-04-06' AND status=1 AND deleted=0 LIMIT 5000;
Продлит до 20 все купоны со сроком действия 2014-04-06. Если надо продлить купоны с определённым префиксом:
UPDATE trm_coupon_data SET date_to='2014-04-20',version=0 WHERE date_to='2014-04-06' AND status=1 AND deleted=0 AND global_id=0 AND id LIKE 'xxxxx%' LIMIT 5000;
где xxxxx - пятизначный префикс номеров купона.
Выполнять в БД СГО. Запрос не отправляет данные, а только метит их на отправку (version=0), чтобы они отправились - нужно где-нибудь в WEBе тыкнуть "применить", не изменяя ничего, либо дождаться выгрузки из ТС - тогда само отреплицируется.
LIMIT 5000 - это чтобы ломанувшаяся на кассы и сервера репликация не забила каналы связи. Выполнять порциями по 5000 записей с интервалом 5-20 минут с наблюдением за show processlist в БД СГО. Выполнять до тех пор, пока в ответ на запрос не придёт "Changed: 0".
Таким образом мы продлим все купоны до 20.04.2014. В магазине, где их приём заканчивается 13.04.2014, придётся тогда настроить вторую скидку на приём суммовых купонов, дату окончания действия этой скидки настроить на 13.04.2014, настроить магазин. У второй скидки, которая будет предоставлять скидку до 20.04.2014, данный магазин исключить.
Как-то так..
По поводу решения: оно требует миграции БД СГО на MySQL 5.1.61 (как минимум), поскольку использует функционал event_scheduler.. Миграцию необходимо выполнять через перезаливку БД через текстовый дамп. Могу помочь всё это сделать, на всё про всё - одна ночь, независимо от размера БД.