Leandro Araújo

Apenas uma sugestão, o projeto ACBr tem nos ajudado muito. Obrigado pela atenção.

Resolvi alterando a unit 'ACBrNFeWebServices.pas', incluindo um método '.Clear' para a classe 'TNFeRecepcao'. procedure TNFeRecepcao.Clear; begin Self.FLote := EmptyStr; Self.FRecibo := EmptyStr; // FNotasFiscais: TNotasFiscais; // Fversao: String; // FTpAmb: TpcnTipoAmbiente; // FverAplic: String; Self.FcStat := 0; // FcUF: integer; Self.FxMotivo := EmptyStr; Self.FdhRecbto := 0; // FTMed: integer; // FSincrono: Boolean; end; Dai antes de qualquer envio eu limpo para evitar algum engano no meu bloco except. // Limpando cStat, dhRecbto, xMotivo etc. ACBrNFe1.WebServices.Enviar.Clear; // ... ACBrNFe1.Enviar(FLote, FImprimir, FSincrono); ACBrNFe1.NotasFiscais.Items[0].GravarXML; //.... // No except: on E: EACBrDFeException do begin FCStat := ACBrNFe1.WebServices.Enviar.cStat; if FCStat <> 0 then begin // Aqui o cStat é tratado em 'ProcessarAposSucessoEnvioNFe'. end else begin // Algum outro erro (Falha de comunicação etc). 'ProcessarAposErroEnvioNFe'. end; end; O que acontece é que após um envio/consulta com sucesso (100), e ao se realizar outro envio/consulta e ocorrer um erro de comunicação por exemplo, ainda está setada a informação do cStat como 100 nos retornos do WebService, no caso apenas estou limpando esses valores, isso também para rejeições, as quais agora o componente lança uma exception e nos tratamentos de excessões pegamos o cStat da rejeição. Para mim esse procedimento foi necessário, pois utilizo o componente de NF-e em um DataModule, ou seja, o componente só é de fato "zerado" quando encerro a aplicação. Vai em anexo a unit 'ACBrNFeWebServices', com um pequeno teste, na linha 1218. Não sei, mas talvez seja necessário fazer para os outros webservices. Muito obrigado. ACBrNFeWebServices.pas Obrigado pela oportunidade Italo, teve um colega, o Waldir Paim, que fez uma alteração dessas também, apenas mandei o modo com que resolvi aqui no meu caso.

Também estou com o mesmo pensamento, e fui ver que algumas propriedades são read only. Seria possível o pessoal do ACBr criar um método '.Clear', algo assim, para não ter necessidade de darmos merge com nossas alterações "próprias"? ACBrNFe.WebServices.Enviar.Clear; ACBrNFe.WebServices.Clear; Muito obrigado.

Realmente, esse erro parece ser de tempo limite estourado. Verifiquei a seguinte descrição no arquivo '...\ACBr\Fontes\Terceiros\synalist\blcksock.pas' na linha 3209-3210 que é um erro de timeout. WSAETIMEDOUT: {10060} Result := 'Connection timed out'; Vou experimentar aumentar ainda mais os intervalos entre as tentativas para ver o que acontece. Obrigado.

Desculpe Daniel, é que acabei digitando o inicio do post e postei. Não se repetirá. Obrigado. Corrigindo: Erro Interno: 10060 Erro HTTP: 0

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL. Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.* O problema que ocorre é que ao efetuar o envio de um lote, ocorre o erro: 'Erro Interno: 11001 Erro HTTP: 500'. Porém ao efetuar uma consulta recebo o retorno da nota autorizada, em alguns casos tenho que fazer mais uma requisição de consulta, pois o mesmo erro as vezes ocorre na consulta e em outros webservices. É como se algo estivesse bloqueado e dai quando faz mais um requisição desbloqueia. Fizemos semana passada a migração para o trunk2 do ACBr, deixando as mesmas configurações de webservice, timeout etc, não sei se tem a ver, porque clientes nossos que possuem o aplicativo compilado com o 'ACBr1' relataram o mesmo problema, então creio que não seja algo diretamente relacionado ao componente, porém esse erro não está nos afetando tanto pois o sistema possui um mecanismo para permitir gerar novamente uma nota somente se a mesma não foi de fato autorizada, enquanto isso o usuário só pode realizar a consulta, não fazer alterações entre outras coisas. Vamos realizar testes com Capicom também. Obrigado.

Também estamos com o meso problema aqui na empresa, no caso utilizando OpenSSL.

Fico feliz em ter ajudado. Obrigado.

Realizamos algumas mudanças e deixamos essa configuração apenas para quando ambiente estiver crítico...

O que fazemos no nosso sistema é que quando o mesmo está configurado para envio Assíncrono (Geralmente deixamos Assíncrono para NF-e, mesmo que seja 1 nota apenas, e Síncrono para NFC-e). No caso da NF-e, se estiver no assíncrono, nas rotinas de processamento a thread dá uma "dormida" por cerca de 2,5 segundos (esse tempo está exagerado... haha) e depois sim consulta o recibo, fizemos assim visando prevenir caso o processamento do 'lado servidor' não seja concluído a tempo e dar também uma "folga" no tempo de consulta do sistema. Qual a opinião de vocês? Obrigado pessoal...

Aproveitando o embalo do tópico... Com todo esse pessoal que estava na versão 2.00 da NF-e e mudaram repentinamente para a 3.10 (Sei que tem gente que mudou gradualmente), tem alguma implicação em enviar a NF-e somente no modo Síncrono ou seria melhor eu enviar no modo Assíncrono e dar um 'timeout/sleep' para minha rotina consultar o recibo, visto que os ambientes das Sefaz podem vir a sobrecarregar por esses dias.. ou não há necessidade disso? Obrigado.

Já utilizando o componente aqui. Parabéns... Obrigado.

Olá, boa tarde. Com relação ao meu problema de não conseguir imprimir corretamente e também da impressora saltar 4 etiquetas, o motivo foi de que faltava calibrar o sensor GAP. Abri o DiagTool, depois no grupo 'Printer Function' cliquei no botão 'Calibrate Sensor', vai abrir uma janela com a opções de calibração, selecionei a opção GAP em 'Media Type', depois no grupo 'Auto Calibration' cliquei em 'Calibrate'. A impressora puxou um pouco as etiquetas para dentro depois voltou, depois disso consegui imprimir corretamente. Fica a dica caso alguém esteja com problema de salto e impressão desconfigurada, experimente fazer a calibração do sensor, as vezes nossa pressa de não consultar o manual né... Obs.: Para mim não houve necessidade de atualizar o firmware. Obrigado a todos.

Entendido. Farei mais testes. Obrigado.

Olá Daniel, então, fiz uma restauração dos padrões de fábrica por um aplicativo disponibilizado pela própria Bematech. Estou em dúvidas, porque aqui quando estávamos com uma Zebra, informamos da propriedade 'Unidade' do componente o valor 'etqMilimetros', porém por esse aplicativo, quando peço para ele ler a configuração da impressora Bematech traz como polegadas, dai mesmo informando como 'etqPolegadas' no componente ACBrEtq ainda apresenta um comportamento peculiar.

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