Painel de líderes

Não uso o ACBr para emitir NFCe, meu software é em C# e eu uso outro projeto (também open source), para tal, logo o problema não é do componente. Sim, testei agora de pouco, o problema esta ocorrendo em produção somente.

Ola, O que poderia ser esta mensagem de retorno da sefaz, se eu enviar uma nota que ja foi aceita novamente, ou enviar uma nova, ambas em homologacao, retorna, comunicacao ok, lote recebido com sucesso, mas ai vem "lote em processamento", e nao imprime a nota. Alguem sabe como resolver isto? ou o que significa isto? desde ja agradeco, Narlem

Olá Fernando Sou de Sergipe.. e estávamos com o mesmo problema. Consigo transmitir agora que alterei de Assincrônico para Sincrônico.

Tem uma nota no portal da SEFAZ: https://www.receita.pb.gov.br/ser/announcements/4530-receita-estadual-libera-em-carater-excepcional-a-emissao-de-notas-fiscais-eletronicas-neste-final-de-semana Notícia (que foi editada há pouco)

Na NF-e também está dando e já postaram que em outros softwares que não utilizam o ACBr também ocorre. Em homologação está OK. Tudo indica que o problema é na SEFAZ.

Pessoal bom dia, aqui em SE estamos com o mesmo problema, eu resolvi aumentando o tempo de "aguardar" e "intervalo" no ACBr e resolveu.

Até as 09 horas e 04 minutos de hoje estava tudo normal. Tenho NFCe protocoladas antes deste horário.

Em Alagoas ta dando o mesmo problema.

Acho que não é questão de atualização pois eu já atualizei o ACBrMonitorPlus para a última versão disponível no site (de 29/09/2016 - versão 1.0.0.0) e o problema persiste. O que pode ser é alguma implementação a nivel de XML que não tenhamos feito.

Bom dia. Estamos usando o AcbrMonitorPlus e estamos com o mesmo problema para emitir NFCe no estado de Rondônia. Há mais de uma hora que nossos clientes não conseguem emitir NFCe mas emitem NFE normal.

Também estou com este problema no RN, orientei os clientes a removerem o cabo de rede e emitir offline, no meu caso trabalho com supermercado, não posso nem sonhar em ficar sem emitir nfce.

Allan, Como dito para gerar o XML do CT-e na versão 1.04 é preciso habilitar uma diretiva de compilação. Se você abrir o arquivo ACBr.inc vai encontrar as linhas abaixo: // Definições para o compomente ACBrCTe // Define o Pacote de Liberação / Descomente o pacote a ser utilizado // Atenção: descomente apenas uma das definições //------------------------------------------------------------------------------ //{$DEFINE PL_103} //{$DEFINE PL_104} {$DEFINE PL_200} Note que por padrão esta habilitado a diretiva da versão 2.00. Para gerar o XML segundo a versão 1.03 temos que habilitar a diretiva PL_103, o mesmo ocorre com a versão 1.04 e 2.00 Não teremos uma nova diretiva para a versão 3.00 pois a estrutura do XML é muito parecida da versão 2.00, as diferenças conseguimos resolver com a propriedade VersaoDF. Não vejo necessidade de remover a condição, pois a rotina que contem essa condição só é usada pela versão 2.00 ou 3.00, como dito anteriormente para gerar na versão 1.04 é outra rotina que nem sequer tem essa condição. Ao habilitar a diretiva PL_104 é usada a rotina que se encontra no arquivo pcteCTeW_V104.inc Para demostrar o que estou dizendo, abra o arquivo pcteCTeW.pas temos logo no inicio: {$I ACBr.inc} unit pcteCTeW; interface uses SysUtils, Classes, pcnAuxiliar, pcnConversao, pcnGerador, pcteCTe, ACBrUtil, pcteConversaoCTe, pcnConsts, pcteConsts; {$IFDEF PL_103} {$I pcteCTeW_V103.inc} {$ENDIF} {$IFDEF PL_104} {$I pcteCTeW_V104.inc} {$ENDIF} {$IFDEF PL_200} // {$I pcteCTeW_V200.inc} //////////////////////////////////////////////////////////////////////////////// // // // Gera o XML para a versão 2.00 // // // //////////////////////////////////////////////////////////////////////////////// A linha em negrito e em vermelho foi colocada prevendo uma nova versão totalmente diferente da versão 2.00, mas isso não ocorreu. Logo não existe o arquivo pcteCTeW_V200.inc Espero ter deixado claro que não se faz necessário remover a condição.

Boa tarde Allan, Quem ainda usa a versão 1.04 do CT-e? Essa versão deixou de ser aceita pela SEFAZ em 01/06/2014. E esta previsto o fim da versão 2.00 em 04/12/2017, a partir dessa data a SEFAZ só vai aceitar a versão 3.00 do CT-e. Outra coisa para poder gerar o XML do CT-e segundo a versão 1.04 é preciso habilitar uma diretiva de compilação que encontra-se no arquivo ACBr.inc Com isso será usado uma outra rotina para gerar o XML que por sinal nem sequer existe essa condição, ou seja, as informações do seguro é gerado independente de versão.

Alterações enviadas ao SVN, obrigado pela colaboração.

Segue mesmo arquivo denovo com pequena correção no ESCPO, tinha ficado Prod.vOutro ao invés da nova var VlrAcrescimo em uma linha... Att Ricardo ACBrNFeDANFeESCPOS.pas

Boa tarde Eduardo, Favor atualizar os fontes e faça novos testes.

Use a StringToFloat da unit ACBrUtil que já faz esse tratamento: FNFSeW.NFSeWClass.VersaoDados := StringToFloat(Configuracoes.Geral.ConfigXML.VersaoDados);

Olá Amigos, Passei pelo mesmo problema e realmente a instalação padrão do ACBR / Fortes no Windows 10 ira apresentar os problemas acima mencionados. Estes procedimentos resolveram o problemas nos pacotes que usam OpenSSL: - Ao instalar o o ACBR marque a opção Copiar DLL pasta bin do DELPHI. - Copie todas as DLLS da pasta DLL do Acbr para a pasta SYSTEM32 e SYSWOW64 - Registre a DLL capicom manualmente e certifique-se que o comando obteve êxito. Estes procedimentos resolveram o problemas nos pacotes que usam FORTES: - No IDE do Delphi remova o pacote do FORTES caso já tenha instalado. - Não instale o fortes pelo instalador, abra o Pacote no Delphi Compile e instale, - Agora basta Reinstalar o ACBR que os pacotes irão carregar normalmente no delphi. Renato Campos.