openerp-brazil-team team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

2010/1/11 Henrique Meira <henrique@xxxxxxxxx>

> Olá Raphael, muito boa notícia.
>
> Como posso ajudar a testar estas implementações?
>
> Gostaria de montar vários escopos de testes, como por exemplo as
> transações interestaduais (UF diferentes) e intraestaduais (mesma UF)
> com mesmo produto. Além é claro da sofisticadíssima ST
> (http://pt.wikipedia.org/wiki/Substituição_tributária<http://pt.wikipedia.org/wiki/Substitui%C3%A7%C3%A3o_tribut%C3%A1ria>)
> onde há
> variações de alíquotas durante o ciclo de transição da mercadoria até
> chegar ao consumidor final.
>
> Depois ainda gostaria de entrar em detalhes como partes de produtos
> para fabricação de um outro produto, onde a tributação das partes pode
> ser (e geralmente é) diferente do produto acabado.
>
> Enfim, se puder, me diga como posso ajudar a testar a implementação.
>
> abraços,
>
> henrique.
>


Ola Henrique e os outros,

bom, aos poucos avançamos.  Esse modulo de NCM generalizado que descrevo é
apenas a metade da resoluçao. A outra metade vem do modulo iniciado por
Renato Lima que permitera elabora as regras de seleçao de "fiscal position"
dependente do tipo pessoa e estados de emissao/recepçao de mercadoria.
Vamos dar detalhes logo; enquanto isso, acho que vc entao viu que meu post
dava os links para ver o desenvolvimento/testar.

Com Renato, pensamos em todos casos que voce mentionou, achamos que mata
todos esses, é bem por isso que iniciamos esses 2 modulos.

No caso do NCM generalizado, teve sexta uma conversa interressante com Luc
Maurer da CampToCamp (Suiça; um dos melhores integradores OpenERP, dentro
desde 2006).
Bom, vou fazer varias alteraçoes:
1) o codigo fiscal por produto tem que ser o mesmo do que do modulo
report_intrastat; qual sera ou nao re-approveitado direitamente para
supporte da nota fiscal brasileira (no caso com noassas melhoras aqui:
https://code.launchpad.net/~akretion-team/+junk/report_intrastat
2) meu NCM generalisado nao estava certo em caso de multi-empresa. Por isso
vou mudar os campos one2many que apo tam nas taixas de vendas e compras para
"propriedades", quais sao definidas por empresa. Isso resolve a venda de um
mesmo produto pro varias empresas; com taxas que pertencem entao de planos
de contas deferentes. Os caras da CampToCamp soa os caras (depois do Lula
claro ;-) quando se trata de multi-empresas, quasi so eles fizeram
completamente.
3) em qualquer caso, esse modulo account_product_fiscal_classification nao
sera obrigatorio para localizaçao brasileira, pois alguem pode querer
definir as taxas ao nivel dos produtos ou das taxas assim que foi falado
pelo cara da Zeekom no topic international. Mas claro, isso so basta em
empresa tipo micro-empresa. Quem vender em varios estados, usando a
nomenclatura NCM, se dara muito melhor com esse modulos que ajudarao a
preencher as taxas certas.


Bom, por fim, a boa noticia é que é imminente para nos começar um projeto no
Brasil. Nos caso, nos permittira se dedicar 80% a localizaçao ao inves de 5%
o que deveria lavancar a tropicalizaçao.

Tambem ainda estavamos enrolados com a integraçao de Kettle e OpenERP via
JRuby + OOOR. Tevemos que matar 2 bugs JRuby mais em final de conta estamos
aqui, com pacote pronto imminente, nos explicaremos, mas achamos que é uma
pequena revoluçao para baixar os custos de integraçao ter um integraçao tao
boa entre o OpenERP e um ETL livre poderoso.

Abraço

Raphaël Valyi
http://www.akretion.com.br  - primeiro integrador OpenERP parceiro da Tiny
no Brasil