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á 763 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.