5

由于某种原因，订单 ID（sales_flat_order 表上的增量 ID）随后在我的 Magento 1.6.1 上没有增加。这是在下达大量实时订单后的样子：

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 之后。有人知道为什么会发生这种情况，是否有办法解决它？

4

3 回答 3

24

这是正常的，尽管令人不安是可以理解的。

当 Magento 进入结帐过程时，它会“保留”一个 increment_id 并将其放在报价（购物车）对象上。您可以在以下位置查看获取增量 id 的代码：

Mage_Eav_Model_Entity_Type::fetchNewIncrementId()

每个商店最后使用的 ID 存储在 eav_entity_store 中。如果客户在完成结账过程之前放弃了他们的购物车（即报价对象），则保留的 increment_id 将永远不会出现在订单上。当订单号进入繁忙的商店时，您有时可以在订单号中看到这种效果 - 有时，在结账旧购物车的客户的当天订单中会出现一个非常旧的订单 ID。

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

您可以在 PayPal express 模块中看到这种情况：

Mage_Paypal_Model_Express_Checkout::start()

调用

Mage_Sales_Model_Quote::reserveOrderId()

如果您想找到您的“缺失”increment_id，请查看字段 reserved_order_id 下的 sales_flat_quote。您应该看到它们附加到未转换的报价对象（购物车）。

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

于 2012-06-07T20:09:59.530 回答
1

我遇到了同样的问题，但只有当服务器受到大量负载时。出现此问题是因为数据库在将报价转换为订单时进入锁定状态。经过进一步检查，我发现问题在于它在插入 sales_flat_order 表后立即尝试在事务中写入 sales_flat_order_grid 表。对于并发查询，它会导致锁定冲突。真正的解决方案是将 sales_flat_order_grid 的东西移出事务。

该链接帮助我理解了这个问题

该补丁为我解决了这个问题。

您必须从 Mage_Sales_Model_Abstract 中删除函数 _afterSave 并添加

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

让我知道它是否可以为您解决问题。

于 2015-01-15T09:09:18.850 回答
-1

在过去的几个月里，我们多次遇到同样的问题。在检查我们的支付服务提供商交易列表后，我们发现由于潜在的欺诈问题，数以千计的低价值（微）交易被拒绝。我的观点是，欺诈者正试图使用​​我们的结帐流程来探查他们必须查明的卡片列表，以找出哪些卡片有效，哪些卡片已失效。我已将其报告给欺诈行为、我们的网络主机和我们的支付提供商。

总之，我的建议是让您检查您的 PSP 交易清单在同一时间段内。

祝你好运，布里斯克。

于 2020-11-22T12:24:53.950 回答