Ir para conteúdo
  • Cadastre-se

dev botao

  • Este tópico foi criado há 2005 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Postado

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.

  • Curtir 1
  • Consultores
Postado
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.

  • Curtir 1

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
  • Membros Pro
Postado (editado)

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

image.png.62c99ffaabc11ae3cb5dacaf17a9d04c.png

Qual número é o da Sefaz-GO?

Editado por ifaster
  • Curtir 1
Postado

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.

  • Curtir 2
  • Obrigado 1
  • Moderadores
Postado
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):
  • valid.pngParser XML: Nenhum erro encontrado
  • valid.pngTipo de Mensagem: NF-e sem assinatura digital
  • valid.pngSchema XML: Nenhum erro encontrado
  • ico_menos.giferro.pngNF-e 52190600024281000112550010000000911000012024
    • alerta.png Mensagem não assinada
    • erro.pngRegras de Negócio [Ambiente de Produção] 3 erros de validação
      • bullet_black.png202 - [Simulacao] Rejeicao: Falha no reconhecimento da autoria ou integridade do arquivo digital
      • bullet_black.png506 - [Simulacao] Rejeicao: Data de Saida menor que a Data de Emissao
      • bullet_black.png564 - [Simulacao] Rejeicao: Total do Produto / Servico difere do somatorio dos itens

 

  • Obrigado 1
Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Postado

@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.

  • Obrigado 1
  • Membros Pro
Postado

@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

  • Curtir 1
Postado

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
 

Postado (editado)
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 por Sandro TC
Postado
4 minutos atrás, Fabrício G. Araújo disse:

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

image.png.a27a663386e526376e638b97f99adb7e.png

@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.

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

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

image.png.a27a663386e526376e638b97f99adb7e.png

@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.

  • Moderadores
Postado
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.

  • Obrigado 2


logoacbr.pngConheça o Portal do Projeto ACBr

Ajude o Projeto ACBr crescer - Assine o SAC ACBr
Assine um dos planos de longa duração do SAC ACBr, obtenha Descontos Especiais, Parcele no Cartão e ainda ganhe Brindes Exclusivos. Saiba mais aqui

Conheça o ACBrLib, o ACBr de forma nativa para qualquer linguagem de programação. Saiba mais aqui

 

 

 

 

Postado
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. :-)

  • Obrigado 1
  • Moderadores
Postado

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

 

  • Curtir 1


logoacbr.pngConheça o Portal do Projeto ACBr

Ajude o Projeto ACBr crescer - Assine o SAC ACBr
Assine um dos planos de longa duração do SAC ACBr, obtenha Descontos Especiais, Parcele no Cartão e ainda ganhe Brindes Exclusivos. Saiba mais aqui

Conheça o ACBrLib, o ACBr de forma nativa para qualquer linguagem de programação. Saiba mais aqui

 

 

 

 

  • Este tópico foi criado há 2005 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...