[Atualizado com a versão 1.53] A Nota Técnica 2019.001, veio recheada de novas regras de validação e atualizações de regras já existentes. Confira!
Publicada em 30 de abril de 2019, a Nota Técnica 2019.001, em sua primeira versão 1.00, no Portal da NF-e, com impactos na Nota Fiscal eletrônica (NF-e), modelo 55, e Nota Fiscal do Consumidor eletrônica (NFC-e), modelo 65.
O objetivo da nota técnica é 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 UF, melhorar o 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 nota técnica 2019.001, em todas as suas versões publicadas ao longo dos anos, apresenta muitas regras de validação novas, além de alterações em regras já existentes. Trata-se de uma Nota Técnica de alto impacto para os desenvolvedores, demandando a implementação de validações mais rigorosas.
Confira as alterações e prepare seu software!
Quais são as mudanças da Nota Técnica 2019.001 v.1.53?
A versão 1.53, publicada em 07 de fevereiro de 2023, no Portal da NF-e 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 – NF-e, modelo 55.
As regras: 930_N12-85 | 928_N12-86 | 931_N12-94 serão ativadas em produção na data de: 01/03/2023.
Quando as alterações da Nota Técnica 2019.001 serão implantadas?
-
- Ambiente de Homologação: 01/10/2022 – GO e DF
- Ambiente de Produção:
- GO: 01/01/2023 (NF-e e NFC-e)
- DF: 01/03/2023 (NF-e) | 01/06/2023 (NFC-e)
Histórico da Nota Técnica 2019.001 e suas versões:
Alterações da versão 1.52
A versão 1.52, publicada em 29 de agosto, no Portal da NF-e apresenta datas de implantação de regras de validação para Goiás e o Distrito Federal:
- Goiás: conforme legislação interna, serão ativadas as seguintes regras de validação:
-
- 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 CST de diferimento sem as informações de diferimento [nItem: nnn]. Serão aplicadas as exceções: 2 e 3; para a NF-e modelo 55.
- 946_N12-98 – 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.
- Distrito Federal: conforme legislação interna, serão ativadas as seguintes regras de validação:
- 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.
- 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.
Alterações da versão 1.51
Publicado em 25 de setembro de 2020, a versão 1.51 trazendo as seguintes informações:
- Distrito Federal: conforme legislação interna, 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 a NF-e modelo 55.
- 923_N12-86: a regra de validação teve sua redação alterada, onde agora 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 6.905 e 6.923 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.
Alterações da versão 1.50
Publicada em 08 de abril de 2020, a versão 1.50 trazendo a prorrogação da entrada no ambiente de produção para 10/08/2020 das alterações realizadas na versão anterior, a v.1.40, em decorrência da COVID-19. Seguem demais orientações e mudanças:
- 946_N12-98: a regra que passou a verificar a existência e a validade do cBenef, já encontrava-se ativa no ambiente de homologação na data de publicação desta versão.
- 931_N12-94: esta regra já encontrava-se vigente em ambiente produção na data da publicação da versão 1.50, e continuou verificando a existência e validade do cBenef, bem como sua a compatibilidade com o CST. Somente em 10/08/2020 que passou a verificar apenas a compatibilidade com o CST.
- 946_N12-98: incluída a Exceção 5: essa RV não se aplica quando informado CSOSN (operação realizada por optante pelo Simples Nacional).
Alterações da versão 1.40
Publicada em 30 de dezembro de 2019, a versão 1.40 apresentando muitas mudanças: uma nova regra de rejeição foi criada, como também temos novas exceções em regras já existentes. Quanto aos prazos: homologação: 16/03/2020 e produção: 11/05/2020 (alterado pela versão 1.50). Vamos as mudanças:
- Criada a 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 informado código de benefício fiscal a mesma deverá:
- Verificar se o código de benefício fiscal existe e está vigente, conforme tabela de código de benefício fiscal por UF publicada pelas SEFAZ. Observação: Implementação a critério da UF e por modelo de DF-e. Exceção 1: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. Exceção 2: a critério da UF, a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a 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 a NF-e de Ajuste; Exceção 4: a critério da UF, a RV não se aplica quando Tipo de Operação (tag: tpNF) igual à Entrada.
- A regra passará a 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 traz impacto para os sistemas emissores que já estão preparados para a validação da regra 931_N12-94, salvo o possível tratamento da mensagem da rejeição.
- Adicionado exceções e modelos as regras: 930_N12-85, 928_N12-86, 934_N12-90, 931_N12-94 e 929_N12-97. Trata-se somente de ajuste da documentação.
Alterações da versão 1.30
Publicada em 30 de agosto de 2019, a versão 1.30 apresentou 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 a tabela tenha a estabilidade necessária.”
Foram apresentadas também 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/10/2019
- 931_N12-94
- PARANÁ: 01/10/2019
- RIO DE JANEIRO: 01/10/2019
- RIO GRANDE 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
Alterações da versão 1.20
Publicada em 20 de agosto de 2019, a versão 1.20 trazendo as seguintes mudanças:
- 936_1C03-10: a regra foi excluída! visto que exigia que a Razão Social do emitente informada na 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).
- 932_N18-10 e 933_N18-20 passaram a ser facultativas a partir desta versão.
- Houve uma alteração de leiaute, onde 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 ). Esta 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.
Alterações da versão 1.10
Publicada em 16 de julho de 2019, a versão 1.10 apresentando as seguintes mudanças:
- Criada as seguintes regras:
- 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 informado 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: – Verificar se CST possui 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 fiscal 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 código de benefício fiscal está vigente e corresponde 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 campos de valores do CST 51 (Diferimento): – modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17).
Nota Técnica 2019.001 versão 1.00
Publicada em 03 de maio de 2019, a Nota Técnica 2019.001 em sua primeira versão (1.00). As novidades previstas pela nota técnica incluem basicamente regras de validação, que se aplicam sobre diversos grupos do layout da NF-e e da NFC-e, além de bancos de dados e até mesmo sobre o Serviço de Autorização EPEC.
Os objetivos da NT 2019.001 incluem:
- 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;
Vamos analisar detalhadamente cada alteração da Nota Técnica 2019.001:
Grupo B. Identificação da NF-e
Criada a regra de validação 897_B03-10 Rejeição: Código numérico em formato inválido, para dificultar a utilizaçã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. Enquanto o nNF (número da Nota Fiscal) sempre foi rigorosamente controlado, o cNF era utilizado principalmente para controles internos do software de gestão, como por exemplo, vincular uma NF-e à uma venda específica.
Com esta NT, a SEFAZ passa a verificar o conteúdo da tag cNF também. Agora, o valor do cNF não pode ser igual ao do nNF. Também não pode conter todos os números iguais (00000000, 11111111, 22222222…) e nem sequências ‘default’ (12345678, 23456789…). Essa validação tem potencial para causar muitas rejeições e muita dor de cabeça ao desenvolvedor que não adaptar seu software. Dependendo de como está seu código hoje, poderá ser necessário implementar uma nova rotina de atribuição do cNF.
Grupo BA. Documento Referenciado
A regra de validação BA10-40 Rejeição: Contra Nota de Produtor referencia somente NF de outro emitente foi alterada. Agora, se a sua SEFAZ Estadual permitir, é possível a utilização do CNPJ-8 com objetivo de identificar que a nota foi emitida pelo mesmo contribuinte.
Neste mesmo grupo de Documento Referenciado, foram criadas 3 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 somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada.
- 923_BA20-20 – Referenciado documento 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 3 novas regras de validação para o Grupo de Identificação do Destinatário. As 3 são bastante óbvias, 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 IE (Inscrição Estadual) 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 estrangeiro (dest/UF=”EX”).
- 696_E16a-40 – Operação com não contribuinte deve indicar 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 exterior (tag:idDest<>3).
Grupo N. Item / Tributo: ICMS
No Grupo N, foram criadas novas regras de validação. Novamente, todas estas regras serão aplicadas, ou não, a critério da SEFAZ 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 como MVA e não informado o campo pMVAST [nItem: nnn]. Exige 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 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 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 Autorização EPEC
Em relação ao Serviço de Autorização EPEC, modo de contingência da NF-e, foram criadas 9 novas regras de validação: 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 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.
Conheça as soluções de Documentos Fiscais da TecnoSpeed
Com as constantes atualizações fiscais, é trabalhoso manter seu software atualizado. Nós podemos ajudá-lo a gastar muito menos tempo com documentos fiscais eletrônicos, com nossas DLLs, APIs, Consultoria Técnica e Tributária.
Com a parceria da TecnoSpeed, você pode focar seu tempo e esforço nos requisitos mais importantes do seu projeto.
