Добрый день, уважаемые!
Подскажите, в какой таблице регистрируется использование промо-акции с признаком once_per_customer = Y
Например, мы запускаем акцию «Скидка за регистрацию». Одно из условий: группа пользователей равно зарегистрированные. И получается, что все ранее зарегистрированные тоже получают эту скидку. А этого делать мы не планируем.
Выходит, нужно где-то проставить признаки.
Где, кто-нибудь может подсказать?
Навскидку точно не скажу, нов таблице users кажется есть поле promotions или как то так, с сериализованным массивом промо акций. Возможно там, да это и вполне логично было бы
Пс. Есть еще такое поле в каждом заказе, но находить все заказы покупателя, вытаскивать это поле, десериализовывать массивы и искать в них - по мне так слишком затратно.
Пс2. Покопался в таблицах, похоже действительно эта информация зарыта в сериализованных массивах в таблице order_data. Если так - понятно, почему много промо - боль и тормоза, и почему любая попытка влезть сюда - страшный головняк. Буду рад, если ошибаюсь.
В таблице users поля такого точно нет, я проверил 
А вот в таблице заказов есть, там просто перечислены использованные в этом заказе акции. Думаю, сгодится
То есть нужно будет тупо всем зарегистрированным пользователям добавить нужный promotion_id в прежние заказы. Эх, врукопашную придется…
Хм, интересно, кстати, а если у зарегистрированного пользователя до этого не было заказов? Выходит, он все равно скидку получит? Какой-то тут факап получается…
Хотя, может, это и логично? И ничего страшного? 
-)
параллельно в поле promotions тоже вроде надо что-то писать… )
Посмотрю в процедуре, наверное. Но думаю, что едва ли 
Зачем проверять два поля, если по promotion_id это достаточно сделать при расчете скидки?
Это не так работает.
Там проверяются данные клиента в заказе - если был заказ с такими же данными ранее, акция не применится.
Сомневаюсь я, однако. Сегодня утром сделал заказ клиент, который до этого делал заказ. С теми же данными. И акция сработала. 
$exists = db_get_field(
"SELECT ((firstname = ?s) + (lastname = ?s) + (b_city = ?s) + (b_state = ?s) + (b_country = ?s) + (b_zipcode = ?s) + (email = ?s) * 6) as r "
. " FROM ?:orders WHERE ?p promotion_ids != '' AND FIND_IN_SET(?i, promotion_ids) AND status IN (?a) HAVING r >= ?i LIMIT 1",
$udata['firstname'], $udata['lastname'], $udata['b_city'], $udata['b_state'], $udata['b_country'],
$udata['b_zipcode'], $udata['email'], $order_management_condition, $promotion_id, $statuses, PROMOTION_MIN_MATCHES
);
А дальше уже смотрите, где у вас отличия были в заказах.
Ну и как обычно, сторонние доработки легко могут сломать.
Пользователей много было зарегистрировано? Можно добавить новое условие Пользователи -> Не в списке
Не так чтобы много, несколько сотен 
Но спасибо, тоже вариант.
Как-то пару лет назад была похожая мысль, давать скидку за регистрацию. Сделать таким образом, чтобы вновь зарегистрированный пользователь получал баллы. Но все загнулось на стадии фантазии, так как оказалось, что в мультивендоре баллы не работают. 
Не плохо бы такой функционал в коробке, но чувствую предлагать его в соответствующей теме бессмысленно. Лучше уж не отвлекать разработчиков на всякие прелести и дать им возможность исправить недоделки в уже существующей функциональности. 
По вопросу не подскажу, но есть мысли, если решение не найдете