ACBrNFe - Rejeição: Assinatura difere do calculado

[Gilson_ST]

Calma ai amigo Gilson, quando você envia uma nf(ece), e os dados de retorno não são salvos, ou não são atualizados por falta de energia elétrica, acredito que esta nota enviada e "não atualizada" não pode ser novamente enviada por contingencia, explico. Não é a falta de energia local que vai impedir a recepção pela SEFAZ, isso porquê, a nota foi enviada, então, deve ser consultada ou em ultimo caso, fazer uma nova nota em modo de contingencia, e cancelar a anterior quando a energia elétrica for restabelecida. Caso contrário, vai dar duplicidade mesmo.

Sim Agnaldo, eu sei disso. Vou tentar explicar de outra forma, envio o XML, ele é recebido e autorizado pela SEFAZ, antes de eu receber a resposta minha internet caixa e eu recebo o erro 12002 ou o 12007, até aqui não fiz nenhum tratamento para verificar se a NFCe foi recebida e autorizada, isso porque estou sem internet. Recebendo um destes erros entro em modo de contingência. Depois ao tentar enviar enviar o XML de contingencia recebo  a rejeição 539 (duplicada com chave diferente). 

Como é seu tratamento neste caso ?

Desculpe-me por estar fugindo do assunto do tópico.

[Gilson_ST]

Amigos, obrigado pelas respostas. Estou mudando para o tópico http://www.projetoacbr.com.br/forum/topic/24169-tratamento-para-envio-de-nfc-e-offline/

[Italo Giurizzato Junior]

Bom dia a todos,

Gilson, a coisa é mais simples o que parece, vamos aos passos:

1. A nota é enviada a SEFAZ;

2. Se não ocorrer nenhuma falha de conexão com a internet temos o retorno da SEFAZ;

2.1. Temos que analisar o cStat para saber se a nota foi autorizada, denegada ou rejeitada;

2.2. Se foi autorizada o XML é atualizado com o protocolo de autorização e o DANFE é impresso.

2.3. Se foi denegada o XML é atualizado com o protocolo de denegação e a venda não é realizada.

2.4. Se foi rejeitada é preciso efetuar a correção do dado errado, gerar, assinar e enviar novamente o XML (voltar ao passo 1);

3. Se ocorreu falha de conexão devemos carregar o componente com o XML assinado e realizar uma consulta;

3.1 Se nessa consulta não ocorrer nenhum erro de conexão temos que analisar o cStat, analise semelhante aos passos 2.2, 2.3 e 2.4

3.2 Caso a nota seja rejeitada por não constar na base de dados da SEFAZ, devemos efetuar o envio novamente, neste caso fica claro que o erro de conexão ocorreu logo no envio e não no retorno.

Seguindo esses passos, você nunca vai ter problemas de notas em duplicidades.

Quando lançamos mão a contingência?

Quando o problema de conexão vai demorar para ser sanado.

Outra coisa, temos que saber onde esta a origem do problema (SEFAZ ou contribuinte)?

Dependendo de onde é o problema o tipo de contingência a ser executado é diferente.

Se o problema é com a SEFAZ devemos alterar o tipo de emissão para offline (no caso da NFC-e), informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML e simplesmente imprimir o DANFE.

Quando os problemas forem sanados devemos enviar esse último XML para a SEFAZ.

Agora se o problema é com o contribuinte, se este possuir uma conexão 3G (por exemplo) deve-se também alterar o tipo de emissão para EPEC, informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML, imprimir o DANFE e por fim enviar via 3G o evento EPEC.

Quando os problemas forem sanados devemos enviar esse último XML para SEFAZ.

[Gilson_ST]

Bom dia a todos,

Gilson, a coisa é mais simples o que parece, vamos aos passos:

1. A nota é enviada a SEFAZ;

2. Se não ocorrer nenhuma falha de conexão com a internet temos o retorno da SEFAZ;

2.1. Temos que analisar o cStat para saber se a nota foi autorizada, denegada ou rejeitada;

2.2. Se foi autorizada o XML é atualizado com o protocolo de autorização e o DANFE é impresso.

2.3. Se foi denegada o XML é atualizado com o protocolo de denegação e a venda não é realizada.

2.4. Se foi rejeitada é preciso efetuar a correção do dado errado, gerar, assinar e enviar novamente o XML (voltar ao passo 1);

3. Se ocorreu falha de conexão devemos carregar o componente com o XML assinado e realizar uma consulta;

3.1 Se nessa consulta não ocorrer nenhum erro de conexão temos que analisar o cStat, analise semelhante aos passos 2.2, 2.3 e 2.4

3.2 Caso a nota seja rejeitada por não constar na base de dados da SEFAZ, devemos efetuar o envio novamente, neste caso fica claro que o erro de conexão ocorreu logo no envio e não no retorno.

Seguindo esses passos, você nunca vai ter problemas de notas em duplicidades.

Quando lançamos mão a contingência?

Quando o problema de conexão vai demorar para ser sanado.

Outra coisa, temos que saber onde esta a origem do problema (SEFAZ ou contribuinte)?

Dependendo de onde é o problema o tipo de contingência a ser executado é diferente.

Se o problema é com a SEFAZ devemos alterar o tipo de emissão para offline (no caso da NFC-e), informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML e simplesmente imprimir o DANFE.

Quando os problemas forem sanados devemos enviar esse último XML para a SEFAZ.

Agora se o problema é com o contribuinte, se este possuir uma conexão 3G (por exemplo) deve-se também alterar o tipo de emissão para EPEC, informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML, imprimir o DANFE e por fim enviar via 3G o evento EPEC.

Quando os problemas forem sanados devemos enviar esse último XML para SEFAZ.

Muito obrigado Italo. Vou rever meu fonte e fazer as alterações necessárias. Deus abençoe a você e todos os outros amigos que contribuem para a melhoria deste excelente componente.