Quebra de Linha - CCe de NFe

[Diego Foliene]

Bom dia.

Efetuado um teste registrando uma carta de correção com config definida como true e como false. Em ambos os casos foi registrada com sucesso.

Removida a linha 908 que chumba a configuração como True na revision 35117

[MarcosRWeimer]

Atualizado para a revision 35117, respeitou o parâmetro mas no XML está indo com a acentuação toda errada:

 

Print ANTES e DEPOIS do NativeStringToUTF8 (ACBrNFeWebServices)

 

 

Ao enviar

 

 

[Diego Foliene]

20 minutes ago, MarcosRWeimer said:

Atualizado para a revision 35117, respeitou o parâmetro mas no XML está indo com a acentuação toda errada:

 

Print ANTES e DEPOIS do NativeStringToUTF8 (ACBrNFeWebServices)

 

 

Ao enviar

 

 

Isso é o valor no watch list do Delphi e está relacionado a codificação nativa da própria IDE.

Veja se no arquivo XML de fato está correto.

Em anexo um XML de carta de correção que transmiti com caracteres acentuados(ocultei algumas informações).

 

11011035240818XXXXXXXXXX3955003000000007145776201506-procEventoNFe.xml

[MarcosRWeimer]

Ao fundo o seu arquivo (anexo no seu comentário, na frente o arquivo gerado aqui

 

 

Ambos tem a mesma codificação mas a acentuação fica com problemas.

 

A impressão (que carrega o xml do evento) tambem fica com problemas

 

 

 

 

[MarcosRWeimer]

Tem uma thread antiga sobre o assunto, mas não tem resposta de solução:

 

[Diego Foliene]

Verificando, enquanto não houver uma resolução definitiva, por favor, defina a opção para RetirarAcentos com o valor True.

[Diego Foliene]

Por favor:

• Qual é a versão da IDE que está utilizando?
• Este seu arquivo XML é o que foi gerado automaticamente pelo componente ou você armazenou a string e salvou por conta?
• Você possui modificações locais em seus fontes?
• Qual é a codificação dos arquivos em seus fontes?

Fiz novos testes em meu ambiente.

Realmente, nas linhas mencionadas a string fica como demonstrada, mas testando em meu ambiente, o XML salvo pelo componente fica com a string correta. Consultando a nota no portal de homologação também está correta a string.

Precisamos entender qual se há alguma diferença ou particularidade que resultou na geração desses arquivos de forma diferente.

[MarcosRWeimer]

Ola!

- Delphi 11.3

- Xml Gerado pelo componente, pego a string e salvo usando o próprio acbr:

procedure TNFeBase.SalvarXML;
var
  LCaminho: string;
  LXML: string;
  LIsUTF8: Boolean;
begin
  LCaminho := GetCaminhoXMLPDF(False);

  if FACBrNFe.EventoNFe.Evento.Count > 0 then
    LXML := String(FACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML)
  else if (not FACBrNFe.WebServices.Inutilizacao.XML_ProcInutNFe.IsEmpty) then
    LXML := FACBrNFe.WebServices.Inutilizacao.XML_ProcInutNFe
  else
    LXML := FACBrNFe.NotasFiscais.Items[0].XML;

  if LXML.IsEmpty then
    Exit;

  LIsUTF8 := LXML.ToLower.Contains('<signature'); //ACBrDFeUtil.XmlEstaAssinado
  FACBrNFe.Gravar(LCaminho, LXml, '', LIsUTF8);
end;

 

- Não possuo modificações locais no fonte

- A codificação do fonte é ANSI

 

[Diego Foliene]

18 hours ago, MarcosRWeimer said:

Ola!

- Delphi 11.3

- Xml Gerado pelo componente, pego a string e salvo usando o próprio acbr:

procedure TNFeBase.SalvarXML;
var
  LCaminho: string;
  LXML: string;
  LIsUTF8: Boolean;
begin
  LCaminho := GetCaminhoXMLPDF(False);

  if FACBrNFe.EventoNFe.Evento.Count > 0 then
    LXML := String(FACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML)
  else if (not FACBrNFe.WebServices.Inutilizacao.XML_ProcInutNFe.IsEmpty) then
    LXML := FACBrNFe.WebServices.Inutilizacao.XML_ProcInutNFe
  else
    LXML := FACBrNFe.NotasFiscais.Items[0].XML;

  if LXML.IsEmpty then
    Exit;

  LIsUTF8 := LXML.ToLower.Contains('<signature'); //ACBrDFeUtil.XmlEstaAssinado
  FACBrNFe.Gravar(LCaminho, LXml, '', LIsUTF8);
end;

 

- Não possuo modificações locais no fonte

- A codificação do fonte é ANSI

 

Bom dia.

Obrigado pelas informações.

Com elas podemos atuar em uma correção mais assertiva.

[Diego Foliene]

Boa tarde @MarcosRWeimer.

Foi enviada uma alteração no SVN visando resolver a questão.

Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

[MarcosRWeimer]

Ola!

 

Salvou corretamente

mas na hora de carregar o XML para impressão:

[Diego Foliene]

34 minutes ago, MarcosRWeimer said:

Ola!

 

Salvou corretamente

mas na hora de carregar o XML para impressão:

Por favor, adicione as dlls deste LINK, escolhendo de acordo com arquitetura que você compila a sua aplicação e não a arquitetura do SO, na mesma pasta do seu .EXE;

Peço que faça também um teste com o programa exemplo do ACBrNFe.

Eu fiz um teste em meu ambiente e não tive o problema.

Se você também não tiver o mesmo problema testando com o exemplo, então podemos reduzir o problema a rotina que você utiliza de diferente em sua aplicação e verificar qual pode ser a causa do problema.

 

[MarcosRWeimer]

Substituindo as DLLs

 

 

Gerando pelo programa exemplo (com as DLLs da pasta do acbr, as que forneceu acontece o mesmo erro acima), autoriza a CCe com acentuação, grava com a acentuação mas na hora de imprimir acontece o mesmo problema"'Input is not proper UTF-8, indicate encoding ! Bytes: 0xE7 0xE3 0x6F 0x20"

[Diego Foliene]

Bom dia!

Outra questão que também vale conferir.

Por favor, você manipula a string de alguma forma quando passando ela por uma rotina de conversão por exemplo, ou você usa a propriedade da forma como é devolvida pelo componente?

Em meu teste, para salvar o arquivo manualmente eu adicionei este trecho de código no evento OnClick do botão da Carta de Correção do exemplo da NF-e.

LStr := TStringList.Create;
try
  LStr.Clear;
  LStr.Add(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento[0].RetInfEvento.XML);
  LStr.SaveToFile(ApplicationPath + '\RetInfEvento.xml');
finally
  LStr.Free;
end;

Por favor, envie os XMLs que está utilizando para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

[MarcosRWeimer]

Alguns posts acima postei a rotina de gravação.

 

utilizo ela por algumas questões referentes ao caminho, unica manipulação é a mesma que o acbr faz internamente

LIsUTF8 := LXML.ToLower.Contains('<signature'); //ACBrDFeUtil.XmlEstaAssinado
  FACBrNFe.Gravar(LCaminho, LXml, '', LIsUTF8);

o LIsUTF8 que é utilizado de parâmetro para o Gravar do próprio ACBr.

 

Mas essa questão cai por terra pois utilizando o programa de exemplo acontece o mesmo erro que acontece no meu executável.

[Diego Foliene]

12 minutes ago, MarcosRWeimer said:

Alguns posts acima postei a rotina de gravação.

 

utilizo ela por algumas questões referentes ao caminho, unica manipulação é a mesma que o acbr faz internamente

LIsUTF8 := LXML.ToLower.Contains('<signature'); //ACBrDFeUtil.XmlEstaAssinado
  FACBrNFe.Gravar(LCaminho, LXml, '', LIsUTF8);

o LIsUTF8 que é utilizado de parâmetro para o Gravar do próprio ACBr.

 

Mas essa questão cai por terra pois utilizando o programa de exemplo acontece o mesmo erro que acontece no meu executável.

Por favor, envie os arquivos XML que está usando para o e-mail solicitado para que possa testar em meu ambiente e comparar com os que estou gerando em meus testes.

[MarcosRWeimer]

17 minutos atrás, Diego Foliene disse:

Por favor, envie os arquivos XML que está usando para o e-mail solicitado para que possa testar em meu ambiente e comparar com os que estou gerando em meus testes.

enviados, tanto do app exemplo do acbr como os meus

[Diego Foliene]

3 minutes ago, MarcosRWeimer said:

enviados, tanto do app exemplo do acbr como os meus

Arquivos recebidos, muito obrigado.

Vamos analisar e reportamos assim que descobrirmos algo.

[Diego Foliene]

Comparando seus arquivos XMLs com os meus, eles parecem estar corretos.

Eles abrem corretamente a visualização no navegador, o notepad++ reconhece como XML válido e em UTF-8.

Testando em meu ambiente com os arquivos que disponibilizou, o preview foi gerado corretamente.

Por favor:

• Faça o download do exemplo anexado.
• Descompacte o mesmo e faça um teste com ele.
  • Não precisa configurar nada.
  • Não remova as dlls que vierem junto da pasta.
  • Não adicione outras dlls fora as que já vieram com ele.

Veja se também ocorre o problema testando com ele.

ACBrNFeExemplo.7z

[MarcosRWeimer]

Ola!

Com esta pasta gerou e imprimiu corretamente, porem em um gerador de relatório desconhecido, aqui utilizamos FastReport.

Não citei o gerador de relatórios antes pois o erro acontece no momento de carregar o xml no componente, antes da impressão.

[Diego Foliene]

Boa tarde!

36 minutes ago, MarcosRWeimer said:

, porem em um gerador de relatório desconhecido, aqui utilizamos FastReport.

Não citei o gerador de relatórios antes pois o erro acontece no momento de carregar o xml no componente, antes da impressão.

O gerador de relatórios utilizado neste caso foi o Fortes Report, no entanto, como comentou, como o problema ocorria na carga do XML, acredito que o gerador utilizado não tenha relação com o problema.

37 minutes ago, MarcosRWeimer said:

Ola!

Com esta pasta gerou e imprimiu corretamente

O .EXE foi compilado em meu ambiente hoje.

Por favor:

Sabendo que deu certo com ele, agora, substitua as dlls que você tem na pasta do seu .EXE pelas dlls que estão na pasta deste que deu certo.

Caso ele ainda apresente o mesmo erro no momento de carregar o XML, então pode ser que você tenha modificações locais.

1º Vou lhe pedir que você faça um SVN update na pasta base do ACBr(no nível mais baixo e não dentro de uma pasta específica por exemplo).

2º Procure por .bpls ou .dcus do ACBr perdidos em seu ambiente, geralmente eles ficam em "C:\Users\Public\Documents\Embarcadero\Studio\VersaoDoSeuDelphi" se encontrar algum do ACBr neste caminho, apague.

3º Reinstale o ACBr com a opção para "Apagar Arquivos Antigos" selecionada no instalador.

4º Faça um novo teste.

[MarcosRWeimer]

Trocando as DLLs gravou, emitiu, autorizou e imprimiu, porem voltou o problema de gravar com a acentuação incorreta

 

[Victor H. Gonzales - Panda]

12 minutos atrás, MarcosRWeimer disse:

Trocando as DLLs gravou, emitiu, autorizou e imprimiu, porem voltou o problema de gravar com a acentuação incorreta

 

EVENTOS.pdfversão do componente 35200 e seus XML não obtive nenhum problema como o reportado acima usando FastReport.

[Diego Foliene]

Tudo indica ser alguma diferença em seu ambiente.

Por favor, veja se consegue fazer o teste em um ambiente limpo.

Esse passo a passo também pode ser útil.

2 hours ago, Diego Foliene said:

1º Vou lhe pedir que você faça um SVN update na pasta base do ACBr(no nível mais baixo e não dentro de uma pasta específica por exemplo).

2º Procure por .bpls ou .dcus do ACBr perdidos em seu ambiente, geralmente eles ficam em "C:\Users\Public\Documents\Embarcadero\Studio\VersaoDoSeuDelphi" se encontrar algum do ACBr neste caminho, apague.

3º Reinstale o ACBr com a opção para "Apagar Arquivos Antigos" selecionada no instalador.

 

[MarcosRWeimer]

Testado hoje em outros 2 computadores, problema persiste.