Problema de Encoding Betha e IPM - 2

[Diogo Loff]

Oi bom dia, eu fiz um tópico sobre um problema que estou tendo com Encoding na Betha e IPM, alguem poderia me ajudar?

Abri este outro tópico pois o original por algum motivo aqui na minha maquina não esta abrindo e não consigo ver.

 

[Juliomar Marchetti]

Boa tarde

não é só na sua máquina em todas.

é algo com o forum que já está sendo trabalhando para resolver

em um primeiro momento diria para remover a opção de colocar acentuações nos campos e irá funcionar

[Diogo Loff]

Boa tarde, então como fiz no relato ali no chamado original, que não esta dando de abrir, a questão não é do meu sistema e sim da prefeitura, vou tentar sintetizar novamente.

 

O problema ocorre quando pegamos um cliente novo por exemplo que emitia NFSe diretamente pelo porta seja da Betha ou do IPM de sua prefeitura. Lá dentro tem o cadastro dos tomadores também, ocorre que muitos destes cadastros tem acentuação e qual o problema que ocorre.

Empresa passa a emitir a NFSe pelo sistema, no sistema envia tudo sem acentuação tudo certo no RPS, porem o cadastro do tomador já foi feito anteriormente lá na prefeitura com acentuação, quando volta a NFSe ela esta vindo com os dados deste cadastro de lá e não com o que foi enviado. E assim acontece o erro, o RPS validou mas para o sistema não pois supostamente deu um erro e o mesmo fica ali preso.

Ocorre que estive vendo no fonte do ACBrNFSeX e lá quando recebe o retorno tem uma conversão para UTF8 e ali acontece o problema, mas não estou dizendo que o ACBr esteja errado queria ver como contornar isto, vendo o arquivo gerado pela prefeitura se removido esta validação, o mesmo no cabeçalho do XML esta UTF-8, porem se abir o arquivo em um editor como Notepad++ o mesmo esta como ISO8891, então acontece uma incosistencia aqui, imagino que é erro destes sistemas, mas é complicado demais, pois tanto a Betha como a IPM solicitam que seja a prefeitura que solicite a verificação, já tentamos reclamar mas esta bem complicado.

 

Qual a solução no momento, sempre que acontece isto pedimos ao nosso cliente entrar no site da prefeitura e corrigir o cadastro do tomador lá dentro, assim tem resolvido o problema, porem gera outro muita reclamação do cliente de ter que estar arrumando cadastros, então queria ver se tem mais alguem passando por isto e se tem como achar uma alternativa a resolver isto pelo componente?

[Juliomar Marchetti]

Sim tenho a mesma situação com clientes.
mas vejo também que precisaria resolver para funcionar

esse é o preço que as vezes pagamos pra manter compatível com versões antigas do delphi

 

[Diogo Loff]

Bom dia, Juliomar!

 

Certo então não imaginava que é algo em relação a manter versões antigas, pois ao meu ver a propria prefeitura esta mandando o arquivo em formato errado, bom eu vou esperar se surge alguma ideia ou solução, enquanto isto vou continuar a indicar o caminho para o cliente corrigir na prefeitura.

[Italo Giurizzato Junior]

Boa tarde @Diogo Loff,

Qual é a cidade que esta ocorrendo o erro de UTF-8 com o provedor Betha e com o provedor IPM?

No caso do IPM foi feita uma alteração na função TratarXmlRetornado visando converter o XML retornado para UTF-8.

[Diogo Loff]

Betha: Cocal do Sul/SC

IPM: Morro da Fumaça/SC

 

Sobre o componente o mesmo esta atualizado, até o meu relato aqui coloquei os dois exemplos mas da IPM já tem um mês por ai que não tem mais acontecido mesmo. Acabei de olhar no fonte e realmente você mudaram ali no retorno. Até conversei agora com o suporte para confirmar e realmente no IPM não esta mais ocorrendo, só esta acontecendo com Betha.

Aqui no exemplo é Cocal do Sul na Betha, provavelmente deve acontecer em qualquer municipio do Betha que tenha a mesma situação, pois pegamos um cliente recente ali quase cada nota que emite é este erro ai.

Talvez aplicar a mesma correção do IPM no caso da Betha possa resolver.

[Italo Giurizzato Junior]

@Diogo Loff,

Apliquei a mesma alteração feita no IPM no Betha, como a cidade mencionada usa a versão 1.00, a alteração foi realizada no TratarXmlRetornado para esta versão.

Caso o problema ocorra em outra cidade que use a versão 2.02 vai ser necessário fazer a mesma coisa.

Ficou da seguinte forma a alteração:

function TACBrNFSeXWebserviceBetha.TratarXmlRetornado(
  const aXML: string): string;
begin
  Result := ConverteANSIparaUTF8(aXML);
  Result := RemoverDeclaracaoXML(Result);

  Result := inherited TratarXmlRetornado(Result);

  Result := StringReplace(Result, '&', '\s\n', [rfReplaceAll]);
  Result := ParseText(Result);
  Result := RemoverPrefixosDesnecessarios(Result);
  Result := RemoverCaracteresDesnecessarios(Result);
end;

Faça essa alteração na unit Betha.Provider, reinstale o ACBr e faça novos testes.

Caso resolva o problema me avise que eu enviarei para o SVN.

[Diogo Loff]

Certo @Italo Giurizzato Junior hoje não consigo mais, mas vou ver se amanhã já aplico esta adequação, e gero uma versão para o cliente que esta com bastante problemas. Ai solicito para o pessoal do suporte acompanhar e observar.

 

Dando uma semana +/- eu responto os resultados.

 

Obrigado.

[Diogo Loff]

Boa tarde @Italo Giurizzato Juniorentão ja adequei aqui, já colocamos no cliente e não deu mais problema.

 

Somente uma coisa ficou estranha nos XMLs que tem estes casos é conforme o print abaixo.

 

Pra nós não é um problema, mas ficou estranho, nestes casos é assim mesmo?

[Italo Giurizzato Junior]

Bom dia @Diogo Loff,

Somente o XML esta assim ou a impressão também esta dessa forma?

Ao abrir esse XML com o bloco de notas ele indica qual codificação (ANSI ou UTF-8)?

[Diogo Loff]

Somente o XML esta assim ou a impressão também esta dessa forma? Então para mim esta somente no XML, pois a impressão eu refaço sempre tenho uma customizada que monta com as informações completas, pois não uso XML de retorno, do mesmo só pego algumas informações, como a chave por exemplo. Então no meu caso sim a impressão sai certa, mas acredito que se utilizasse o XML daria problema, pois até fiz um debug para só tirar a duvida e as variaveis ficam preenchidas com caracteres estranhos.

 

Ao abrir esse XML com o bloco de notas ele indica qual codificação (ANSI ou UTF-8)? UTF-8 e no bloco de notas no lugar ali destas ???? aparece uns quadradinhos.

[Italo Giurizzato Junior]

Boa tarde @Diogo Loff,

Configure o componente para salvar os arquivos soap.

Faça um novo teste e anexe ele aqui no fórum ou envie por mensagem privada para mim o arquivo soap de retorno para que eu possa analisar.

Desde já muito obrigado pela colaboração.

[Diogo Loff]

Oi @Italo Giurizzato Juniorentão como eu faço para configurar para gerar os dados Soap? Qual propriedade do ACBrNFSeX é?

[Diogo Loff]

To fazendo uns testes aqui e agora até as mensagens estão ficando todas atravessadas, por exemplo duplicação de RPS.

 

Este é a string que esta sendo passada na rotina ConverteANSIparaUTF8, antes de converter. Depois de convertido fica cheio de ?????.

'<env:Envelope xmlns:env=''http://schemas.xmlsoap.org/soap/envelope/''><env:Header></env:Header><env:Body><ns2:ConsultarSituacaoLoteRpsEnvioResponse xmlns:ns2=''http://www.betha.com.br/e-nota-contribuinte-ws''><ConsultarSituacaoLoteRpsResposta><ListaMensagemRetorno><MensagemRetorno><Codigo>E10</Codigo><Mensagem>RPS já informado.</Mensagem><Correcao>Para essa Inscrição Municipal/CNPJ já existe um RPS informado com o mesmo número, série e tipo.</Correcao></MensagemRetorno></ListaMensagemRetorno></ConsultarSituacaoLoteRpsResposta></ns2:ConsultarSituacaoLoteRpsEnvioResponse></env:Body></env:Envelope>'

 

No sistema acaba ficando assim.

 

[Diogo Loff]

Boa tarde senhores, então estou aqui debugando um pouco mais e sinceramente não estou entendendo o que acontece na Betha.

 

Por exemplo removido o código de forçar a conversão que o Italo, passou, neste caso as mensagens voltaram a ficar corretas, porem acontece o ERRO do inicio deste tópico de não entender o XML.

Sem a questão de forçar a conversão, dentro da string que retorna, antes de começar o "TratarXmlRetornado" no da mensagem por exemplo temos a palavra "INSCRIÇÃO" e no XML da NFSe temos a paravra por exemplo ESTAÇÃO.

 

Na string da mensagem o ÇÂO esta representado por Ã§Ã£o.

Na string da NFSe o ÇÂO esta representado por Ã'#$0087'Ã'#$0083'O

 

Na da mensagem que não precisa de nenhum tipo de tratamento, com o fonte sem alteração, a mesma converte correto.

Na do XML da NFSe sem alteração o mesmo nem aceita pois da uma exceção dentro de um procedimento "TACBrXmlDocument.LoadFromXml" que basicamente diz que não reconhece o texto.

Se força a conversão, não temos mais o erro do XML, porem ele fica todo estranho com ????, e no caso das mensagens elas também passam a ficar com ????.

 

Anexo ambos exemplos, peguei a informação da variavel FRetorno após EnviarDados e antes do SalvarRetornoWebService na função "TACBrNFSeXWebservice.Executar".

Retorno XML Mensagem.txt Retorno XML NFe.txt

[Italo Giurizzato Junior]

Boa tarde @Diogo Loff,

Eu preciso do XML salvo pelo componente e não a captura do mesmo como você fez.

Se for o caso faça um teste usando o programa exemplo do componente.

Configure o componente para salvar os arquivos soap.

Faça 2 testes, um sem a minha alteração e o outro com a minha alteração.

Anexe o XML retorno soap de cada teste para que eu possa checar o que esta ocorrendo.

[Diogo Loff]

Segue anexo fiz os dois exemplos diretamente no programa de testes.

 

Um detalhe que não falei, é que estes testes é em produção que estou fazendo, pois só neste que tenho esta situação.

Sem alteração que você sugeriu inclusive da erro no programa, que o XML retornou vaziu.

XML sem Alteração.zip XML com Alteração.zip

E mais alguns detalhes com os debugs que fiz, pelo que vi a conversão que você sugeriu talvez não seria necessária, me parece que tem algo lá no parse "Result := ParseText(Result);" dentro do "TratarXmlRetornado", dentro dele esta entrando na primeira condição, ele esta convertendo ali corretamente para NativeString, e depois quando percorre os caracteres ali que meio que alguma coisa não faz certo, quando no final transforma novamente para UTF8 esta diferente.

 

Bom obrigado pela atenção por enquanto.

[Italo Giurizzato Junior]

Bom dia @Diogo Loff,

Teste que eu fiz:

1. Na função:  function TACBrNFSeXWebserviceBetha.TratarXmlRetornado fiz com que ele carrega-se para uma variável string o retorno da consulta.

2. Removi as linha que faziam a conversão para UTF-8, pois analisando o arquivo de retorno do webservice ele já esta em UTF-8.

3. "Debuguei" a função mencionada acima e a procedure procedure TACBrNFSeProviderABRASFv1.TratarRetornoConsultaNFSeporRps que se encontra na unit ACBrNFSeXProviderABRASFv1.

4. Em nenhum momento ocorreu erro de UTF-8, pelo contrario a leitura ocorreu com sucesso o XML da nota foi extraído do retorno, salvo em disco.

5. Solicitei a impressão do DANFSE com a carga do XML da NFS-e, tanto a leitura do XML quanto da geração do DANFSE ocorreu com sucesso.

A questão agora é: será que tem algum serviço do provedor cujo retorno não esta em UFT-8?

O retorno do ConsultarNFSePorRps esta Ok.

Se algum retorno não esta em UTF-8 vai ser necessário entrar em contato com o provedor e solicitar a padronização.

[Diogo Loff]

Bom dia @Italo Giurizzato Junior não entendi também como você conseguiu fazer sem nenhuma modificação.

 

No exemplo com o programa de exemplo do ACBrNFSeX conforme coloquei no print, se efetuar a consulta com os dados especificos daquela NFSe acontece erro, observar que no programa exemplo da "X201 Webserver Retornou um XML vaziu".

 

Vou fazer um video aqui mostrando sem nenhuma adequação para lhe enviar, acho que é mais facil.

[Diogo Loff]

Boa tarde @Italo Giurizzato Junior fiquei muito encucado com o que você passou. Fui testar por via das duvidas em outra maquina e funcionou.

Acabei descobrindo uma coisa no menu Delphi esta configurado o CodePage como 28591, e em outros delphis aqui da empresa esta 1252. E não sei o porque, no fim estou a um bom tempo batendo cabeça com isto e é uma configuração do Delphi.

E porque acontece no cliente, ocorre que as releases são justamente geradas da minha maquina, eu sou responsável pelas releases.

Que loucura meu.

 

Bom valeu ai, no fim gerei uma perda de tempo sem tamanho, aqui e para vcs ali....

[Italo Giurizzato Junior]

Boa tarde @Diogo Loff,

Com o Delphi configurado com o CodePage 1252 o problema foi sanado, correto?

Sendo assim posso fechar o tópico?

[Diogo Loff]

Sim foi. Pode encerrar.

[Alexandre de Paula]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.