Leandro Araújo

Realizou alguma configuração pela ferramenta de disgnóstico da Bematech? Aqui ainda sai desconfigurado e salta 4 etiquetas....

Desculpe.. Não tinha visto essa resposta... Mas então, tenho interesse em colaborar.. de alguma forma. Programo em Delphi/Object Pascal e Java, e já utilizo os componentes no ambiente Delphi/RAD, principalmente NF-e. Não tenho um vasto conhecimento, mas acho que consigo colaborar de alguma forma...

Existe algum projeto em que os fontes do ACBr que estão em Delphi seriam portados para Java? Principalmente ACBr NF-e? Se não, alguém tem interesse em iniciar um projeto assim, utilizar a mesma lógica/estrutura utilizadas atualmente no Delphi/FPC, porém voltados para recursos do Java? Estava vendo, existe um curso da T2Ti para implementação de NF-e com Java, foi a única coisa mais próxima que achei de NF-e para essa plataforma, pois projetos como jNFe por exemplo, parecem ter sido descontinuados a um bom tempo, se não me engano, para Java, esse assunto de NF-e é bem escasso, difícil achar alguma coisa, a maioria dos sistemas nessa linguagem tem suas soluções fechadas/privadas, nenhum framework aberto. Visto que a implementação do ACBr é elegante e totalmente padronizada, e como é open source poderíamos aproveitar essa lógica e design para Java... Será que compensa ou não?

Desculpe, sei que o tópico é antigo. Mas, com relação ao Cancelamento, realmente é necessário informar o 'nSeqEvento'? (Visto que é um evento único para nota informada.) Atualmente informo apenas o lote do evento (Obs.:Lote do Evento é incrementado e controlado). Para 'Cancelamento' pode sempre ser 1, ou tem que obrigatoriamente controlar esse sequência? Obrigado.

Entendido e implementado aqui... Obrigado...

Obrigado pelo esclarecimento. Então não posso gerar uma NFC-e referenciando outra NFC-e para devolução, certo? Tem que ser uma NF-e de devolução referenciando a NFC-e.., ok?

Olá, boa tarde. Gostaria de saber se agora, posso utilizar essa diretiva, a {$DEFINE SoapHTTP} juntamente com a {$DEFINE ACBrNFeOpenSSL} descomentadas, ou é incompatível e só funciona com a versão Capicom (Segundo o próprio arquivo ACBr.inc)? Obrigado.

Aqui na minha máquina, com a versão do QuickReport que tenho, o pacote é "QR506RunDXE6W64". Quando o ACBrInstall acusou erros, fui no log, verifiquei cada pacote que deu erro, abri eles com o Delphi, removi a referência a "QR5RunDXE6" (no Requires) e adicionei a "QR506RunDXE6W64" (apenas inclui o nome naquela janelinha de adicionar, ele já busca automático no search path), compilou e instalou com sucesso. Verifique na sua pasta, por exemplo: C:\Program Files (x86)\Embarcadero\Studio\14.0\lib\win64\release, algo assim, para ver se tem os .dcp, .bpl, etc. Abraços. Obrigado.

Olá. Sim, também "desregistramos" e registramos novamente, mas depois de um tempo volta novamente os problemas. Obrigado.

Bom dia pessoal. Apesar do post ser antigo, gostaria de deixar aqui minha experiência com relação ao uso da DLL MSXML na sua versão 5. Em seções locais, no Windows XP e Windows 7 34/64 Bits, funcionou sem crashes, tudo ok. Mas ao utilizar em seções remotas e no Windows Server (No nosso caso, o 2008 R2), tivemos travamentos, investigando bem, observamos que sempre ocorria quando se tentava realizar a Assinatura e/ou Validação do arquivo .XML, mais precisamente quando na unit ACBrNFeUtil, tentava utilizar os recursos da devida DLL, digamos a função ValidaMSXML: function ValidaMSXML(XML: AnsiString; out Msg: AnsiString; const APathSchemas: string = ''; AModeloDF: TpcnModeloDF = moNFe; AVersaoDF: TpcnVersaoDF = ve200): Boolean; E a função AssinarMSXML: function AssinarMSXML(XML : AnsiString; Certificado : ICertificate2; out XMLAssinado : AnsiString): Boolean; Ao utilizar algum recurso COM, algo assim, ocorre algum conflito interno, não sei exatamente. Resolvemos decidindo passar a compilar o ACBrNFe para utilizar OpenSSL/LibXML2 no lugar de Capicom/MSXML, sendo a única limitação, o suporte a certificado A3, dai nesse caso continuamos com o Capicom ou utilizamos o ACBrNFeMonitor para o A3. Realizamos todos os testes no sistemas citados acima, e funcionou perfeitamente, emitimos uma grande quantidade de NFC-e's, fazendo testes de estresse na aplicação e tudo certo até o momento. Conforme já dito por alguns colegas aqui no fórum, pelo que se dá a entender, a versão 5.0 da MSXML é limitada a uso do aplicativos da suíte Office da Microsoft, recomendam utilizar a versão 4.0 ou a 6.0 (Que ao que tudo indica, se adapta as políticas do sistema operacional onde está instalada). Olhem o link, por gentileza: http://support2.microsoft.com/kb/269238/pt-br Fica aqui meu feedbak com relação a esse erro. Desde já, muito obrigado ao pessoal do ACBr, pelo excelente trabalho

Uma solução mais interessante, é a de utilizar o ACBrNFeMonitor em uma estação 32 Bits, para assinar e enviar os .XML's. Mas acho que também poderia ser pautado a troca da versão da DLL, ou não? Obrigado pessoal.

Bom dia colegas. Também estou passando por problemas com as DLLs MSXML, no Terminal Server, e em sessão local no Server 2008. Observamos aqui na empresa, e acontecem telas brancas/travamentos no sistema justamente quando algum recurso na unit ACBrNFeUtil, como AssinarMSXML/ValidarMSXML, ou no retorno, observamos bastante, e parece ser algo relacionado a DLL (não do componente) com o sistema operacional, pois em 32 Bits funciona perfeitamente. Não é sempre que as telas brancas acontecem, mas acontecem. A respeito do teste, realizei testes com a MSXML6 mas obtive alguns erros, como OLESysError, e não encontrar também referências a algumas funções da DLL (vinculo dinâmico), etc. No aguardo. Muito obrigado.

Pra mim deu certo de primeira. Não lembro, mas talvez eu tenha dado um build sim. Obrigado.

Nossa, que estranho. Quando ocorre o erro, seu IDE para em qual unit, ACBrNFeConfiguracoes ou na ACBrNFeUtil?

Não tive mais necessidade de comentar a chamada a CoUninitialize, já que foi corrigido. Creio que não seja bom comentar essa chamada do método, não entendo muito bem e quais os impactos, mas por algum motivo, sei lá, liberação de memória, recursos, objetos COM etc, acredito eu que não seria legal ocultar essa linha. Teria que verificar com os mantenedores do ACBrNF-e.

Boa noite Caetano. Atualizei hoje aqui na minha máquina de produção e está funcionando normalmente. Inclusive observei lá nas units ACBrNFeConfiguracoes e ACBrNFeUtil e estão com as chamadas de CoInitialize e CoUninitialize para possibilitar o uso com thread.

Muito obrigado. Me tirou uma grande dúvida. FCStat := DMNFCe.ObjetoNFCe.WebServices.Enviar.cStat; // Mensagem do status da resposta (Descrição do cStat): FxMotivo := DMNFCe.ObjetoNFCe.WebServices.Enviar.xMotivo; Estava colocando: FCStat := DMNFCe.ObjetoNFCe.WebServices.Retorno.cStat; // Mensagem do status da resposta (Descrição do cStat): FxMotivo := DMNFCe.ObjetoNFCe.WebServices.Retorno.xMotivo; Sendo que envio no modo síncrono, por isso nunca conseguia obter os retornos, status, etc.

É isso mesmo italojjr. Agora se tem efeitos ou não, ai é com vocês que tem mais experiência... hahaha Obrigado.

A solução da Vanessinha Mocellin funcionou aqui também, coloquei onde precisava as diretivas de compilação e deu certo. Bem interessante, melhor comentar no ACBr.inc do que nos fontes né... Bem mais dinâmico, e creio que o mais correto. Obrigado pessoal...

Ok Juliomar, baixei aqui e testei, funcionou, perfeito. Para mim também, foi necessário colocar na function ValidaMSXML, na ACBrNFeUtil: function ValidaMSXML(XML: AnsiString; out Msg: AnsiString; const APathSchemas: string = ''; AModeloDF: TpcnModeloDF = moNFe; AVersaoDF: TpcnVersaoDF = ve200): Boolean; var DOMDocument: IXMLDOMDocument2; ParseError: IXMLDOMParseError; Schema: XMLSchemaCache; Tipo,I: Integer; schema_filename: String; begin CoInitialize(nil); // <-- Aqui... Tipo := NotaUtil.IdentificaTipoSchema(XML,I) ; // ............... DOMDocument.schemas := Schema; ParseError := DOMDocument.validate; Result := (ParseError.errorCode = 0); Msg := ParseError.reason; DOMDocument := nil; ParseError := nil; Schema := nil; CoUninitialize; // <-- Aqui... end; Obrigado.

Entendi, obrigado Juliomar Vai ser feita alguma alteração no ACBr por causa disso? Para atualizar depois..? Achei onde disparava o erro aqui, no meu caso, acontece quando vou assinar o arquivo .XML, onde lança a exception, é na unit ACBrNFeUtil, na function AssinarMSXML, dai importei a unit ActiveX e coloquei uma chamada a CoInitialize(nil) no início, e um CoUninitialize no final: function AssinarMSXML(XML : AnsiString; Certificado : ICertificate2; out XMLAssinado : AnsiString): Boolean; var I, J, PosIni, PosFim : Integer; URI : String ; Tipo : Integer; xmlHeaderAntes, xmlHeaderDepois : AnsiString ; xmldoc : IXMLDOMDocument3; xmldsig : IXMLDigitalSignature; dsigKey : IXMLDSigKey; signedKey : IXMLDSigKey; begin CoInitialize(nil); // <--- Alterei aqui. if Pos('<Signature',XML) <= 0 then begin Tipo := NotaUtil.IdentificaTipoSchema(XML,I); // Restante do código do ACBr... dsigKey := nil; signedKey := nil; xmldoc := nil; xmldsig := nil; Result := True; CoUninitialize; // <--- Alterei aqui. end; Não sei se essa é a solução mais correta, no aguardo da análise de vocês. Obrigado.

Não daria para chamar na 'Finalization' da aplicação? Ou então, chamar novamente o 'CoUnitialize' lá na ACBrNFEUtil, onde está o erro? Desculpem não poder indicar em qual procedure ou function ocorre o erro, por algum motivo o IDE aqui não está debugando, mas mesmo assim para lá na untit ACBrNFEUtil.

Achei, pelo menos eu acho. Percebi uma chamada de 'CoUninitialize' na unit ACBrNFeConfiguracoes. Comentei, no bloco finally da function GetCertificado a chamada 'CoUninitialize', testei e funcionou, depois descomentei novamente e deu o erro. finally Lista.free; end; break; end; Extension := nil; end; break; end; end; if not(Assigned(Result)) then raise EACBrNFeException.Create('Certificado Digital não encontrado!'); finally // CoUninitialize; end; Tem algum problema em comentar ai? Obrigado.

Bom dia Juliomar. Acho que não esclareci direito. Já funcionava antes, com a linha 'CoInitialize(Nil)' descomentada. Apenas atualizei os fontes, observei que já está vindo com a mesma linha descomentada e a uses da ActiveX, porém o erro persiste, como se não estivesse chamando o método, não estou utilizando essas as diretivas de compilaçao do ACBr.inc incluídas pelos colegas {IFDEF ACBrThread}. Obrigado.

Boa tarde. Hoje resolvi atualizar o ACBr, dai quando fui rodar a aplicação, me deparei com o erro: OLeSysError with message 'CoInitialize não foi chamado'. No Delphi aqui, quando dá o erro, ele abre e fica parado na unit ACBrNFeUtil. Detalhe, já utilizamos thread antes para emitir as notas, já havia descomentado a linha CoInitialize(nil); // PERMITE O USO DE THREAD Mas como atualizei pelo tortoise, deu conflito e resolvi o conflito dando preferência para o arquivo do projeto ACBr, depois olhei lá e o mesmo já veio com a uses da unit ActiveX e a linha CoInitialize(nil); // PERMITE O USO DE THREAD descomentada, mas o erro continua. Alguém já conseguiu resolver? Obrigado.