Nf e indisponibilidade@fazenda.sp.gov.br

Otávio, discordo que mandar o lote parado resolva. Pra mim, o x da questão, né, é o impacto no financeiro: o fechamento do mês não espera o portal voltar, e a contabilização depende do status. Deixar tudo parado cria um passivo de notas sem status, que pesa depois na conversa com o governo. Prefiro a fila com limite, registrada, a uma espera sem prazo. O prazo do fechamento é o que manda aqui.

Concordo em parte com a Luciana: guardar o registro salva a auditoria. Mas discordo do reenvio automático. Na prática, no meu dia a dia, né, a equipe separa os documentos pendentes numa lista para conferência manual antes de qualquer envio. Isso vale quando o volume é pequeno e cada nota pode ser olhada. Quando o volume cresce, vale uma fila com reprocessamento limitado, que serve para casos diversos e reduz o risco de duplicidade. Esse modelo tem outra vantagem: o time sabe quem divulga o status de cada lote.

Será que a consulta da chave resolve o caso? Discordo do ponto de que o portal seja o gargalo. A dinâmica do lote depende de como o sistema trata o retorno em tempo real, e se o webservice não está disponível, a consulta também não está, então a chave não resolve nada nessa hora. A tela, e aí, diga-se de passagem, só serve de apoio. No nosso caso, o dispositivo que decide é a fila de envio com reprocessamento controlado, não o navegador.

Na minha rotina de auditoria, o caso concreto é a nota gerada que o portal ainda não devolveu. Renato Rocha, completo o seu ponto: o status vem antes da tela, e a chave de acesso correspondente ao lote é o elo que liga o documento à consulta. Vou direto: eu guardo os códigos de retorno numa tabela de controle, com os lotes destinados a reenvio, para ninguém reenviar algo autorizado. Esse registro vale mais que qualquer print e facilita a conversa com o time fiscal.

O resultado que importa é saber se a nota foi autorizada. Não concordo que a janela anônima venha primeiro, porque isso se confere pela consulta da chave no sistema de origem, não pela tela do portal. O curioso é, viu, que limpar o cache mexe só na apresentação e não no status do lote. A codificação do retorno no log é o primeiro dado a olhar, e a leitura complementar vem depois, pelo webservice. Sem um limite de tentativas definido, o reenvio acaba duplicando o que já estava autorizado.

Primeiro, limpe o cache do navegador. O arquivo de estilo do portal leva um cachekey no nome e muda a cada publicação, então a tela antiga fica presa e o campo não responde. Teste depois numa janela anônima. Ah, e bem, minha ressalva: se a consulta da chave continuar sem resposta, o problema está do lado da Fazenda, e a classificação do erro serve para documentar. Anote o horário, o print e a mensagem do webservice, e não reenvie a nota sem antes conferir se ela foi autorizada.