Contingencia NFC-e

[Jeferson Procopio]

Agora no Topico correto hehehehe

 

           Amigos eu coloquei la tipo de emissao = 9 (tpemis=9) data e hora de contingencia alem de justificativa porem o acbrnfemonitor nao me emite em contingencia, ele da erro de timeout digamos assim. Eu tenho um comando na minha linguagem que trato se ha ou nao internet na maquina e consigo entrar em contingencia automaticamente. A Minha duvida é, eu tenho que alterar o INI do acbrnfemonitor para off-line no tipo de emissao antes de emitir a nfce em contingencia offline... mesmo colocando o tpemis=9 ?

 

           Vi algumas dicas de amigos q fizeram um programinha a parte rodando para envio das nfce em contingencia offline, queria saber como os amigos enviam as notas depois, qual o comando usado para enviar as notas pelo acbrnfemonitor e a sintaxe do comando?

 

obrigado amigos

[Juliomar Marchetti]

Sim tu precisa informar para o aplicativo

[Jeferson Procopio]

Entao para emitir preciso alterar o INI do acbrnfemonitor no momento da emissão ?

 

                  Sabem os comandos e toda a sintaxe para enviar as notas em contingencia offline ?

 

Obrigado

[Italo Giurizzato Junior]

 

Boa tarde Jeferson,

Em offline você não envia nada, apenas gera o XML assina e imprimi o DANFE.

Quando os problemas forem sanados ai sim o XML assinado é enviado.

Por favor na Nota Técnica 2013/005 versão 1.22 você encontra quais os campos devem ser alterados para gerar o XML com o tipo de emissão Offline.

[Eber Constantinov]

Caros,

 

Aproveitando o tópico, gostaria de fazer algumas considerações e uma pergunta: 

1) Temos a disponibilidade do ambiente de contingência com a ressalva de que, segundo a legislação, após a emissão em contingência, temos 24 para efetuar o envio efetivo da NFC-e para a SEFAZ;

2) Uma vez que a internet retorne, ou o SEFAZ retorne, ao realizarmos a tentativa de envio, havendo eventuais erros que impeçam a autorização efetiva na SEFAZ, podemos realizar a correção e posteriormente realizar o re-envio destas NFC-es, efetuando o registro devido na SEFAZ;

3) Porém, e se o motivo que nos impede de contactar a SEFAZ extrapolar o prazo de 24 horas exigido, somos obrigados a cancelar as NFC-es. Mas os produtos já foram entregues e os clientes já saíram da loja. Como proceder ?

Alguém já passou por isso e poderia compartilhar a experiência ?

 

[Italo Giurizzato Junior]

Bom dia Eber,

Você concorda que se o problema é na SEFAZ e o mesmo não for sanado dentro do prazo, ela é obrigada a aceitar as NFC-e com emissão superior a 24 horas?

 

[Eber Constantinov]

Italo,

Desculpe, peço que não interprete minha resposta como rude, mas nós todos sabemos que não se trata do que eu concordo ou não. Não sei qual a sua experiência em relacionamentos com a SEFAZ, mas eu, que preciso credenciar a empresa nos 27 estados para poder operar com o software que comercializo, posso lhe garantir que, o que qualquer atendente da SEFAZ fala ou até mesmo escreve eventualmente para nós, não tem validade nenhuma se não tiver respaldo jurídico.

No fim, quando confrontamos eles em alguma circunstância específica, mesmo que com um email, por exemplo, eles contra argumentam com o artigo x da lei y. E as vezes sofremos até por conta da interpretação dessa lei. Por isso lancei a questão, até para saber se alguém já passou por isso. 

Infelizmente a legislação neste ponto me parece omissa e isso dá margens a variadas interpretações. Pode ter certeza de que eles não se obrigarão a nada que não tenha respaldo na legislação, independente da falha ser do servidores deles ou não.

Além do mais, a falha que eventualmente pode nos impedir de enviar as NFC-es em 24 horas pode não ser da SEFAZ. Todos nós sabemos das limitações de conexões que temos em diversas partes do país. Já tive situações do "caminhão que bateu no poste e levou 5 dias para voltar a internet"... E aí o que fazer ?

A situação é crítica, pois, como ilustrei, o cliente sai da loja com o produto. E agora, se não houve a transmissão no prazo, seguindo a legislação à risca, o cupom deve ser cancelado, até porque se houver tentativa de envio ele será denegado. E se alterarmos a data ou numeração para poder realizar o envio, o que seria mais que meras correções de eventuais críticas ao XML, teremos a alteração do QRCODE, ou seja, o que o cliente levou não tem mais validade nenhuma. E ainda precisamos resolver a questão fiscal e física (estoque) da loja.

Trabalhamos com lojistas em todo o país e em muitas regiões o sinal da internet é precário. Justamente as regiões que, além da precariedade da internet, ainda adotaram o modelo da NFC-e, com todas estas limitações. São Paulo, que teria a internet um pouquinho melhor (também com diversas variações de região para região), se preocupou e criar o SAT que, na minha opinião, dá mais segurança ao lojista, justamente por não depender tanto da internet (no SAT são 10 dias para realizar a transferência e você pode até levar o equipamento para outra conexão e deixar ele fazer o serviço).

Infelizmente, como em muitos casos, os governos dos estados definem determinadas coisas que nem sempre são factíveis e, apesar do prejuízo para todos, eles não estão nem aí. Me parece que houve uma competição entre norte, nordeste e sudeste e sul no sentido de ver quem saía na frente com a iniciativa de um cupom fiscal eletrônico. E nós, desenvolvedores, e principalmente os lojistas/varejistas ficamos no meio desse ridículo fogo cruzado que termina por causar problemas a todos.

É isso.

Eber

 

 

[Italo Giurizzato Junior]

Boa tarde Eber,

Você esta coberto de razão, a SEFAZ sempre no primeiro momento se faz de morta e diz que o problema é externo e que seus servidores e sistemas estão rodandos redondinhos.

Mas acredito que com a massificação da NFC-e, esse e outros problemas vão surgir e ai o negócio vai ser colocar a boca no trombone.

Quando entupir a caixa de e-mail deles com reclamações, eles vão ter que tomar uma providencia.