FAQ – Padrão Nacional NFS-e Orientações práticas para correção dos erros mais comuns

FAQ – Padrão Nacional NFS-e Orientações práticas para correção dos erros mais comuns

Erro: "Falha Schema Xml Correção: The element cServ in namespace http://www.sped.fazenda.gov.br/nfse has invalid child element xDescServ in namespace http://www.sped.fazenda.gov.br/nfse. List of possible elements expected: cTribNac in namespace http://www.sped.fazenda.gov.br/nfse."

O que fazer?
O tag <codTributNacional> deverá estar preenchida. Verificar no XML de envio para a Migrate e também no XML da Migrate. No painel da Migrate há uma validação de recepcionamento de tags. Para validar o valor a ser preenchido neste campo, fazer simulação nos portal nacional




Erro: ": A IM deve ser informada para o emitente prestador do servico na DPS, conforme informacoes complementares registradas no CNC NFS-e do municipio emissor informado na DPS. Pode estar relacionado à tag IM."

O que fazer?
Quando essa rejeição ocorrer, a orientação é verificar inicialmente no ERP, no cadastro de Fornecedores, Clientes e Subempreiteiros, se o campo Inscrição Municipal está devidamente preenchido, pois é a partir desse cadastro que a informação é enviada tanto para a prefeitura quanto para a solicitação municipal. Em seguida, é necessário confirmar se a Inscrição Municipal também está corretamente configurada na Migrate.
Caso o cadastro não possua Inscrição Municipal, a orientação é confirmar a informação com o cliente e realizar o preenchimento tanto no CRTI quanto na Migrate antes de tentar uma nova emissão. Se a Inscrição Municipal já estiver informada e, ainda assim, a rejeição persistir, é importante validar diretamente no Portal Nacional da NFS-e, pois algumas inscrições municipais passaram por alterações recentes, como inclusão ou retirada de zeros ou mudança de numeração.
Por fim, após confirmar os dados com o cliente, recomenda-se realizar a simulação de uma nota para validar o preenchimento antes de seguir com novas emissões, evitando retrabalho e novas rejeições.


Migrate
Painel de Controle > Dados da empresa



Erro: ": Notas com status “Em processamento” no CRTI e na Migrate"

O que fazer?
O status “Em processamento” ocorre porque a Migrate trabalha com uma fila de recepção e tratamento das notas, aplicando ajustes técnicos conforme o layout e as regras específicas de cada prefeitura. A CRTI envia o XML da nota com um layout mais completo, contendo todas as tags previstas no padrão. No entanto, nem todos os municípios aceitam todas essas informações. Dependendo do município e do tipo de operação, alguns campos precisam ser ajustados ou removidos antes do envio final — por exemplo, há prefeituras que não aceitam o envio da alíquota de ISS em determinados cenários.
Essas adequações são feitas diretamente pela Migrate, que é responsável por tratar o XML, adequá-lo às exigências do município e somente então encaminhá-lo para a prefeitura. Enquanto essas tratativas estão sendo realizadas, a nota permanece em processamento. Esse comportamento é esperado e pode ser acompanhado por meio dos logs da nota fiscal de serviço, onde ficam registradas as etapas e ajustes executados. Após a conclusão do processamento, a Migrate retorna o status final da nota, informando se ela foi autorizada ou rejeitada.



Erro: ": O tipo de deducao/reducao informado na DPS nao e permitida pelo municipio de incidencia do ISSQN, conforme parametrizacoes do codigo de servico do municipio de incidencia."

O que fazer?
Quando a NFSe apresentar essa rejeição trata-se de uma rejeição complexa e relacionada a regra fiscal do município, não a um erro ou validação do sistema. Indica que o município de incidência não permite a dedução de materiais nas notas que possuem o serviço indicado. Até cerca de dois anos atrás, era comum que as notas de concretagem permitissem a dedução do valor dos materiais, tributando o ISSQN apenas sobre o valor do serviço prestado. Contudo, esse entendimento foi alterado com a Lei Complementar nº 845, de dezembro de 2024, que passou a estabelecer que o material utilizado no serviço de concretagem não pode ser deduzido na NFS-e. Na prática, cada município vinha aplicando essa regra de forma distinta. Porém, com a migração para o Portal Nacional da NFS-e e a adoção de validações mais rigorosas, especialmente para serviços enquadrados no item 7.02, diversos municípios passaram a bloquear a dedução de forma definitiva. Já identificamos esse comportamento em municípios como Chapecó, Concórdia, Xanxerê, Nonoai e Piçarra, entre outros.

A orientação padrão do atendimento CRTI nesses casos é:
Simular a mesma nota no Portal Nacional da NFS-e ou no portal da prefeitura, quando aplicável;
Confirmar que o campo de dedução não está disponível ou que, mesmo aparecendo, a simulação não permite o avanço da nota;
Validar que essa rejeição não é causada pelo sistema, mas sim por regra fiscal do município;
Orientar o cliente a procurar o setor de fiscalização da prefeitura para confirmar oficialmente essa regra e verificar qual é a orientação adequada do próprio município para o faturamento desse tipo de serviço.




Dessa forma, a orientação ao cliente deve ser clara: não é possível deduzir material na nota de serviço de concretagem nesses municípios, sendo necessário ajustar a forma de faturamento conforme a legislação vigente e a orientação da fiscalização municipal.


Erro: Erros ao integrar municípios que utilizam sistema BETHA

O que fazer?
No início do ano, o Betha apresentou diversos erros, o que impactou diretamente o avanço das integrações. Recentemente, conseguimos autorizar com sucesso a emissão de uma NFSe, após identificar e ajustar os pontos obrigatórios exigidos pelo Betha. Para que a integração funcione corretamente, é indispensável observar os seguintes requisitos:
Configuração obrigatória no Invoicy:
Preenchimento dos campos CNO e ART com exatamente 8 dígitos.
"E"
Envio obrigatório do endereço da obra (O Betha não trata esse dado como opcional. A ausência do endereço da obra é hoje a principal causa de rejeição nas autorizações.)




Por fim, ao término da integração, será necessário encaminhar ao cliente o documento orientativo abaixo, com o objetivo de formalizar todo o processo, garantir ciência das regras aplicáveis e evitar problemas ou questionamentos futuros relacionados à emissão das NFSe.

OBS: Betha está com erros e não permite  o cancelamento via integração. Qualquer cancelamento deverá ser feito diretamente no site da prefeitura 

Warning
TEXTO MODELO
"Prezados,

Conseguimos autorizar uma NFSe no município onde vocês emitem e cujo provedor é o BETHA. Como já é de conhecimento, o BETHA vem apresentando instabilidades e validações indevidas desde o início do ano. A CRTI tem feito todos os ajustes possíveis para minimizar os impactos, dentro do que está sob nossa responsabilidade. Após algumas adequações internas, foi possível autorizar um RPS. Abaixo, listamos os pontos que exigem atenção e decisão de vocês.


1. Preenchimento e liberação de códigos com a Pref.

  • O Código de Tributação Nacional e o Código do Item da Lista de Serviços devem ser informados exatamente conforme o código que autorizou a nota. (colocar o código informado)

  • É necessário revisar todos os cadastros e validar, inclusive junto à prefeitura, se esse código está liberado para o CNPJ.

  • Em alguns casos, a prefeitura não libera corretamente os códigos, e essa validação é de responsabilidade do cliente.

Vou encaminhar abaixo o link de referência para apoio nessa conferência: https://crticombr-my.sharepoint.com/:v:/g/personal/camille_crti_com_br/IQBMM2Ki90bJSKlEoL6nRjSyAVoajGwO5KXWlymrrE8S8w4?nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D&e=GjYizt


2. Exigência de CNO, ART "E" endereço da obra (regra do BETHA)

  • O BETHA exige obrigatoriamente o envio de CNO + ART e endereço da obra no XML. Essa informação não é opcional.

  • Como o provedor está com erro nessa validação, ajustamos o sistema para enviar CNO e ART como “00000000”.

  • Por isso, é obrigatório que o endereço da obra esteja corretamente preenchido na aba Construção Civil da NFSe.


3. Limitação operacional do BETHA

  • Hoje, a cada rejeição, o BETHA exige a geração de um novo número de RPS. Ou seja, um RPS rejeitado não pode ser corrigido e reenviado. Mesmo após o ajuste, ele continuará rejeitando, sendo necessário replicar a nota e gerar um novo RPS para nova transmissão.

  • Isso gera impacto no controle do ERP, pois o RPS original fica vinculado a um ticket. Ao gerar um novo RPS, esse vínculo se perde e o controle passa a ser manual. Esse comportamento não está sob governança da CRTI e não há, até o momento, previsão de correção por parte do BETHA.

    Diante disso, temos dois caminhos possíveis:

    Seguir emitindo as notas dessa forma, assumindo o controle manual dos RPS, com cancelamento do ticket rejeitado e vinculação manual do novo ticket à NFSe, sem responsabilidade de correção ou suporte por parte da CRTI; ou

    Aguardar um posicionamento diferente do BETHA e não emitir as notas pelo sistema neste momento. Até agora, o retorno do provedor é de que se trata de uma nova regra de negócio.

    Seguimos à disposição para apoiar no que for possível, mas reforçamos que, a partir deste ponto, a limitação é exclusivamente do BETHA. Por ora, encerramos a demanda no âmbito da CRTI e ficamos no aguardo da decisão de vocês sobre como desejam prosseguir."


OBS: Betha está com erros e não permite  o cancelamento via integração. Qualquer cancelamento deverá ser feito diretamente no site da prefeitura


    • Related Articles

    • 1. Comece por aqui a entender sobre o cenário de migração para Ambiente Nacional + Reforma Tributária

      Para que a migração da NFSe ocorra de forma segura, é fundamental o alinhamento e a colaboração de todos os envolvidos. A CRTI está realizando uma ampla revisão do ERP para atender às exigências da Reforma Tributária, porém o cenário atual da NFSe no ...
    • 2. Configuração de NFSe - Ambiente Nacional e Reforma Tributária.

      ✔ Sobre a NFS-e (Nota Fiscal de Serviço Eletrônica) No caso da NFS-e, existe uma particularidade importante: cada prefeitura tem autonomia para ativar o Ambiente Nacional, adotar o Padrão Nacional e incluir ou não todos os novos campos. Por isso, ...
    • Cadastro de mais de uma série

      Implementado estratégia para que houvesse o mínimo impacto em configurações no sistema, priorizando assim os clientes e rotina diretamente na tela de Pedidos de Vendas. Será necessário configurar as séries que o emissor poderá emitir NFe. Ao ...
    • Como fazer uma Carta de Correção do CT-e

      A carta de correção (CCe) do CTe é feita na mesma tela de envio do CTe, apenas alterando as informações permitidas pela SEFAZ e clicando no botão Transmitir CCe Acessar a tela Emissão de CTe Pesquisar o número do CT-e que deseja fazer as correções, ...
    • Como fazer uma Carta de Correção (CCe) da NFe

      O CRTI ERP possui uma tela específica para realização de Carta de Correção (CCe) da NFe. Caso não tenha acesso à tela será necessário solicitar ao responsável pelo CRTI na sua empresa que libere ou gerencie a rotina que desejam. Acessar a tela Carta ...