Jump to content
Notícias do ACBr

click.png click.png click.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

Codigo de Hash no QR-Code difere do calculado


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

Recommended Posts

  • Consultores

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

Consultor SAC ACBr Juliomar Marchetti
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

skype: juliomar
telegram: juliomar
http://www.juliomarmarchetti.com.br
Embarcadero MVP
Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Membros Pro

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

  • Like 1

Gabriel Rodrigues Da Costa Neto

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 11 months later...
  • Consultores
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
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

skype: juliomar
telegram: juliomar
http://www.juliomarmarchetti.com.br
Embarcadero MVP
Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil
Link to comment
Share on other sites

  • 1 month later...
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!

 

Link to comment
Share on other sites

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.