TaxRules

TaxRules (Regras Tributárias) é um serviço do BIS para tentar abranger as leis tributárias. A ideia aqui não é ter a tributação cadastrada por operação, mas sim ter o cadastro das definições das leis.

O foco é conseguir uma adaptação dos conteúdos das leis (texto complicado de advogado) para lógica programável. De cada lei temos de separar o conteúdo em três partes: parâmetros de entrada, lógica e resultados de saída. Mesmo que para completar o quadro o conteúdo venha de leis e de esferas governamentais diferentes.

Esta estrutura está sendo montada a medida que o conhecimento sobre as leis, e a necessidade do estabelecimento vão sendo compreendidas.

Ao reunir todas as informações de forma organizada e categorizada no sistema somos capazes de criar a lógica e o filtro de quais dados de quais tabelas devem ser utilizados. Afinal, se uma "pessoa real" utiliza lógica para encontrar essas informações, essa lógica pode ser transferida para um programa. (Mesmo sem IA e por óbvio cobrindo só os casos programados, o que serve 100% para nosso caso)

Parâmetros de Entradas

Até o momento os parâmetros de entrada detectados são os seguintes:

• Dados do Item - Dados provenientes do Item foco da operação fiscal. Obtidos a partir do cadastro do item. Ex.: Código NCM, Fabricação Própria ou de Terceiros, Origem (Nacional, Importada e variações), tamanho da embalagem, etc.
• Definições da Empresa - São informações provenientes da empresa. Obtidos a partir do cadastro da empresa. Ex.: Regime Tributário, Regimes Especiais de ICMS, Perfil SPED, Estado, etc.
• Operação Sendo Realizada - O principal "definidor" sobre a tributação a ser aplicada é justamente a operação. E o provavelmente o mais difícil de cobrir todas as possibilidades.
• Tabelas e Informações Tributárias - Tabelas fornecidas pelo governo, como tabelas de Pauta e MVA do ICMS. Tabelas de NCMs sujeitos ou não a deferimentos, isenções, etc. Tabelas de NCMs que geram crédito. Tabelas de Itens monofásicos de PIS/COFINS, etc.

Tipo De Itens

Algumas regras tributárias tem desempate em atributos muito específicos de itens. Talvez não seja o melhor exemplo, mas a água é um exemplo de produto que a tributação altera de acordo com o tamanho da embalagem. Casos como esses podem ser resolvido criando campos específicos no Tipo de Item do produto. Campos estes que podem ser utilizado para filtrar a regra que será aplicada.

Requisitos

ICMS/ST

Como o foco atual é apenas a venda direta para consumidor, não estamos preocupados com cadastro das margens de operação, tabelas de pautas, etc.. A única informação que precisamos nesta etapa é se o produto está ou não sujeito a substituição tributária no estado da operação. Assim, nossos requisistos atuais são:

• Estado/UF - Estado/UF à qual a regra se aplica. Obrigatório
• Descrição - Um campo para descrever a regra, a quem se aplica, etc.
• NCM - Código NCM à qual esta regra se aplica. Obrigatório
• CEST - Código CEST à qual esta regra se aplica. Não é obrigatório, neste caso se aplicará a todas as NCMs do estado.
• Sujeito a ST - Indicador booleano para orientar se os produtos que se classificarem nesta regra estão ou não sujeitos a regra de Substituição Tributária de ICMS no estado. Obrigatório

  A ideia de ter a flag é poder diferenciar as regras entre "Está" ou "Não está" sujeito ao regime de substituição tributária. E assim, consideramos que a ausência de regra indica que não temos o conhecimento e não assumimos nenhuma das duas opções. Desta forma chamamos a atenção para o cadastro o tempo todo. Se assumir que a ausência de regra simplesmente indica que não está sujeito ao regime, podemos acabar tributando muitos produtos de forma erradas.

• Início de Vigência - Indica o início da vigência desta regra. Obrigatório
• Fim de Vigência - Indica o fim da vigência da regra. Deixando em branco indica que a regra ainda não foi finalizada e será válida até que tenha seu cadastro alterado.
• Definição Legal - Campo livre para escrita da base legal, fonte e outras informações que justifiquem a regra criada.

Validações

• [ve0001] Se sujeito à tributação ST, obriga CEST - sempre que o campo Sujeito a ST for verdadeiro, o campo CEST passa a ser obrigatório.

Lógica/Fluxo de Decisão e Cálculo

A lógica tributária está separada de acordo com o tributo: ICMS/ST, ICMS, PIS/COFINS e IPI.

Para melhor organização e facilidade na leitura, a lógica da tributação é mantida em um fluxograma e implementada conforme essa definição. Veja os arquivos de cada tributo versionados juntos com o projeto: TaxRuleICMS.vsd, TaxRuleIPI.vsd e TaxRulePISCOFINS.vsd

Assim, o fluxo de filtro e definição não será repetido aqui.

TaxRuleIPI

A regra de IPI é hoje a regra mais simples de ser criada e obtida, por isso vamos usa-la de exemplo. De forma resumida, a tabela de IPI só define uma alíquota de acordo com o NCM, e algumas Exceções (ExTipi).

Ou seja, com base no NCM e no ExTipi já é possível obter a alíquota a ser aplicada. Aqui estamos apenas falando em relação a alíquota à ser aplicada, MAS se ela for aplicada. Saber se deve ser aplicada ou não depende da lógica e regras que são mantidas também nos fluxogramas.

TaxRuleICMS/ST

Esta regra é bem parecida com a regra de IPI em facilidade. Ela simplesmente existe no banco de dados indicando se um determinado produto está ou não sujeito a substituição tributária. As regras são filtradas por UF, Data de Vigência, NCM/ExTipi e CEST.

A regra deve obrigatoriamente existir para efeitos de cálculo, seja para indicar ou não se o item está sujeito a regra de substituição tributária. Embora desta maneira sejamos obrigador a alimentar o sistema mesmo quando o item não está sujeito ao ST, fica mais garantido que não tributaremos algum produto desnecessariamente só por falta da regra.

Atualmente, como o foco é apenas na venda ao consumidor final, a regra não está comportando os dados necessários para o cálculo do ICMS/ST, apenas o indicador se ele está ou não sujeito à ST.

TaxRuleICMS

Já quando falamos do ICMS, a tabela se complica muito mais. Afinal temos uma tributação para cada uns dos 26 estados. A alíquota pode mudar se a operação for interestadual. Além de poder gerar "outros situações" de recolhimento em ambos os estados. O BIS terá suas regras melhoradas e implementadas conforme a necessidade for aparecendo, sem se preocupar, a princípio, com uma visão geral de todas as leis e situações.

Funcionamento

A fachada tem métodos específicos para montar a tributação desejada. Onde, montar a tributação desejada, é saber os valores a serem colocados nos campos dos documentos ficais. São os métodos com prefixo mountTaxRule*. Estes métodos aceitam um TaxBeanVO, que deve conter os Parâmetros de Entrada dentro dele. Os métodos avaliam as informações passadas e completam o mesmo objeto com as informações possíveis e retornam.

Note que dependendo das informações passadas e das configurações do sistema, é possível que o sistema encontre mais de regra a ser utilizada ou mesmo nenhuma conhecida que possa ser utilizada. Em ambos os casos algum afinamento precisa ser feito no sistema. Seja cadastrar as regras faltando, seja entender o que causaria o desempate entre as regras múltiplas encontradas.

A partir do objeto retornado, deve ser possível encontrar todas as informações necessárias para o documento fiscal.

Utilidades

Impressão do TaxBeanVO

Para análise e exibição, a classe FiscalUtils contém métodos de printTaxBeanVO* que geram um conteúdo HTML com o conteúdo do 'TaxBeanVO' de forma mais "humana".

Montagem do TaxBeanVO

A montagem do TaxBeanVO além de ser uma tarefa "chata", que exibe a cópia de diversos dados do CompanyVO e do ItemVO/ItemCodeVO, é melhor que fique centralizada para simplificar a manutenção. Para isso a classe FiscalUtils oferece os métodos mountTaxBeanVO* que copiam informações dos parâmetros de entrada que são provenientes de outros objetos.