Problème de numéro de commande Magento

9

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

Capture d'écran du numéro de commande

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?

Dexter
la source
Je peux voir clairement que vous avez installé n'importe quel module lié à la commande, cela posera un problème,
Keyul Shah
Il n'y a pas de module lié à la commande. Le seul module tiers que nous utilisons est Ebizmarts_SagePay, Mass_Product_Relater, TBT_Enhancegrid et Sphinix Search
Dexter
1
Pas de gros problème, quelqu'un avec un compte client a presque terminé une commande au point qu'il a soumis pour le paiement, s'est vu attribuer un numéro de commande client et a ensuite abandonné le panier pendant un certain temps. Ça arrive tout le temps ... Tu as la commande, félicitations, commande terminée au lieu de l'abandon.
Fiasco Labs du
Je pense que vous n'avez pas eu ma question
Dexter
1
@huzefam - Veuillez en discuter avec l'équipe de conception de Magento, ou créez votre propre colonne de numéro automatique de série que vous désactivez pour votre ERP sur le Magento SO terminé. Oui, je comprends du point de vue de l'audit s'il manque des numéros de facture, il y a des mouchoirs. Magento semble avoir pris la position que toutes les commandes ne sont pas valides, donc les numéros SO manquants ne sont pas un gros problème. Je comprends également que certains systèmes comptables, les juridictions gouvernementales pensent la même chose à propos des commandes client et s'attendent à avoir une piste d'audit qui montre les commandes annulées dans une séquence série complète.
Fiasco Labs

Réponses:

28

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.

Fiasco Labs
la source
À des fins de vérification, j'ai fait semblant de rester bloqué dans la caisse en ne sélectionnant pas le mode de paiement et en fermant finalement le navigateur (sur l'ordinateur qui a ouvert le site + la caisse en premier). et en attendant terminé la deuxième commande d'ordinateurs (qui devrait obtenir le prochain incrément d'ID). Le résultat est qu'il ne saute pas par-dessus le nombre. Si cela fonctionnait de cette façon, il aurait ajouté un identifiant inutilisé entre l'ordre 10 et l'ordre 11, ce qu'il n'a pas fait. Selon vos informations, j'ai essayé de vérifier et de faire exactement la chose que vous spécifiez, mais cela ne donne pas la sortie.
Siva
Au lieu de cela, si un client échoue dans Payement Gateway, il apparaîtra comme paiement en attente ou annulé, et si la commande échoue dans la dernière partie de la caisse, il ne s'affichera pas du tout (et continuez avec l'ID correct dans le séquence). Alors maintenant, je suis confus avec ça. Veuillez m'aider à comprendre pourquoi le numéro de commande saute au hasard. Merci
Siva
Grande explication.
Wolfack
2

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.

Shaily
la source
Quelqu'un at-il essayé cette méthode comme l'a dit Shaily ?
Siva
0

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.

Pradeep
la source
Merci .. mais déjà vérifié le tableau et il a l'identifiant d'incrément correct
Dexter
quel est votre identifiant de commande maximum (pas le plus récent) dans les ventes admin -> commandes? Mettez cette valeur dans le tableau que j'ai dit .. passez une commande de test et vérifiez ..
Pradeep