AllanFC

Revivendo o tópico... Comigo tem acontecido de forma esporádica essa demora de 2 minutos na NFCe, normalmente em clientes com internet ruim, e eu contornei forçando a desconexão do PDV com o serviço que faz o envio, mas acredito que essa não seja a melhor solução. Alguma outra maneira de configurar o componente THTTPSend para dar timeout?

Provável equívoco deste cara. Em recente reunião de algumas empresas associadas a ACATS (Associação Catarinense de Supermercados) com representantes da SEF SC - inclusive alta cúpula da área de TI - ficou claro que eles não tem a menor intenção de que isso ocorra, apesar da pressão das empresas de software e, principalmente, das grandes redes supermercadistas do estado. (Sim! Eles acham que assim diminui a chance de sonegação e que os demais estados brasileiros estão errados) De envio de informação via internet apenas foi citado que logo seremos obrigados a enviar informações de estoque na Redução Z.

Boa tarde, srs. Venho mexendo no ACBr para emissão da NFC-e e NF-e há um certo tempo e nunca tinha me deparado com essa situação que começou a ocorrer para NFC-e no Paraná: Uma nota fiscal rejeitada por NCM (por exemplo), se consultada posteriormente, retorna o mesmo erro da nota quando enviada... Nesta situação eu estava "quase certo" de que retornaria "217 Rejeição: NF-e não consta na base de dados da SEFAZ". Alguém sabe o porquê disso? A sefaz começou a armazenar as NFs rejeitadas também? Apenas para entender a situação no nosso sistema: Caso o usuário cancele a venda, eu executo uma consulta da chave, se o retorno for 100 eu cancelo, se for 217 eu inutilizo. Alteramos para forçar a inutilização nestes caso e o número foi inutilizado com sucesso... Mesmo assim fiquei em dúvida quanto a esse processo e agradeço a quem puder ajudar.

Funcionou. Muito obrigado!

Agora que vi que a solução era mais simples que eu imaginava. Tem que alterar o método Assinar, conforme também foi feito para Capicom, adicionando a linha: XmlAss := StringReplace(XmlAss, '<?xml version="1.0"?>', '', []); Arquivo alterado em anexo. ACBrDFeOpenSSL.pas

Bom dia senhores. Após a liberação das últimas alterações referente a problemas na assinatura utilizando OpenSSL, começou a ocorrer o seguinte erro na inutilização de número de NF: Erro Interno: 0 Erro HTTP: 400 Testei com Capicom e funcionou corretamente. Pude constatar que isso ocorre pois o XML do pedido de inutilização é gerado de forma errada (em anexo os dois XMLs). Para OpenSSL está adicionando <?xml version="1.0"?> sendo que já existe essa informação em <?xml version="1.0" encoding="UTF-8"?>. Atualizei DLLs e Schemas mas não corrigiu o problema. Ao debugar verifiquei que esse trecho é adicionado na function TDFeOpenSSL.Assinar após a execução da instrução: XmlAss := XmlSecSign(AXml, AnsiString(SignatureNode), AnsiString(SelectionNamespaces), AnsiString(infElement)); Não senti segurança para fazer alterações neste método. Agradeço a quem puder ajudar. CAPICOM_15160600298500084765001000000507000000507-ped-inu.xml OPENSSL_15160600298500084765001000000507000000507-ped-inu.xml

Fizemos alguns testes aqui com a nova liberação e não ocorreu mais o erro Certificado Assinatura Invalido com OpenSSL. Muito obrigado aos envolvidos.

Boa tarde. Aqui tivemos diversos casos em que os clientes geraram um novo certificado e passou a ocorrer a mensagem "Certificado Assinatura Invalido". Usamos Delphi e OpenSSL, mas tivemos que alterar a aplicação para utilizar CAPICOM, onde essa mensagem não ocorreu mais. Pode ter a ver com este problema?

No caso do Pará não tem isso. Pior que não tem um telefone onde as pessoas me atendam decentemente... Sefa do Pará ja desisti.

Ninguém com problema parecido? Temos um num cliente no Pará onde a Sefaz está retornando Rejeicao: Emissor nao habilitado para emissao da NF-e. É uma loja recém aberta, onde desde sua abertura emitimos NF-e e NFC-e normalmente, mas teve a inscrição estadual bloqueada (talvez esse não seja o termo certo) pois os fiscais não localizaram a loja no endereço informado (que estava correto). Desfeito o equívoco, a Sefa do Pará voltou a autorizar NF-e porém continuou retornando o mesmo erro no caso da NFC-e. Ligo na Sefa do Pará e eles me dão prazo de 72 horas para responder. Não sei mais o que fazer..

Você tem que utilizar tpEmis := teOffline para contingência da NFC-e.

Muito obrigado pelo auxílio, Italo. Apenas pra finalizar, então devo imprimir a DANFE mesmo não tendo sido autorizada. Neste caso, ela deve ser prontamente corrigida? Ou posso continuar as vendas normalmente e deixar para corrigir em outro momento? Como o tpEmis é "Normal" acredito que no reenvio apenas a data de emissão deva ser atualizada (campo dEmi) pra não ultrapassar os 5 minutos. Estou certo? Caso isso seja possível, irei alterar o sistema para finalizar a venda e imprimir a DANFE da NFC-e mesmo sendo rejeitada. Temos um num cliente onde a Sefaz está retornando Rejeicao: Emissor nao habilitado para emissao da NF-e. É uma loja recém aberta, onde desde sua abertura emitimos NF-e e NFC-e normalmente, mas teve a inscrição estadual bloqueada (talvez esse não seja o termo certo) pois os fiscais não localizaram a loja no endereço informado (que estava correto). Desfeito o equívoco, a Sefa do Pará voltou a autorizar NF-e porém continuou retornando o mesmo erro no caso da NFC-e. (Sim, para NFC-e o erro retornado é o 203, não habilitado para emissão da NF-e). Cliente está com as vendas paradas há dois dias...

Boa tarde, Italo. Será que inutilizar nota rejeitada pode dar problema com o fisco? Pois hoje este é o único procedimento possível caso você cancele a venda. Além do mais, seria facilmente "explicável" já que a venda seguinte teria os mesmos valores. Mas como você contorna erros de validação e rejeição durante as vendas? Algumas validações eu já faço, seja nos cadastros necessários ou ao finalizar a venda, mas sempre ocorrem erros não previstos... E o cliente vai à loucura se tem que deixar um caixa parado.. hehehe

Na pasta ACBr\ACBrDFe\ACBrNFe\ você tem que alterar o arquivo ACBrNFeServicos.ini e executar o Compila_RES.bat desta mesma pasta, o que irá atualizar o ACBrNFeServicos.res. Mesmo assim, estou anexando os arquivos alterados. ACBrNFeServicos.rar

Senhores, desculpe me intrometer, mas gostaria de aproveitar o assunto contingência e rejeição para tirar uma dúvida. Como vocês estão fazendo quanto a rejeição da sefaz? Param a venda? O que eu pensei em implementar pra não parar a venda no PDV é, ao ter uma NFC-e rejeitada, cancelar (inutilizar o número, no caso) e gerar a mesma off-line (com o número seguinte) para uma verificação posterior do cliente. Posso fazer desta forma?