Marcílio Jr

@Juliomar Marchetti Segue anexo o arquivo solicitado. ACBrCTeWebServices.pas

Boa tarde. Ao efetuar a consulta de CT-es com eventos vinculados e cujos emitentes possuam "&" na razão social o erro "xmlParseEntityRef: no name" é gerado. A solução aplicada foi alterar o método TCTeConsulta.TratarResposta da unit ACBrCTeWebServices, conforme abaixo: Antes Depois A linha destacada em verde, com a instrução: CTeRetorno.XmlRetorno := StringReplace(CTeRetorno.XmlRetorno, '&', '&', [rfReplaceAll]); foi adicionada para substituir o '&' por '&' . Se possível, gostaria de saber se: Primeiro: Essa solução pode ser considerada ideal ou há uma outra melhor? Segundo: Essa solução deve também ser aplicada aos outros métodos de nome TratarResposta que se encontram na mesma unit, porém em outras classes? Desde já agradeço a atenção.

Boa tarde. Ao gerar o arquivo Conemb com a versão 3.1 (anexo) deparei-me com um problema no tamanho do registro 329. O layout determina que o tamanho desse registro seja 680, mas estava sendo gerado com 663. Analisando a unit ACBr\Fontes\ACBrTXT\ACBrEDI\ACBrEDIConhectos.pas identifiquei alguns problemas no método TACBrEDIConhectos.GerarComplConhecto e fiz algumas alterações: 1 - Adicionei o método FTxt.RFill com o tamanho 5 para que o campo seja formatado de acordo com o layout: 2,3 - Alterei o parâmetro size das chamadas ao método FTxt.VLFill de 13 para 15 para que os campos sejam formatados de acordo com o layout: 4 - Substitui o método Copy pelo método FTxt.RFill para que o campo seja formatado de acordo com o layout: 5 - Adicionei o método FTxt.RFill com o tamanho 3 para que o registro seja gerado com o tamanho 680, conforme consta no layout. * * Os campos cColeta, docViagemEmb, docAutorizacao, xChaveAcesso e cTipoDocto não constam no layout padrão Proceda 3.1 (anexo). Procurei bastante pelos layouts das versões 3.0 e 3.0a porém não consegui encontrar até o momento. Dessa forma não consegui verificar se nesses layouts anteriores esses campos existiam. Uma possibilidade é que esses campos sejam provenientes de alguma customização do arquivo para alguma empresa específica (o que comumente é solicitado) e tenham sido implementados como padrão. Pensei em adicionar uma verificação da versão nos métodos TACBrEDIConhectos.LerComplConhecto e TACBrEDIConhectos.GerarComplConhecto, adequando a leitura e a geração do registro 329 ao layout padrão da versão 3.1 (anexo) e deixando aqueles campos inexistentes nessa versão apenas para as versões anteriores (3.0 e 3.0a), mas achei melhor esperar pelas considerações da comunidade. Segue anexo arquivos para análise. Desde já agradeço a atenção. CONEMB 31.pdf ACBrEDIConhectos.pas

Acho que você não entendeu a minha colocação. Seguindo no mesmo exemplo do campo 14 - VALOR TOTAL DA NOTA, que citei para justificar as alterações feitas nos campos 13 - QTDE DE VOLUMES e 15 - PESO TOTAL DA MERCADORIA A TRANSP.: Em TACBrEDINotaFiscais.GerarNotasFiscais é utilizado o método TACBrTXTClass.VLFill para a formatação dos 3 campos supracitados. Ocorre que o método TACBrTXTClass.VLFill retorna uma string com o tamanho passado no parâmetro Size. Veja que o campo 14 - VALOR TOTAL DA NOTA começa na posição 86 e vai até a 100, ou seja, deve ter o tamanho total de 15 (13 inteiros e 2 decimais). Todos os campos que no layout estão como N 13.2 no método TACBrEDINotaFiscais.GerarNotasFiscais já estavam sendo formatados com 15,2 na chamada ao método TACBrTXTClass.VLFill. Os campos 13 - QTDE DE VOLUMES e 15 - PESO TOTAL DA MERCADORIA A TRANSP. estavam com a mesma formatação tanto no layout ( N 5,2 ) quanto na chamada ao método TACBrTXTClass.VLFill ( 5,2 ). O que fiz foi apenas adequar a formatação dos campos 13 - QTDE DE VOLUMES e 15 - PESO TOTAL DA MERCADORIA A TRANSP. à formatação que já estava vigente para os demais campos, alterando de ( 5,2 ) para ( 7,2 ) na chamada ao método TACBrTXTClass.VLFill em TACBrEDINotaFiscais.GerarNotasFiscais. Com isso os campos ocupam as posições corretas, conforme consta no layout e o tamanho do registro fica conforme o esperado: 240.

Segui o manual sim @Juliomar Marchetti, e quanto às alterações que fiz, apenas apliquei a mesma regra de formatação utilizada nos demais campos. Por exemplo: o campo 14 - VALOR TOTAL DA NOTA consta no layout como N 13.2 e nesse mesmo trecho de código que você destacou pode-se ver que o campo vTotalNF é processado com a formatação 15,2, ou seja, somando-se ao valor inteiro as casas decimais. Se os campos 13 - QTDE DE VOLUMES e 15 - PESO TOTAL DA MERCADORIA A TRANSP. forem processados com a formatação 5,2 e não com a formatação 7,2 o tamanho do registro fica 236, diferente do tamanho esperado, que é de 240.

Bom dia @Juliomar Marchetti Não estávamos encontrando o layout da versão 5.0 pois estávamos procurando como Proceda. Até a versão 3.1 os layouts estão como Proceda, mas a versão 5.0 está como Tivit ( empresa criada em dezembro de 2004 com a fusão das empresas Optiglobe e Proceda ). Por fim encontramos o layout da versão 5.0. Segue anexo conforme solicitado. Obrigado. NOTFI31.pdf NOTFIS-50.pdf

Boa tarde @Juliomar Marchetti Tenho sim, segue anexo NOTFI 31.pdf. Nesse caso especificamente trata-se da versão 3.1 do layout. Foi necessário fazer mais alterações na classe ACBrEDINotaFiscal, as quais detalho no anexo Alteracoes_ACBrEDINotaFiscal.txt. Segue anexo também o arquivo ACBrEDINotaFiscal.pas, atualizado para avaliação. O registro 314 não está com o tamanho esperado (240), mas esse ainda não conseguimos finalizar os ajustes para que ele fique conforme o tamanho especificado pelo layout. Mais uma vez agradeço à toda equipe ACBr. NOTFI 31.pdf Alteracoes_ACBrEDINotaFiscal.txt ACBrEDINotaFiscal.pas

Boa tarde. Ao gerar o arquivo EDI - NOTFIS aqui na empresa nos deparamos com o seguinte erro: EACBrTXTClassErro with message 'Parâmetro "Value" não possui um valor numérico.' A solução que encontramos foi modificar a unit ACBrEDINotaFiscal alterando o método GerarItensNF de: procedure TACBrEDINotaFiscais.GerarItensNF( Registro: TItensNF ) ; var I: Integer ; begin // Registros 511 ou 314 Itens da Nota Fiscal for i := 0 to Registro.Count - 1 do begin with Registro.Items[i] do begin if Versao = ve50 then begin Conteudo.Add( IdRegistro + FTxt.VLFill(qVolumes , 6, 2, '0') + FTxt.RFill(xEspecie , 15) + FTxt.RFill(cItem , 20) + FTxt.RFill(xDescricao, 50) + FTxt.LFill(CFOP , 4) + FTxt.RFill(nroLote , 20) + FTxt.LFill(dtValidade, 'ddmmyyyy', false) + FTxt.RFill(xMarca , 50) + FTxt.RFill(nroVolume , 50) + FTxt.RFill(nroLacre , 50) + FTxt.VLFill(nroPedido, 20) + FTxt.VLFill(Filler , 22) ) ; end else begin Conteudo.Add( IdRegistro + FTxt.VLFill(qVolumes , 5, 2, '0') + FTxt.RFill(xEspecie , 15) + FTxt.RFill(xDescricao, 30) + FTxt.VLFill(Filler , 29) ) ; end; end; end; end; para: procedure TACBrEDINotaFiscais.GerarItensNF( Registro: TItensNF ) ; var I: Integer ; begin // Registros 511 ou 314 Itens da Nota Fiscal for i := 0 to Registro.Count - 1 do begin with Registro.Items[i] do begin if Versao = ve50 then begin Conteudo.Add( IdRegistro + FTxt.VLFill(qVolumes , 6, 2, '0') + FTxt.RFill(xEspecie , 15) + FTxt.RFill(cItem , 20) + FTxt.RFill(xDescricao, 50) + FTxt.LFill(CFOP , 4) + FTxt.RFill(nroLote , 20) + FTxt.LFill(dtValidade, 'ddmmyyyy', false) + FTxt.RFill(xMarca , 50) + FTxt.RFill(nroVolume , 50) + FTxt.RFill(nroLacre , 50) + FTxt.VLFill(nroPedido, 20) + FTxt.RFill(Filler , 22) ) ; end else begin Conteudo.Add( IdRegistro + FTxt.VLFill(qVolumes , 5, 2, '0') + FTxt.RFill(xEspecie , 15) + FTxt.RFill(xDescricao, 30) + FTxt.RFill(Filler , 29) ) ; end; end; end; end; Identificamos que nas linhas 2141 e 2149 o Filler estava sendo tratado com numérico e não como string, por isso em ambas as linhas substituímos FTxt.VLFill por FTxt.VLFill e então o arquivo foi gerado com sucesso. Segue anexo a unit alterada para análise. Desde já agradeço. ACBrEDINotaFiscal.pas

Bom dia @Italo Jurisato Junior Consegui identificar a origem do problema. No meu caso era o caminho dos schemas, que estavam sendo carregados no formato UNC (\\Servidor\CTe\Schemas) e, que pelo que entendi, a libxml2 tem problemas para carregar arquivos da rede. Para funcionar basta carregar os schemas localmente ou mapear uma unidade de rede (D:\CTe\Schemas), caso seja preciso deixar os schemas centralizados no servidor. Encontrei essas informações no seguinte tópico: https://www.projetoacbr.com.br/forum/topic/42063-erro-ao-transmitir-nfe-schema-inválido/?page=2 Mais uma vez agradeço a atenção.

Bom dia @Italo Jurisato Junior Configurei aqui o componente da seguinte maneira: CTe.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; CTe.Configuracoes.Geral.SSLHttpLib := httpWinHttp; CTe.Configuracoes.Geral.SSLLib := libWinCrypt; CTe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; CTe.SSL.SSLType := LT_TLSv1_2; A consulta funciona normalmente, mas ao tentar gerar/enviar a receita retorna a seguinte mensagem: Falha na validação do Modal do Conhecimento: 1090 Erro: Schema Inválido Atualizei os fontes e reinstalei todo o ACBr hoje, bem como me certifiquei de que os arquivos schemas estão atualizados e devidamente sendo carregados pela propriedade PathSchemas. Desde já agradeço a atenção.

Bom dia @Juliomar Marchetti e @BigWings. Atualizei os fontes, testei no Delphi 10.1.2 Berlin e funcionou. Muito obrigado. Att, Marcílio Júnior

Boa tarde @Juliomar Marchetti. Atualizei os fontes e mesmo assim tive problema com alguns clientes, que reportaram quebra de linha em algumas notas fiscais. Debugando o código do método Split, que agora se encontra na unit ACBrUtil, precisei alterar a linha: {$IFDEF CompilerVersion >= 18} //Delphi 2006+ para {$IF CompilerVersion >= 18} //Delphi 2006+ removendo apenas o DEF da compilação condicional para que o problema fosse resolvido. Segue anexo a unit para averiguação. Att, Marcílio Júnior ACBrUtil.pas

Bom dia. Outra possibilidade seria refatorar o método TACBrNFeFRClass.Split da unit ACBrNFeDANFEFRDM.pas verificando a versão do delphi: function TACBrNFeFRClass.Split(const ADelimiter, AString: string): TSplitResult; var vRows: TStrings; vI: Integer; begin vRows := TStringList.Create; try vRows.Delimiter := ADelimiter[1]; // Delphi 2006 em diante If RTLVersion >= 18 Then Begin vRows.StrictDelimiter := True; vRows.DelimitedText := AString; End // Versões Anteriores ao Delphi 2006 Else vRows.DelimitedText := '"' + StringReplace(AString, ADelimiter, '"' + ADelimiter + '"', [rfReplaceAll]) + '"' ; SetLength(Result, vRows.Count); for vI := 0 to vRows.Count - 1 do Result[vI] := vRows.Strings[vI]; finally FreeAndNil(vRows); end; end; Segue anexo a unit ACBrNFeDANFEFRDM.pas para averiguação. ACBrNFeDANFEFRDM.pas

Encontrei uma outra maneira para resolver o problema da quebra de linha sem quebrar a compatibilidade com versões anteriores do delphi. Alterei o método TACBrNFeFRClass.Split da unit ACBrNFeDANFEFRDM.pas, substituindo a linha: vRows.DelimitedText := AString; por: vRows.DelimitedText := '"' + StringReplace(AString, ADelimiter, '"' + ADelimiter + '"', [rfReplaceAll]) + '"' ; Segue anexo a unit ACBrNFeDANFEFRDM.pas para averiguação. ACBrNFeDANFEFRDM.pas