Ir para conteúdo
  • Cadastre-se

dev botao

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

Recommended Posts

Postado

Olá a todos. Hoje (Aqui no Estado da PB) eu não mais consegui emitir a NFC-e, pois em todos os meus clientes deu este erro: Codigo de Hash no QR-Code difere do calculado.
Alguém poderia me ajudar por favor?

Desde já agardeço toda ajuda, pois, sou iniciante.

Postado
2 minutos atrás, Juliomar Marchetti disse:

Verificou os códigos deles senão precisa gerar novamente ou se eles mudaram algo!

Juliomar, ao que percebi, o URL indicado por eles está correto. Também verifiquei o CSC e Tokken e estão corretos.
Eu não sei como é validado este QR-CODE
Este é o link que informa a mudança que houve:
https://www.receita.pb.gov.br/ser/view-docs?task=document.viewdoc&id=454

Postado

@RONALDO NASCIMENTO

Estávamos com o mesmo problema, resolvemos da seguinte maneira:

1.No nosso caso a arquivo ACBrNFeServicos.ini estava desatualizado no cliente, fizemos a atualização e resolveu a rejeição 395 Endereco do site da UF da consulta via QR-Code diverge do previsto;

 

2. Para a  rejeição 464 Codigo de Hash no QR-Code difere do calculado, solicitamos ao contador do cliente a geração de um novo CSC, este foi gerado com "-" e ID 000002, alteramos e conseguimos emitir;

1 minuto atrás, Concentro disse:

@RONALDO NASCIMENTO

Estávamos com o mesmo problema, resolvemos da seguinte maneira:

1.No nosso caso a arquivo ACBrNFeServicos.ini estava desatualizado no cliente, fizemos a atualização e resolveu a rejeição 395 Endereco do site da UF da consulta via QR-Code diverge do previsto;

 

2. Para a  rejeição 464 Codigo de Hash no QR-Code difere do calculado, solicitamos ao contador do cliente a geração de um novo CSC, este foi gerado com "-" e ID 000002, alteramos e conseguimos emitir;

@Juliomar Marchetti existem mais 2 tópicos com este mesmo problema posso dar a mesma resposta ou jogar o link da minha resposta?

  • Curtir 1
Postado
13 minutos atrás, Concentro disse:

@RONALDO NASCIMENTO

Estávamos com o mesmo problema, resolvemos da seguinte maneira:

1.No nosso caso a arquivo ACBrNFeServicos.ini estava desatualizado no cliente, fizemos a atualização e resolveu a rejeição 395 Endereco do site da UF da consulta via QR-Code diverge do previsto;

 

2. Para a  rejeição 464 Codigo de Hash no QR-Code difere do calculado, solicitamos ao contador do cliente a geração de um novo CSC, este foi gerado com "-" e ID 000002, alteramos e conseguimos emitir;

@Juliomar Marchetti existem mais 2 tópicos com este mesmo problema posso dar a mesma resposta ou jogar o link da minha resposta?

amigo vc tentou adicionar os "-" no CSC que ja estava cadastrado?

Gabriel Rodrigues Da Costa Neto

Postado
13 minutos atrás, Concentro disse:

@RONALDO NASCIMENTO

Estávamos com o mesmo problema, resolvemos da seguinte maneira:

1.No nosso caso a arquivo ACBrNFeServicos.ini estava desatualizado no cliente, fizemos a atualização e resolveu a rejeição 395 Endereco do site da UF da consulta via QR-Code diverge do previsto;

 

2. Para a  rejeição 464 Codigo de Hash no QR-Code difere do calculado, solicitamos ao contador do cliente a geração de um novo CSC, este foi gerado com "-" e ID 000002, alteramos e conseguimos emitir;

@Juliomar Marchetti existem mais 2 tópicos com este mesmo problema posso dar a mesma resposta ou jogar o link da minha resposta?

Olá @Concentro, muito obrigado pelas informações. Eu solicitei um CSC novo hoje pela manhã ao contador. Mas ainda assim está dando o erro. Vou ver se é o arquivo ACBrNFeServicos.ini que você falou. Mas, não lembro de usar ele na minha aplicação.

Postado
6 minutos atrás, RONALDO NASCIMENTO disse:

Amigos eu agradeço demais a todos pela ajuda que me fora dada. O problema aparentemente foi solucionado após eu colocar o CSC no formato exato enviado pela Sefaz (00000000-0000-0000-00000000). Fazendo isso, ele voltou a emitir normalmente. Mais uma vez muito obrigado aos amigos @Concentro, @Juliomar Marchetti.

aqui nao deu certo assim ronaldo, so consegui com um novo CSC!

  • Curtir 1

Gabriel Rodrigues Da Costa Neto

Postado
1 hora atrás, gabriellc disse:

deu e nao deu, aff velho ja to doido aqui,

 

troquei o CSC emiti 3 notas foi normal, quando fui emitir a quarta deu o mesmo erro novamente

Complicado viu @gabriellc. Parece até que fazem questão de complicar nossa vida. E cada vez fica mais difícil. Mas vai da certo cara.

Postado

Boa Noite colegas,

Estive acompanhando este problema desde do dia 01/02 quando a SEFAZ PB começou esta validação. Passei pelos mesmos problemas citados e procurando soluções eis que relato os seguintes acontecimentos:

1 - Minha aplicação captura o CSC do banco de dados através da query diferente de alguns sistemas que capturam de um ini ou txt na pasta da aplicação. O que percebi é que em alguns momentos ao executar a query e preencher o componente este recebe o CSC mas em modo debug o mesmo CSC recebe caracteres ANSII #$AD no lugar do "-" o que gera o cstat 464.

2 - O ACBR não tem nenhum problema uma vez que, para alguns clientes funciona e em outras não, provando que se fosse o mesmo não funcionaria em momento algum e em nenhum cliente.

3 - Aplicações que usam o INI para passar o parâmetro ao componente não tem esse problema porque não gera o ASCII (Não sei explicar porque)

Para contornar o problema e pode até ser considerada como uma "gabi" mas aqui resolveu 100% em todos meus clientes sendo eles com o "-" ou sem.

Passos:

1 - Armazeno a o CSC que vem na query do banco de dados em uma string

2 - Uso uma função para retirar todos os caracteres ANSII inclusive o "-"

3 - Com a string "Limpa" faço ainda um Uppercase para tornar tudo em caixa alta para garantir o padrão

4 - Aplico a formatação nativa do CSC sendo 00000000-0000-0000-0000-000000000000 adicionando denovo o "-"

4 - Agora o massete, preencho o componente com a string já formatada conforme padrão nativo da SEFAZ antes do GeraNFe, Valida, Assina etc...

OBS: Não adianta preencher o componente na inicialização pois os códigos ANSII insistem estar junto com o CSC no mesmo e percebam que retiro e coloco o "-" mas também não obtive sucesso deixando ele no passo 2, então retirando e recolocando resolveu e além disso não preciso ter que ficar preocupado se o CSC do cliente está ou não no formato padrão e com ou sem o "-".

Bem é isso, desculpe aos colegas se faltou alguma ressalva, mas por aqui resolveu assim. A quem quiser repasso as funções usadas é só pedir!

Abraço aos amigos da PB!

Espero ter ajudado!

Postado
Em 03/02/2017 at 22:50, LIDERNetwork disse:

Boa Noite colegas,

Estive acompanhando este problema desde do dia 01/02 quando a SEFAZ PB começou esta validação. Passei pelos mesmos problemas citados e procurando soluções eis que relato os seguintes acontecimentos:

1 - Minha aplicação captura o CSC do banco de dados através da query diferente de alguns sistemas que capturam de um ini ou txt na pasta da aplicação. O que percebi é que em alguns momentos ao executar a query e preencher o componente este recebe o CSC mas em modo debug o mesmo CSC recebe caracteres ANSII #$AD no lugar do "-" o que gera o cstat 464.

2 - O ACBR não tem nenhum problema uma vez que, para alguns clientes funciona e em outras não, provando que se fosse o mesmo não funcionaria em momento algum e em nenhum cliente.

3 - Aplicações que usam o INI para passar o parâmetro ao componente não tem esse problema porque não gera o ASCII (Não sei explicar porque)

Para contornar o problema e pode até ser considerada como uma "gabi" mas aqui resolveu 100% em todos meus clientes sendo eles com o "-" ou sem.

Passos:

1 - Armazeno a o CSC que vem na query do banco de dados em uma string

2 - Uso uma função para retirar todos os caracteres ANSII inclusive o "-"

3 - Com a string "Limpa" faço ainda um Uppercase para tornar tudo em caixa alta para garantir o padrão

4 - Aplico a formatação nativa do CSC sendo 00000000-0000-0000-0000-000000000000 adicionando denovo o "-"

4 - Agora o massete, preencho o componente com a string já formatada conforme padrão nativo da SEFAZ antes do GeraNFe, Valida, Assina etc...

OBS: Não adianta preencher o componente na inicialização pois os códigos ANSII insistem estar junto com o CSC no mesmo e percebam que retiro e coloco o "-" mas também não obtive sucesso deixando ele no passo 2, então retirando e recolocando resolveu e além disso não preciso ter que ficar preocupado se o CSC do cliente está ou não no formato padrão e com ou sem o "-".

Bem é isso, desculpe aos colegas se faltou alguma ressalva, mas por aqui resolveu assim. A quem quiser repasso as funções usadas é só pedir!

Abraço aos amigos da PB!

Espero ter ajudado!

faz todo sentido sua explicacao, quanto ao item 3 - Aplicações que usam o INI para passar o parâmetro ao componente não tem esse problema porque não gera o ASCII (Não sei explicar porque), 

na minha aplicacao pego direto do ini exatamente como é no demo do ACBR, e sempre retorna o erro 464, fiz uma modificacao no fonte acbr para pegar diretamente o campo CSC do ini, e esta funcionando, se eu deixo o fonte do ACBR como é pegando o CSC do componente carregado, sempre sempre retornar o erro 464.

 

Gabriel Rodrigues Da Costa Neto

  • 11 meses depois ...
  • Moderadores
Postado
3 horas atrás, SMITH PROGRAMMER disse:

Alguem conseguiu ? Estou com o mesmo problema aqui no GOIAS assim ja verifiquei tudo. Como CSC igual ao da sefaz. Dentre outras coisas

Caso não tenha lido as regras do fórum favor ler!

poste em um local e aguarde.

 

Consultor SAC ACBr Juliomar Marchetti
 

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Transparent-02.png
 

 

  • 1 mês depois ...
Postado
Em 03/02/2017 at 22:50, LIDERNetwork disse:

Boa Noite colegas,

Estive acompanhando este problema desde do dia 01/02 quando a SEFAZ PB começou esta validação. Passei pelos mesmos problemas citados e procurando soluções eis que relato os seguintes acontecimentos:

1 - Minha aplicação captura o CSC do banco de dados através da query diferente de alguns sistemas que capturam de um ini ou txt na pasta da aplicação. O que percebi é que em alguns momentos ao executar a query e preencher o componente este recebe o CSC mas em modo debug o mesmo CSC recebe caracteres ANSII #$AD no lugar do "-" o que gera o cstat 464.

2 - O ACBR não tem nenhum problema uma vez que, para alguns clientes funciona e em outras não, provando que se fosse o mesmo não funcionaria em momento algum e em nenhum cliente.

3 - Aplicações que usam o INI para passar o parâmetro ao componente não tem esse problema porque não gera o ASCII (Não sei explicar porque)

Para contornar o problema e pode até ser considerada como uma "gabi" mas aqui resolveu 100% em todos meus clientes sendo eles com o "-" ou sem.

Passos:

1 - Armazeno a o CSC que vem na query do banco de dados em uma string

2 - Uso uma função para retirar todos os caracteres ANSII inclusive o "-"

3 - Com a string "Limpa" faço ainda um Uppercase para tornar tudo em caixa alta para garantir o padrão

4 - Aplico a formatação nativa do CSC sendo 00000000-0000-0000-0000-000000000000 adicionando denovo o "-"

4 - Agora o massete, preencho o componente com a string já formatada conforme padrão nativo da SEFAZ antes do GeraNFe, Valida, Assina etc...

OBS: Não adianta preencher o componente na inicialização pois os códigos ANSII insistem estar junto com o CSC no mesmo e percebam que retiro e coloco o "-" mas também não obtive sucesso deixando ele no passo 2, então retirando e recolocando resolveu e além disso não preciso ter que ficar preocupado se o CSC do cliente está ou não no formato padrão e com ou sem o "-".

Bem é isso, desculpe aos colegas se faltou alguma ressalva, mas por aqui resolveu assim. A quem quiser repasso as funções usadas é só pedir!

Abraço aos amigos da PB!

Espero ter ajudado!

 

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

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • 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...