...
Questão: | Como deverão ser informados os valores do grupo de campo N33 - ICMS Efetivo, a partir da NT 2016.002.v 1.60, na Nota Fiscal eletrônica 4.00 Conforme NT 2018.005 - Para as notas fiscais com CST60 com a finalidade a consumidor final tag infFinal = 1 é facultativa, implementação a critério da UF e no Estado de São Paulo a Regra de Validação N12-82 está inativa, não sendo apresentado desta forma a Rejeição 906 - Não Informados os campos para informações do ICMS Efetivo. Nas emissões de documento eletrônico -NFE, emitidos no Estado de São paulo, não devemos calcular e apresentar os campos do Grupo N33-ICMS Efetivo ? |
Resposta: | Foi criado pela NT 2016.002 versão 1.60, um grupo de campos (N33) para informação do ICMS EFETIVO. O grupo de campos foi criado por solicitação de alguns Estados que estão implementando ou vão implementar este tratamento. Na nota técnica, o grupo está como Opcional a critério da UF, ou seja, cada Unidade Federativa que implementar o grupo de campos do ICMS Efetivo é que deve estabelecer, através de um ato normativo, quais serão os critérios a serem adotados pelos seus contribuintes. Este tipo de procedimento é absolutamente normal, em se tratando de um imposto (ICMS), cuja competência e autonomia para os critérios de sua cobrança pertencem ao Estado. Ao analisarmos esta versão da Nota Técnica 2016.002, observamos que junto com o grupo de campos N33 foi criada uma regra de validação na qual, se o contribuinte informar o Código de Situação Tributária (CST) = 60 ou, no caso de a empresa ser optante do Simples Nacional, informar o Código de Situação da Operação no Simples Nacional (CSOSN)= 500 e a operação se der com um Consumidor Final (indFinal = 1), deverá informar o grupo de campos N33. Esta regra de validação está atrelada à utilização do grupo de campos pela UF. Nosso entendimento é que, pela lógica, se não foi estabelecido nenhum ato normativo no Estado, ou ainda, este Grupo de Campos não foi adotado na Unidade Federativa, é possível que não ocorra a validação desta regra. Enquanto cada uma das UFs, que optarem pela utilização deste grupo de campos, não publicarem a sua norma, estabelecendo as regras a serem adotadas pelos contribuintes, não há a possibilidade de realizarmos uma Orientação sobre o assunto, tão pouco definir se haverá ou não rejeição da NF-e, na versão 4.00. Lembramos porém, que esta é uma análise sistemática, baseada no nosso entendimento das regras demonstradas na NT 2015.002 e experiências vividas com outras implementações já realizadas através de outras NTs, publicadas com a mesma regra de outorga aos Estados sobre alguma situação. Baseados nestas análises e na falta de conclusão do assunto, realizamos uma consulta informal em cada uma das Secretarias da Fazenda, que disponibilizam o canal Fale Conosco. Conforme recebermos os seus retornos, publicaremos uma FAQ com as considerações encaminhada pelo Portal. Salientamos, ainda que estas consultas são Informais, não caracterizando a resposta enviada como posicionamento oficial da Sefaz, apenas como orientação ao contribuinte. Nossa orientação é que o contribuinte postule uma consulta formal, na Sefaz a qual esteja vinculado, para que obtenha um posicionamento oficial.
Orientamos que perante ao Estado de São Paulo as tags não precisam ser geradas assim como o cálculo também, devido a regra N12-82 estar inativa85 estar inativa, porém por uma medida pró fisco o cálculo deve ser realizado. (Realizamos abertura de Chamado na Sefaz questionando qual o melhor procedimento neste caso, pois não temos nenhuma orientação e legislação quanto ao assunto). "Esta regra de validação está atrelada à utilização do grupo de campos pela UF. Nosso entendimento é que, pela lógica, se não foi estabelecido nenhum ato normativo no Estado, ou ainda, este Grupo de Campos não foi adotado na Unidade Federativa é possível que não ocorra a validação desta regra"
|
Chamado/Ticket: | 3423225, 7147283 |
Fonte: | http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s= Regras de Validação Facultativas por UF - São Paulo NT 2016.002 v. 1.60 |