2009/12/12 Henrique Meira <henri...@meira.net> > 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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-brazil-team Post to : openerp-brazil-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-brazil-team More help : https://help.launchpad.net/ListHelp