magento订单ID增量跳跃 [英] magento order id increment jumps

问题描述

由于某些原因，订单ID(sales_flat_order表上的increment_id)随后在我的Magento 1.6.1上没有递增.这是在下达大量实时订单后的样子:

For some reason order ID's (increment_id on sales_flat_order table) are not incrementing subsequently on my Magento 1.6.1. This is how it looks after a number of live orders placed:

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之后.有人知道为什么会这样吗，是否有办法解决?

My question is why is Magento jumping increments sometimes? And worse yet, in my example order with increment 100000008 goes after 100000020. Does someone know why this is happening and if there's a way to fix it?

推荐答案

这是正常现象，尽管可以理解令人不安.

This is normal, albeit understandably disconcerting.

当Magento进入结帐过程时，它将保留"一个增量ID，并将其放置在报价(购物车)对象上.您可以在以下位置查看获得增量ID的代码:

When Magento enters the checkout process it 'reserves' an increment_id and places it on the quote (cart) object. You can see the code that gets an increment id at:

Mage_Eav_Model_Entity_Type::fetchNewIncrementId()

每个商店的上次使用ID存储在eav_entity_store中.如果客户在完成结帐流程之前放弃了购物车(即报价对象)，则保留的增量ID将永远不会显示在订单上.您有时会在忙碌的商店中看到订单号时看到这种效果-有时候，一天的订单中会出现一个真正旧的订单ID，该订单来自正在检查旧购物车的客户.

The last used ID for each store is stored in eav_entity_store. If a customer abandons their cart (ie the quote object) before completing the checkout process, the reserved increment_id will never show up on an order. You can see this effect sometimes in the order numbers as they come in on a busy store - occassionally a really old order id comes through in the day's orders from a customer that is checking out an old cart.

存在此行为是为了允许Magento在完成订单之前将最终的订单ID(increment_id)发送给支付网关，从而允许网关将订单ID与订单相关联.如果客户放弃网关中的付款流程，则订单ID无效(或更准确地说，仍附加在报价上).

This behaviour exists to allow Magento to send payment gateways the final order id (increment_id), before the order is completed allowing the gateway to associate the order id with the order. If the customer abandons the payment process in the gateway, the order id is dead (or more correctly still attached to the quote).

您可以在PayPal Express模块​​中看到以下情况:

You can see this happening in the PayPal express module at:

Mage_Paypal_Model_Express_Checkout::start()

哪个调用

Mage_Sales_Model_Quote::reserveOrderId()

如果要查找缺失的" increment_id，请在reserved_order_id字段下的sales_flat_quote中查看.您应该看到它们附加在未转换的报价对象(图表)上.

If you want to find your 'missing' increment_ids, take a look in sales_flat_quote under the field reserved_order_id. You should see them attached to unconverted quote objects (carts).

此行为可能会导致某些支付网关出现问题；莫内里斯浮现在脑海.当您两次将相同的订单ID发送给Moneris的托管付款页时，它会阻塞并为客户创建一个隐秘的错误状态.当客户访问托管的付款页面，退出并重新访问该页面时，会发生这种情况.因此，在某些情况下，有必要以编程方式重新生成与报价对象关联的订单ID.

This behaviour can create issues with some payment gateways; Moneris comes to mind. When you send Moneris' hosted paypage the same order id twice, it chokes and creates a cryptic error state for the customer. This condition occurs when the customer visits the hosted pay page, backs out and re-visits the page. Hence in some cases, it is necessary to re-generate the order id associated with the quote object programmatically.

这篇关于magento订单ID增量跳跃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！