aocampioni

Deu certo Luiz ?

Amigo Antônio, boa tarde. Confuso mesmo, pICMSInterPart não seria pICMSInter ? porque senão um produto de 100,00 eu teria que fazer 100 * 100 / 100;

Bom dia Italo, Sensacional. Valeu, obrigado.

Frm_ACBrNFerev.zip

Boa noite amigos, Fazendo uns testes com o programa de exemplo do ACBrNFe surgiu estes pequenos erros: Era só pra eu ver as tags, como seriam geradas. Talvez pelo fato agora de querer diferenciar simples de regime normal, dentro do fonte exemplo, tinha que alterar mais locais, acho. Fiz uma pequena correção, apenas pra gerar o exemplo e validar, se for de valia para a equipe, segue anexo.

Juliana, boa tarde. Farei um teste e te reporto tá ok. Até, Daniel, boa tarde. Ok, entendido, também enxergo que a solução proposta reduz drasticamente a performance da aplicação , principalmente se o arquivo é escrito em rede. Vamos estudar mais um pouco aqui e qualquer resultado diferente que consigamos aqui eu reporto tá ok. Obrigado e até mais,

Boa noite. Infelizmente tenho esse mesmo problema até hoje. Alguns clientes usam Kaspersky e outros não. Imagino que seja um problema que ocorreu em um dos grandes refactorys do ACBr, no fim do ano passado, um dano colateral normal. Acredito que um tratamento com IOResult deva resolver, assim como foi feito nos ACBDeviceSerial e em outros arquivos. O que acha @Daniel Simoes, será que pode ser o mesmo problema que encontramos lá em fevereiro? Afinal existem nessa unit a WriteLog também. Vamos aguardar, Boa noite a até mais,

Amigo alexandre.abaco tente variar então o SSL Type pra LT_All, ou tentar usar o capicom (atualize as dlls e registre, conforme arquivo que te enviei e execute-o novamente) pra ver se surte efeito. Desmarque as opções de protocolo nas configurações do IE e deixe apenas o TLS 1.2 marcado, enfim, tente isso e nos avise. Abraço

Bom dia Juliomar, Então, assim, rsrs, como disse acima pro colega, as vezes passamos mil vezes pelo problema e não o vemos, então, adotei esses mesmos procedimentos que passei pra ele. Nesse, em questão, quando baixo o ACBr simplesmente desinstalo todo ACBr do meu delphi, executo o bat de apagar pra não ficar nenhum vestígio (pra se ter uma ideia a minha máquina é particionada em dois volumes, eu executo nos dois) e depois instalo tudo novamente, confiro DLL`s atualizadas e tals. Uma vez o Daniel comentou que qualquer vestígio de BPL, DCU perdida em algum diretório poderia causar o problema, então resolvi adotar esse procedimento passo a passo. Executo ele calmamente e nunca mais tive problema. Mas qualquer hora vou estudar novamente essa questão de somente recompilar, mas com calma e tempo (este que não ando tendo a algum tempo, infelizmente) e daí posto o resultado . Abraço e obrigado pela atenção.

Estimado, Bom dia! Desmarca SSL3, TLS 1.3. Marca a TLS 1.0 e a 1.1 e copia as novas dlls disponíveis no ACBr pro diretório de sua aplicação. Esse erro aí é problema de DLL. Ao baixar o ACBr (atualizações) já lhe adianto que não adianta recompilar, pelo menos comigo aqui funciona assim: Desinstalo tudo, executo o apagarAcbr. Instalo novamente, verifico no diretório DLLs se há novas versões de DLL (mais novas que as que tenho no diretório da minha aplicação), atualizo as que são mais novas, e só depois recompilo meu sistema e executo ele. As vezes é calma, principalmente nessa hora do cliente parado, vc passa mil vezes por cima do problema mas não o vê. Um teste bobo, pega todas as dll`s do seu sistema copia pro diretório do exemplo e executa, veja se consulta status, se envia nota etc. Depois apaga todas essas dlls, copia as mesmas dlls pegando do diretório DLLS do ACBr (tem que ir entrando em cada diretório e copiando as necessárias) pra dentro do diretório do exemplo também e executa. Veja se há mudança. Outra coisa que sugiro é copiar TODAS as cadeias de certificado direto do repositório ITI do governo: https://www.iti.gov.br/repositorio/84-repositorio/489-certificados-das-acs-da-icp-brasil-arquivo-unico-compactado Ao baixar, coloca num diretório qualquer , junto com as dlls que vou listar abaixo (atualizadas, sempre atualizadas) e executa esse arquivo BAT. if EXIST %windir%\SysWOW64 goto Win64 :Win32 ECHO *** CA NF-e v.4.0 *** ECHO *** Copiando as DLLs x86 *** copy capicom32bit\capicom.dll %windir%\System32 copy capicom32bit\Interop.CAPICOM.dll %windir%\System32 copy msxml5.dll %windir%\System32 copy msxml5r.dll %windir%\System32 copy libeay32.dll %windir%\System32 copy libssl32.dll %windir%\System32 copy ssleay32.dll %windir%\System32 ECHO *** Registrando as DLLs x86 *** regsvr32 %windir%\System32\capicom.dll /s regsvr32 %windir%\System32\msxml5.dll /s regsvr32 %windir%\System32\libeay32.dll /s regsvr32 %windir%\System32\ssleay32.dll /s goto end :Win64 ECHO *** CA NF-e v.4.0 *** ECHO *** Copiando as DLLs x64 *** copy capicom32bit\capicom.dll %windir%\SysWOW64 copy capicom32bit\Interop.CAPICOM.dll %windir%\SysWOW64 copy msxml5.dll %windir%\SysWOW64 copy msxml5r.dll %windir%\SysWOW64 copy libeay64.dll %windir%\SysWOW64 copy libssl32.dll %windir%\SysWOW64 copy ssleay64.dll %windir%\SysWOW64 ECHO *** Registrando as DLLs x64 *** regsvr32 %windir%\SysWOW64\capicom.dll /s regsvr32 %windir%\SysWOW64\msxml5.dll /s regsvr32 %windir%\SysWOW64\libeay64.dll /s regsvr32 %windir%\SysWOW64\ssleay64.dll /s goto end :end ECHO *** CA NF-e v.4.0 *** ECHO *** Instalando cadeias de certificados do repositório ITI *** for %%I in (*.p7b,*.crt, *.cer) do certutil -f -addstore CA %%~I Esse arquivo .BAT funciona no windows 7 , 8 e 10 também. Lembre-se apenas de, ao sair para o prompt de comando (tem que ser no prompt de comando) saia executando o mesmo como administrador (digita CMD no campo pesquisa e quando aparecer clica com o botão direito sobre e EXECUTAR COMO ADMINISTRADOR). Nos reporte aqui. Abraço e sorte.

Daniel, obrigado. Matou a pau, erro em uma máquina que tenho aqui que simula o mesmo ambiente que tem na maioria dos clientes. Windows 7. Um KB estava desatualizado nela (assim como em muitos dos clientes) e por isso não rodou a impressão. Rodei pela minha que tem windows 10 (no começo do post eu havia rodado na minha e deu erro 103) e não deu mais nenhum erro. Engraçado que pelo posprinter , lá na máquina que tem windows 7 funcionou. Mas é isso, acredito que está resolvido essa questão no ACBr. Obrigado mais uma vez e até mais.

Pessoal, Boa tarde. Dando um retorno prometido sobre a situação é o seguinte. Em 90% do tempo não consigo usar mais os comandos a : Assignfile(iImp,'\\192.168.100.97\tp650'); Rewrite(iImp); <== agora o erro é i/o error 1265 Writeln(iImp,sCodigoInicializacaoImp); <== não chega aqui. Se eu coloco Assignfile(iImp,'\\192.168.100.97\tp650'); {$I-} Rewrite(iImp); <== engole o erro {$I+} Writeln(iImp,sCodigoInicializacaoImp); <== então dá i/o error 103 No posprinter, tudo resolvido, digo, no programa de exemplo. Ativação, impressão. Os arquivos texto que abro e leio utilizando o AssignFile também estão ok, mesmo estando em qualquer local, mesmo compartilhado. Analisando o antigo arquivo ACBrDevice e agora os novos ACBrDevice e ACBrDeviceSerial, a impressão que tenho é que muitos recursos são utilizados porque muitas classes são criadas de uma vez. (LPT, SERIAL, TXT, RAW). No meu datamodule que instancio quando crio de cara tem um ACBrECF pra caso a aplicação utilizar ECF já verificar o estado da impressora (se está em erro ou ainda em venda, caso caia a energia , já corrige o estado de erro). Quando entro na tela de vendas, tenho componentes de balança, leitor, gaveta, display, ou seja, muitas vezes se passa pelo device e instancia-se todas essas classes. Acho que o erro 1265 (que por acaso não encontrei gogleando) mais se parece com um MANY RESOURCES OPENED. Veja , não tenho competência pra isso tá, só minha impressão. No antigo ACBrDevice era apenas separado por tipos (fsDeviceType: dtTCP, dtSerial, dtFile, dtParallel dtUSB, dtRawPrinter) e a instância era 1 apenas e na hora de ver quem é quem perguntava-se pelo tipo mas depois cada tipo virou uma classe a ser instanciada. Mais alguma dica/sugestão do que ser feito ?

ok Daniel, farei mais uns testes esse fim de semana e na segundona reporto como está tá ok. Obrigado pessoal. Abraço.

Opa, vou verificar Waldir e aplicar esse workaround aqui no meu código, valeu. Abraço.

Waldir e Daniel, Bom dia. Olha, olhando aqui com um pouco mais de calma (não consegui acompanhar todo fluxo pois me falta tempo e certa competência) mas notei que falta aplicar as diretivas também no arquivo ACBrDeviceRaw. No arquivo ACBrECFNaoFiscal não notei que precisa dessas diretivas se bem que há pontos em que elas 'calham'. A impressão, como o Waldir disse mesmo, é que após um assign pra começar a trabalhar com Reset ou Rewrite em algum ponto arquivo parace ser fechado antes de eu comandar Reset ou Rewrite, mas após acontecer pela primeira vez ele parece permanecer aberto (ou é ao contrário tá, como eu disse não tive tempo, nem competência, pra acompanhar o fluxo) pois se eu voltar pra executar novamente a rotina do sistema e não dá o erro. E aí ao final do processo tudo ocorre corretamente, mas, se eu for imprimir novamente dá o mesmo erro 103 e aí, denovo, se eu repetir em seguida ocorre normalmente. Então vamos lá, executo o processo; // primeira vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { aqui surge o erro 1ª vez } IOResult; {$I+} Writeln(iImp,sConfigInicial); // segunda vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { não acontece o erro mais } IOResult; {$I+} Writeln(iImp,sConfigInicial); // terceira vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { acontece erro novamente } IOResult; {$I+} Writeln(iImp,sConfigInicial); Claro que se eu fizer essa super ultra gambi, tudo funciona. try Assignfile(iImp,sPorta); try {$I-} Rewrite(iImp); IOResult; {$I+} except end; finally {$I-} Rewrite(iImp); IOResult; {$I+} end; Mas são muitos pontos e muitas situações dentro do meu software. Como na volta das revisões não peguei nada que me atrapalhasse resolvi voltar pra versão onde o ACBrDevice é único. Tá aí, foi o que consegui reproduzir. Se ajudar tá valendo. Obrigado por enquanto pessoal.