Magentoの注文番号の問題

Magentoの注文番号に奇妙な問題があります。

最近、私のウェブサイトで1つの注文が行われたとき、注文番号が来ました100000350。理想的には100000370、以前の注文番号100000369と同じであるはず100000367です。以下のスクリーンショットを添付しました

さらに、エラーログを確認しましたが、エントリが見つかりませんでした。SagePayとPayPalを支払いゲートウェイとして使用しています。

誰かがこれについて私を案内できますか？

初めてシーケンス番号を取得したとき、何が起こっているのかを理解するまでは驚きと驚きがありました。Magentoが販売注文番号を割り当てる方法に関係しています。

現在の割り当て数よりも前で、1か月以上前のように、そのような順序のないものを1つ持つことは完全に正常です。その秘密は、特定の重要な段階の後で注文を完了せず、戻ってきてログインし、最終的に購入することを決定したのはログインした顧客だったということです。

割り当てられた販売注文番号のある見積もりは、その番号を販売注文番号として使用します。

説明のために。

Magentoの注文プロセスでは、カートに初めて何かが追加されたときに見積もりが作成されます。

• ゲスト顧客の場合、この見積もりはセッションがタイムアウトしない限り存続します。その時点でデータベースに存在しますが、ゲスト顧客は回復できません。
• 登録済みの顧客がログインすると、カートの見積もりに顧客IDが割り当てられるので、顧客がカートを空にしない限りカートは存続し、登録済みの顧客は自分のアカウントにログインして取得できます。

この時点では、見積もりは潜在的な販売注文のみです。顧客が支払いを約束していないため、番号は割り当てられていません。

お客様が[ Proceed]ボタンをクリックしてチェックアウトすると、次のようになります。

• カートを開始する前にログインする
• または、ログインしていない場合は、ゲストとして登録またはチェックアウトするかどうかを尋ねられます。

重要なのは次の点です。カートに登録することを選択した顧客は、注文が完了して成功ページに到達するまでゲスト顧客として扱われ、その時点でアカウントが作成されてログインします。見積もり注文が完了せず、成功ページが表示された場合、セッションタイムアウトのカートが失われるというゲストの顧客の見積もりが残ります。

クレジットカード注文の場合、[ 注文する ]ボタンをクリックすると、次のことが起こります。

• クレジットカード情報、請求先住所情報、カートの合計、注文情報がまとめられます
• この見積書には販売注文番号が割り当てられています（列のsales_flat_quote表reserved_order_id）
• データパッケージはクレジットカードゲートウェイに送信され、注文の支払いに使用する資金を承認/取得します。
• クレジットカートプロセッサはパスバックします。
  • いずれかの資金の許可/キャプチャ記録する適切なトランザクション情報
  • または、承認/取得が拒否された理由に関する適切な情報を含む支払いの拒否。
• 承認/キャプチャが成功すると、見積もりが販売注文に変換され、これがカートレジスタである場合は、顧客アカウントが作成されます。

クレジットカード決済ゲートウェイによって顧客のクレジットカード取引が拒否され、次の顧客が注文を成功させると、拒否された支払い販売注文に予約済みの販売注文番号が割り当てられるため、販売注文番号シーケンスがスキップされます。次の成功した販売注文には、次に利用可能な番号が割り当てられます。

ゲストカート（ゲスト注文とカートの顧客への登録の失敗）がセッションタイムアウトを超えた場合、この予約された販売注文番号はセッションが期限切れになると失われ、販売注文シーケンスにギャップが残ります。

[ 続行 ] ボタンをクリックする前にログインした顧客には、見積もりに顧客IDが割り当てられているため、注文しようとして拒否された場合は、戻ってログインし、カートにまだコンテンツが含まれていることを確認して、注文、時々ずっと後で（これまでの最長は4ヶ月でした）。引用につながる、割り当てられた予約受注番号を使用するシーケンスのうち、あなたの受注管理画面に示す受注番号。

私は同じ問題に直面していましたが、それはサーバーに大量の負荷がかかった場合のみでした。この問題が発生するのは、見積もりを注文に変換している間にデータベースがロック状態になるためです。さらに調査したところ、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();
}

問題が解決したかどうかをお知らせください。

よくわかりませんが、これで問題が解決する可能性があります。

私の考えでは、何かがあなたのeav_entity_storeテーブルを乱したのかもしれません。次のincrement_id、つまり使用するorder_idに関する情報が含まれています。magentoシステムのモジュールまたはコードが変更した可能性があります。

このテーブルを開き、increment_last_id列を最後の注文IDで更新します。注意してください。これには、請求書、出荷などの他の増分IDが含まれます。確認するには、eav_entity_types表に移動しentity_type_idてsales/order（列entity_model）が何であるかを確認してください 。私のmagentoでは5です。eav_entity_storeテーブルに移動して、5の行のincrement_idを更新しますentity_type_id。phpmyadminを使用して直接更新するか、次のようなクエリを実行できます。

update eav_entity_store set increment_last_id = 'your_last_order_id' where entity_type_id = 5; 

注5は注文用のmagentoのentity_type_idです。

問題にはさまざまな理由がありますが、これで問題が解決する可能性があります。