Nfs e nacional orientações gerais para contribuintes de belo horizonte

Na minha rotina de key user fiscal, separo a nota por município, e cada prefeitura tem o seu conjunto de documentos com regras próprias. Pois bem, no meu projeto o caminho que deu certo foi usar o portal nacional só para o padrão, e manter os documentos eletrônicos num gerador próprio quando o município ainda não aderiu. Vale esse caminho quando a prefeitura não aceita o padrão nacional e o prazo aperta; vale menos quando o município já está ativo, porque aí o padrão nacional simplifica a manutenção e evita duplicidade.

Maria, uma dúvida curta: no seu gerador próprio, o emissor já gera o XML no leiaute padrão? Mas, agora, o prazo é o que mais pesa, porque a parte federal exige o compartilhamento logo depois da adesão. Eu acrescento um ponto novo: vale testar o leiaute com um lote pequeno antes da virada e registrar cada retorno da prefeitura, para não depender de memória. Se o gerador não cumprir o leiaute, o envio para a base nacional falha, e o time perde dias corrigindo lote por lote.

Túlio, você tem razão ao separar o papel de cada um, e acrescento um ponto que o pessoal de Belo Horizonte costuma esquecer. E olha, de longe, o sinal mais claro é a lista de municípios que concluíram a parametrização, porque ela costuma mudar. Conforme a orientação, a checagem deve acontecer antes do envio, e o time de integração precisa olhar essa lista no início de cada ciclo, não só quando o erro aparece.

Nós usamos outro caminho. Em vez de depender do portal a cada envio, a equipe guarda o conteúdo das orientações gerais num quadro próprio, e isso vale quando o município já está ativo e a regra de retenção não muda. Quando o contrato com a prefeitura muda, ou quando o contribuinte pede tratamento especial, o caminho manual com checagem de lista é mais seguro. E, então, pra não esquecer, use o quadro no dia a dia e volte à consulta oficial sempre que algo fugir do padrão.

O que importa é confirmar o município antes de qualquer envio, porque a declaração de adesão segue esse fluxo e ninguém quer descobrir isso no meio da emissão. Carlos, você falou do quadro próprio, e eu reforço um ponto: daqueles casos que deram certo, o problema apareceu quando o quadro ficou para trás do portal. Olha, o combinado é tratar o quadro como um apoio, e nunca como referência final, porque a regra vale o que a consulta oficial da NFS-e mostrar. Na prática, o ideal é renovar esse quadro toda vez que a lista mudar.

O risco que já vi é tratar a concessionária como se fosse a prefeitura, e isso faz o time procurar erro no lugar errado. Nádia, discordo com educação do seu adendo sobre a classe de serviço, porque no meu projeto o nó estava na ligação entre as concessionárias e o portal nacional. E, em linhas gerais, tá, o município responde pela própria adesão, e a concessionária só entrega o que a API pede, sem mudar a regra da prefeitura.

Viviane, a dúvida curta é se o município está ativo, e a resposta prática é que, se não estiver, nenhum envio passa. E, como bem lembrou, né, a orientação pede regularização com a maior brevidade possível, então a prefeitura precisa confirmar a adesão antes de qualquer teste. Eu checaria primeiro se o município aparece como ativo no portal nacional da NFS-e e só depois revisaria a parametrização do SAP. Para autorizar o envio, a regra fica no município, e só então cadastrar o vínculo no SAP. Assim o erro deixa de parecer problema de programação.

Concordo em parte com a Priscila: esperar a prefeitura é o caminho certo, mas discordo que a checagem baste sozinha. E, agora, um adendo: vale compartilhar com o time de integração a categoria de serviço usada na nota, porque algumas regras de município dependem dela e o erro só aparece depois. Se a gente compartilhar o diagnóstico com todo mundo, o retrabalho cai e ninguém repete o teste. Compartilhe também o prazo que o padrão nacional informou para não perder a janela.