Nota Técnica 2019.001: Atualizações das Regras de Validação

Douglas Pinheiro

A Nota Técnica 2019.001 trata-se de um documento com alto impacto para desenvolvedores e exige regras de validação mais rígidas. Por isso, passa por atualizações constantes, a fim de melhorar os serviços oferecidos aos consumidores.
Nos últimos meses, foram lançadas novas versões deste documento, com inclusão de novas regras de validação relacionadas a itens como: inclusão de campos para informações para crédito presumido; obrigatoriedade de preenchimento do código de benefício fiscal; alterações de regras de validação em operações de aquisição ou prestação de serviços; entre outras atualizações.
Além disso, as versões mais antigas da nota possuem regras que se relacionam com tópicos importantes, como benefícios fiscais, melhora do controle de documentos

Conteúdo

Quais foram as mudanças da Nota Técnica 2019.001 da NF-e e NFC-e?

Basicamente, as mudanças dizem respeito à criação e à alteração de regras de validação da Nota Técnica. Tais regras relacionam-se, entre outras coisas, à inclusão de campos para códigos de benefícios fiscais, alterações de datas de ativação em produção para regras de validação, inclusões e exclusões de CFOPs, entre outras.

A seguir, trazemos detalhes completos das alterações na Nota Técnica 2019.001. 

Versão 1.64

Nesta versão da Nota Técnica, lançada em 3 de setembro de 2024, foram divulgadas novas regras de validação e atualizadas regras existentes da NF-e/NFC-e versão 4.0, com os seguintes objetivos:

  • dificultar utilização de código de segurança fraco;
  • melhorar o controle de documentos referenciados e da identificação do destinatário;
  • descrever benefícios fiscais e informações da tributação do ICMS com mais precisão;
  • criação de valor máximo para a base de cálculo do ICMS por unidade federada;
  • melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC.

A seguir, citamos essas regras:

Ativação da regra de validação N12-85 na NF-e e na NFC-e para SC

Tal regra exige o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. 

O prazo de homologação para tais regras de validação é 4 de novembro de 2024 e a implantação de produção está marcada para 3 de fevereiro de 2025 (no caso da alteração para a NF-e) e 1º de abril de 2025 (no caso da alteração para a NFC-e). 

Inclusão das regras de validação N14a-20 e I05h-10 a critério da UF; e ativação das regras de validação N12-94, N12-98, N14a-20 e I05h-10 para SC

A regra de validação N14a-20 visa o correto preenchimento do campo código de benefício fiscal de redução de BC do Grupo Tributação do ICMS= 51 (tag:ICMS51/cBenefRBC).

Também é incluída a regra de validação I05h-10 para NF-e e NFC-e, que pretende validar o preenchimento correto do campo código de crédito presumido (tag: cCredPresumido).

A regra de validação N12-94 exige que o CST corresponda ao código de benefício fiscal informado, a critério da unidade federada. A regra N12-98, por sua vez, verifica a existência do cBenef, a critério do estado, exceto para Simples Nacional. 

O prazo de homologação para essa regra é 2 de dezembro de 2024 e a implantação de produção está marcada para 28 de abril de 2025. 

Inclusão da regra de validação N14a-10 a critério da UF; e ativação das regras de validação N12-86 e N14a-10 para SC

A regra N14a-10 valida a obrigatoriedade do campo código de benefício fiscal de redução de BC do Grupo Tributação do ICMS= 51 (tag:ICMS51/cBenefRBC). A regra N12-86 impede que se informe o código de benefício fiscal para CST de benefício fiscal, a critério do estado.

O prazo de homologação para essa regra é 2 de dezembro de 2024 e a implantação de produção está marcada para 1º de setembro de 2025. 

Versão 1.63

Publicada em 13 de agosto de 2024, esta versão da Nota Técnica atualiza regras existentes da NF-e/NFC-e versão 4.0 e divulga novas regras de validação, com os mesmos objetivos da versão anterior. 

Esta nota técnica trouxe as seguintes alterações:

  • alteração da data de ativação em produção para NFC-e (modelo 65), pelo DF, das regras de validação N12-85, N12-86 e N12-94; 
  • inclusão da regra de validação I05g-10 a critério da UF. Esta regra verifica a permissão de utilização do grupo de informações sobre crédito presumido na UF. Ela permite que determinado estado possa validar o preenchimento correto da tag: gCred; 
  • adequação dos textos das RV 5E17-10, 5E17-30, 5E17-46, 5E17- 80, 6P31-30 e 6P31-46 conforme NT 2020.005 v.1.10, excluindo os comentários referentes à expressão “(*7)”. 

Em relação às regras de validação, o prazo de homologação foi 5 de outubro de 2020, enquanto para as demais mudanças, a homologação iniciou em 2 de agosto de 2024. O prazo de implantação de produção foi 2 de setembro de 2024

Versão 1.62

Esta versão da Nota Técnica, lançada em 19 de março de 2024, também divulgou novas regras de validação e atualizou regras da NF-e/NFC-e versão 4.0, com os mesmos objetivos das versões anteriores. 

As alterações trazidas por esta versão foram as seguintes:

  • alteração das regras de validação que tratam das operações de aquisição ou prestação de Serviços (RV I08-160 e I08-70); 
  • eliminação da RV I08-17, sobre o mesmo assunto;
  • alteração da data de ativação em produção para NFC-e (modelo 65), pelo DF, das regras de validação N12-85, N12-86 e N12-94;
  • inclusão da obrigatoriedade de código de benefício fiscal para o Espírito Santo na NF-e (modelo 55), conforme legislação interna do estado;
  • atualização do Schema;
  • ateração do leiaute, nomeando a tag do grupo de Crédito Presumido (tag:gCred, Id:I05g).

A homologação dessas alterações foi até 25 de março de 2024. A implantação de produção foi 1º de julho de 2024, com exceção da atualização do Schema e alteração do leiaute, ambas em 6 de maio de 2024.

Versão 1.61

Com os mesmos objetivos das versões mais recentes, esta nota técnica tem como alteração a prorrogação da implantação da versão 1.60 em homologação e informar sobre publicação do Schema XML da versão 1.60 da NT 2019.001 seria publicado em conjunto com o Schema da NT 2023.004 versão 1.10. 

O prazo de homologação para esta alteração foi prorrogado para o dia 11 de março de 2024, enquanto a implantação de produção teve como prazo o dia 1º de abril de 2024

Versão 1.60

A versão 1.60 traz a inclusão de um novo grupo e campos para as informações do crédito presumido e um novo campo para as informações do cBenef.

No grupo I, Produtos e Serviços da NF-e, foi incluído um grupo opcional com objetivo de detalhar as informações do crédito presumido, porém estes campos só serão utilizados conforme determinação de cada UF, ficando logo após o campo cBenef no XML:

  • cCredPresumido_I05h — Código de Benefício Fiscal de Crédito Presumido na UF aplicado ao item; tipo: C, ocorrência 1-1; tamanho: 8, 10; obs.: deve ser utilizado mesmo código adotado na EFD e outras declarações, nas UF que o exigem; 
  • pCredPresumido_I05i — Percentual do Crédito Presumido; tipo: N, ocorrência 1-1; tamanho 3v2-4;
  • vCredPresumido_i05j — Valor do Crédito Presumido; tipo: N, ocorrência 1-1; tamanho: 13v2; 
  • No Grupo N 07. Grupo Tributação do ICMS = 51 foi incluído um campo chamado cBenefRBC visando informar o código de benefício fiscal de redução de base de cálculo dentro do CST 51 quando acumular com o diferimento, devendo ser utilizado conforme critério de cada UF;
  • cBenefRBC_N14a — Código de Benefício Fiscal na UF aplicado ao item quando houver RBC; tipo: C, ocorrência 0-1; tamanho: 8, 10; obs: deve ser utilizado mesmo código adotado na EFD e outras declarações, nas UF que o exigem.

Os prazos para implantação da versão 1.60 foram alterados pela versão 1.61 da NT 2019.001 e foram os seguintes:

  • Ambiente de Homologação: 11/03/2024 (alterado pela versão 1.61);
  • Ambiente de Produção: 01/04/2024.

Porém, a exigência de preenchimento das informações dos novos campos incluídos na NT 2019.001 v.160 é critério de cada UF. Portanto, deve ser observada a obrigatoriedade conforme a legislação de cada estado. 

Versão 1.54

Publicada em 12 de dezembro de 2023, a versão 1.54 da Nota Técnica apresentou novas datas de ativação de regras de validação em ambiente de produção para o Distrito Federal no ambiente de produção em 04/09/2023, para a NF-e, enquanto para a NFC-e a ativação em ambiente de produção foi feita em 01/04/2024.

As regras de validação relativas aos códigos de benefícios fiscais 930_N12-85 | 928_N12-86 | 931_N12-94 estão ativas para a UF Goiás no ambiente de produção desde 01/07/2023. 

Outra mudança é a inclusão da regra de validação 374_I08-171 para NF-e modelo 55, com proibição o uso de CFOPs 1.933, 2.933, 5.933 e 6.933 no grupo de tributação de ICMS (tag: imposto/ICMS), em que retornará a rejeição: CFOP incompatível com o grupo de tributação.

Para a regra de validação 374_I08-171 da versão 1.54, o seu prazo de ambientação e homologação foram os seguintes:

  • Ambiente de Homologação: 12/01/2024;
  • Ambiente de Produção: 01/04/2024.

Além disso, foi incluída a obrigatoriedade de preenchimento do código de benefício fiscal e valor desonerado para Santa Catarina conforme legislação do estado, com data de homologação e produção determinadas para 2 de dezembro de 2024 e 28 de abril de 2025, respectivamente, conforme determinado na versão 1.64 desta nota técnica. 

Versão 1.53

Esta versão apresenta nova data de ativação em ambiente de produção para o Distrito Federal. A mudança irá impactar somente as regras para a Nota Fiscal Eletrônica — modelo 55.

As regras 930_N12-85 | 928_N12-86 | 931_N12-94 seriam ativadas em produção na data de 01/03/2023 (tal regra foi alterada pela versão 1.54). 

Versão 1.52

Esta versão apresenta datas de implantação de regras de validação para Goiás e Distrito Federal.

  • Validação para Goiás: em Goiás, conforme legislação interna, seguem as regras de validação acertadas, com prazo de implantação de produção para 01/01/2023:
  • 930_N12-85: Rejeição: CST com benefício fiscal e não informado o código de benefício fiscal [nItem: nnn]. Serão aplicadas as exceções: 2, 3 e 4; para a NF-e modelo 55, e NFC-e modelo 65;
  • 928_N12-86: Rejeição: Informado código de benefício fiscal para CST sem benefício fiscal [nItem: nnn]. Serão aplicadas as exceções 2, 3 e 4; para a NF-e modelo 55 e NFC-e modelo 65;
  • 934_N12-90: Rejeição: Não informado valor do ICMS desonerado ou o Motivo de desoneração [nItem: nnn]. Serão aplicadas as exceções 2 e 3; para a NF-e modelo 55 e NFC-e modelo 65; 
  • 931_N12-94: Rejeição: Informado código de benefício fiscal incompatível com CST e UF (nItem: nnn]. Serão aplicadas as exceções: 2 e 3; para a NF-e modelo 55 e NFC-e modelo 65;
  • 929_N12-97: Rejeição: Informado código de benefício fiscal incorreto ou inexistente na UF [nItem: nnn]. Serão aplicadas as exceções: 2 e 3; para a NF-e modelo 55, e NFC-e modelo 65.
  • 946_N12-98Rejeição: Informado código de benefício fiscal incorreto ou inexistente na UF [nItem: nnn]. Serão aplicadas as exceções: 2 e 3; para a NF-e modelo 55, e NFC-e modelo 65.
  • Validação para Distrito Federal: já no Distrito Federal, conforme legislação interna, as mudanças foram as seguintes, com prazo de produção para 01/03/2023 (no caso de NF-e) e 01/04/2024 (no caso de NFC-e). 
  • 930_N12-85: Rejeição: CST com benefício fiscal e não informado o código de benefício fiscal [nItem: nnn]. Serão aplicadas as exceções: 2, 3 e 4; para a NF-e modelo 55, e NFC-e modelo 65;
  • 928_N12-86: Rejeição: Informado código de benefício fiscal para CST sem benefício fiscal [nItem: nnn]. Serão explicadas as exceções 2, 3 e 4; para a NF-e modelo 55, e NFC-e modelo 65;
  • 931_N12-94: Rejeição: Informado código de benefício fiscal incompatível com CST e UF [nItem: nnn]. Serão aplicadas as exceções: 2, 3 e 4; para a NF-e modelo 55, e NFC-e modelo 65.

Versão 1.51

Esta versão, publicada em 25 de setembro de 2020, traz informações relacionadas ao Distrito Federal.

Conforme legislação interna, foram implantadas as seguintes regras de validação:

934_N12-90 

Rejeição: Não informado valor do ICMS desonerado ou o Motivo de desoneração [nItem: nnn]. Serão aplicadas as exceções 2 e 3; para a NF-e modelo 55 e NFC-e modelo 65.

929_N12-97 

Rejeição: Informado CST de diferimento sem as informações de diferimento [nItem: nnn]. Serão aplicadas as exceções 2 e 3; para NF-e modelo 55.

923_N12-86

A regra de validação teve sua redação alterada, na qual se passa a verificar se CST não possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF publicada no Portal da Fazenda da respectiva UF. 

626_N-28

Foram incluídos os CFOPs 6905 e 6923 para serem utilizados nas operações isentas destinadas à Zona Franca de Manaus.

A inclusão dos CFOPs na rejeição 626 entrou em homologação e produção em 28/09/2020; as demais mudanças foram ativadas no ambiente de homologação em 05/10/2020 e ambiente de produção em 02/11/2020 (regra alterada na versão 1.52).

Versão 1.50

As principais alterações trazidas por esta versão são as seguintes:

946_N12-98

Como já comentado, esta é a regra que passou a verificar a existência e a validade do cBenef, já se encontrava ativa no ambiente de homologação na data de publicação desta versão. 

Incluída a exceção 5: essa RV não se aplica quando informando CSOSN (operação realizada por optante no Simples Nacional).

931_N12-94

Esta regra já estava em vigor em ambiente de produção na data da publicação da versão 1.50, e continuou verificando a existência e validade do cBenef, bem como a compatibilidade com o CST.

Versão 1.40

Publicada em 30 de dezembro de 2019, a versão 1.40 traz muitas mudanças, entre elas uma nova regra de rejeição, além de novas exceções em regras já existentes. Em relação aos prazos: homologação: 16/03/2020 e produção 11/05/2020 (sendo este prazo alterado pela versão 1.50). As mudanças foram as seguintes:

Regra 946_N12-98

Rejeição: Informado Código de Benefício Fiscal incorreto ou inexistente na UF [nItem:nnn]. 

A regra será aplicada aos modelos 55 (NF-e) e 65 (NFC-e), onde se informando código de benefício fiscal, a mesma deverá:

Verificar se o código de benefício fiscal existe e está vigente

Essa verificação deverá ser feita conforme tabela de código de benefício fiscal por UF publicada pela Sefaz. 

Observação: Implementação a critério da UF por modelo de DF-e. 

  • Exceção 1: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual à Devolução da Mercadoria e Identificador de local de destino da operação (tag: idDest) igual à Operação interestadual ou com o Exterior;
  • Exceção 2: a critério da UF, a RV não se aplica quando a Finalidade de Emissão da NF-e (tag: finNFe) igual à Devolução de Mercadoria; 
  • Exceção 3: a critério da UF, a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual à Devolução de Mercadoria; 
  • Exceção 4: a critério da UF, a RV não se aplica quando Tipo de Operação (tag: tpNF) for igual à entrada.
Verificar apenas se o cBenef é compatível com o CST

Essa nova regra permite que determinada UF possa validar apenas a existência do cBenef, caso não opte por validar a compatibilidade com o CST. A nova regra não exerce impacto sobre os sistemas emissores já preparados para a validação da regra 931_N12-94, salvo o possível tratamento da mensagem da rejeição. 

Além disso, foram adicionadas exceções e modelos às regras: 

Regra N12-85

É exigido o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. 

Regra N12-86

É impedido que se informe o Código de Benefício Fiscal para CST de benefício fiscal, a critério da unidade federada. 

Regra N12_94 

É exigido que o CST corresponda ao tipo de código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada.

Regra 929_N12-97

São exigidas informações sobre o diferimento quando se utiliza um CST de deferimento, a critério da unidade federada. 

Versão 1.30

A versão 1.30 da Nota Técnica 2019.001 apresentou os seguintes comentários a respeito do Código de Benefício Fiscal:

“O código de benefício fiscal (tag: cBenef), por tratar de situações particulares de cada unidade federada, tem sua definição também especificada pelas UF que o utilizam. Estas definições constam de tabela publicada no Portal Nacional da NF-e, na área “Diversos” da aba “Documentos”. Esta tabela tem sofrido atualizações com frequência maior do que a desejável, em virtude do fato que o uso dos códigos pelas empresas no ambiente de homologação tem evidenciado a necessidade de ações de correção de natureza emergencial por parte das Administrações Tributárias envolvidas. É esperado que em um futuro próximo à tabela tenha a estabilidade necessária.”

Foram apresentadas novas datas de vigências em ambiente de produção para as seguintes regras:

930_N12-85

  • Paraná: 02/09/2019;
  • Rio de Janeiro: 01/10/2019; 
  • Rio Grande do Sul: 01/10/2019;
  • Mato Grosso: 01/01/2020.

928_N12-86

  • Paraná: 02/09/2019;
  • Rio de Janeiro: 01/10/2019; 
  • Rio Grande do Sul: 01/10/2019;
  • Mato Grosso: 01/01/2020.

934_N12-90

  • Rio de Janeiro: 01/10/2019;
  • Rio Grande do Sul: 01/10/2019;
  • Mato Grosso: 01/01/2020. 

931_N12-94

  • Paraná: 01/10/2019;
  • Rio de Janeiro: 01/10/2019;
  • Mato Grosso do Sul: 01/10/2019;
  • Mato Grosso: 01/01/2020.

929_N12-97

  • Paraná: 02/09/2019;
  • Rio de Janeiro: 01/10/2019;
  • Rio Grande do Sul: 01/10/2019.

Versão 1.20

Publicada em 20 de agosto de 2019, a versão 1.20 da Nota Técnica traz as seguintes mudanças:

936_1C03-10

A regra não existe mais. Isso porque a razão social da emitente informada tag emit\xNome fosse exatamente igual ao cadastro da SEFAZ, o que se demonstrou problemático. 

934_N12-90

Removida a informação de aplicação somente em casos de operação interna (idDest=1). 

Regras de validação 932_N18-10 e 933_N18-20 são facultativas a partir desta versão da Nota Técnica. 

Também houve uma alteração de layout, em que a tag modBCST passou a admitir uma sexta modalidade de determinação, que é o próprio valor da operação (6 = Valor da Operação). 

Essa alteração viabilizou, entre outras necessidades, o preenchimento da NF-e em operações realizadas por contribuintes substitutos tributários responsáveis pelo pagamento do diferencial de alíquota e da ST.

Versão 1.10

A versão 1.10 da Nota Técnica 2019.001 foi publicada em 16 de julho de 2019, com as seguintes alterações: 

927_H02-10

Rejeição: Número do item fora da ordem sequencial. Essa regra tem o objetivo de informar os números sequenciais do item no arquivo XML “nItem” fora de ordem incremental, consecutiva, a partir de 1. Observação: Regra de validação opcional, a critério da UF. 

930_N12-85

Rejeição: CST com benefício fiscal e não informado o código de benefício fiscal [nItem: nnn]. Essa regra tem o objetivo de validar se informando CST e não informado código de benefício fiscal: — Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. 

928_N12-86

Rejeição: Informado código de benefício fiscal para CST sem benefício fiscal [nItem:nnn]. Essa regra tem o objetivo de validar se e informado CST e informado código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. 

931_N12-94

Rejeição: Informado código de benefício incompatível com CST e UF [nItem: nnn]. Essa regra tem o objetivo de validar se informado CST e informado código de benefício fiscal: — Verificar se o código de benefício fiscal está vigente e correspondente ao CST informado, conforme tabela de código de benefício fiscal por UF. Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST.

929_N12-97

Rejeição: Informado CST de diferimento sem as informações de diferimento [nItem: nnn]. Essa regra tem o objetivo de validar se não informados os campos de valores do CST 51 (Diferimento): — modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSDif (id: N16c), vICMS (id: N17).  

Versão 1.00

Basicamente, as novidades da Nota Técnica 2019.001 em sua primeira versão. As novidades incluíam basicamente regras de validação, bancos de dados e o Serviço de Autorização EPEC. 

A seguir, as alterações trazidas por esta versão da Nota Técnica versão 1.00:

Grupo B: Identificação da NF-e

Foi criada a regra de validação 897_B03-10 Rejeição: Código numérico em formato inválido, para dificultar a invalidação de um código de segurança fraco. Antes, o cNF (código da Nota Fiscal) era um campo ignorado pelas validações da Sefaz.

Já o nNF (número da nota fiscal) sempre foi controlado com rigor, enquanto o cNF era utilizado principalmente para controles internos do software de gestão, como, por exemplo, vincular uma NF-e a uma venda específica. 

Grupo BA: Documento referenciado

A regra de validação BA10-40 Rejeição: Contra Nota de Produtor faz referência somente à NF de outro emitente que foi alterada. Agora, se a Sefaz do seu estado permitir, é possível a utilização do CNPJ-8 com objetivo de identificar que a nota foi emitida pelo mesmo contribuinte. 

No mesmo grupo de documento referenciado, foram criadas três novas regras de validação:

  • 922_BA10-50: Contra Nota de Produtor só pode referenciar NF-e ou NF de Produtor Modelo 4. Exige que uma contra nota de produtor rural só possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada; 
  • 923_BA20-20: Referenciado documentação de operação interna em operação interestadual ou com o exterior. Impede que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior; 
  • 923_BA20-30: Informado Cupom Fiscal referenciado. Impede referência a um Cupom Fiscal, a critério da unidade federada. 

Grupo E: Identificação do Destinatário

Foram criadas três novas regras de validação para o Grupo de Identificação do Destinatário. Todas são referentes a erros lógicos no preenchimento da nota. 

  • 925_E03a-30: NF-e com identificação de estrangeiro e inscrição estadual informada para destinatário. Impede o uso simultâneo de Inscrição Estadual (IE) e de identificação de estrangeiro para o destinatário; 
  • 926_E14-30: Operação com exterior e país de destino igual a Brasil. Impede informar o país de destino Brasil (cPais=1058) em operações destinadas ao exterior (dest/UF=”EX”); 
  • 696_E16a-40: Operação com não contribuinte deve indicar a operação com consumidor final. Informado indicador de IE do Destinatário não contribuinte (tag: indIEDest = 9) e não é operação com consumidor final (tag: indFinal <> 1) em operação de saída (tag: tpNF = 1) que não é com o exterior (tag: idDest <> 3). 

Grupo N: Item/Tributo – ICMS

No grupo N, foram criadas novas regras de validação. Vale ressaltar que tais regras serão aplicadas ou não, a critério de cada estado.

  • 934_N12-90: Não informado o valor do ICMS desonerado ou o motivo da desoneração [nItem: nnn]. Exige o valor do ICMS desonerado (vICMSDeson) e o motivo da desoneração (motDesICMS) quando se utiliza um CST com desoneração (20, 30, 40, 41, 50, 70 ou 90); 
  • 932_N18-10: Informada modalidade de determinação da BC da ST diferente da MVA e não informado o campo pMVAST [nItem: nnn]. Exige a informação do percentual de Margem de Valor Adicionado do ICMS ST informada (pMVAST), caso a modalidade de determinação da Base de Cálculo da ST seja Margem de Valor Adicionado (modBCST=4);
  • 933_N18-20: Informada modalidade de determinação da BC da ST diferente de MVA e informado o campo PMVast [nItem: nnn]. Impede a informação do percentual da Margem de Valor Adicionado do ICMS ST Informada (pMVAST), caso a modalidade de determinação da Base de Cálculo da ST não seja Margem de Valor Adicionado (modBCST<>4).

Grupo W: Total da NF-e

Foi criada apenas uma regra de validação. A regra 935_W03-20 — Valor total da Base de Cálculo superior ao valor limite estabelecido [Valor Limite: R$ XXX.XXX,XX] (valor definido pela UF), que impede a informação de um valor de Base de Cálculo (vBC) superior ao valor máximo estabelecido pela respectiva SEFAZ.

Banco de Dados: destinatário

No Banco de Dados do Destinatário, foram criadas as 11 novas regras de validação:

  • 5E17-10;
  • 5E17-20;
  • 5E17-30;
  • 5E17-40;
  • 5E17-43;
  • 5E17-46;
  • 5E17-50;
  • 5E17-60;
  • 5E17-63;
  • 5E17-70; e
  • 5E17-80. 

Estas novas regras servem para verificar se o destinatário está sendo informado corretamente, ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços. 

Serviço Autorizado EPEC 

Em relação ao Serviço Autorizado EPEC, modo de contingência da NF-e, foram criadas nove regras de validação, sendo elas: 

  • 6P31-10;
  • 6P31-20;
  • 6P31-30;
  • 6P31-40;
  • 6P31-43;
  • 6P31-46;
  • 6P31-50;
  • 6P31-60; e
  • 6P31-63. 

Semelhante às alterações no Banco de Dados: Destinatário, estas regras verificam se o mesmo está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.

Simplifique sua gestão de documentos fiscais com a Focus NFe

Somos um ecossistema de soluções para a emissão e gestão de documentos fiscais, permitindo que empresas dos mais diversos portes e segmentos ganhem mais tempo para focar no que importa.

Sua empresa possui desenvolvedores, sistema interno e quer otimizar a emissão de notas? Conheça nosso conjunto de APIs para emissão de documentos fiscais!

Converse já com a nossa equipe!

Picture of Douglas Pinheiro

Douglas Pinheiro

Analista de Suporte na Focus NFe

Inscreva-se em nossa newsletter​

Receba nossos conteúdos exclusivos em primeira mão.

Explore outros conteúdos:

caminhões em fila na estrada
CTe
Egon Hilgenstieler

CTe: Qual sua função e como emitir?

O CTe (Conhecimento de Transporte Eletrônico) é um documento fiscal digital utilizado por empresas que realizam serviços de transporte de cargas no Brasil. Sua emissão é obrigatória e tem como principal objetivo promover a segurança das cargas e otimizar a fiscalização.

No artigo de hoje explicamos o que é CTe, quais são as suas vantagens, diferenças em relação a outros documentos, assim como emitir e realizar operações corretamente. Confira!

Leia mais »
Contabilidade
Ricardo Acras

Entenda as formas de classificação fiscal para emissão de NF-e

A classificação fiscal serve para identificar mercadorias em vista de uma organização otimizada nos processos de produção, comercialização, importação e exportação. Por meio de uma série de códigos, os produtos são categorizados de acordo com suas características físicas, químicas, econômicas e de uso. Esse sistema é utilizado por governos em todo o mundo para fins de tributação, comércio exterior e estatísticas.

Logo, para garantir a emissão correta da Nota Fiscal Eletrônica (NFe), é essencial entender quais são os códigos exigidos e suas especificações. Acompanhe o artigo de hoje e fique por dentro desse assunto.

Leia mais »
Nota fiscal denegada
Documentos fiscais
Luciano Romaniecki

Nota denegada: o que é, quando acontece e como evitar

A denegação da Nota Fiscal Eletrônica era um o processo em que a Secretaria de Fazenda (SEFAZ) denegava a nota, não autorizando a realização das operações na qual ela se referia, por conta de irregularidades fiscais nos cadastros do emitente ou do destinatário.

No entanto, houve mudanças a respeito desse tema. Basicamente, o processo de denegação é eliminado para a NF-e (modelo 55) e é substituído pelo procedimento de rejeição.

Logo, é necessário que as empresas adaptem as suas operações fiscais. A seguir, trazemos tudo o que mudou e como se deve proceder no caso de sua nota fiscal ser rejeitada.

Leia mais »