Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

AllanFC

Membros
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

5 Neutral

About AllanFC

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    Blumenau, SC

Recent Profile Visitors

721 profile views
  1. 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?
  2. 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 n
  3. 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 cancel
  4. 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
  5. 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 corrig
  6. 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.
  7. 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?
  8. 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.
  9. 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 s
  10. Você tem que utilizar tpEmis := teOffline para contingência da NFC-e.
  11. 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á retornand
  12. 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
  13. 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
  14. 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?
×
×
  • Create New...