5

何らかの理由で、注文ID（sales_flat_orderテーブルのincrement_id）がMagento1.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を「予約」し、quote（カート）オブジェクトに配置します。増分IDを取得するコードは次の場所で確認できます。

Mage_Eav_Model_Entity_Type::fetchNewIncrementId()

各店舗で最後に使用されたIDはeav_entity_storeに保存されます。顧客がチェックアウトプロセスを完了する前にカート（つまり見積もりオブジェクト）を放棄した場合、予約されたincrement_idが注文に表示されることはありません。この効果は、忙しい店で入荷する注文番号で確認できる場合があります。古いカートをチェックアウトしている顧客からのその日の注文で、非常に古い注文IDが届く場合があります。

この動作は、注文が完了する前にMagentoが支払いゲートウェイに最終的な注文ID（increment_id）を送信できるようにするために存在し、ゲートウェイが注文IDを注文に関連付けることを可能にします。顧客がゲートウェイでの支払いプロセスを放棄した場合、注文IDは無効になります（より正確には、見積もりに添付されたままになります）。

これは、PayPalエクスプレスモジュールで発生していることがわかります。

Mage_Paypal_Model_Express_Checkout::start()

これは

Mage_Sales_Model_Quote::reserveOrderId()

'欠落している'increment_idsを見つけたい場合は、フィールドreserved_order_idの下のsales_flat_quoteを調べてください。変換されていない見積もりオブジェクト（カート）に添付されているのがわかります。

この動作により、一部の支払いゲートウェイで問題が発生する可能性があります。モネリスが頭に浮かぶ。Monerisがホストするペイページに同じ注文IDを2回送信すると、Monerisは窒息し、顧客に不可解なエラー状態を作成します。この状態は、顧客がホストされている支払いページにアクセスし、バックアウトしてページに再度アクセスしたときに発生します。したがって、場合によっては、quoteオブジェクトに関連付けられた注文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

この同じ問題は、過去2か月間に何度も発生しています。決済サービスプロバイダーのトランザクションリストを確認すると、潜在的な不正問題のために、数千の低価値（マイクロ）トランザクションが拒否されていることがわかります。私の意見では、詐欺師は私たちのチェックアウトプロセスを使用して、有効なカードと無効なカードを見つけるために必要なカードのリストを調査しようとしています。私はそれをアクション詐欺、私たちのウェブホストと私たちの支払いプロバイダーに報告しました。

要約すると、同じ期間のトランザクションのPSPリストを確認することをお勧めします。

それで頑張ってください、Brisc。

于 2020-11-22T12:24:53.950 に答える