Emissão do número do pedido Magento

Eu tenho um problema estranho com o número do pedido no Magento.

Recentemente, quando um pedido foi feito no meu site, o número do pedido foi 100000350: Idealmente, deveria ter sido 100000370como meus números de pedidos anteriores eram 100000369e 100000367. Anexei a captura de tela abaixo para ela

Além disso, verifiquei os logs de erros, mas não encontrei nenhuma entrada. Estamos usando o SagePay e o PayPal como gateway de pagamento.

Alguém pode me orientar sobre isso?

A primeira vez que obtive um número fora de sequência, tivemos surpresa e algum desânimo até descobrir o que estava acontecendo. Tem a ver com a forma como o Magento aloca números de pedidos de vendas.

É totalmente normal ter uma sequência fora dessa, ser anterior aos números alocados atuais e ter um mês ou mais. O segredo é que era um cliente logado que não completou o pedido após um certo estágio crítico, voltou, efetuou login e decidiu finalmente comprar.

A cotação com o número da ordem do cliente alocado usa esse número para o número da ordem do cliente.

Agora, a explicação.

O processo de pedido do Magento cria uma cotação na primeira vez que algo é adicionado ao carrinho.

• Para clientes convidados, essa cotação dura enquanto a sessão não tiver atingido o tempo limite; nesse momento, ela existe no banco de dados, mas não pode ser recuperada pelo cliente convidado.
• Quando um cliente registrado faz login, a cotação do carrinho recebe sua identificação de cliente, para que o carrinho dure enquanto o cliente não o esvazia e pode ser recuperado pelo cliente registrado efetuando login em sua conta.

Nesse ponto, a cotação é apenas um pedido de venda em potencial . Não possui um número atribuído, porque o cliente não se comprometeu a pagar por ele.

Quando o cliente clicar no botão Continuar para finalizar a compra, ele:

• seja logado antes de iniciar o carrinho
• ou, se não estiver conectado, perguntará se eles querem se registrar ou fazer check-out como convidado.

O que se segue é uma parte importante: Os clientes que optam por se registrar no carrinho são tratados como clientes convidados até que o pedido seja concluído e acessem a página de sucesso, quando sua conta é criada e eles são logados. permanece uma cotação de cliente convidado com a perda do carrinho de tempo limite da sessão se o pedido não for concluído e uma página de sucesso for exibida.

Com um pedido de cartão de crédito, o seguinte acontece quando o botão Efetuar pedido é clicado.

• As informações do cartão de crédito, do endereço de cobrança, dos totais do carrinho e do pedido são reunidas
• Um número de pedido de venda é atribuído a esta cotação ( sales_flat_quotetabela na reserved_order_idcoluna)
• O pacote de dados é enviado ao gateway do cartão de crédito para autorizar / proteger os fundos para pagar pelo pedido.
• O processador do carrinho de crédito retorna:
  • uma autorização / captura de fundos com as informações apropriadas da transação a serem registradas
  • ou rejeição de pagamento com informações apropriadas sobre por que a autorização / captura foi negada.
• Com uma autorização / captura bem-sucedida, a cotação é convertida em um Pedido de Vendas e, se for um registro de carrinho, a conta do cliente é criada.

Se a transação do cartão de crédito for recusada para qualquer cliente pelo gateway de pagamento com cartão de crédito e o próximo cliente fizer um pedido com êxito, haverá uma pular na sequência do número do Pedido de Vendas devido ao fato de o Pedido de Vendas recusado ter recebido um número de Pedido de Venda reservado e o seguinte pedido de vendas bem-sucedido sendo atribuído ao próximo número disponível.

Para carrinhos de convidados (pedidos de convidados e registro malsucedido nos clientes do carrinho) que excederem o tempo limite da sessão, esse número reservado do Pedido de Vendas será perdido quando a sessão expirar, deixando lacunas na sequência do Pedido de Vendas.

Para os clientes que efetuaram login antes de clicar no botão Continuar , a cotação recebe um ID de cliente. Portanto, se eles tentarem fazer um pedido e descobrirem que foi recusado, poderão voltar, fazer login, encontrar o carrinho ainda com conteúdo e colocar o ordem, às vezes muito mais tarde (o mais longo até o momento foi de quatro meses). A cotação usará o número de pedido de venda reservado atribuído, levando a um número de pedido de venda fora de sequência, exibido no visor de gerenciamento de pedidos de vendas.

Eu estava enfrentando o mesmo problema, mas foi apenas quando o servidor foi atingido com uma enorme quantidade de carga. Esse problema ocorre porque o banco de dados entra no estado de bloqueio ao converter cotação em ordem. Em uma inspeção mais aprofundada, descobri que o problema era tentar gravar na tabela sales_flat_order_grid dentro da transação logo após a inserção na tabela sales_flat_order. Com consultas simultâneas, causava colisões de bloqueio. A solução real é mover coisas da sales_flat_order_grid para fora da transação.

O link me ajudou a entender o problema

O patch resolveu o problema para mim.

Você precisa remover a função _afterSave do Mage_Sales_Model_Abstract e adicionar

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

Deixe-me saber se isso resolve o problema para você.

Não tenho certeza, mas isso pode resolver seu problema:

Na minha opinião, algo pode ter perturbado sua eav_entity_storemesa. Ele contém informações sobre o próximo increment_id, ou seja, order_id a ser usado. Pode ser que algum módulo ou código no seu sistema magento possa ter mudado.

Abra esta tabela e atualize o incrum_last_id coloumn com o seu último ID de pedido. Tenha cuidado, ele contém id do incremento de outras pessoas, bem como a nota fiscal, expedição etc. Para ter certeza, basta ir à eav_entity_typesmesa e ver o que é o entity_type_idde sales/order(coluna entity_model). No meu magento, é 5. Então agora vá para a eav_entity_storetabela e atualize o increment_id para a linha cujo entity_type_idé 5. Você pode atualizá-lo diretamente via phpmyadmin ou executar consultas como,

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

Observe que 5 é entity_type_id no meu magento para pedido

Pode haver muitos motivos para o seu problema, mas acho que isso pode resolvê-lo.