NFC-e + A3 = problema

[bnobre]

Olá a todos, estou tento um sério problema com certificados do tipo A3 na emissão de NFC-e.

Basicamente meu aplicativo executa os comandos para inserção dos dados da venda no banco e tenta  enviar a NFC-e, em caso de erro de internet ele emite em contingência, do contrário ele descarta as mudanças feitas no banco. 

Tal rotina funciona perfeitamente em todos os meus clientes, exceto em 1 que possui esse tipo de certificado. É um comércio pequeno, onde o próprio dono é o vendedor. O que ocorre no mesmo é que em um momento qualquer ele tenta enviar a nota, a mesma não é enviada, não retorna erro nenhum e as mudanças no banco são concretizadas. Vira e mexe dá isso e sou obrigado a desfazer as alterações, além de voltar a numeração da NFC-e. Achei que o problema fosse no Windows dele e como esse problema só ocorre as vezes, não dei muita importância.

Agora acabo de implantar o aplicativo em outro cliente bem maior que usa esse tipo de certificado. Simplesmente no segundo dia começou dar esse problema. O aplicativo executa os comandos de inserção dos dados no banco, tenta enviar, não dá erro nenhum e grava as mudanças. Eu vi pessoalmente, o problema realmente se dá no certificado pois em dado momento o aplicativo até pediu a senha do mesmo, mesmo já estando configurada, tive que reiniciar para parar de pedir.

Formatei a máquina e o problema persiste. As cadeias e o certificado em si estão aparentemente instalados normalmente, acesso os portais do governo sem problema.

Uma coisa que observei no problema citado, em ambos o clientes, é que o mesmo começa a surgir quando ocorre uma falha na internet, e as vezes mesmo voltando a internet, sou obrigado a reiniciar o micro para cessar o problema, como se o certificado tivesse travado.

Os amigos com experiência nessa modalidade de emissão com A3 possuem essa problemática ou alguma outra? Alguma dica para solucionar o problema? Já estou quase desistindo de trabalhar com esse tipo de certificação .

Desde já agradeço a atenção de todos.

[Sérgio Assunção]

Creio que o problema não seja com o A3, até mesmo pelo fato que a falta de internet não iria "bloquear" as funçoes do certificado.

Passe a gravar no banco após a certeza que a nota foi emitida, seja em modo normal ou contingência.

[bnobre]

43 minutos atrás, Sérgio Assunção disse:

Creio que o problema não seja com o A3, até mesmo pelo fato que a falta de internet não iria "bloquear" as funçoes do certificado.

Passe a gravar no banco após a certeza que a nota foi emitida, seja em modo normal ou contingência.

Olá Sérgio,

Na verdade essa realmente seria a solução mais lógica, gravar só após a certeza da nota ter sido emitida.

Mas a problemática não é só essa, ao menos que eu tenho observado nesses únicos dois clientes A3 que tenho, o problema maior é o fato do certificado ficar "travado" e gerar os problemas que relatei, não enviar a nota no comando ENVIAR e as vezes pedir até a senha gravada. Com isso vou checar a nota, ver que ela não foi enviada e vou continuar NÃO conseguindo enviar. Quanto ao fator internet, não quis dizer que bloqueia, só observei que coincidentemente tenho esses problemas com o certificado após certas falhas com a internet.

Você emite sem problemas com o A3? Sua rotina no envio é similar a minha (explicada na abertura do tópico)? Nesses 2 clientes, por exemplo, logo que instalei recebi o erro 12057, coisa que no A1 não tenho, resolvi pela dica em http://scansist.blogspot.com.br/2015/02/corrigindo-erro-requisicao-12031-e.html, existe mais algum procedimento específico à se realizar para se trabalhar com o A3?  

 

[bnobre]

Um outro detalhe importante que observei Sérgio...

Durante esse "travamento", o meu aplicativo detectou ausência da internet na emissão de 4 notas, consequentemente tentou gerá-las de forma OFF-LINE, mas o componente simplesmente não retornou nenhum conteúdo do XML ao final da procedure GenaNFCe(similar a do demo) e também nenhum erro. Tal comportamento anormal só cessou após reiniciar tal máquina. Por isso simplesmente checar o sucesso do envio da nota não irá resolver o problema, que é bem maior do que isso.

[Régys Silveira]

Pode postar a parte de código que você utiliza para enviar para tentarmos entender o que ocorre?

Se possível como você configura o componente também

[bnobre]

Olá Régys, 

Grato pelo retorno.

Para que possar ter uma visão bem completa, anexarei 2 units que uso.

Na u_nfce_pdv.pas é que ocorre o envio, mas precisamente na procedure spb_finalizavendaClick.

No ato do envio, observe que chamo dtm_banco.CarregaParametrosNFCe, presente em u_banco.

 

u_nfce_pdv.pas

u_banco.pas

[Régys Silveira]

Pelo que vi você está enviando em modo Síncrono, pode ser que o servidor para o qual está enviando não esteja respondendo como deveria ou a internet é precária e tem atrapalhado, tentou enviar em modo assíncrono e verificar se melhora algo?

Eu costume deixar isso como configuração para poder personalizar conforme o cliente.

[bnobre]

Ola Régys, obrigado pelo contato.

Não o tentei fazer, nem sei como faz para ser sincero. Muda muito o código para a forma assíncrona? Teria um exemplo?

Irei realizar o teste conforme sua sugestão, mas ainda é estranho o fato de tal comportamento anormal ocorrer apenas nos clientes com cartão. Seus clientes com cartão funcionam normalmente?

Editado 14 Dezembro, 2015 por doidopb

[Italo Giurizzato Junior]

Boa tarde,

O método Enviar possui 3 parâmetros:

    function Enviar(ALote: integer; Imprimir: Boolean = True; Sincrono: Boolean = False): Boolean;

ALote é o numero do lote que contem uma ou mais notas a serem enviadas.

Imprimir, se True faz com que o DANFE seja impresso assim que a SEFAZ retorna o protocolo de autorização, se False não imprime o DANFE.

Sincrono, se True realiza o envio no modo síncrono, neste caso o lote só pode conter apenas uma nota, se False o envio é assíncrono e neste caso o lote pode conter até 50 notas.

Se cada PDV é autônomo no que diz respeito ao envio da nota para SEFAZ, pressupõe que o lote vai conter apenas uma nota, neste caso o terceiro parâmetro pode valer True.

Por outro lado se o envio é centralizado em um servidor, isso faz com que podemos ter um lote com mais de uma nota, neste caso o terceiro parâmetro tem que ser False.

Espero ter ajudado.

[bnobre]

Grato pela ajuda Italo,

Uma pergunta, eu nunca enviei via modo ASSINCRONO, fiz como você falou, apenas alterei o TERCEIRO parâmetro para False.

Eu achei que ia mudar alguma coisa, que eu precisasse enviar um comando posteriormente para consultar o recibo da nota, mas a mesma foi normal, autorizou e logo em seguida imprimiu, igual no modo SINCRONO. É assim mesmo? A forma de usar os 2 é igual?

 

Editado 14 Dezembro, 2015 por doidopb

[Régys Silveira]

Sim, para você praticamente não muda nada, a diferença é que o componente no modo assíncrono envia e consultar o lote na sequencia aguardando o tempo informado pelo webservice.

[bnobre]

Ok Régys,

Fiz conforme você falou, deixei como configuração e nos 2 clientes com A3 acabo de deixar como assíncrono, vamos ver no que dá.

Ontem um desses clientes ficou sem internet o dia todo e deu o problema que citei apenas na nota 63. Estou enviando o arquivo de log que meu aplicativo faz para você analisar, além da função GravaXML.

Existem 2 tipos de erro no log, um descrito como "Erro: " e outro como "Erro de Contingencia: ", o primeiro é gerado na tentativa de envio da nota pelo aplicativo emissor, já o segundo é gerado pelo aplicativo que envia as notas em contingência de 5 em 5 minutos.

Observe o erro da linha 17580, referente a nota 63, a mesma gerou um log de erro (Ação cancelada pelo usuário). Se observar a u_nfce_pdv, supõe-se que o aplicativo fez o seguinte:

• Executou o "dtm_banco.ACBrNFe1.Enviar(lote,False,True); //linha 630"
• Logo após entrou na exceção referente a outros erros que não sejam de "requisição não enviada", linha 694, pois logou esse erro.
• Não descartou as alterações, linha 695, pois logo em seguida se vê no log, linha 17585, um erro de internet referente a nota 64.
• Após esse erro de internet da nota 64, ele gerou em contingência normalmente.
• Na linha 17594, vemos que o aplicativo simplesmente tentou enviar uma nova nota dinovo como 63, onde obteve erro de "requisição não enviada". O que não tem explicação, pois a próxima na contagem seria 65.
• Observa-se que ele então executou a linha 665 já que logou o erro da contingência, a 667 e 668 que converte a venda para CONTINGENCIA também foi executada normalmente. Já as linhas 670 a 678 não retornaram nada, pois a 685 "GravaXML" não efetua gravação nenhuma (o que é estranho, já que deveria disparar uma exceção por tentar gravar em branco com campos vazios).
• Por fim ele salva as alterações, linha 686. Logo em seguida, nas linhas 688 a 691 ele tenta imprimir e nada sai (isso eu sei porque já vi acontecer).
• Já na linha 18067 do log, observa-se a tentativa de envio da próxima nota pelo emissor, que saiu corretamente como 65 seguindo a sequência, a mesma gerou também normalmente em contingência.

Bem, esse é um exemplo do que ocorre, mas varia. O fato é que algo acontece ao executar o .Enviar da linha 630, normalmente quando existe algum tipo de falha da internet, fazendo com que o código se perca. Vamos observar agora se pára no envio ASSÍNCRONO.

erros.txt

gravaxml.txt

[bnobre]

Olá, gostaria de expor outro detalhe que verifiquei referente ao relato exposto acima.

Conforme podem observar no log de erros do post superior, no dia do erro citado (14-15-15) foram emitidas apenas as notas 61, 62, 63 (que deu erro), 64 e 65... Todas foram em contingência, devido a ausência de internet no dia do problema.

No dia seguinte, enviei todas normalmente, menos a 63 conforme já relatado. A questão é que agora observei que o componente por alguma razão simplesmente não gerou os XMLs das notas 61, 62, 64 e 65. Tive que fazer manual. Mais um detalhe do caso acima que queria compartilhar com vocês para abranger o assunto e ajudar a descobrir o X dessa questão.

[Régys Silveira]

Poderia nos posicionar se nas últimas versões ainda ocorre o relatado?

[bnobre]

Em 30/12/2015 at 21:03, Régys Silveira disse:

Poderia nos posicionar se nas últimas versões ainda ocorre o relatado?

Olá Régys, tudo bom?

Desculpe a demora, mas só vi a sua mensagem agora. Na verdade estava aguardando um pouco mais de tempo para lhes posicionar com 100% de certeza, mas vamos lá.

Na verdade deixei a conexão como síncrona mesmo, pois assim que ia seguir a sua idéia eu tive um insight sobre o problema e acho que descobri a real causa, bem, ao menos até agora resolveu.

Seguinte, conforme relatei, se meu aplicativo detecta erro de conexão ao tentar enviar a NFC-e ele emite em contingência, até ai tudo bem. Só que tem um detalhe, eu tenho um outro aplicativo (contingencia.exe) rodando na máquina que tenta enviar as notas em contingência de 5 em 5 minutos, aí que tive uma "iluminação", percebi que poderia estar acontecendo de na hora que a nota em contingencia estivesse sendo enviada pelo contingencia.exe, o meu cliente poderia estar no mesmo instante enviando outra nota pelo meu aplicativo principal. Nos testes que realizei em certificados A1 não tive problemas com essa situação, mas lembrei que nunca testei essa possibilidade em certificados A3.

Daí imaginei que essa seria a causa do problema, o contingencia.exe usa o cartão para assinar a nota no mesmo momento que o aplicativo principal tenta usá-lo e pronto, o componente se perde. Então nesses clientes com A3 desativei o envio automático e eles são obrigados a enviar manualmente pelo programa principal, para garantir que não tenha outro envio de nota paralelo a esse.

Até agora não tive mais problemas.

Acha que minha teoria pode estar certa???

[Régys Silveira]

Tem fundamento sim, o A3 é aberto em modo exclusive, ou seja, se alguém abrir e outro tentar usar vai dar erro de leitura.

Como o certificado é usado para tudo, assinar, conexão, etc, então pode influenciar sim.