Ir para conteúdo
  • Cadastre-se

dev botao

ACBrNFSeX Fortaleza Erro Input is not proper UTF-8, indicate encoding ! Bytes


Ver Solução Respondido por Italo Giurizzato Junior,
  • Este tópico foi criado há 849 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro
Postado

Bom dia!

Pesquisei no fórum e achei alguns tópicos falando deste erro em outros provedores e todos pelo que vi foram liberados atualizações do componente.

Estou utilizando o ACBRNFSeX para o provedor ISSFortaleza - Versão 1.0.
Esta enviando corretamente e inclusive incluindo a NFS-e no site da prefeitura, somente a consulta ocorre o erro mencionado.

Estou com o componente atualizado.

Alguém poderia me dar uma dica de como resolver?

Obrigado.

  • Administradores
Postado

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

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

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

  • Moderadores
Postado
20 minutos atrás, Patrick Knopf disse:

Segue os dois arquivos gerados.

Obrigado.

177872212-con-lot-soap.xml 4 kB · 0 downloads 177872212-lista-nfse-con-lot-soap.xml 5 kB · 0 downloads

Pelo que vi o Bairro tem o Ç "ALTO DA BALANÇA".

Marca a opção para remover caracteres acentuados e tenta fazer novamente

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
 

 

  • Membros Pro
Postado

Não sei se ajuda mais o erro ocorre na função na imagem anexo.

Fiz uma alteração utilizando uma função que tenho para remover acentos e deu certo, conforme linha abaixo:

Esta assim:
loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument)));
Alterei para:
loadedDoc := xmlParseDoc(PAnsiChar(ansistring(RemoveAcentos(AXmlDocument))));

Com isso resolveu, mais se puderem ajustar no componente agradeço.

Captura de Tela 2022-09-26 às 10.05.57.png

  • Consultores
Postado

Bom dia Patrick,

O que tudo indica o problema é a razão social do prestador, veja:

<RazaoSocial>R & S SERVICOS AUTOMOTIVOS LTDA ME</RazaoSocial>

Quando o componente executa o Parte temos o seguinte:

<RazaoSocial>R &amp; S SERVICOS AUTOMOTIVOS LTDA ME</RazaoSocial>

Para mim é esse &amp; que sobra na razão social que esteja gerando o erro.

Não entendo essa mania de empresas usarem o "&" na razão social.

Acham que fica chique.

  • Haha 1
Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • Membros Pro
Postado

Italo, a função que utilizei "RemoveAcentos" função interna nossa, remove somente os acentos e não o & (E comercial) e não ocorreu mais o erro. Acredito que não seja ele o problema não, me parece ser o Ç do bairro mesmo.

Até tentei alterar no site da prefeitura o cadastro do cliente mas não é permitido, somente com a prefeitura mesmo.

Com a minha função de remover os acentos estou enviando, consultado e cancelamento normalmente.

  • Consultores
Postado

Bom dia Patrick,

Analisando o arquivo XML de retorno que você anexou, apesar de constar que o encoding é UTF-8 na realidade ele está no formato ANSI.

O componente ao tentar ler esse arquivo encontra a letra Ç (cedilha) e acaba gerando o erro.

O correto seria o provedor gerar o XML em UTF-8 em vez de ANSI.

Desta forma não teríamos nenhum problema com a letra Ç (cedilha).

Eu acredito que o provedor se recusaria a fazer essa correção, mas não custa nada tentar.

Caso eles façam, maravilha, problema resolvido.

Se recusarem, uma segunda abordagem seria solicitar a troca do Ç (cedilha) por C no nome do bairro do cadastro do prestador.

Além do formato do arquivo estar em desacordo com o encoding a sua geração também está misturada, veja:

&lt;Numero>304&lt;/Numero>

Ao meu ver o XML deve ser gerado desta forma:

&lt;Numero&gt;304&lt;/Numero&gt;

ou

<Numero>304</Numero>

Sem contar que o XML contém quebras de linhas e está identado.

Resumindo:

Acho muito importante que tudo isso que vou levantado a respeito do XML gerado por eles seja comunicado, pois da forma que esta, está muito feio, para não dizer outra coisa.

  • Curtir 1
Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • 2 semanas depois ...
×
×
  • 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...
The popup will be closed in 10 segundos...