Fala ai Radizeiros e Radizeiras, tudo bem com vocês?

Agora que já estamos gerando e imprimindo nossa nota fiscal, tudo bonitinho e funcionando, vamos trabalhar nossa regra de negócio, trabalhar as regras fiscais, como  por exemplo, quando é regime normal eu coloco o cst, quando é simples o csosn.

Mas você pode estar se perguntando, como eu coloco essas regras em meu código, deixando ele ainda flexível sem engessar ele mantendo as boas práticas.

Vamos lá então na nossa implementação, para nossas regras fiscais, e você verá o como é relativamente simples.

Para essa implementação nós iremos usar outro padrão de projeto, o qual nesse post você irá conhecer e aprender como utilizá-lo, o padrão de projeto Visitor.

Todas as vezes que você tiver uma regra de negócio para ser aplicada, que for mutável, entende-se como mutável, com por exemplo a nota fiscal, os impostos de um produto, os impostos dentro da nota fiscal são mutável. podem mudar de acordo com a regra de negócio, uma tabela de preço é mutável, o preço de um produto ele pode ter a tabela a vista, a prazo, a cartão e atacado, então o preço do produto é mutável, se ele é mutável, você pode preparar seu software para sofrer essa mutações, para receber alguns visitantes dentro da sua classe, é mais ou menos isso o padrão de projeto visitor.

Agora vamos preparar essa nossa estrutura de nota fiscal, para validar o imposto da nota.

Seguindo o que iremos fazer aqui para validar os impostos da nota, vocè poderá replicar para toda a nota fiscal, com maior flexibilidade.

Onde cada uma da nossa estrutura que venha mudar conforme o regime fiscal do cliente, pode implementar esse padrão visitor.

Então vamos ao que interessa…

Agora vamos criar em nossa estrutura as regras fiscais.

Vamos criar uma nova unit e chamá-la de  Blog.Model.Fiscal.NFe.RegrasFiscais.Interfaces.

Observe como ficou nossa estrutura.

Agora vamos tratar os comandos, e os campos que forem mutáveis nesses comandos, irão sofrer influências direto das regras fiscais.

Desta forma irei fazer com que minhas regras fiscais visitem os meus comandos, de acordo com a regra fiscal ele irá ter um comportamento diferente.

Vamos implementar as interfaces para o padrão visitor, e para este padrão iremos precisar simplesmente de duas interfaces para resolver esses problemas.

iModelNFeRegras = interface
   ['{F6D013E9-6CA6-4C6B-BA7C-9107D4311D7C}']
   function ProdutoImpostoICMS : iModelNFeRegras;
end;

iVisitor = interface
   ['{69285067-A966-4240-A17C-649C8EDFB148}']
   function Visit(Value : iModelFiscalNFe) : iModelNFeRegras;
end;

iVisitable = interface
   ['{3B18B734-8049-48BF-AFDB-602C8AB3E513}']
   function Accept(Value : iVisitor) : iModelNFeRegras;
end;

Essas duas interfaces que iremos precisar a iVisitor, que é o visitante, quem irá visitar outra classe, e no nosso caso de quem irá visitar a outra classe é o método que chamamos Visit, que é o nome da visita, que recebe um parâmetro que é específico para as regras fiscais, poderíamos ter um parâmetro genérico, mas preferimos colocar ele para tratar direto as minhas regras fiscais.

E como retorno desse meu método, tudo que precisar ser mutável você deve criar uma interface de regras para ele, onde você pode observar que foi criado uma interface chamar iModelNFeRegras, tudo que for mutavel de acordo com o regime fiscal eu crio um método para tratar minhas regras, por exemplo, imposto do produto, ele é mutável de acordo com o regime fiscal, então eu tenho que ter dentro das minhas regras um método para tratar o imposto do produto, foi o que fizemos no código acima.

Na minha interface iVisitabel é a que permite ser visitada, ela fica com as portas abertas aguardando as visitas das regras fiscais.

Essas três interfaces vão fazer com que possamos criar regras fiscais separada, cada uma no seu devido lugar, de uma forma elegante.

Desta forma a nossa classe não irá precisar ser alterada, mas ela poderá mudar de comportamento, desta forma estamos seguindo um dos padrões do SOLID, isso é muito legal, pois se eu preciso tratar o imposto do produto, eu não tenho que ir lá no meu produto e criar um monte de IF, mas a nossa classe vai estar aberta para extensão e fechada para modificações.

Seguindo o que aplicamos no código acima, com tudo que for trabalhado para tratar dos regimes fiscais podem ser feitos nessa nossa interface.

Continue…

Viu como vamos melhorando todo nosso código para implementação do ACBrNFe, esse é apenas o primeiro post da nossa série de Boas práticas para geração de arquivos fiscais com ACBr, este post foi extraído de um dos meus treinamentos que ensino todas as técnicas de boas práticas com clean code para geração de arquivos fiscais.

Com as técnicas aplicadas nesse treinamento, alem de aprender a aplicar na criação e emissão da NF-e, você pode também aplicar facilmente para o SPED e o SINTEGRA, ou seja, o que é problema para você hoje, depois desse treinamento você irá enxergar como oportunidade.

CLIQUE AQUI PARA SABER MAIS SOBRE O TREINAMENTO BOAS PRÁTICAS PARA GERAÇÃO DE ARQUIVOS DISCAIS COM ACBr