1) Conceito Inicial do Problema

             Até as versões de junho de 2018, era muito comum clientes abrirem pendências anexando XMLs assinados e enviados para a Sefaz de cupons fiscais eletrônicos (SAT e NFCE) que não foram gravados no sistema, nem a nota, nem a movimentação. Isso ocorria porque após o envio para Sefaz, o sistema realizava diversas tratativas para enfim registrar o cupom na base de dados, porém após esse envio para a sefaz, quando ocorria algum erro, seja de queda de conexão, energia, ou até mesmo falha de programação em algum método, o sistema não conseguia gravar o cupom transmitido na base, gerando diversas divergências nos relatórios e consultas pela falta dessas notas.


2) Solução desenvolvida (Todas as versões do Linx-Millennium e Basic)

              A solução proposta e desenvolvida foi inverter o fluxo do processo. Os cupons agora são gravados na base de dados antes do processo de envio para a Sefaz, porém como não é possível saber de antemão o número da nota fiscal que será gerada pelo SatServer, este cupom é gravado com a numeração provisória -1 e somente após o processo de envio e assinatura na Sefaz realizado com sucesso, essa numeração -1 é atualizada para o número da nota fiscal gerado pelo módulo do SatServer.
             Abaixo fluxograma resumido do processo de envio e gravação dos cupons eletrônicos (SAT / NFCE) que é realizado hoje no sistema.



Abaixo tela de consulta movimentação com um cupom -1 com status cancelado. Esta é uma movimentação que não deve afetar em nada o sistema.



3.0) Problema frequente com estorno de Estoque e Financeiro

              Conforme visualizado no fluxograma acima, quando ocorrer algum erro no processo de envio do cupom, seja uma rejeição da Sefaz ou falha no módulo SatCfeServer, o sistema irá acionar o método Millenium.Movimentacao.Cancela para cancelar esse cupom e automaticamente estornar o estoque, financeiro ou comissões quando houver referente a este cupom. No entanto, neste momento o sistema poderá ainda estar sem conexão com o servidor e não conseguir executar esse método, como sabemos, a nota -1 já está gravada com o Status de cancelada na base, porém o financeiro e estoque já foram gerados. Nesta situação alguns clientes estavam deixando de efetuar uma nova tentativa de emissão de cupom para não ter duplicação de estoque e financeiro.


3.1) Solução desenvolvida.

               Para este caso específico, foi desenvolvido no Scheduler o método Millenium.Movimentacao.CancelaCfeNaosEnviados que já está habilitado no Scheduler com timer de 1 minuto. Este método a cada minuto procura na base dados cupons -1 com a movimentação não cancelada e pra cada cupom encontrado ele chama o método movimentacao.cancela que estorna estes cupons liberado o estoque e excluindo o financeiro.


Abaixo o método configurado no Scheduler




4.0) Problemas Comuns
4.1) Não Devolver Estoque

  • Verificar se o método CancelaCfeNaosEnviados está configurado no Scheduler
  • Acessar o BrokerLog e através de pesquisa verificar se este método está sendo executado com sucesso ou está retornando erro.

4.2) Não Estornar Financeiro

  • Seguir as mesmas instruções do item anterior

4.3) Grande Quantidade de Cupons -1

  • Um cupom fiscal só permanece -1 quando ele não consegue receber da Sefaz a confirmação de envio, verificar conexão com internet, rede
  • Rejeições, acessar o BrokerLog e através de pesquisa verificar quais erros estão ocorrendo no processo.


4.4) Não Aparecer como cancelado nos relatórios

  • Além das verificações acima, verificar se versão é antiga, em versões antigas (mais de um ano) o cupom -1 não iniciava com o status cancelado, hoje já é gravado com cancelado='True' mudando esse status para False apenas quando o envio é concretizado com sucesso na Sefaz.