Problème de numéro de commande Magento

J'ai un problème étrange avec le numéro de commande dans Magento.

Récemment, lorsqu'une commande a été passée sur mon site Web, le numéro de commande est venu 100000350. Idéalement, il aurait dû être 100000370comme mes numéros de commande précédents 100000369et 100000367. J'ai joint la capture d'écran ci-dessous pour cela

De plus, j'ai vérifié les journaux d'erreurs mais je n'en ai trouvé aucune entrée. Nous utilisons SagePay et PayPal comme passerelle de paiement pour cela.

Quelqu'un peut-il me guider à ce sujet?

La première fois que j'ai obtenu un numéro de séquence, nous avons été surpris et quelque peu consternés jusqu'à ce que je comprenne ce qui se passait. Cela concerne la façon dont Magento attribue les numéros de commande client.

Il est tout à fait normal d'en avoir un hors séquence comme celui-ci, soit antérieur aux numéros alloués en cours et âgé d'un mois ou plus. Le secret est que c'était un client connecté qui n'a pas terminé la commande après une certaine étape critique, est revenu, s'est connecté et a finalement décidé d'acheter.

Le devis avec le numéro de commande client attribué utilise ce numéro pour le numéro de commande client.

Maintenant pour l'explication.

Le processus de commande Magento crée un devis la première fois qu'un article est ajouté au panier.

• Pour les clients invités, ce devis dure aussi longtemps que leur session n'a pas expiré, date à laquelle il existe dans la base de données, mais n'est pas récupérable par le client invité.
• Lorsqu'un client enregistré se connecte, le devis du panier reçoit son identifiant client afin que le panier dure aussi longtemps que le client ne le vide pas et peut être récupéré par le client enregistré en se connectant à son compte.

À ce stade, le devis est une commande client potentielle uniquement. Il n'a pas de numéro attribué car le client ne s'est pas engagé à le payer.

Lorsque le client clique sur le bouton Continuer pour passer à la caisse, il:

• soit être connecté avant de démarrer le panier
• ou s'ils ne sont pas connectés, leur a demandé s'ils souhaitaient s'inscrire ou effectuer un paiement en tant qu'invité.

Ce qui suit est un élément important: les clients qui choisissent de s'inscrire dans le panier sont traités comme des clients invités jusqu'à ce que la commande soit terminée et qu'ils accèdent à la page de réussite, moment auquel leur compte est créé et connecté. Le devis reste un devis client invité avec la perte de délai d'expiration de la session du panier si la commande n'est pas terminée et une page de succès s'affiche.

Avec une commande par carte de crédit, ce qui suit se produit lorsque le bouton Passer la commande est cliqué.

• Les informations de carte de crédit, les informations d'adresse de facturation, les totaux du panier et les informations de commande sont assemblées
• Un numéro de commande client est attribué à ce devis ( sales_flat_quotetableau dans la reserved_order_idcolonne)
• Le paquet de données est soumis à la passerelle de carte de crédit pour autoriser / capter les fonds pour payer la commande.
• Le processeur du panier de crédit renvoie:
  • soit une autorisation / capture de fonds avec les informations de transaction appropriées à enregistrer
  • ou refus de paiement avec les informations appropriées expliquant pourquoi l'autorisation / la capture a été refusée.
• Avec une autorisation / capture réussie, le devis est converti en commande client et s'il s'agit d'un registre de panier, le compte client est créé.

Si la transaction par carte de crédit est refusée pour un client par la passerelle de paiement par carte de crédit, et que le prochain client passe une commande réussie, il y aura un saut dans la séquence de numéros de commande client en raison du paiement refusé. La commande client se voit attribuer un numéro de commande client réservé. et la commande client réussie suivante se voit attribuer le prochain numéro disponible.

Pour les paniers d'invités (commandes d'invités et inscriptions infructueuses dans les clients du panier) qui dépassent le délai d'expiration de la session, ce numéro de commande client réservé sera perdu à l'expiration de la session, laissant des lacunes dans la séquence des commandes client .

Pour les clients qui se sont connectés avant de cliquer sur le bouton Continuer , le devis se voit attribuer un identifiant client, donc s'ils tentent de passer une commande et constatent qu'elle est refusée, ils peuvent revenir, se connecter, trouver que le panier contient toujours du contenu et placer le commande, parfois beaucoup plus tard (le plus long à ce jour était de quatre mois). Le devis utilisera le numéro de commande client réservé attribué, ce qui entraînera un numéro de commande client hors séquence affiché dans votre écran de gestion des commandes client.

J'étais confronté au même problème, mais ce n'est que lorsque le serveur a été touché par une énorme quantité de charge. Ce problème se produit car la base de données passe à l'état de verrouillage lors de la conversion de devis en ordre. Après une inspection plus approfondie, j'ai découvert que le problème était qu'il essayait d'écrire dans la table sales_flat_order_grid dans la transaction juste après l'insertion dans la table sales_flat_order. Avec des requêtes simultanées, il provoquait des collisions de verrouillage. La vraie solution consiste à retirer des éléments de sales_flat_order_grid de la transaction.

Le lien m'a aidé à comprendre le problème

Le patch a résolu le problème pour moi.

Vous devez supprimer la fonction _afterSave du Mage_Sales_Model_Abstract et ajouter

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

Faites-moi savoir si cela résout le problème pour vous.

Je ne suis pas sûr, mais cela pourrait résoudre votre problème:

Autant que je pense, quelque chose aurait pu déranger votre eav_entity_storetable. Il contient des informations sur le prochain increment_id, c'est-à-dire order_id à utiliser. Il se peut qu'un module ou un code de votre système magento l'ait modifié.

Ouvrez ce tableau et mettez à jour la colonne increment_last_id avec votre dernier identifiant de commande. Attention, il contient id incrément de d'autres aussi, comme la facture, l' expédition , etc. Pour être sûr, allez à la eav_entity_typestable et voir ce qui est entity_type_idpour sales/order(colonne entity_model). Dans mon magento, son 5. Alors maintenant, allez à la eav_entity_storetable et mettez simplement à jour l'incrément_id pour la ligne qui entity_type_idest 5. Vous pouvez le mettre à jour directement via phpmyadmin ou vous pouvez exécuter une requête comme,

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

Veuillez noter que 5 est entity_type_id dans mon magento pour la commande

Il peut y avoir plusieurs raisons à votre problème, mais je pense que cela pourrait résoudre votre problème.