luisclaudio_jr

Italo, estava aqui analisando. Creio que essa sequencia #$D#$A aconteça quando eu jogo o arquivo pra uma TXMLDocument, nós fazemos isso aqui, porque antes de popularmos pro ACBR a gente valida algumas coisas, principalmente pra saber se o XML em questão é uma nfe, se não é um evento, se não veio corrompido (arquivo zerado), se não foi um resumo... Enfim, são feito N situações. Quando eu dei direto um LoadfromFIle deu certo, meu problema foi no LoadfromString e ai quando eu debuguei, identifiquei que de fato o xml após entrar no TXMLDocument leva essas "quebras" de linha. Usando um stringReplace e removendo tudo (debugando eu vi que sumiram de fato os #$D#$A ), o problema ainda persistiu. E isso ocorre com todos os xmls, que fazemos usando esse cenario (carregando ele pra uma txmldocument) após isso, usando um loadfromString.. Vou enviar mais xmls contendo o topico novamente, mas basicamente todos acontece isso, quando carregamos dessa forma.

Ou via email, ou baixam da sefaz,whats... mas sim,pegam local, vou testar com algumas rotinas que usam pra baixar do banco de dados também, pra ver se isso ocorre. Mas se usar o metodo antigo, funciona de boa, o problema ta no processo novo usando o xmlacbr.

No caso não está no banco de dados, é arquivo carregado mesmo, onde o cliente pega da pasta que ele tem e importa.

Estava vendo nossa rotina aqui, antes a gente carrega o xml em um Txmldocument e depois usa o loadfromstring... Será que pode ser alguma coisa nesse sentido? (lembrando que antes funcionava normal.. foi após usar o xmlacbrdocument) var aXml: XMLString; sl: TStringList; ADoc := TXMLDocument.Create(nil); try ADoc.Active := True; ADoc.Version := '1.0'; ADoc.Encoding := 'utf-8'; ADoc.Options := [doNodeAutoIndent]; vTam := TamanhodoArquivo(arquivo); //aruivo em branco if (vTam < 100) then begin abort; end; ADoc.LoadFromFile(arquivo); aXml := ADoc.XML.Text; finally sl.Free; end; DM_NFE.ACBrNFe1.NotasFiscais.Clear; DM_NFE.ACBrNFe1.NotasFiscais.Add; DM_NFE.ACBrNFe1.NotasFiscais.LoadFromString(aXml)

Italo, atualizei reinstalei, mas continua tudo igual por aqui. ele chega nessa parte e cai no exception, eu vi no log a alteração, mas tu fez só tirar o or de lá.. mas o problema de fato é nessa abaixo... na hora do xmlparseDoC que entra como nil. 'XML declaration allowed only at the start of the document'#$A m <- é isso que dá naquele exception.

Voltou o de manhã agora, mandei pelo meu particular, pode [email protected]

Mandei ontem, depois de horas apareceu que voltou... e reenviei hj novamente as 6h:34, nao recebeu de novo? This is the mail system at host mcrelay.correio.biz. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <[email protected]>: lost connection with mx3.zoho.com[204.141.43.44] while receiving the initial server greeting

Ja foi enviado.

Então, todos que eu havia tentado, vou mandar alguns no email. Outra coisa que vi aqui, como eu tinha atualizado um cliente, precisei mandar um cancelamento de nota e imprimir, hora que deu um loadStream também ja estourou alguns erros.. Envio no consultores com o link aqui.

Boa noite pessoal Atualizei tudo o acbr pra ver se tinham resolvido e não tinha sido, mas vamos lá. Eu havia feito um alerta que os xmls com mais de 1500 chaves de ctes estavam demorando, foi migrado toda a rotina de cte também para utilizar o acbrxmldocument.. ao invés do antigo, pois bem, foi resolvido tudo, ficou zero bala e agradeço, mas começou a dar problema na importação de XMLs de notas fiscais, ele cai no except a baixo.. com qualquer nota, podem testar e verificar isso? Isso ocorre na hora de dar um .NotasFiscais.LoadFromString.. nos xmls de nfe, coisa que se eu remover o acbrxmldocument do acbrinc não acontece. Isso ocorre com qualquer xml.

Vou tentar instalar ela.. problema que mexer com fast as vezes da umas trabalheiras danadas de conflito... então preciso de um tempo pra poder realizar isso sem comprometer as outras atividades. Desde ja agradeço Tentei instalar o fortes, eu consegui, ele aparece pra mim, mas quando coloco no componente pra instalar ele não acha o frce... estranho que ele tá na minha library path... Required package 'frce' not found

Versão do delphi é a 10.2 architect

Essa é a versão que eu uso. Só se foi algo que foi resolvido talvez nas versões mais recentes do fast.

Testei no Fortes. A lentidão não ocorre, com 101 ctes, levou 01:22 segundos, bem mais rapido em relação ao fast. O gargalo no fast ocorre aqui nessa linha abaixo... esse prepareReport... Não teriamos outra estratégia talvez? if Assigned(ACBrCTe) then begin for i := 0 to TACBrCTe(ACBrCTe).Conhecimentos.Count - 1 do begin FCTe := TACBrCTe(ACBrCTe).Conhecimentos.Items[i].CTE; CarregaDados; if (i > 0) then Result := frxReport.PrepareReport(False) else Result := frxReport.PrepareReport; end; end else

Não cheguei, porque não tenho o fortes aqui.. mas onde gargala é justamente onde coloquei, pode ser que com fortes até resolva, mas não tenho nem ideia de como ele funciona. o FPDF tem impressão pra cte?

Vou buscar os fontes e testar depois, pode ser que tenha sido corrigido algo posterior.

ah maravilha, verdade, vou até ajustar aqui

O processo é bem semelhante ao da NFe.. ACBrCTe1.Conhecimentos.Clear; ACBrCTe1.Conhecimentos.Add; ACBrCTe1.Conhecimentos.LoadFromFile(arquivo); pode carregar dessa forma.. with DM_CTE.ACBrCTe1.Conhecimentos.Items[1].cte do begin ai aqui tu consegue pegar varias informações... end

Até estive vendo esse topico, que parece ser exatamente o que acontece... pelo que vi, ao invés de usar o prepare ele usou uma outra tatica...

Se for de um em um não demora, digamos carrego e ja imprimo.. tanto que na rotina que tenho de exportar um a um aqui é rapido, o problema é quando junta tudo em um pdf só, que eu carrego o componente com 100xmls e ai chega no preparereport ele vai gargalando depois de uns 40 itens

Pelo meu entendimento, ao analisar a lentidão pode ser algo do fast.. Na unt acbrCtedacteFR, ao passar no prepareReport, depois de uns 40 itens, começa a demorar muito, causando o gargalo de minutos que eu comentei acima. Não sei se existe algo que possa ser feito, os itens de carregar dados, é bem rapido, quando chega no PrepareReport que está com muitos itens que começa a lentidão. Na nova rotina de FPDF é possivel imprimir cte já? Nunca usei, mas posso tentar utilizar pra ver se resolve. if Assigned(ACBrCTe) then begin for i := 0 to TACBrCTe(ACBrCTe).Conhecimentos.Count - 1 do begin FCTe := TACBrCTe(ACBrCTe).Conhecimentos.Items[i].CTE; CarregaDados; if (i > 0) then Result := frxReport.PrepareReport(False) else Result := frxReport.PrepareReport; end; end else raise EACBrCTeDACTEFR.Create('Propriedade ACBrCTe não assinalada.');

Ocorre sim, era algo que eu tinha notado há muito tempo, até esperei estar o novo componente pra ver se isso resolvia. Vou ver se consigo debugar aqui pra ver onde exatamente está a lentidão e comunico

Sim, são xmls que são de 1 a 2 notas, normal. pequenos de 7 a 9kb. Populo o componente e depois chamo a rotina de impressão.(via fast) Abaixo é o tempo que levou cada teste que eu fiz, note que de 50 pra 100 mudou drasticamente o tempo. 100 ctes: 8:30s 50 ctes 1:27s 45ctes :58s 35 ctes - 36s 25ctes : 22 s

Problema do protocolo resolvido! Porém, a lentidão ao imprimir muitos documentos (normais, xmls de 8kb) ainda continua, fiz um teste com 73 ctes, levou um tempo consideravel.. Se coloco uns 30/40 vai rapido, notei que essa demora é quando excede 50.

Boa tarde pessoal Obtive o retorno do email que enviei ao cora sobre o código de barras me responderam isso, veja se ajuda a equipe.. Os três primeiros dígitos representam o código da IF (403) O quarto dígito representa o código da moeda (9) O quinto dígito é um dígito variável Os dígitos seis a nove representam o fator de vencimento Os dígitos de dez a dezenove representam o valor (acrescido de um zero na frente) Os dígitos vinte a vinte e quatro são preenchidos com zeros (00000) Os dígitos vinte e cinco a quarenta e dois representam o nosso número Os dígitos quarenta e três e quarenta e quatro representam a identificação do tipo de documento do processamento (01)