Pesquisar na Comunidade

Ao gerar um relatorio com mais de 200 notas fiscais (sim, o cliente imprime tudo de uma vez para enviar ao contador) fica absurdamente lento. Identifiquei que o problema é um bug conhecido do fast report neste ponto: function TACBrNFSeDANFSeFR.PrepareReport(NFSe: TNFSe): Boolean; . . . for I := 0 to TACBrNFSe(ACBrNFSe).NotasFiscais.Count - 1 do begin CarregaDados(TACBrNFSe(ACBrNFSe).NotasFiscais.Items.NFSe); if (I > 0) then Result := frxReport.PrepareReport(false) else Result := frxReport.PrepareReport end; Onde o PrepareReport(false) acrescenta um novo relatorio a cada NFs-e (usando o recurso de multi-relatorios). Mas depois de uma certa quantidade fica muito lento. Fiz algumas alterações nos fontes para tornar isto mais rapido. Qual o procedimento para submeter a alteração à eventual incorporação definitiva? Abraços

Boa tarde pessoal, Recebemos uma reclamação de um cliente nosso, que a partir do momento em que recebe na tela a mensagem de aprovado e é impresso no ECF, está lento. Estava analisando o log do componente ACBrTEFD e verifiquei o seguinte: -- 18/06 07:20:11:854 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 18/06 07:20:45:596 - *** ContinuaFuncaoSiTefInterativo, Finalizando: STS = 0 Somente no bloco acima, que loga parte da função ContinuaFuncaoSiTefInterativo temos uma demora de 34 segundos. A princípio pelo que tenho lido, neste bloco em específico, esta função está apenas efetuando as requisições para o servidor SiTEF, conforme o fluxo do TEF, sendo que não existe uma intervenção da aplicação. Acredito que neste caso seria uma lentidão mais devido a algum problema de rede ou até mesmo de alguma demora de resposta de algum servidor relacionado ao procedimento. Seria isso mesmo a explicação? Eu anexei um trecho do log relacionado ao problema para demonstrar o caso acima com mais detalhes. Desde já agradeço a resposta. ACBrTEF_CliSITEF_20180618.txt

Ao enviar a NFe utilizo o método ACBrNFe.Enviar mas ele envia e logo me retorna o erro ou ok, queria enviar o lote e depois verificar o mesmo, sem ser de forma automática como neste método. Sei que na rotina de NFSe exite uma configuração a ConsultaLoteAposEnvio, existe algo para a NFe?

Olá pessoal, Estou me deparando com a seguinte situação: Quando tem muitos usuários acessando o mesmo exe a aplicação fica lenta. Funciona assim. Compartilhamos a pasta onde está o executável, e colocamos nos terminais o um atalho na área de trabalho. Não sei o numero exato, mas o numero de usuários conectados varia entre 60 a 100. Parece não ser problema com Firebird por que fizemos um teste com alguns usuarios copiando o exe para outro PC, mas apontando para a mesma base de dados e ficou normal a utilização. Alguém já se deparou com essa situação ou tem alguma ideia do que posso fazer para resolver esse problema?

Eu tenho uma impressora Bematech MP-4000 TH FI nova com menos de 10 mil de totalizador total e quando eu chamo a função ECF.VendaBruta está demorando mais de 6 segundos. Tem como vocês verificarem por favor.

O ERP que usamos se chama Construshow, da VIASOFT, e esse AC se utiliza de componentes ACBr. Estou utilizando o equipamento RB-2000 com Layout XML Entrada 0.07. O arquivo de configuração da DLL está em C:\Windows\SysWOW64 em um servidor de aplicações Windows 2008 Server R2. Configurei o arquivo bemasat.xml para que não gere nenhum Log (NivelLog 0): <?xml version="1.0" encoding="UTF-8" ?> <bematech> <Sistema> <LocalizarPorta>1</LocalizarPorta> <Porta>COM4</Porta> <Path>D:\VIASOFT\Server\NFeAcbr\SAT\LOGS</Path> <NivelLog>0</NivelLog> <ValidarParametros>1</ValidarParametros> <ArquivoDados>D:\VIASOFT\Server\NFeAcbr\SAT\DB\bemasat.db</ArquivoDados> </Sistema> <Timeouts> <ativacao>600000</ativacao> <icp_brasil>480000</icp_brasil> <consultar_sat>10000</consultar_sat> <associar_assinatura>20000</associar_assinatura> <consultar_sessao>30000</consultar_sessao> <trocar_codigo_ativacao>20000</trocar_codigo_ativacao> <bloquear_sat>300000</bloquear_sat> <desbloquear_sat>30000</desbloquear_sat> <extrair_logs>60000</extrair_logs> <atualizar_sat>1800000</atualizar_sat> <configurar_rede>30000</configurar_rede> <enviar_venda>60000</enviar_venda> <cancelar_venda>20000</cancelar_venda> <teste_fim_a_fim>30000</teste_fim_a_fim> <consultar_status>15000</consultar_status> </Timeouts> <Manutencao> <Sessoes>498202,17028,270460,383274,125525,107481,607937,565872,117253,91379,237622,428019,252542,878825,970386,253675,415605,300506,815360,948361,252157,955123,102642,297113,589769,40892,895674,374221,674955,797292,742820,16063,182641,734640,963965,439103,395557,401412,844546,606114,987326,507011,927399,643922,656824,483316,427162,756040,484813,252976,780216,711814,575398,693811,572460,667607,956999,132303,412184,533505,348933,936792,881270,442858,587552,889138,349188,871430,521342,702573,167423,426471,316008,952229,497960,380199,694871,39780,71100,969755,71500,273180,248540,525157,328268,255188,594336,838624,385187,75572,345894,320663,227540,252626,630789,969235,780016,898411,949373,161571</Sessoes> </Manutencao> </bematech> Ocorre que está sendo gerado um arquivo de log na raiz do servidor C:\ com o nome SAT_log.txt. Este arquivo grava todos os comandos enviados ao sat e os respectivos retornos, incrementando o arquivo cada vez que a aplicação se comunica com o SAT. São geradas 4 linhas como essas abaixo para cada cupom enviado ao SAT(omiti alguns dados como CNPJ, IE e signAC): 23/12/17 14:10:06:370 - ACBrSAT.Inicializado 23/12/17 14:10:06:516 - NumeroSessao: 252157 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?><CFe><infCFe versaoDadosEnt="0.07"><ide><CNPJ>99999999999999</CNPJ><signAC>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</signAC><numeroCaixa>001</numeroCaixa></ide><emit><CNPJ>99999999999999</CNPJ><IE>999999999999</IE><indRatISSQN>S</indRatISSQN></emit><dest></dest><det nItem="1"><prod><cProd>24907</cProd><cEAN>7891435064568</cEAN><xProd>CANALETA TRAMON.C/DIVIS. 20X10X2000 C/FITA</xProd><NCM>39162000</NCM><CFOP>5405</CFOP><uCom>UN</uCom><qCom>4.0000</qCom><vUnCom>6.90</vUnCom><indRegra>A</indRegra></prod><imposto><ICMS><ICMS40><Orig>0</Orig><CST>60</CST></ICMS40></ICMS><PIS><PISAliq><CST>01</CST><vBC>0.00</vBC><pPIS>0.0000</pPIS></PISAliq></PIS><COFINS><COFINSAliq><CST>01</CST><vBC>0.00</vBC><pCOFINS>0.0000</pCOFINS></COFINSAliq></COFINS></imposto></det><total><vCFeLei12741>0.00</vCFeLei12741></total><pgto><MP><cMP>01</cMP><vMP>50.00</vMP></MP></pgto><infAdic><infCpl>Valor Aprox. dos Impostos: R$ 8,03 Federal e R$ 4,97 Estadual, referente a 47,07% do Total da Nota. Fonte: IBPT Nota Gerada no Caixa</infCpl></infAdic></infCFe></CFe> ) 23/12/17 14:10:08:335 - NumeroSessao: 252157 - Resposta:252157|06000|0000|Emitido com sucesso + conteúdo notas|||PENGZT48aW5mQ0ZlIElkPSJDRmUzNTE3MTI1MDg3MTk2MTAwMDE0MDU5MDAwNDE4MDc2MDAyNDIxMTEwNDEyOCIgdmVyc2FvPSIwLjA3IiB2ZXJzYW9EYWRvc0VudD0iMC4wNyIgdmVyc2FvU0I9IjAyMDEwMCI+PGlkZT48Y1VGPjM1PC9jVUY+PGNORj4xMTA0MTI8L2NORj48bW9kPjU5PC9tb2Q+PG5zZXJpZVNBVD4wMDA0MTgwNzY8L25zZXJpZVNBVD48bkNGZT4wMDI0MjE8L25DRmU+PGRFbWk+MjAxNzEyMjM8L2RFbWk+PGhFbWk+MTQxMDA0PC9oRW1pPjxjRFY+ODwvY0RWPjx0cEFtYj4xPC90cEFtYj48Q05QSj4xMzI4NDM5NjAwMDE5ODwvQ05QSj48c2lnbkFDPkZ2ZGZKZUpycDdNbFZIK2RMd05vTW5iQjF3Tk8rZk1WUkpETkRZRXFyank4T24yU0x5VnV5dWxjeVBTSUc0OWVEaThWVnhoaFRCTkNjYUZudW1xNGNmelF5QXpRMEhOelhXTkpKMU9QU1ZYVGQzWDdqQjJ0ZmVFZFBXVXpPdGtlQWZmTkhGUnlkWk1adi9rV1pZSldEL2dXWjhNVDJvaXNodnpreDVyMFRLNy9rVVh2cm5TWGxhMzA0M2p0MHlyaWprVWpKVW1HdzlXTHJidUVBeEN1TVRoaThnRytoZlRNVEkwbEdHNFZIZ2lGbTV3N2hpcTZKWW84ekJDbjkxVTQ0ZG11cTlRcVFaTHdteW5WYVJ1bElyZEo3ckZ0dHdpMnZFOW1mdnZwN3VLWSs2VzdjaEtzdytPZ3lHeTBZSUFNSEtqQWZxZFphb2xyTFFqNGhBVHViUT09PC9zaWduQUM+PGFzc2luYXR1cmFRUkNPREU+WUFQYWlhc2RnSzRCaG1mbEVLYVJZY1dudkZMcDRZdk5pUmZmdnJMUG9iYzBNYktwVmZseXF5WnoxMnRlTXREZk5FR3ZlcU1BRUt1cm9XN3BqZEp0cUd1MzN6enV0OTJodVkrNmtzM2VwSkJnNzgwMFJJTXFyYmlFUFlDemN5cUYveW5ncVVRc0wyd2tXZGFTait1czRHWFBBSkNtTnd2Z0J5dnB3Wk5jYVFhbVQrZEg4MlIxZW5rNTZSOU1udE8wdGRyL2tiUisrajJJWE5jRDZOMXpOKytpWVFSeFhmWEJsVE9BNENmVkd5VCtOdHlKNUp3N05jZU5XL25zOTdsaytIWC9nSlNyc1E4VU1kdUhTcmYvUytXdGpseCtqamtLS09xTVZYM1R0TnBRS2w5M0xHNXlsbkF0TWxqY1ZrWlZZYVhEbVA0VEkwMU1aMFd3QmJxRlNBPT08L2Fzc2luYXR1cmFRUkNPREU+PG51bWVyb0NhaXhhPjAwMTwvbnVtZXJvQ2FpeGE+PC9pZGU+PGVtaXQ+PENOUEo+NTA4NzE5NjEwMDAxNDA8L0NOUEo+PHhOb21lPkNBUlJFVEFPIE1BVEVSSUFJUyBQQVJBIENPTlNUUlVDQU8gTFREQTwveE5vbWU+PGVuZGVyRW1pdD48eExncj5BVkVOSURBIElUQVBBUks8L3hMZ3I+PG5ybz4yNjk1PC9ucm8+PHhCYWlycm8+SkFSRElNIElUQVBBUks8L3hCYWlycm8+PHhNdW4+TUFVQTwveE11bj48Q0VQPjA5MzUwMDAwPC9DRVA+PC9lbmRlckVtaXQ+PElFPjQ0MjAzNDM0MjExMDwvSUU+PGNSZWdUcmliPjM8L2NSZWdUcmliPjxpbmRSYXRJU1NRTj5TPC9pbmRSYXRJU1NRTj48L2VtaXQ+PGRlc3Q+PENQRj48L0NQRj48L2Rlc3Q+PGRldCBuSXRlbT0iMSI+PHByb2Q+PGNQcm9kPjI0OTA3PC9jUHJvZD48Y0VBTj43ODkxNDM1MDY0NTY4PC9jRUFOPjx4UHJvZD5DQU5BTEVUQSBUUkFNT04uQy9ESVZJUy4gMjBYMTBYMjAwMCBDL0ZJVEE8L3hQcm9kPjxOQ00+MzkxNjIwMDA8L05DTT48Q0ZPUD41NDA1PC9DRk9QPjx1Q29tPlVOPC91Q29tPjxxQ29tPjQuMDAwMDwvcUNvbT48dlVuQ29tPjYuOTA8L3ZVbkNvbT48dlByb2Q+MjcuNjA8L3ZQcm9kPjxpbmRSZWdyYT5BPC9pbmRSZWdyYT48dkl0ZW0+MjcuNjA8L3ZJdGVtPjwvcHJvZD48aW1wb3N0bz48SUNNUz48SUNNUzQwPjxPcmlnPjA8L09yaWc+PENTVD42MDwvQ1NUPjwvSUNNUzQwPjwvSUNNUz48UElTPjxQSVNBbGlxPjxDU1Q+MDE8L0NTVD48dkJDPjAuMDA8L3ZCQz48cFBJUz4wLjAwMDA8L3BQSVM+PHZQSVM+MC4wMDwvdlBJUz48L1BJU0FsaXE+PC9QSVM+PENPRklOUz48Q09GSU5TQWxpcT48Q1NUPjAxPC9DU1Q+PHZCQz4wLjAwPC92QkM+PHBDT0ZJTlM+MC4wMDAwPC9wQ09GSU5TPjx2Q09GSU5TPjAuMDA8L3ZDT0ZJTlM+PC9DT0ZJTlNBbGlxPjwvQ09GSU5TPjwvaW1wb3N0bz48L2RldD48dG90YWw+PElDTVNUb3Q+PHZJQ01TPjAuMDA8L3ZJQ01TPjx2UHJvZD4yNy42MDwvdlByb2Q+PHZEZXNjPjAuMDA8L3ZEZXNjPjx2UElTPjAuMDA8L3ZQSVM+PHZDT0ZJTlM+MC4wMDwvdkNPRklOUz48dlBJU1NUPjAuMDA8L3ZQSVNTVD48dkNPRklOU1NUPjAuMDA8L3ZDT0ZJTlNTVD48dk91dHJvPjAuMDA8L3ZPdXRybz48L0lDTVNUb3Q+PHZDRmU+MjcuNjA8L3ZDRmU+PHZDRmVMZWkxMjc0MT4wLjAwPC92Q0ZlTGVpMTI3NDE+PC90b3RhbD48cGd0bz48TVA+PGNNUD4wMTwvY01QPjx2TVA+NTAuMDA8L3ZNUD48L01QPjx2VHJvY28+MjIuNDA8L3ZUcm9jbz48L3BndG8+PGluZkFkaWM+PGluZkNwbD5WYWxvciBBcHJveC4gZG9zIEltcG9zdG9zOiBSJCA4LDAzIEZlZGVyYWwgZSBSJCA0LDk3IEVzdGFkdWFsLCByZWZlcmVudGUgYSA0NywwNyUgZG8gVG90YWwgZGEgTm90YS4gRm9udGU6IElCUFQgTm90YSBHZXJhZGEgbm8gQ2FpeGE8L2luZkNwbD48b2JzRmlzY28geENhbXBvPSIwMi4wMy4wNC4wMyI+PHhUZXh0bz5Db25zdWx0ZSBvIFFSQ29kZSBkZXN0ZSBleHRyYXRvIGF0cmF2ZXMgZG8gQXBwIERlT2xob05hTm90YTwveFRleHRvPjwvb2JzRmlzY28+PC9pbmZBZGljPjwvaW5mQ0ZlPjxTaWduYXR1cmUgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxTaWduZWRJbmZvIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1Ij48L0Nhbm9uaWNhbGl6YXRpb25NZXRob2Q+PFNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiPjwvU2lnbmF0dXJlTWV0aG9kPjxSZWZlcmVuY2UgVVJJPSIjQ0ZlMzUxNzEyNTA4NzE5NjEwMDAxNDA1OTAwMDQxODA3NjAwMjQyMTExMDQxMjgiPjxUcmFuc2Zvcm1zPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSI+PC9UcmFuc2Zvcm0+PFRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1Ij48L1RyYW5zZm9ybT48L1RyYW5zZm9ybXM+PERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiI+PC9EaWdlc3RNZXRob2Q+PERpZ2VzdFZhbHVlPmhMNm93V0ZHMjJDSVJ6QVJ6QjRoeldMRUdyQ1BSY1RnY1RsRU1Pa1EzOHc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1NpZ25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPmc1cDlRdTdDU3puU05TOWJrbDF4b2NGeEtUaE0wUWNIN2tEbmJ6ZVNMcnRDN3lhM0ZJWk1RWVhpZmhLVlNTbWYxbytqcC9nSUNNMXlGNEg1Zkc0Z3QyakxYV2pVR1U0bHZJa3VEVWtSbGdjV2pZOE93WXMzeHk5c0NwYVptS3Rxaml5dEh1N3VMbkVQMm10bGFJSnM0QzhWdVg1WDgvQ2F6MnQ1ZGVoV0t6NUQwZ1BNZ1M2Q0E1amJhZHIwbG9Ddm0rckVzZ2RJTDUrMWkyVXVLSStKck9PRnJSN05HWnJrbDhyVXZ0VFlETUQzR0ZDZjFIRWI4eWdjUFRqRmszZFZ6a1BPWTBPVmRwdUVvdi9JckliOHFCdUxmZFhueXpPKzVncTFDRXlGUTltN1hLWDNSYmhjd29Od0g2NUZCTUQxOHlQMHM2UHFZRm1FR2RuZHhzMS9SZz09PC9TaWduYXR1cmVWYWx1ZT48S2V5SW5mbz48WDUwOURhdGE+PFg1MDlDZXJ0aWZpY2F0ZT5NSUlHaXpDQ0JIT2dBd0lCQWdJSkFSZW80aDIvdnhXK01BMEdDU3FHU0liM0RRRUJDd1VBTUZFeE5UQXpCZ05WQkFvVExGTmxZM0psZEdGeWFXRWdaR0VnUm1GNlpXNWtZU0JrYnlCRmMzUmhaRzhnWkdVZ1UyRnZJRkJoZFd4dk1SZ3dGZ1lEVlFRREV3OUJReUJUUVZRZ1UwVkdRVm9nVTFBd0hoY05NVGN4TWpFME1UTXdOelV4V2hjTk1qSXhNakUwTVRNd056VXhXakNCeERFU01CQUdBMVVFQlJNSk1EQXdOREU0TURjMk1Rc3dDUVlEVlFRR0V3SkNVakVTTUJBR0ExVUVDQk1KVTJGdklGQmhkV3h2TVJFd0R3WURWUVFLRXdoVFJVWkJXaTFUVURFUE1BMEdBMVVFQ3hNR1FVTXRVMEZVTVNnd0pnWURWUVFMRXg5QmRYUmxiblJwWTJGa2J5QndiM0lnUVZJZ1UwVkdRVm9nVTFBZ1UwRlVNVDh3UFFZRFZRUURFelpEUVZKU1JWUkJUeUJOUVZSRlVrbEJTVk1nVUVGU1FTQkRUMDVUVkZKVlEwRlBJRXhVUkVFNk5UQTROekU1TmpFd01EQXhOREF3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ2thWjRQY1c3YkNRYWZuVFdZUFZnakpmK2FkcVFpOUtFUnpGUFBMaEJXVHhHckJPQTdLZVRmTjJraGFvb2pTWC81MkVuR1l4TnJDalYwOEtOUWIwVElBcE9SRXdoVkNIMEhsdVRYRlZSS3A1NmdqTWw4Nk5lZDI3OFZsR1pYcVVhN3puUFRIMU0vc0JUYnBNeWQxbDczdWFkSitEQlB3aEdYTkJLRFY5SkZGc2NXcWZvbVZEVi9NOW1melRla2I4K1R0dm9zZUlwMEpyZVhzNlpPZXRXQ1NDOUlSQnJLNXpQK2tzTDRES1R4VWtTWG5sK2JicmxDY0xOdFpuV000bDdXS1BST3lJODlxMVVFVWNZaUNHMXlkSFdVTWFYSmhQUDFGSkJNalpDTllVUXgwVXR1cUpwRDBHQTk0OVpISFZ4TXBjWHBjNytxMXJiK3lLTHltYWlwQWdNQkFBR2pnZ0h3TUlJQjdEQU9CZ05WSFE4QkFmOEVCQU1DQmVBd2RRWURWUjBnQkc0d2JEQnFCZ2tyQmdFRUFZSHNMUU13WFRCYkJnZ3JCZ0VGQlFjQ0FSWlBhSFIwY0RvdkwyRmpjMkYwTG1sdGNISmxibk5oYjJacFkybGhiQzVqYjIwdVluSXZjbVZ3YjNOcGRHOXlhVzh2WkhCakwyRmpjMlZtWVhwemNDOWtjR05mWVdOelpXWmhlbk53TG5Ca1pqQmxCZ05WSFI4RVhqQmNNRnFnV0tCV2hsUm9kSFJ3T2k4dllXTnpZWFF1YVcxd2NtVnVjMkZ2Wm1samFXRnNMbU52YlM1aWNpOXlaWEJ2YzJsMGIzSnBieTlzWTNJdllXTnpZWFJ6WldaaGVuTndMMkZqYzJGMGMyVm1ZWHB6Y0dOeWJDNWpjbXd3Z1pRR0NDc0dBUVVGQndFQkJJR0hNSUdFTUM0R0NDc0dBUVVGQnpBQmhpSm9kSFJ3T2k4dmIyTnpjQzVwYlhCeVpXNXpZVzltYVdOcFlXd3VZMjl0TG1KeU1GSUdDQ3NHQVFVRkJ6QUNoa1pvZEhSd09pOHZZV056WVhRdWFXMXdjbVZ1YzJGdlptbGphV0ZzTG1OdmJTNWljaTl5WlhCdmMybDBiM0pwYnk5alpYSjBhV1pwWTJGa2IzTXZZV056WVhRdWNEZGpNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01DTUFrR0ExVWRFd1FDTUFBd0pBWURWUjBSQkIwd0c2QVpCZ1ZnVEFFREE2QVFCQTQxTURnM01UazJNVEF3TURFME1EQWZCZ05WSFNNRUdEQVdnQlN3aFlHektNMTJLaWtrUzE5WVNtOW8yYXl3S2pBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQWdPck1qcWY0TUR6clZDRVJ3YUIxSlNPUnFWVDN3aUdYL1liRHhXOE1hVnJHOUNzN3dQSW0wN0sra3JMYXpqTDJEOXB6Sms0RTlodG9PRzJ2MXJzemEvbTMzTzNhcW1NVVlDUGRPS05TdGp3dDVQSGJtTTQ4WkI5VU5udjIxT0QwUFJ6YzBGM3lyRFkyWmxCY1E0TkZsVllUcFRYbmJ4VnF3b0RSTGJReEdTOGNiYlRsT3hxUnhuT1Q5NkFzWVllaU9yY0Iva2krbG5jWlR1SFJ2S3RRMFJWdXg0ZHdzMncvT3VWYTFpVmJsNUVDZGNCUWZFMFlSZDVJa3drR2RsSHo2V2hiZEkzcmpyYWkwRkQ5U3dGL1QzK1BiQU9aYW95L2h2SUlVdFNTVERkMXp3UVNEUTdpREVUWFBzaC9XRmtBdHo2Zkd0ZktKN2JlQkk5VWZJeG11U3RXSVJYcW9kZWpwYktrQ3lmWUdUM0ZwSEZ6bC9USnpqYWJGTmcxNUNzTytLeTdXOURZUDM3YkNidUNXOHRWSmt6TW4rN3hZL0hjdEZ0QUs2b2U1R21nbE50d0xDR3hiNS9hUm5HRnMwUS9ENitoVVNMQUMvNlZoVEVNUU9Icm4rYTJvZ1lYdGFMNng2bUFTOHM0K1JPVTg2WkNXNXZDQW5waE9wK0dlRmFBS0pHbWZqNjljamhNMmpPVDgrSFhmUUxkbHJuV0ozTEtvN20xN0NjQnYxMUphRnVWYXNRZWllMDl4OFpWVmM5eGUxMUkySitRMXArWitNMW5UaHF0cXBKeG1tZkgxbmtJYlJLYTB0NXBISXFhZHV4b282TWUyUU5EWnFKRDh6UThROWdkVDBrYnh0MHlETFlRMXFxeEhXbUFkU1dBSmhxb25sMHpyTWVxdGt3PTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURhdGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ0ZlPg==|20171223141004|CFe35171250871961000140590004180760024211104128|27.60||YAPaiasdgK4BhmflEKaRYcWnvFLp4YvNiRffvrLPobc0MbKpVflyqyZz12teMtDfNEGveqMAEKuroW7pjdJtqGu33zzut92huY+6ks3epJBg7800RIMqrbiEPYCzcyqF/yngqUQsL2wkWdaSj+us4GXPAJCmNwvgByvpwZNcaQamT+dH82R1enk56R9MntO0tdr/kbR++j2IXNcD6N1zN++iYQRxXfXBlTOA4CfVGyT+NtyJ5Jw7NceNW/ns97lk+HX/gJSrsQ8UMduHSrf/S+Wtjlx+jjkKKOqMVX3TtNpQKl93LG5ylnAtMljcVkZVYaXDmP4TI01MZ0WwBbqFSA== 23/12/17 14:10:08:447 - ACBrSAT.DesInicializado Diariamente estou renomeando os arquivos para sanar esse problema pois, o arquivo de log fica enorme e quando a aplicação envia um cupom ao SAT o arquivo é acessado e incrementado com novas linhas e quanto maior o arquivo maior a chance de dar erro de comunicação com o SAT. Eu acredito que o componente ACBr que a empresa se utiliza esteja gerando esse log pois, como eu comentei acima, eu configurei para que a DLL da Bematech não gere log algum. Se alguém está passando pelo mesmo problema ou conseguiu resolvê-lo eu agradeço. Bom Final de Ano à todos. Abraços.

Boa tarde, estou manifestando NFe para download do XML, só estou sofrendo com lentidão entre manifestar e depois fazer o download, após manifestar preciso esperar 5 minutos em média para conseguir fazer o download, o retorno da consulta entre este período é de que ainda não foi manifestada. Alguém tem alguma ideia do que pode ser? alguém está sofrendo com este problema?

Bom dia pessoal, A algum tempo, temos notado que na impressão das vias do comprovante do TEF nos clientes existe um pequeno atraso na impressão do mesmo, ou seja, quando comparamos com alguns outros frentes de caixa, a impressão parece ser feita de maneira contínua, mais fluída, enquanto que no nosso caso, o ECF aparenta imprimir por partes. Ontem, em um cliente o processo de impressão da via do TEF estava demorando em média duas vezes mais o tempo do processo de venda dos produtos. Estamos tentando analisar, o que poderia estar ocorrendo. No nosso source efetuamos deste modo o processamento do vinculado: procedure TdmVendaECF.TEFComandaECFImprimeVia(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante: TStringList; var RetornoECF : Integer); case TipoRelatorio of trGerencial: begin ... end; trVinculado: begin ecf.AcbrEcf.LinhaCupomVinculado(ImagemComprovante.Text); end; end; Analisando o método ACBrECF.LinhaCupomVinculado vimos a seguinte implementação padrão: if MaxLinhasBuffer < 1 then begin ... end else begin Texto := '' ; Buffer := DecodificarTagsFormatacao( Linha ); Buffer := AjustaLinhas(Buffer, Colunas) ; SL := TStringList.Create ; try SL.Text := Buffer ; For Lin := 0 to SL.Count - 1 do begin Texto := Texto + SL[Lin] + sLineBreak; if (Lin mod MaxLinhasBuffer) = 0 then begin ComandoLOG := 'LinhaCupomVinculado( '+Texto+' )'; fsECF.LinhaCupomVinculado( Texto ) ; Texto := '' ; end ; end ; if Texto <> '' then begin ComandoLOG := 'LinhaCupomVinculado( '+Texto+' )'; fsECF.LinhaCupomVinculado( Texto ) ; end ; finally SL.Free ; end ; end ; Ou seja, pelo que pudemos perceber, recebeu a imagem do comprovante como entrada e em seguida é realizado alguns tratamentos e adicionada para a variável Buffer, em seguida esta variável é associada para um stringlist SL que é percorrido inteiramente, imprimindo linha a linha(posições da mesma). Fizemos uma alteração para teste no seguinte sentido: if MaxLinhasBuffer < 1 then begin ... end else begin Texto := '' ; Buffer := DecodificarTagsFormatacao( Linha ); Buffer := AjustaLinhas(Buffer, Colunas) ; fsECF.LinhaCupomVinculado( Buffer ) ; end ; E obtivemos que na implementação original, foi impresso em média 2,234 s e no teste com o source acima em média 1,341 s isto para cada via, ou seja, no total, ficou 4,468 s e 2,682 s. Estamos utilizando uma Daruma FS700(MACH 1) e o Sitef Demo 6.1.0.23. Gostaríamos da opinião de vocês no seguinte sentido: Existe um modo de agilizar este procedimento de impressão sem ser a alteração acima? O modo padrão implementado acima utilizando uma stringlist, ele seria mais seguro? Haveria algum motivo específico? Desde já agradeço.

Pessoal, bom dia! Sei que os componentes ACBr deixaram de utilizar o QuickReport. Optei por postar a dúvida aqui no fórum em função da quantidade de colegas desenvolvedores que participam. Possivelmente alguém já passou por experiência parecida. Tenho um sistema que utiliza QuickReport para impressão. Um cliente optou por hospedar o sistema na Amazon AWS. Orientei para que uma das VM's fosse dedicada ao SQL Server e a outra dedicada ao TS. O banco de dados ainda é pequeno, 4GB. Em processos mais pesados o aplicativo não chega a atingir 150mb de memória. O TS roda em média com apenas 30 conexões simultâneas no decorrer do dia. A velocidade nos procedimentos operacionais melhorou bastante. O único ponto que está complicando a minha vida é a lentidão na impressão dos relatórios. Quando o usuário clica para gerar o relatório, o procedimento de geração é rápido, mas o preview está bastante lento. Me lembro de ter lido em algum lugar que a formatação do preview no QuickReport depende diretamente da impressora padrão do computador. Me parece que a lentidão ocorre em função disto, a comunicação entre o Windows do TS e o Windows local para buscar as configurações da impressora padrão. Alguém já passou por problema semelhante?

Amigos, um cliente trocou de computador (PDV) por uma maquina muito melhor, porém, ocorreu algo estranho, o sistema ficou muito mais lento. Está usando Impressora bematech em porta serial, no windows 7 32bits. Segue abaixo o log do acbr, notei que aparece muitos erros de ACK: -- 11:10:03:760 Estado TX -> [sTX][ENQ][NUL][FS]#[WAK]P[NUL] 11:10:03:776 RX <- ACK = 6 Falha: 0 11:10:03:885 RX <- $[NUL][NUL][NUL][NUL] -- 11:10:03:885 TX -> [sTX][ENQ][NUL][FS]#A[128][NUL] 11:10:03:901 RX <- ACK = 6 Falha: 0 11:10:04:010 RX <- [NUL][NUL][NUL][NUL][NUL] -- 11:10:04:010 TX -> [sTX][ENQ][NUL][FS]#[ESC]Z[NUL] 11:10:04:026 RX <- ACK = 6 Falha: 0 11:10:04:135 RX <- [ETX][ACK][NAK][NUL][NUL][NUL][NUL] -- 11:10:04:135 TX -> [sTX][ENQ][NUL][FS]#[23]V[NUL] 11:10:04:150 RX <- ACK = 6 Falha: 0 11:10:04:260 RX <- [ETX][ACK][NAK][18]"8[NUL][NUL][NUL][NUL] -- 11:10:13:542 AbreCupom( , , ) TX -> [sTX][4][NUL][FS][NUL][FS][NUL] 11:10:13:542 RX <- ACK = 6 Falha: 0 11:10:13:557 VerificaFimImpressao: Pedindo o Status (19) 11:10:13:744 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 11:10:14:119 RX <- [NUL][NUL][NUL][NUL] -- 11:10:18:440 DataHora TX -> [sTX][ENQ][NUL][FS]#[23]V[NUL] 11:10:18:456 RX <- ACK = 6 Falha: 0 11:10:18:643 RX <- [ETX][ACK][NAK][18]"R[NUL][NUL][NUL][NUL] -- 11:10:19:563 NumCupom TX -> [sTX][4][NUL][FS][30]:[NUL] 11:10:19:626 RX <- ACK = 6 Falha: 0 11:10:19:735 RX <- [4][146]X[NUL][NUL][NUL][NUL] -- 11:10:20:187 NumCCF TX -> [sTX][ENQ][NUL][FS]#7v[NUL] 11:10:20:203 RX <- ACK = 6 Falha: 0 11:10:20:312 RX <- [4]$ [NUL][NUL][NUL][NUL] -- 11:10:35:834 VendeItem( 0021896 , DORIL-DM-c/6 comp , FF , 1 , 5,21 , 0 , UN , $ , D , -1 ) TX -> [sTX]\[NUL][FS]?FF0000052100001000000000000000000000000100000000000000000000UN0021896[NUL]DORIL-DM-c/6 comp[NUL][218][18] 11:10:35:928 RX <- ACK = 6 Falha: 0 11:10:36:099 RX <- [NUL][NUL][NUL][NUL] -- 11:10:40:639 Estado TX -> [sTX][ENQ][NUL][FS]#[WAK]P[NUL] 11:10:40:654 RX <- ACK = 6 Falha: 0 11:10:40:764 RX <- %[NUL][NUL][NUL][NUL] -- 11:10:40:764 Subtotal TX -> [sTX][ENQ][NUL][FS]#A[128][NUL] 11:10:40:779 RX <- ACK = 6 Falha: 0 11:10:40:888 RX <- [NUL][NUL][NUL][NUL][NUL] -- 11:10:40:888 TX -> [sTX][4][NUL][FS][GS]9[NUL] 11:10:40:888 RX <- ACK = 6 Falha: 0 11:10:41:029 RX <- [NUL][NUL][NUL][NUL][NUL][ENQ]![NUL][NUL][NUL][NUL] -- 11:10:49:172 Estado TX -> [sTX][ENQ][NUL][FS]#[WAK]P[NUL] 11:10:49:188 RX <- ACK = 6 Falha: 0 11:10:49:297 RX <- %[NUL][NUL][NUL][NUL] -- 11:11:01:324 CancelaCupom TX -> [sTX][ENQ][NUL][FS]#[WAK]P[NUL] 11:11:01:356 RX <- ACK = 6 Falha: 0 11:11:01:465 RX <- %[NUL][NUL][NUL][NUL] -- 11:11:01:465 TX -> [sTX][4][NUL][FS][14]*[NUL] 11:11:01:465 RX <- ACK = 6 Falha: 0 11:11:01:496 VerificaFimImpressao: Pedindo o Status (19) 11:11:01:761 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 11:11:03:274 RX <- [NUL][NUL][NUL][NUL] -- 11:11:03:274 TX -> [sTX][ENQ][NUL][FS]#[WAK]P[NUL] 11:11:03:290 RX <- ACK = 6 Falha: 0 11:11:03:399 RX <- $[NUL][NUL][NUL][NUL] -- 11:11:03:399 TX -> [sTX][ENQ][NUL][FS]#A[128][NUL] 11:11:03:415 RX <- ACK = 6 Falha: 0 11:11:03:524 RX <- [NUL][NUL][NUL][NUL][NUL] -- 11:11:03:524 TX -> [sTX][ENQ][NUL][FS]#[ESC]Z[NUL] 11:11:03:540 RX <- ACK = 6 Falha: 0 11:11:03:649 RX <- [ETX][ACK][NAK][NUL][NUL][NUL][NUL] -- 11:11:03:649 TX -> [sTX][ENQ][NUL][FS]#[23]V[NUL] 11:11:03:664 RX <- ACK = 6 Falha: 0 11:11:03:774 RX <- [ETX][ACK][NAK][18]#7[NUL][NUL][NUL][NUL]

Olá pessoal! Primeiramente gostaria de agradecer a equipe ACBR pelo excelente componente que vocês desenvolvem. Sou usuário do ACBR a 5 anos e possuo centenas de clientes rodando o sistema sem problemas, porém recentemente um cliente gerou uma NF-e muito grande com 380 itens e para minha surpresa o programa demorou muito, mais muito mesmo para gerar e transmitir a nfe. Inicialmente pensei que a lentidão era no meu código que calcula os impostos dos itens, debugando o código cheguei na seguinte linha que causa a demora: ACBrNFe1.NotasFiscais.Valida; ( Cerca de 5 minutos ) ACBrNFe1.NotasFiscais.GerarNFe; ( Cerca de 5 minutos ) Debugando a função VALIDA encontrei o ponto do codigo do acbr onde ocorre a demora no processamento: Arquivo : PcnNfeW.pas Vou tentar colocar a pilha (call stack) para facilitar o entendimento: ACBrNFeNotasFiscais.TNotasFiscais.Valida ACBrNFeNotasFiscais.NotaFiscal.GetNFeXML pcnNFeW.TNFeW.GerarXml pcnNFeW.TNFeW.GerarInfNFe pcnNFeW.TNFeW.GerarDet A Função GerarDet leva cerca de 30 segundos para ser processada, até ai tudo bem um tempo aceitável para o tamanho da nota fiscal e a quantidade de itens, mas debugando percebi que a função GerarInfNFe é chamada dezenas de vezes inclusive em algumas partes do código onde ela é chamada consta um (**) na frente do comando. (**)GerarInfNFe; Creio que esta função GerarInfNFe > GeraDet deveria ser processada somente uma vez e setar um flag para indicar que os itens já foram processados. Pensei até em alterar o componente mas achei melhor informar para alguém mais experiente para que faça a alteração caso seja necessário ou me informar oque estou fazendo de errado. Aguardo ajuda dos colegas.