openerp-brazil-team team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

2009/12/12 Henrique Meira <henrique@xxxxxxxxx>

> Sim, uma boa perspectiva.
>
> A questão do layout da NF-e é complicada sim, de propósito? Não posso
> afirmar. Mas como tenho envolvimento direto com as pessoas responsáveis por
> projetos deste tipo na SEFAZ, posso afirmar que muitas vezes nem eles mesmos
> sabem pq pedem determinada informação. É de irritar qualquer um.
>
> Com relação ao XML, também é possível gerar um arquivo texto, um pouco mais
> simplificado. Você já chegou a ver isto? Recentemente desenvolvemos, em
> delphi, uma extração de um cliente para este formato TXT. Também o fazemos
> em XML, neste caso em Java.
>
> Nota importante: já saiu a vesão 4.0 do documento que determina o layout da
> NF-e, mas o sistema da SEFAZ/SP ainda está utilizando a versão anterior. É
> sempre bom ficar atento à estes casos para que a extração não pare de
> funcionar da noite para o dia.
>
> henrique.
>


Ola Henrique,

Quando falo que a NFe brasileira me parece complicada de proposito, nao
estou falando do layout (que nao sera tao dificial alcançar), mas aos
webservices SOAP encryptados para se comunicatar com o servidar da receita
federal. Dei uma olhada nos programas Java que fazem (os caras sao tao buros
que nem obfuscar o codigo direito eles sabem), sao umas 50 000 linhas de
Java bem complexo com varios webservices para cada coisa, sem nenhuma
explicaçao clara de que fazem que achei.

Me parace estranho esse protocol estar tao trabalhoso. Fiquei sabendo que na
Argentina e Ecuador eles tambem tem coisas parecidas com NFe brasileira. So
que por exemplo no Ecuado, o Cristian Salamea  (ovnicraft), conseguiu fazer
em 500 linhas de Python. Na Argentina, os caras dda Thymbra tambem fizeram.
Mesmo que Python seja bem menos verboso do que Java, para fase-lo no Brasil,
teria provavelement que ter a minimo 10 000 linhas codigo. Me parece absurdo
na epoca do Rails e do REST. Dai sempre me perguntei se alguiem nao quis
fazer o standard complexo assim so para garantir o monopolo de quem
implementou. Mas ai, ja nao tenho mais provas é apenas suposiçoes...

De qualquer forma, que planejamos fazer é exportar ods dados de NFe em XML
ou texto para um daqueles 2 softwares "oficiais" em Java que se comunicam
com o servidor da receita federal. Claro, é um pouco mais chato que se fosse
todo integrado, mas acho que ate a Totvs nao faz melhor em algums ERP's
deles (meu socio Renato podera confirmar).

Pena que voce chegou agora na discussao porque nos ja debatimos sobre isso
ha algums messes, mas tudo bem, é bom mesmo confirmar as decisoes.


Assim que eu falei, nosso primeiro paso a relaçao de Nfe sera de extendir a
estrura de dados do "account.invoice" do OpenERP para nao faltar informaçao
par NFe. Ate que se prova on contrario, me parece melhor faze-lo em cima do
modulo report_intrastat na sua verao melhorada (sera integrada na 5.2, teve
confirmaçao da Tiny) porque ja responde as umas coisas (possibilide de
fatura sem parte finacieara é codigos em funçao de que estado vende e recebe
o produto) de forma integrada com o ERP.

Depois que acertamos isso, passaramos a cuidar do exporte em XML/txt para
software de NFe. Nao sei exatamente se voce pretende ajudar numa daquelas
tarefas, mas voce pode dar um pensadinha e falar. Bom de qualquer jeito,
melhor se virar direito com o OpenERP antes de contribuir codigo porque
senao nao tera qualidade, entao de qualquer jeito voce pode gastar umas
semanas para teinar, je que sera preciso. Acho que me socio Renato teria mas
tempo agora tambem para se dedicar na articulaçao dessas tarefas com quem
quer contribuir. Voce pode tambem analisar o novo modulo report_intrastat
para ver com melhor encaixar ele no suporte da NFe.
https://code.launchpad.net/~akretion-team/openobject-addons/openobject-addons_5.0_report_intrastat

Nos explicaremos melhor que ele faz. Por enquanto o chato e que estamos
ainda ocupados com projetos OpenERP europeos; temos sim um especificaçao da
evoluçao do report_intrastat que fizemos, so que o cliente (Anevia) fez em
frances e tambem corrigimos umas coisas, entao nao é mais exatamente que
fois espeficicado. Quer dizer, nos vamos precisar de algums dias para
documentar isso em ingles, agora se alguem que botar a mao na massa, fazer
revese engineering do codigo, conversar com nos e faze-lo, sejam bem vindos.

Bom, do nosso lado, como falei, para optimisar nossa carga de trabalho,
ainda pegamos projetos europeos por enquanto ate que a opçao brasileira se
torna provavel suficente para nos. Quer dizer, nos ajudamos ja como ninguem
a tropicalizaçao com o modulo l1àn_br, mas passara a accelerar muito caso
comemos um projeto brasileiro. Nos temos ums 3 contatos avançados, que podem
iniciar projetos em Janeiro, sendo benefico para os dois lados. Caso
iniciar, logo cuidaremos do export da NFe e os outros assunto segundarios
mas trabalhosos. Agora claro, quem quiser contibuir as coisas mais
rapidamente fica a vontade, nos ajudaremos a atricular os trabalhos. Tambem
tem a opçao academica, nos vamos sim fazer parceirias (ja temos com a "UTC"
na França e a Universidade de Saragossa na Espanha no momento), mas como
falei, nao estou tao optimisto com isso porque alunos, se uteis em algumas
parte de projetos de integraçao (como reportes, alteaçoes da 'views'..),
dificilemente terao nivel suficente para contribuir codigo com qualidade
suficente para coisas tao importantes. na verdade isso é tanto devido a
complexidade de um ERP como a falta de qualidade que ainda pode haver no
OpenERP (apesar do melhor open source), que dificulta muito a tarefa.

Por fim, nao tudo mundo precisa da NFe. Talvez começamos por esse tipo de
cliente que tem contabilidade externalizada para alisar melhor o custo da
tropicalizaçao, continuando a avançar...

Olha, pensando bem, logo que temos os dados para a Nfe, quem treinar com os
reports do OpenERP podera facilemente contribuir o layout da NFe. Seria uma
boa divisao do trabalho. Repito, espero que ate o fim de decembro temos
esses dados para suporte da NFe.

Abraço,

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