[Como configurar Timeout na comunicação com SEFAZ]

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?

[NFCe em SC]

Em 27/08/2016 at 21:31, davidsonbiz disse:

Recentemente precisei homologar meu pafecf, e minha impressora estragou, então liguei na bematech, descobri que não tinha conserto, então cogitei em adquirir uma nova pra desenvolvimento... O cara me disse que não valia a pena pois SC estava iniciando os trâmites pra aderir a nfce...

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.

[Consulta de NFCe rejeitada retornando o erro da rejeição e não mais o 217 (Paraná)]

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.

[Erro ao inutilizar NFe e NFCe com OpenSSL]

1 hora atrás, Daniel Simoes disse:

Apliquei um Workaround, baseado nas sugestões... favor atualizar pelo SVN e testar

Funcionou. Muito obrigado!

[Erro ao inutilizar NFe e NFCe com OpenSSL]

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

[Erro ao inutilizar NFe e NFCe com OpenSSL]

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

["Falha no reconhecimento da autoria" quando usando OpenSSL]

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.

["Falha no reconhecimento da autoria" quando usando OpenSSL]

15 horas atrás, André Ferreira de Moraes disse:

O problema está na função AjustarXMLAssinado da unit ACBrDFeSSL.pas, amanhã irei tentar debugar e encontrar a melhor solução.

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?

[Nfc-E Distrito Federal Esta Dando Emissor Não Habilitado Mesmo Credenciado]

14 minutos atrás, iransousa disse:

NO DF voce tem que no site http://dec.fazenda.df.gov.br/NFCE/ e fazer o credenciamento da empresa como emissor de NFC-e geralmente o contador faz isso mas como   alguns não sabem fazer eu geralmente acesso a pagina com o certificado do cliente e faço o cadastro , o credenciamento leva em torno de 24hrs para ficar ativo.

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.

[Nfc-E Distrito Federal Esta Dando Emissor Não Habilitado Mesmo Credenciado]

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.. 

[Rejeição ao enviar NFC-e Contingência]

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

[Nfc-E Em Contingencia]

34 minutos atrás, Italo Jurisato Junior disse:

Boa tarde Allan,

Primeiro vamos corrigir a sua primeira frase: onde você diz "Será que inutilizar nota rejeitada..." o correto é dizer: "Será que inutilizar o numero da nota rejeitada..."

Para que outras pessoas não confunda as coisas.

Não vejo com bons olhos a inutilização de numeração, uma vez que a SEFAZ diz que se a nota for rejeitada a mesma deve ser corrigida e enviada novamente.

Segundo o Manual versão 5.00 da NF-e - página 43 Item 4.1.10 trata sobre o processamento do lote de notas enviadas.

Rejeição – a NF-e será descartada, não sendo armazenada no Banco de Dados podendo ser corrigida e novamente transmitida;

Apesar de estar escrito "podendo ser corrigida" veja o quadro abaixo, temos a coluna Consequência para o contribuinte diz "Corrigir NF-e" quando a situação da mesma for: Rejeição.

Se tratando da NFC-e o procedimento é o mesmo, só que para que o cliente não fique esperando, imprima o DANFE, faça a correção e envia.

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... 

[Nfc-E Em Contingencia]

3 horas atrás, Italo Jurisato Junior disse:

Bom dia Allan,

Cancelar não tem como pois você só pode cancelar uma nota autorizada, e no caso ela foi rejeitada.

Inutilizar o numero não acredito ser uma solução viável, pois o fisco amanhã pode lhe questionar sobre isso.

Emitir em Offline talvez seja a solução e depois fazer as devidas correções e enviar novamente pode ser a saída.

Lembre-se que o prazo para autorizar uma nota emitida em Offline é de 24 horas.

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

[Código do Token inexistente para o CNPJ]

Em 16/12/2015 at 10:53, Bruno Meireles disse:

Ninguém nunca passou por isso pessoal ?

O erro ainda persiste !!

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

[Nfc-E Em Contingencia]

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?

[Código do Token inexistente para o CNPJ]

Amigo, veja se você consegue consultar a nota alterando o endereço

De:   https://appnfc.sefa.pa.gov.br/portal-homologacao/

Para:   https://appnfc.sefa.pa.gov.br/portal/

Aqui a consulta funcionou corretamente. Desta forma, acredito que deva ser corrigido pelos amigos do ACBr no fonte ACBrNFeServicos.res.

 

Uma pergunta aos moderadores. Quanto a utilizar o "ACBrNFeServicos.ini", preciso ter o arquivo completo no diretório do executável, ou posso ter apenas o a URL diferente da que está no .res ?

Ficaria um arquivo apenas da seguinte forma:

[NFCe_PA_P]
URL-QRCode=https://appnfc.sefa.pa.gov.br/portal/view/consultas/nfce/nfceForm.seam

Grato a quem puder ajudar.

[URL de envio em homologação (Amazonas)]

Em 24/11/2015 20:36:19, AllanFC disse:

Opa. Não consegui cancelar notas emitidas dessa forma.

Retornou: Erro: Rejeicao: UF informada no campo cUF nao e atendida pelo Web Service.

 

O que posso estar fazendo de errado?

Está certo fazer este contorno que falei no post anterior?

 

Ninguém mais tendo problema para cancelar a NFC-e em ambiente de homologação?

[URL de envio em homologação (Amazonas)]

Opa. Não consegui cancelar notas emitidas dessa forma.

Retornou: Erro: Rejeicao: UF informada no campo cUF nao e atendida pelo Web Service.

 

O que posso estar fazendo de errado?

Está certo fazer este contorno que falei no post anterior?

[URL de envio em homologação (Amazonas)]

Quando em homologação, passei a forçar também a variável ACBrNFe.NotasFiscais.Items[0].NFe.Ide.cUF para 13 pra validar.

Pensei que haveria alguma crítica, mas o servidor do Amazonas autorizou.

 

Podem fechar o tópico.

[URL de envio em homologação (Amazonas)]

Ontem atualizei meus fontes e as notas emitidas em ambiente de homologação (estado do Amazonas) não estão sendo autorizadas.

Verificando as alterações entre a versão anterior e a nova, vi que o fonte ACBrNFeWebServices.pas foi alterado para pegar a UF de autorização do emitente da Nota Fiscal e não mais a configurada no WebService:

procedure TNFeRecepcao.DefinirURL;
var
  xUF: String;
  ok: Boolean;
  VerServ: Double;
  Modelo: TpcnModeloDF;
begin
  if FNotasFiscais.Count > 0 then    // Tem NFe ? Se SIM, use as informações do XML
  begin
    Modelo  := StrToModeloDF(ok, IntToStr(FNotasFiscais.Items[0].NFe.Ide.modelo));
    FcUF    := FNotasFiscais.Items[0].NFe.Ide.cUF;
    VerServ := FNotasFiscais.Items[0].NFe.infNFe.Versao;

    if FPConfiguracoesNFe.WebServices.Ambiente <> FNotasFiscais.Items[0].NFe.Ide.tpAmb then
      raise EACBrNFeException.Create( CErroAmbienteDiferente );
  end
  else
  begin                              // Se não tem NFe, use as configurações do componente
    Modelo  := FPConfiguracoesNFe.Geral.ModeloDF;
    FcUF    := FPConfiguracoesNFe.WebServices.UFCodigo;
    VerServ := VersaoDFToDbl(FPConfiguracoesNFe.Geral.VersaoDF);
  end;

 

Vai ficar dessa forma mesmo?

Tem alguma outra configuração que deve ser feita para funcionar a emissão em homologação de SC no servidor do AM?

[Consulta Nfe Destinadas]

Muito obrigado pela atenção, Ítalo.

 

Abraço.

[Consulta Nfe Destinadas]

Não tem jeito. Não consegui descobrir a situação da Nota.

Então eu mesmo que terei que controlar pelo sistema? Ou seja, a situação atual é a que eu envio à Sefaz?

[Consulta Nfe Destinadas]

Aqui estou alterando para o método DistribuicaoDFe.

Porém, não consegui descobrir o estado atual da manifestação da nota, que antes era em "resNFe.cSitConf".

 

Alguém dá uma luz?

 

Obrigado.

 

Ninguém? 

[Consulta Nfe Destinadas]

Aqui estou alterando para o método DistribuicaoDFe.

Porém, não consegui descobrir o estado atual da manifestação da nota, que antes era em "resNFe.cSitConf".

 

Alguém dá uma luz?

 

Obrigado.

[Mesmo Produto Com Valores Diferentes Na Nfc-E]

Que eu saiba o valor de desconto total não precisa ser rateado entre os itens. E sim o inverso, o desconto de cada item deve ser totalizado como desconto total da NFC-e.

Nosso sistema permite duas vezes o mesmo produto, sendo um com desconto e outro não.