897-Valor Fatura maior que Valor Total da NF-e - em GO

[Fabrício G. Araújo]

Vi o tópico nos assinantes SAC, mas criei outro aqui para poder informar que o mesmo está acontecendo comigo no ambiente de homologação em GO para NFC-e. Simplesmente deu essa loucura na SEFAZ/GO.

Ah, e só respondendo ao questionamento do @EMBarbosa, o meu lote está diferente assim como o cNF e nNF, e mesmo assim está ocorrendo a rejeição.

[Marco Ezequiel]

o mesmo problema esta ocorrendo comigo, no meu sistema e no de outra revenda, que loucura e essa?  será que vai demorar a concertar?

[EMBarbosa]

2 horas atrás, Fabrício G. Araújo disse:

Ah, e só respondendo ao questionamento do @EMBarbosa, o meu lote está diferente assim como o cNF e nNF, e mesmo assim está ocorrendo a rejeição. 

Agradecemos o retorno. Nesse caso, o problema deve ser na SEFAZ mesmo. Não tem muito sentido o retorno de erro deles.

Assim, o melhor é vocês começarem a questionar a SEFAZ o quanto antes. Quem sabe, com muitos questionando eles não corrigem logo ou dão uma posição melhor.

[DIGITAL SOFTWARE SUPORTE]

Entrei em contato com a Sefaz-GO e o problema já está sendo analisado pelo departamento de  TI

[ifaster]

Encontrei o mesmo problema, com outro código de erro, em produção.

Qual número é o da Sefaz-GO?

Editado 25 Junho, 2019 por ifaster

[DIGITAL SOFTWARE SUPORTE]

47 minutos atrás, ifaster disse:

Encontrei o mesmo problema, com outro código de erro, em produção.

Qual número é o da Sefaz-GO?

Suporte Sefaz: 03003130100

[Fabrício G. Araújo]

Olá pessoal,

Passando por aqui só para informar que o ambiente de homologação NFC-e em GO voltou a funcionar... mas com uma ressalva, está funcionando apenas com Wincrypt, pois com OpenSSL (mingw) não está funcionando... vou fingir que nem vi isso... dá até arrepio no cabelo da nuca só de pensar a possibilidade de ocorrer algo nesse sentido em produção... torcer para que não.

[MAC.SISTEMAS]

Olá pessoal, consegui resolver deixando o nnf <> cnf e respeitando a seguinte validação:

[ifaster]

@MAC.SISTEMAS No meu já estão diferentes e seguinte a regra, anexei um arquivo xml. Talvez vocês vejam algo que não estou percebendo.

Vou esperar até as 14h00 e ligar novamente na Sefaz.

 

Acabei de tentar novamente, estou em produção.

 

Testei usando Capicom e Wincrypt com estas configurações:

52190600024281000112550010000000911000012024-nfe.xml

[BigWings]

13 minutos atrás, ifaster disse:

 No meu já estão diferentes e seguinte a regra, anexei um arquivo xml. Talvez vocês vejam algo que não estou percebendo.

Veja que a sua rejeição foi diferente.

Se você validar o teu XML no validador da SEFAZ-RS verá que realmente tem algo errado com a nota, neste caso o problema não é a SEFAZ.

Citar

Resultado da Validação do Schema e de Regras de Negócio (atualizado até a NT2018/005 v1.20 e anteriores):

Parser XML: Nenhum erro encontrado Tipo de Mensagem: NF-e sem assinatura digital Schema XML: Nenhum erro encontrado NF-e 52190600024281000112550010000000911000012024 Mensagem não assinada Regras de Negócio [Ambiente de Produção] 3 erros de validação 202 - [Simulacao] Rejeicao: Falha no reconhecimento da autoria ou integridade do arquivo digital 506 - [Simulacao] Rejeicao: Data de Saida menor que a Data de Emissao 564 - [Simulacao] Rejeicao: Total do Produto / Servico difere do somatorio dos itens

 

[Fabrício G. Araújo]

@ifaster, acabei de validar novamente e o ambiente de homologação em GO está tudo ok.

Se for o caso, criar um novo tópico, mas olhei o seu xml e você está gerando incorretamente, a mensagem de restrição está correta, realmente o valor do seu produto não confere com os totais da nota.

[ifaster]

@BigWings Realmente, o arquivo XML que enviei estava com estes problemas, acabei enviando o arquivo de ontem. Obrigado pelo apoio.

@Fabrício G. Araújo Testei em homologação e está tudo funcionando. Realmente, o arquivo XML que enviei estava com estes problemas, acabei enviando o arquivo de ontem. Obrigado pelo apoio.

Tudo funcionando!

 

[]'s

[Sandro TC]

Bom dia, pessoal.

Para mim a rejeição 897 começou em 25/06/2019 com a mensagem "Valor Fatura maior que Valor Total da NF-e".
Hoje a rejeição 897 já apareceu com a mensagem "Código numérico em formato inválido", conforme abaixo.
Não fiz nenhuma alteração em minha aplicação e a rejeição aqui em GO persiste.
É uma simples NFC-e com pagamento em dinheiro emitida no modo de homologação.

CStat=897
CUF=52
DhRecbto=27/06/2019 10:23:43
Msg=
VerAplic=GO4.0
Versao=GO4.0
XMotivo=Rejeição: Código numérico em formato inválido
 

[Fabrício G. Araújo]

@Sandro TC, acabei de testar agora e está tudo normal. Talvez a SEFAZ/GO passou a validar o código numérico e agora você não está conseguindo emitir as notas. Como sempre gerei corretamente nunca tive esse tipo de problema.

[Sandro TC]

5 minutos atrás, Fabrício G. Araújo disse:

@Sandro TC, acabei de testar agora e está tudo normal. Talvez a SEFAZ/GO passou a validar o código numérico e agora você não está conseguindo emitir as notas. Como sempre gerei corretamente nunca tive esse tipo de problema.

Obrigado pelo retorno, Fabrício.
A questão é qual código numérico, já que o código da rejeição é o mesmo 897 e a mensagem diferente?
Ainda porque não fiz nenhuma alteração em meus fontes e o mesmo problema foi apontado por outras pessoas aqui no fórum.
Mesmo assim, vou ajustar o campo cNF para ficar diferente do nNF, pois no meu XML está assim:

<cNF>00001389</cNF>
<nNF>1389</nNF>

Editado 27 Junho, 2019 por Sandro TC

[Fabrício G. Araújo]

Olha o protocolo da nota que acabei de enviar tudo ok:

@Sandro TC, você não está obedecendo essa regra:

Em 26/06/2019 at 09:08, MAC.SISTEMAS disse:

Olá pessoal, consegui resolver deixando o nnf <> cnf e respeitando a seguinte validação:

 

[Sandro TC]

4 minutos atrás, Fabrício G. Araújo disse:

Olha o protocolo da nota que acabei de enviar tudo ok:

@Sandro TC, você não está obedecendo essa regra:

 

Sim, vou fazer o ajuste, pois como até então estava funcionando, achei que eu poderia colocar zeros à esquerda em cNF para diferenciá-lo de nNF.
Mas pelo jeito não é aceito. A Sefaz deve ter atualizado seus servidores de homologação com esta verificação, pois em produção está funcionando.

Obrigado, Fabrício.

[Sandro TC]

25 minutos atrás, Fabrício G. Araújo disse:

Olha o protocolo da nota que acabei de enviar tudo ok:

@Sandro TC, você não está obedecendo essa regra:

 

Fiz o devido ajuste e funcionou! Obrigado por me lembrar da NT 2019.001.

Porém, tenho uma dúvida sobre a regra de validação B03-10 da NT 2019.001 que você mencionou:
A regra cita, por exemplo, que o número 01234567, entre outros, não pode ser utilizado na tag cNF.
Neste caso, se eu utilizo um contador com auto incremento e, se esse meu contador atingir esse número 01234567,
eu teria a rejeição, certo? Como você está fazendo, Fabrício? Está utilizando um contador?

Desde já agradeço.

[Kiko Fernandes]

28 minutos atrás, Sandro TC disse:

Neste caso, se eu utilizo um contador com auto incremento e, se esse meu contador atingir esse número 01234567,
eu teria a rejeição, certo?

Bom dia!

Primeiro: a SEFAZ orienta que o número deve ser aleatório. (Obs. e  sempre foi assim, não mudou o método, o que mudou é que eles tiveram que incrementar validações e rejeição, porque só o manual não foi suficiente para muitos procederem conforme a instrução).
 

Citar

Campo cNF - Código Numérico que compõe a Chave de Acesso da NF-e. Esse campo "DEVE" ser preenchido com um número aleatório gerado pelo emitente para cada NF-e para evitar acessos indevidos da NF-e 

Segundo: Como agora existe a regra de validação você terá que validar em seu sistema se o numero aleatório gerado pelo teu sistema é válido segundo as regras da NT.
Se não fizer uma pré-validação a nota será rejeitada quando acontecer isto e ai você terá que tratar o  erro e gera outro número aleatório. 

Terceiro:  Se você usa o ACBrMonitorPLUS e deixar o campo cNF=0, o número aleatório será gerado pelo ACBr, porém você deverá gravar em seu banco de dados para que em uma necessidade de usar comandos que geram novamente a chave você não fique gerando outras chaves e permaneça na chave gerada.

[Fabrício G. Araújo]

33 minutos atrás, Sandro TC disse:

Fiz o devido ajuste e funcionou! Obrigado por me lembrar da NT 2019.001.

Porém, tenho uma dúvida sobre a regra de validação B03-10 da NT 2019.001 que você mencionou:
A regra cita, por exemplo, que o número 01234567, entre outros, não pode ser utilizado na tag cNF.
Neste caso, se eu utilizo um contador com auto incremento e, se esse meu contador atingir esse número 01234567,
eu teria a rejeição, certo? Como você está fazendo, Fabrício? Está utilizando um contador?

Desde já agradeço.

Hum... nunca atentei para esse fato, mas sim uso um contador, outras pessoas geram valores aleatórios para não ficar fácil identificar a chave (que imagino seja o mais correto).

Com certeza quando meu contador chegar em algum daqueles números dará m... Mas não fiz nada para tratar isso por enquanto. Até porque no seguimento que atuo até chegar em algum daqueles números já terei aposentado.

[Sandro TC]

Tudo certo. Compreendido.

Muito obrigado ao Kiko Fernandes e ao Fabrício.

 

[Kiko Fernandes]

Fechando o tópico.
Para nova dúvida, abra novo tópico.