Branch separando fiscal position.

[Cloves Almeida]

Pessoal,

como disse em um e-mail anterior, achei a solução para tratamento fiscal baseado no 'account.fiscal.position' muito complexa para configuração. O problema nem é o fiscal.position em si, mas a complexidade da nossa legislação que não se encaixa com o conceito, exigindo literalmente centenas de objetos de configuração. Mas como já disse o Linus Torvards, "Talk is cheap. Show me the code".

Eu criei uma branch separando toda a lógica dependente do "fiscal.position" (e também do "fiscal.operation") em um módulo l10n_br_tax_fiscal_position. A branch é tão somente uma refatoração - ao se instalar esse módulo o resultado é (ou deveria ser) exatamente o mesmo de usar a branch principal 6.1 da localização.

O endereço da branch:

bzr branch lp:~cjalmeida/openerp.pt-br-localiz/6.1-fiscalposition_split

A refatoração é pesada, o diff tem quase 10000 linhas! Os dados de demo estão instalando direitinho, mas como não tenho uma base de produção disponível, tenho dificuldade de testar além disso. Se estiver estável e os líderes da comunidade aceitarem a ideia, faço um merge proposal.

A vantagem é que permite implementações alternativas das regras fiscais apenas criando um módulo "l10n_br_tax_???" sem, no entanto, divergir o modelo de dados.

Na minha empresa, estou implementando as regras fiscais usando "tabelas Python". http://pastebin.com/raw.php?i=Hk09eE6z Quando estiver mais maduro eu crio uma branch com o código completo.

Acho importante manter um modelo de dados coeso para não dispersar a comunidade. Na minha opinião, os módulos "de dados" como "l10n_br_account", "l10n_br_sale", etc. devem ter poucas regras de negócios. Estas devem ser delegadas a módulos "de negócio" que implementam as funcionalidades (regras fiscais, integração bancária, NFe, etc.)

Abraço a todos e ótimo 2013!

Cloves Almeida

[Renato Lima]

Olá Cloves,

Eu demorei um pouco para responder o seu email, na verdade a ultima mensagem sobre o assunto que você tinha mandado https://groups.google.com/forum/#!searchin/openerp-brasil/Regras$20para$20Impostos/openerp-brasil/-n0Pz8h-024/6GUi5cM6IZUJ na lista, quando pensei no desenvolvimento do account_fiscal_position_rule existia dois caminhos, primeiro: criar um conjunto de regras simples mas que iria acabar na geração de grande quantidade de regras para atender todos os casos ou segundo: elaborar um motor de regra mais elaborado e com a flexibilidade para atender mais situações de forma dinâmica que resultaria de regras complexas mas em menor número, no inicio do desenvolvimento foi optado o primeiro caminho, que consegue atender a maioria dos casos de forma rápida.

Eu sugiro você dar uma olhada na branch https://code.launchpad.net/~openerp-brazil-team/openerp.pt-br-localiz/fiscal_position que é uma branch da versão 6.1, mas que essas funcionalidades estão sendo migrada para a 7.0 em que foi melhorado alguns conceitos fiscais para facilitar a configuração fiscal, por exemplo o objeto operação fiscal não existe mais, a função da operação fiscal foi integrado na posição fiscal entre outras mudanças que vale a pena você dar uma olhada.

Atualmente aqui na Akretion estamos trabalhando em melhorar a parte fiscal (como o suporte principalmente na NFe adicionando informações que ainda não tem no OpenERP) e também com a integração do OpenERP, a gente pode analisar a sua proposta para a regras de posições fiscais, a principio se você puder dar uma olhada e adaptar a sua branch com a localização (link acima) podemos olhar novamente e discutir essa melhoria.

Obrigado pela iniciativa em contribuir,

Renato Lima - http://www.akretion.com

--
 
 

[Cloves Almeida]

Olá Renato,

vejo sim sem problema. A questão tributária é complexa e imagino que não terá solução única que atende a todas as empresas. O monstro que é a especificação da NFe que o diga.

Quanto à estratégia regras entre várias regras simples ou poucas regras complexas, eu também prefiro o caminho das várias regras simples por serem mais simples de escrever e manter. Mas a quantidade fica sob controle ao não utilizar um, mas vários objetos de "posição fiscal", resultante da aplicação das regras fiscais, agrupadas por atributo ("regras para CST - ICMS", "regras para Alíquota ICMS", etc.).

Só uma pergunta: imagino que todo o desenvolvimento da localização agora está voltado para a versão 7.0, correto? Acha que a localização na branch 7.0 já está estável suficiente para fazer essa separação?

Como disse, a separação consiste basicamente de migrar para um módulo específico:

a) as dependências ao fiscal_position e fiscal_position_rule;

b) os métodos on_change;

c) os dados dependentes (init, demo, etc.);

d) ajustar os metodos de criação de objetos quando há transferência de atributos (sale.order -> picking -> invoice);

Até imagino que no futuro dá para usar a mesma estratégia para cálculo de folha de pagamento, outro monstro "made in brazil". Imagina só!

--