aocampioni

Bom dia @Daniel Simoes e amigo @Italo Giurizzato Junior, muito obrigado mesmo pelos comits, estarei visualizando eles em instantes. Abraço a todos.

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.

Daniel, Boa tarde. É isso mesmo, somente pela página do COMSAT, se eu baixar o recibo do lote vem os XML's completos dentro. Pelo jeito então não conseguiremos fazer o download ? Há outra saída ? Como sites como o ARQUIVEI conseguem retornar será hein ? Alguém ou algum membro Pro tem esse serviço que possa dar um parecer ? Obrigado.

Bom dia amigos, Conforme conversamos no DISCORD, estou criando essa publicação para verificarmos a possibilidade de fazer o download do XML do SAT-CFe usando o ACBrSATWS. Será de extrema valia para a comunidade. Agradecido.

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.

Waldir, Sinceramente digo que me preocupo mas sei o que tem por traz de todo esse projeto. Essa sim é uma grande equipe de desenvolvimento, das melhores que já vi. Do outro lado, muitos usuários testando e é isso que fazcom que o ACBr seja esse sucesso que é hoje. Sei que será resolvido e o que nós usuários pudermos fazer para contribuir, faremos. Estou agora copiando essa versão de 06/01 para um diretório isolado e vou fazer um SVN Update nele lá e voltar algumas revisões pra chegar em 06/01 e de lá pra cá tentar identificar algo. Qualquer coisa posto aqui. Muito obrigado, abraço e bom dia.

Então Waldir, muito estranho, eu fiz aplicação desse item que você mencionou em todas minhas chamadas, inclusive não só impressão, mas também quando eu precisei ler ou gravar arquivos textos em algumas rotinas. Fiz em todas mas não resolveu. Apenas gostaria de dizer, que aparentemente depois que o ACBrDeviceSerial entrou na jogada (pois eu não tinha ele quando atualizei em 06/01/2020) o erro começou a aparecer. Pode ser alguma coincidência. pode estar em alguma rotina nova, ou alguma outra alterada/melhorada, não sei. Fiz o teste na outra máquina que estava funcionando também, atualizei o ACBR lá com as últimas revisões até o dia 10/02 e o erro começou a acontecer também. Voltei essa versão que baixei em 06/01 e o erro não aconteceu mais. Fiquei preocupado pois agora não posso ter as últimas alterações no ACBr enquanto não descobrir o que pode estar ocorrendo de fato, mas sigo testando, com a versão / correções até 06/01 não estou tendo problemas. Até mais,

Daniel, Confirmando apenas : - fiz o teste com o fonte que você me passou e continuou o problema. - fiz o teste com o fonte que você me passou, com instalação limpa do delphi e do acbr, o problema continuou, até ao abrir os projetos pela primeira vez dava o bendito erro io 103 e não só nas impressões com o writeln e o posprinter. - removi novamente todo acbr e instalei a versão anterior que eu tinha (sempre guardo) de 06/01/2020 e funcionou, sem problemas, tive que remover todos os ACBrDeviceSerial dos fontes onde tinha a unit ACBrDevice pois não está presente esse arquivo nessa versão. Então, verde funcionando, vermelho é só instalar que passo a ter erro io 103 até na hora de abrir o projeto, não só na impressão com o prosprinter ou usando o writeln. O que pode ser feito? Há mais algum teste que quer que eu faça? Até mais,

Daniel, boa noite. Muitíssimo obrigado pelas prontas respostas, vou substituir a biblioteca agora e testar. Retorno mais breve possível. Até mais, Daniel, Passo a passo é o seguinte, entrei no demo, coloquei a porta de rede \\127.0.0.1\tp650, como eu disse é local mas poderia ser \\192.168.0.30\tp650 (que é como outra máquina da minha rede vê a minha) e daí ativei, desativei, ativei novamente e aqui já dá o erro. Lembrando, que pelo USB:Tanca local ou se tivesse RAW:Tanca-TP650 posso fazer o procedimento que o erro não acontece. Também não acontece com a impressora RAW:NPI0DE3D que é uma HP via cabo de rede. Até mais,

Pessoal, Boa tarde. Notei um fatídico I/O error 103 após última atualização que fiz nessa semana, dia 10. Simplesmente não sei o que é, antes eu utilizava portas no sistema , mesmo com o ACBrPosPrinter ou com o famoso Rewrite dessa maneira: \\127.0.0.1\tp650 , tipo, impressoras compartilhadas em outras máquinas (claro que essa impressora é compartilhada mas tá local na minha máquina para testes) e agora obtenho esse erro; Basta tentar ativar ou desativar que o erro é provocado. Pra simular certinho, entrei no posprinter demo, dei ativar e não ocorreu o erro. Desativei e selecionei Cortar Papel e fui ativar novamente e deu erro na Função abrir arquivo: procedure TACBrDeviceLPT.AbrirArquivo; var CreateModeFlag: Integer; NomeArq: String; begin NomeArq := ObterNomeArquivo(fpPorta); if fsUsarStream then begin if IsTXTFilePort and FileExists(NomeArq) then CreateModeFlag := fmOpenReadWrite else CreateModeFlag := fmCreate; CreateModeFlag := CreateModeFlag or fmShareDenyWrite; // Tentando abrir o arquivo fsFileStream := TFileStream.Create(NomeArq, CreateModeFlag); fsFileStream.Seek(0, soEnd); // vai para EOF end else begin AssignFile(fsArqPrn, NomeArq); if IsTXTFilePort and FileExists(NomeArq) then Append(fsArqPrn) else Rewrite(fsArqPrn); =====> nessa linha dá o erro ao tentar ativar novamente. end; end; Não sei o que pode estar ocorrendo, agora nem os formulários que estão somente com o Rewrite funcionam. Passei todos os formulários de impressão para o PosPrinter mas ao ativar e desativar e ativar novamente dá esse problema do erro 103. Tentei usar o controle da porta mas o erro persiste. Interessante é, que se eu utilizar como USB:Tanca ou RAW:TANCA TP-650, local, o erro não acontece de forma nenhuma. Se a impressora compartilhada for detectada de forma local como RAW (caso da NPI0DE3D) o erro também não acontece. Posso desativar, mudar opções, ativar e imprimir que o erro não acontece nesse caso. Será que alguma mudança no ACBrDevice fez isso? Antes não havia necessidade de utilizar ACBrDeviceSerial e agora tenho que utilizar senão dá alguns erros na compilação. Tenho uma máquina com uma versão anterior do trunk2 com o ACBrDevice sem a presença do ACBrDeviceSerial e lá, o erro não acontece em nenhuma das simulações que fiz. Alguém tem alguma ideia do que pode estar ocorrendo ? Obrigado.

Boa tarde estimado, Neste link tem um apanhado geral/mapeado de códigos de erro e de não atendimento das solicitações da NFe/NFCe: https://www.oobj.com.br/bc/article/erros-e-rejeições-na-emissão-de-nfe-e-nfce-mapeados-no-oobj-dfe-453.html No mais, todo resto se encontra em: http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s= Espero que ajude, Até mais

Boa tarde estimados, Para as empresas do simples, quando meu csosn = csosn500 eu preencho os campos com estes valores abaixo pICMSST := 0 ; vBCST := 0 ; vICMSST := 0 ; vBCSTRet := 0 ; pST := 0 ; vICMSSubstituto := 0.0001 ; vICMSSTRet := 0.0001 ; Ainda estou analisando o impacto, mas fiz isso e está validando sem nenhum problema. Verifique se resolve. Abraço.