2012-06-07 3 views
4

По какой-то причине идентификаторы заказа (increment_id on sales_flat_order table) не увеличиваются впоследствии на моем Magento 1.6.1. Вот как это выглядит после того, как количество живых заказов:Приращение приращения орфографии magento

increment_id created_at   updated_at 
100000001  2011-12-14 12:35:24 2011-12-14 12:35:25 
100000002  2011-12-14 13:02:39 2011-12-14 13:02:39 
100000003  2011-12-14 13:04:18 2011-12-14 13:04:18 
100000004  2012-02-01 16:54:58 2012-02-01 16:54:58 
100000005  2012-03-14 12:22:35 2012-03-14 12:22:35 
100000006  2012-03-20 13:10:48 2012-03-20 13:10:48 
100000011  2012-03-29 20:58:48 2012-03-29 20:58:48 
100000012  2012-03-29 21:06:43 2012-03-29 21:06:43 
100000013  2012-03-30 10:48:20 2012-03-30 10:48:21 
100000014  2012-03-30 13:05:40 2012-03-30 13:05:41 
100000015  2012-04-03 15:51:01 2012-04-03 15:51:02 
100000016  2012-04-19 15:00:49 2012-04-19 15:00:50 
100000017  2012-05-09 12:09:21 2012-05-09 12:09:22 
100000019  2012-05-24 05:35:35 2012-05-24 05:35:36 
100000020  2012-05-24 05:41:11 2012-05-24 05:41:12 
100000008  2012-05-24 05:48:52 2012-05-24 05:48:53 

Мой вопрос, почему прыгающий Magento приращения иногда? И что еще хуже, в моем примере порядок с шагом 100000008 идет после 100000020. Кто-нибудь знает, почему это происходит, и есть ли способ его исправить?

+0

Могут ли они быть отменены заказы? Заказы, которые находятся в корзине покупок, но не приносят успеха? Что-то вроде того? –

+0

Вы потянете эти цифры непосредственно из БД, посмотрите в sales_flat_order, я предполагаю, что они все там. –

ответ

19

Это нормальное явление, хотя, по-видимому, смущающее.

Когда Magento входит в процесс проверки, он «резервирует» increment_id и помещает его в объект quote (cart). Вы можете увидеть код, который получает приращение идентификатора по адресу:

Mage_Eav_Model_Entity_Type::fetchNewIncrementId() 

последний использовавшийся идентификатор для каждого магазина хранится в eav_entity_store. Если клиент заканчивает свою корзину (т. Е. Объект цитаты) до завершения процесса оформления заказа, зарезервированное значение increment_id никогда не будет отображаться в заказе. Вы можете видеть этот эффект иногда в порядковых номерах, когда они входят в загруженный магазин. Иногда в заказе дня приходит действительно старый идентификатор заказа от клиента, который проверяет старую корзину.

Такое поведение существует, чтобы позволить Magento отправлять платежные шлюзы на конечный идентификатор заказа (increment_id) до завершения заказа, позволяя шлюзу связать идентификатор заказа с заказом. Если клиент отказывается от процесса оплаты в шлюзе, идентификатор заказа мертв (или, вернее, все еще привязан к цитате).

Вы можете увидеть, как это происходит в модуле PayPal выразить по адресу:

Mage_Paypal_Model_Express_Checkout::start() 

который называет

Mage_Sales_Model_Quote::reserveOrderId() 

Если вы хотите, чтобы найти свой «отсутствующий» increment_ids, посмотрите в sales_flat_quote под поле reserved_order_id. Вы должны увидеть, что они прикреплены к объектам без конвертации (телеги).

Такое поведение может создавать проблемы с некоторыми платежными шлюзами; Монерис приходит на ум. Когда вы отправляете гостевую платежную систему Moneris одинаковый идентификатор заказа дважды, он зажимает и создает критическое состояние ошибки для клиента. Это условие возникает, когда клиент посещает размещенную страницу оплаты, возвращается и повторно посещает страницу. Следовательно, в некоторых случаях необходимо повторно генерировать идентификатор заказа, связанный с объектом кавычек, программно.

+0

Если вы хотите найти «недостающие» предметы (возможно, если вам нужно восстановить неудачную продажу), выполните поиск в sales_flat_quote_items таблицу для объекта entity_id, расположенную в таблице sales_flat_quote по инструкциям Roscius. – CarComp

1

Я столкнулся с той же проблемой, но это было только тогда, когда на сервер попал огромный объем нагрузки. Эта проблема возникает из-за того, что db переходит в состояние блокировки при преобразовании котировки в порядок. При дальнейшей проверке я узнал, что проблема заключалась в том, что она пыталась записать в таблицу sales_flat_order_grid в транзакции сразу после вставки в таблицу sales_flat_order. При одновременных запросах он вызывал блокирующие столкновения. Реальное решение состоит в том, чтобы переместить материал из sales_flat_order_grid из транзакции.

The link helped me understand the issue

Патч решен вопрос для меня.

Вы должны удалить функцию _afterSave из Mage_Sales_Model_Abstract и добавить

public function afterCommitCallback(){ 
    if (!$this->getForceUpdateGridRecords()) { 
     $this->_getResource()->updateGridRecords($this->getId()); 
    } 
    parent::afterCommitCallback(); 
} 

Позвольте мне знать, если он решает эту проблему для вас.