Maiconn Koczenski

Boa tarde a todos. Pessoal encontrei uma nota da receita que diz o seguinte : "É vedada a reutilização, em contingência, de número de NFC-e transmitida com tipo de emissão 'Normal' " No mesmo documento tem um exemplo para uso da contingência offline Tentativa de transmissão Há a tentativa de transmissão de uma NFC-e com numeração 20. Há um problema técnico na comunicação ou processamento das informações. Não há retorno da SEFAZ. Observação: É vedada a reutilização, em contingência, de número de NFC-e transmitida com tipo de emissão 'Normal'. Emissão off-line A NFC-e é emitida offline com numeração diferente, n° 21, para evitar a duplicidade da nota. Deve-se imprimir o DANFE-NFCe, em duas vias ou manter em local seguro o arquivo digital, sendo impresso para apresentar ao fisco quando solicitado Observação:  Caso na tentativa de transmissão (opção 1) o serviço de comunicação seja retomado, e a NFC-e autorizada,o procedimento correto é cancelar a NFC-e n°20.  Caso não haja tentativa de transmissão, a numeração utilizada na emissão off-line pode ser mantida. Transmissão Superado o problema técnico, a NFC-e n°21 é transmitida para obtenção da autorização de uso. Se vier a ser rejeitada, gerar novamente o arquivo com a mesma numeração e série, sanando a irregularidade e transmitir novamente. Para aquela que ficou pendente de retorno (a nota n° 20 desse exemplo):  inutilizar a numeração, se não autorizada; ou  cancelar, se autorizada. Eu me assustei ao ver isso tudo pois hoje eu tento transmitir... se a nota não obter resposta eu imediatamente faço a impressão offline e resolvo a nota mais tarde mas utilizando sempre a mesma numeração... no meu caso tenho muitos problemas com: Duplicidade de NFe com diferença na chave... Diferença também no DigestValue, entre outros problemas... acredito que são ocasionados pela tentativa de transmitir uma nota que anteriormente foi para a areceita em situação normal mas que não obtive resposta. Por fim o que é correto fazer quando não se obtém resposta em uma transmissão? muitas vezes ao transmitir retorna cStat = 0 e xMotivo = '' neste caso para não segurar o andamento eu imprimo offline para liberar o cliente que está aguardando com as compras... isso em supermercados como ficaria? é necessário realmente abandonar aquela nota e gerar uma nova com a próxima numeração? Existem 2 situações no meu caso: 1° tem internet no cliente, mas ela está lenta, instável etc... dai a nota transmite mas não obtém resposta... consequentemente estas notas eu tenho problema para conseguir autorizar depois.. 2°não tem internet no cliente, completamente offline... neste caso a receita não sabe da existência da nota... nesta situação transmite em contingência offline normalmente pois não vai dar conflito, a primeira tentativa não chegou a enviar a nota.

Pessoal quando eu vou transmitir uma nota, a transmissão falha... eu imprimo offline... neste momento já preciso colocar motivo de contingência offline e data e hora que entrou em contingência? eu nunca coloquei isso, e hoje me deparei com uma nota que ao tentar carregar o XML original dela para transmitir pediu data e hora de entrada em contingência... está certo isso?

Olá pessoal. Venho recorrer a vocês sobre um problema que estou enfrentando, e está se tornando insustentável nos clientes. Poise bem na empresa onde eu trabalho, atendemos a alguns supermercados. Desenvolvemos um sistema monitor de notas, onde fica uma Thread/Timer rodando e verificando se existem notas por serem transmitidas. Cada caixa do supermercado utiliza uma série distinta. E cada caixa tem seu monitor de envios independente, ou seja, se um caixa parar, os demais continuam funcionando. O que vem acontecendo com frequência é o aumento de casos de "consumo indevido"... Andei lendo as notas técnicas a respeito, e já estou ciente que o erro se dá ao número de requisições para o mesmo documento em um curto espaço de tempo... Porém existem algumas situações rotineiras que acontecem neste clientes... uma delas, é ao transmitir a nota fiscal pela primeira vez, em alguns casos a aplicação demora a obter resposta, e acaba recebendo cStat = 0, e xMotivo = vazio... neste caso eu não sei afirmar se é algo de errado com a sefaz do meu estado, ou se pode ser a conexão com a internet do cliente... a aplicação demora a obter resposta quando recebe o cStat = 0... e quando isso acontece imediatamente "para não segurar o andamento do caixa" eu imprimo a nota fiscal em modo offline... e no banco de dados eu mudo o status desta nota como pendente... dai então tenho outra fila de processamento em segundo plano... que tenta transmitir estas notas pendentes quando não há notas novas na fila de processamento.... "já mais executo 2 transmissões simultaneamente"... o problema começa a acontecer quando tento transmitir estas notas que estão pendentes... tenho como hábito consultar a nota antes do envio... se a nota já estiver na receita eu pego chave e protocolo e dou por encerrada... se a nota não estiver na receita então eu executo a transmissão novamente.... este processo de consultar e executar a transmissão na maior parte dos casos gera consumo indevido.. Resumindo tudo o sistema vinha funcionando corretamente até 1 mês atrás... começou recentemente... não sei se estou lidando com uma instabilidade de conexão nos clientes, ou estou lidando com alguma eventual mudança de regras na sefaz do meu estado... estou compartilhando com vocês esta situação pois estou ficando desamparado de alternativas, já tentei muitas coisas, porém não estabiliza... estou pensando em desistir de consultar as notas... tentar enviar todas, e somente o que der duplicidade eu consulto... não sei se é certo ou errado fazer isso... Lembrando que só acontece isso em supermercados com vários caixas, onde o volume de notas é muito grande. Alguém teria alguma sugestão ou resposta? Fico agradecido a todos pela atenção. E aos administradores, me perdoem se eu dupliquei o assunto, porém não encontrei algo exatamente semelhante ao que acontece no meu caso. Obrigado.