luisclaudio_jr

Vou interceptar algumas requisições e retornos quando gerarmos aqui e envio pra vocÊs tudo, talvez dê pra pegar algo, porque o contato é sempre muito vago pelo suporte deles. E sobre o acbrJson, vou ver se consigo um tempo pra verificar também.

Bom dia Posso ver com eles se consigo tirar essas duvidas, também posso passar pra vocês minhas requests e retornos (quantas quiserem), pra analise, sem problemas. Sobre o ACBRJson, nunca nem tinha ouvido falar,mas se tiver algo que eu possa me basear.. Até essa contribuição eu nunca tinha feito nada de muito grande nos fontes do ACBR, fui me virando baseado em outros bancos.

Bacana, parabéns Acbr, entrarei com os testes na proxima semana e relato! valeu!

Obrigado pelo retorno Italo, fico no aguardo, grande abraço

Contem comigo caso precisem de testes ou mais informações.

Certo Italo, mas é algo que eu possa estar ajudando? O problema como eu simulei aqui foi justamente da forma que citei na ultima vez, o problema acontece quando jogo um arquivo pra um xmlString e ai uso um loadfromstream ou loadfromString... Em algo ele se perde.. Se eu uso um loadfromfile resolve, mas por aqui a gente faz muitas validações antes de liberar pra importação, principalmente porque pode ter xml de eventos(cancelamento, carta de correção..) etc

@Italo Giurizzato Junior sabe me dizer se foi possivel simular o problema por ai?

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