SPED contábel e fiscal (ECD, EFC, EFD-ICMS-PIS, EFD-PIS-COFINS) no Odoo v11 por Akretion

588 views
Skip to first unread message

Raphael Valyi

unread,
Jul 24, 2018, 5:47:42 PM7/24/18
to openerp...@googlegroups.com
Fala galera, tudo bem?

Na Akretion a gente ficou um pouco ausente do nosso grupo porque a gente ficou muito caregado. mas so tou dando um alo para dizer que as coisas estao andando.

Para quem acompanha, o core da localizacao da OCA ta quase migrada para a V10 (ver os PRs do Renato). Tem tb varios PRs para suportar a NFe 4 na v8 por enquanto.

Tb desde o ano passado, revoltado que alguns recém-chegados no projeto faziam pressao na OCA para adotar um montao de codigo fiscal manual impossivel de se manter de forma barrata e que enfiava codigo fiscal que muda cada ano dentro dos objetos da operaçoes, eu mergulhei na geraçao de codigo. Nisso tenho uma soluçao para gerenciar e transmitir todos documentos ficais electronicos que eu irei divulgar nos proximos dias. Acho que a gente consegiu convencer a KMEE que era interessante faze-lo por geracao de codigo tb.

Mas ate para o SPED eh possivel faze-lo. Irei logo publicar esse codigo que permite de armazenar a informacao do SPED para emitir os relatorios. Vou logo publicar o prototipo que deve funcionar nas versoes 8, 9, 10 e 11 com poucas modificaçoes. Para usar em produçao sera preciso mais P&D mas pelo menos fica razoavel ter certeza de quanto vai custar e depois quanto vai custar para manter cada ano (enquanto com codigo manual para qual era impossivel medir a aderencia com as especificaçoes era impossivel de dizer).

Aqui no anexo print na v11 que a gente acabou de demostrar para um potencial cliente por enquanto.
O codigo usa um mix entre essa lib Python python-sped https://github.com/sped-br/python-sped e geraçao de codigo a partir dos pdfs.

Logo irei tb falar mais do ShopInavder, a soluçao de e-commerce no Odoo da Akretion e que esta chegando no Brasil tb.

Abraço.

-- 
Raphaël Valyi
Founder and consultant


Screenshot from 2018-07-24 18-28-53.png

Raphael Rodrigues

unread,
Jul 24, 2018, 5:53:48 PM7/24/18
to OdooBrasil / OpenERPBrasil.org
Cara eu achei que você nem trabalhava mais com Odoo, haha.
Mas parabéns, parece que deu uma trampada boa no código e calado hein.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.


--
Atenciosamente
Raphael Rodrigues Nogueira
Phone: (94) 9153-7552
Skype: raphael.r.nogueira

Raphael Valyi

unread,
Jul 24, 2018, 6:26:43 PM7/24/18
to openerp...@googlegroups.com
Ola Raphael,

eu nao sei como vc se mantem informado, mas se seguir meu twitter https://twitter.com/rvalyi
ou o Github da Akretion https://github.com/akretion
ou ver o rankings das contribuicoes no Appstore do Odoo: https://www.odoo.com/apps/contributors/modules
Nao tem como pensar que eu ou a Akretion nao trablhamos mais com Odoo.

Uma coisa eh vdd a gente ficou menos ativos no grupo e a gente parou de pagar a parceiria da Odoo SA que nao nos serve, mas contimuamos firme e fortes.
Teve 2 forks ou alternativas do nosso codigo da OCA nesse ultimos anos. Um ja quebrou a cara como bem avisamos por aqui. O outro que apostou tudo numa parceiria milagrosa com Odoo SA que nao se realisara nao vai demorar muito para cair na real tb. Mas tudo bem, eh o jogo do open source quem tem cabeca dura eh livre de sonhar como bem quer. Connfesso 

Abraço.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.


--
Atenciosamente
Raphael Rodrigues Nogueira
Phone: (94) 9153-7552
Skype: raphael.r.nogueira

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Sergio Garcia

unread,
Jul 24, 2018, 7:19:39 PM7/24/18
to openerp...@googlegroups.com
Oi pessoal, tudo bem?

Fico feliz que tenha gente usando a python-sped.

Eu estou terminando uma melhoria da python-sped, onde ela vai suportar leiautes de mais de um ano, está adiantado para ECD e ECF, eu extrai os dados dos documentos de forma automática e os transformo em um JSON, que dinamicamente gera os módulos.

Devo fazer o mesmo para o Fiscal e Contábil no próximo mês, isso ainda não está no PyPI por não estar finalizado, mas creio que será um ajuda por não terem que trabalhar os PDFs.

Eu subi a versão atual para que possam ter uma prévia,

Feedbacks são bem vindos.



Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.


--
Atenciosamente
Raphael Rodrigues Nogueira
Phone: (94) 9153-7552
Skype: raphael.r.nogueira

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--

Raphael Valyi

unread,
Jul 24, 2018, 8:10:42 PM7/24/18
to openerp...@googlegroups.com
Ola Sergio,

que beleza que temos vc o autor do python-sped na nossa lista!!

Entao irei explicar sobre todo isso nesses dias que vem. Venho trabalhando nisso faz uns 6 meses de forma ocasional. Para nos da Akretion a ideia era para mostrar pros ayatollahs do codigo manual que era inviavel para sustentar de forma open source que uma alternativa inteligente era possivel. Tb a ideia eh pegar mais projetos grandes no Odoo e poder falar o Odoo sabe fazer sabendo quanto vai custar e obtendo lucro no projeto ainda. Devo dizer que sempre foi usado essa estrategia para desestabilizar o projeto de falar que o projeto nao faz a funcionalidade X entao deixar que a empresa do fulano que acabou de chegar com varios $$$$ para perder vai liderar o projeto entao. Olho grande nunca faltou. Era preciso mostrar o ridiculo da solu;ao que os caras tava tentando enfiar a força no projeto.

Enfim logo me dei conta que a versao do python-sped nao esta completa: para gerir os objetos Odoo necessarios era preciso de:
  • no minimo informaçao sobre a hierarchia dos registros por examplo para dizer que as a nota fiscal tem campo o2m para os itens (o nome quase dava a informaçao mas nao dava exactamente nao pelo jeito)
  • era interessante saber se os campos eram obrigatorios
  • era interessante saber a precisao decimal dos campos numericos
Para fazer isso comecei a mergulhar em extrair esses meta-dados dos pdfs de especificaçoes usando tabula-jar. Tive que criar VAAAARIIIAAAS heuristicas para ler correctamente os dados do pdfs, mas mesmo assim eh muito menos codigo de que escrever esses objetos manualmente e pelo menos eh possivel de verificar se o codigo final esta correcto ou ate que ponto.

Ai nisso me dei conta que o python-sped era desatualizado comparando com as especificaçoes do SPED de 2018. Tem mais ou menos 10% de campos errado.

Nisso fui de cara para extrair tudo que eu podia mesmo dos pdfs. Tive entao a tentaçao de gerir tudo a partir dos pdfs sem usar mais o python-sped. so que vi que tinha erros no pdf tb. As vezes o tabula nao conseguia extrair a informaçao ou as vezes realmente tinha um erro tipo o cara botou um espaço no nome do campo ou algo do tipo.

Entao a soluçao que eu adotei foi de começar a monitorar o diff entre os que tinha nos pdf e nao tinha no python-sped. A partir dai eh facil corrigir manualmente o que falta no python-sped para bater com a especifiçao atual sacou.
Ai acabei de te botar um issue com o log da  aderência com as especificaçoes do SPED de 2018:

Entao a ideia eh que meu script permite de corrigir o python-sped. Ai depois vc assume que o python-sped esta ok para dar a lista dos registros e campos. Entao o script gera os objetos Odoo correspondante a partir do python-sped mas ainda completa com alguns meta-dados que vem dos pdfs como hierarchia, obrigatoriedade dos campos, precisao decimal etc...
Ou seja os dois se completam.

Depois a ideia eh que vc vai mapear os objetos operacional do Odoo para jogar a informaçao nesses novos objetos do SPED. Sendo assim, a informaçao fiscal dos documentos fiscais pode evoluir de forma independente da especificaçao do SPED, algo que infelizmente acontece na vida real e que era impossivel com aquilo que os caras queriam fazer no projeto que era de re-escrever tudo para enfiar a informçao do SPED no codigo operacional do ERP. Puta que pariu.

Enfim, entao isso eh um assunto um pouco secondario na Akretion, como sempre falamos, temos mais interesse em projetos mais simples que nem tem SPED dentro do ERP. Mas as vezes eh preciso de projeto maiores porque sao eles que geralmente bancam a P&D para fazer o restante. Enfim hoje nossa prioriadade eh mesmo finalizar a migraçao do codigo da OCA para a v10. O tempo de finalizar isso e vai sair a v12. Entao mesmo que iremos analisar os PRs na OCA se tiverem respeitando as regras da OCA, na Akretion nao iremos ter muito foco na v11 e provavelmente iremos dar mais foco na v12.

Mas como ja falei uns 6 meses atras aqui,da v11 para a v10, o codigo do modulo de stock (entao mrp etc...) mudou bastante. Para nos era inviavel migrar alguns clientes da v8 para a v11 direitamente pois ia custar demais de rever todas customizaçoes de stock/mrp. Mas tb ficar na v8 ia ficar logo inviavel tb. Entao a v10, que eh uma versao muito boa era uma boa versao para migrar esses clientes da v8 antes de migra-los para a v12 ou versoes superiores.

Quero ainda enfatisar que hoje o gerador dos objetos do SPED no Odoo pesa menos de 400 linhas de codigo. Os objetos geridos do SPED no Odoo pesam um pouco menos de 8000 linhas. Esses objetos sao indepedentes dos outros objetos da localizaçao, por isso eh facil usa-los para v8, v9, v10 ou v11 independemente da evoluiçao da localizaçao. Mas enfim, tb para dizer, que ao contrario de um fork por ai, nao se trata de uma localizaçao secreta gigantesca nao, mas apenas de um modulo razoavelmente pequeno.
Ainda falta o codigo para serializar os objetos Odoo em objetos python-sped para gerir os relatorios mas imagino que seria umas 200 linhas no maximo ja que os campos tem os mesmos nomes e que nao tem mapping manual necessario entao.

Ai depois claro precisa jogar os dados das notas fiscais Odoo e outros dados nesses objetos do SPED. A prioridade sera da NFe, importando os XMLs para preencher esses objetos Odoo. Sendo assim, sera possivel fazer os SPED de outras instancias Odoo ou ate de outros ERP a partir do modulo Odoo. Tb, com essa estrategia de ter objetos concretos do SPED, quando ainda nao existe mapping dos XML ou dados do Odoo, ainda eh possivel preencher na mao. Entao uma empresa que so tem umas linhas para detalhar digamos de amortização por examplo poderia preencher essa informaçao manualmente no modulo de SPED e depois poderia ser diretamente pego do Odoo qdo alguem implementar esse mapping especificamente, Dessa forma a gente sai do tudo o nada que nao eh muito amigo do open source.

Por fim, a Akretion sempre foi pioneira na questao da consolidaçao fiscal no Odoo, com as delcaraçoes de taxas e DEB/DES INTRASTAT na Europa que que foi trabalhando nisso para um cliente Europeo que Renato e mim bolamos os primeiros conceitos fiscais do Brasil como codigo de operaçao fiscal, regras de posiçao fiscal etc no Odoo la em 2010. E ai nesses dias vou migrar os modulos de DEB INTRASTAT da OCA da v10 para a v11 e isso eh bom para ter convergencia com a estrategia da OCA na Europa. Inclusive, a forma de tratar o INTRASTAT na Europa eh exactemente com modelos fiscais independente dos modulos operacionais do Odoo, pelos motivos que eu ja descrevi em cima.

Enfim em breve mais informaçoes sobre isso.


Abraço.

-- 
Raphaël Valyi
Founder and consultant


Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.


--
Atenciosamente
Raphael Rodrigues Nogueira
Phone: (94) 9153-7552
Skype: raphael.r.nogueira

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.

Sergio Garcia

unread,
Jul 24, 2018, 9:39:50 PM7/24/18
to openerp...@googlegroups.com
Respondendo aqui:

Ola Sergio,

que beleza que temos vc o autor do python-sped na nossa lista!!

> Acompanho a lista a alguns anos (desde quando era OpenERP), apesar de não ser usuário do Odoo, acho que posso aprender com os erros/acertos do projeto.

Entao irei explicar sobre todo isso nesses dias que vem. Venho trabalhando nisso faz uns 6 meses de forma ocasional. Para nos da Akretion a ideia era para mostrar pros ayatollahs do codigo manual que era inviavel para sustentar de forma open source que uma alternativa inteligente era possivel. Tb a ideia eh pegar mais projetos grandes no Odoo e poder falar o Odoo sabe fazer sabendo quanto vai custar e obtendo lucro no projeto ainda. Devo dizer que sempre foi usado essa estrategia para desestabilizar o projeto de falar que o projeto nao faz a funcionalidade X entao deixar que a empresa do fulano que acabou de chegar com varios $$$$ para perder vai liderar o projeto entao. Olho grande nunca faltou. Era preciso mostrar o ridiculo da solu;ao que os caras tava tentando enfiar a força no projeto.

> Então, eu tenho um pequena empresa e uma esposa contadora, tentamos juntar as coisas e nisso nasceu uma pequena solução contábil e algumas bibliotecas auxiliares, dentra elas o python-sped, a ideia minha foi sempre manter uma parte do código aberta.

Enfim logo me dei conta que a versao do python-sped nao esta completa: para gerir os objetos Odoo necessarios era preciso de:
  • no minimo informaçao sobre a hierarchia dos registros por examplo para dizer que as a nota fiscal tem campo o2m para os itens (o nome quase dava a informaçao mas nao dava exactamente nao pelo jeito)
  • era interessante saber se os campos eram obrigatorios
  • era interessante saber a precisao decimal dos campos numericos
> Isso é um dos problemas de manter ela genérica e ao mesmo tempo atender as minhas necessidades, porém nunca consegui lidar com multiplos leiautes na mesma versão. Esse ano resolvi dar uma polida nela e agora os leiautes são arquivos JSON que podem ser manipulados de outra forma, inclusive pretendo em breve separar os leiautes da biblioteca de forma a usar em mais linguagens. Todas essas informações que você falou estão nos leiautes em JSON, porém apenas para ECD e ECF por hora.

Para fazer isso comecei a mergulhar em extrair esses meta-dados dos pdfs de especificaçoes usando tabula-jar. Tive que criar VAAAARIIIAAAS heuristicas para ler correctamente os dados do pdfs, mas mesmo assim eh muito menos codigo de que escrever esses objetos manualmente e pelo menos eh possivel de verificar se o codigo final esta correcto ou ate que ponto.

Ai nisso me dei conta que o python-sped era desatualizado comparando com as especificaçoes do SPED de 2018. Tem mais ou menos 10% de campos errado.

> Isso é um problema de falta de atualização da minha parte a da "dona receita federal", os leiautes mudam todo ano e é um trabalho arduo ir registro a registro vendo o que mudou, daí acabo sempre atualizando quando gero as minhas declarações, e como bom brasileiro é sempre na última hora. Tendo mais gente usando (e me cobrando) posso tentar gerenciar para sempre atualizar com a atualização dos manuais pela receita.

Nisso fui de cara para extrair tudo que eu podia mesmo dos pdfs. Tive entao a tentaçao de gerir tudo a partir dos pdfs sem usar mais o python-sped. so que vi que tinha erros no pdf tb. As vezes o tabula nao conseguia extrair a informaçao ou as vezes realmente tinha um erro tipo o cara botou um espaço no nome do campo ou algo do tipo.

Entao a soluçao que eu adotei foi de começar a monitorar o diff entre os que tinha nos pdf e nao tinha no python-sped. A partir dai eh facil corrigir manualmente o que falta no python-sped para bater com a especifiçao atual sacou.
Ai acabei de te botar um issue com o log da  aderência com as especificaçoes do SPED de 2018:

> Olherei com carinho e respondei a issue em breve, mas creio que todos os itens estão corrigidos com a versão da python-sped usando leiautes dinâmicos. Porém, até eu extrair os leiautes do Fiscal e Contábil não publicarei uma versão 1.0

Entao a ideia eh que meu script permite de corrigir o python-sped. Ai depois vc assume que o python-sped esta ok para dar a lista dos registros e campos. Entao o script gera os objetos Odoo correspondante a partir do python-sped mas ainda completa com alguns meta-dados que vem dos pdfs como hierarchia, obrigatoriedade dos campos, precisao decimal etc...
Ou seja os dois se completam.

Depois a ideia eh que vc vai mapear os objetos operacional do Odoo para jogar a informaçao nesses novos objetos do SPED. Sendo assim, a informaçao fiscal dos documentos fiscais pode evoluir de forma independente da especificaçao do SPED, algo que infelizmente acontece na vida real e que era impossivel com aquilo que os caras queriam fazer no projeto que era de re-escrever tudo para enfiar a informçao do SPED no codigo operacional do ERP. Puta que pariu.

> Essa parte eu não posso me comprometer, porque não conheço o Odoo, mas se alguém quiser pegar a empreitada e conhecer o código, pode ser gerado a informação com base no meu software, eu posso disponibilizar os códigos que tenho para geração para minha realidade, empresa prestadora de serviço, em lucro presumido

> Daqui pra baixo, como não conheço a arquitetura do Odoo, é grego pra mim, mas dúvidas quanto ao SPED posso tentar ajudar.

Enfim, entao isso eh um assunto um pouco secondario na Akretion, como sempre falamos, temos mais interesse em projetos mais simples que nem tem SPED dentro do ERP. Mas as vezes eh preciso de projeto maiores porque sao eles que geralmente bancam a P&D para fazer o restante. Enfim hoje nossa prioriadade eh mesmo finalizar a migraçao do codigo da OCA para a v10. O tempo de finalizar isso e vai sair a v12. Entao mesmo que iremos analisar os PRs na OCA se tiverem respeitando as regras da OCA, na Akretion nao iremos ter muito foco na v11 e provavelmente iremos dar mais foco na v12.

Mas como ja falei uns 6 meses atras aqui,da v11 para a v10, o codigo do modulo de stock (entao mrp etc...) mudou bastante. Para nos era inviavel migrar alguns clientes da v8 para a v11 direitamente pois ia custar demais de rever todas customizaçoes de stock/mrp. Mas tb ficar na v8 ia ficar logo inviavel tb. Entao a v10, que eh uma versao muito boa era uma boa versao para migrar esses clientes da v8 antes de migra-los para a v12 ou versoes superiores.

Quero ainda enfatisar que hoje o gerador dos objetos do SPED no Odoo pesa menos de 400 linhas de codigo. Os objetos geridos do SPED no Odoo pesam um pouco menos de 8000 linhas. Esses objetos sao indepedentes dos outros objetos da localizaçao, por isso eh facil usa-los para v8, v9, v10 ou v11 independemente da evoluiçao da localizaçao. Mas enfim, tb para dizer, que ao contrario de um fork por ai, nao se trata de uma localizaçao secreta gigantesca nao, mas apenas de um modulo razoavelmente pequeno.
Ainda falta o codigo para serializar os objetos Odoo em objetos python-sped para gerir os relatorios mas imagino que seria umas 200 linhas no maximo ja que os campos tem os mesmos nomes e que nao tem mapping manual necessario entao.

Ai depois claro precisa jogar os dados das notas fiscais Odoo e outros dados nesses objetos do SPED. A prioridade sera da NFe, importando os XMLs para preencher esses objetos Odoo. Sendo assim, sera possivel fazer os SPED de outras instancias Odoo ou ate de outros ERP a partir do modulo Odoo. Tb, com essa estrategia de ter objetos concretos do SPED, quando ainda nao existe mapping dos XML ou dados do Odoo, ainda eh possivel preencher na mao. Entao uma empresa que so tem umas linhas para detalhar digamos de amortização por examplo poderia preencher essa informaçao manualmente no modulo de SPED e depois poderia ser diretamente pego do Odoo qdo alguem implementar esse mapping especificamente, Dessa forma a gente sai do tudo o nada que nao eh muito amigo do open source.

Por fim, a Akretion sempre foi pioneira na questao da consolidaçao fiscal no Odoo, com as delcaraçoes de taxas e DEB/DES INTRASTAT na Europa que que foi trabalhando nisso para um cliente Europeo que Renato e mim bolamos os primeiros conceitos fiscais do Brasil como codigo de operaçao fiscal, regras de posiçao fiscal etc no Odoo la em 2010. E ai nesses dias vou migrar os modulos de DEB INTRASTAT da OCA da v10 para a v11 e isso eh bom para ter convergencia com a estrategia da OCA na Europa. Inclusive, a forma de tratar o INTRASTAT na Europa eh exactemente com modelos fiscais independente dos modulos operacionais do Odoo, pelos motivos que eu ja descrevi em cima.

Enfim em breve mais informaçoes sobre isso.


> Abraços!

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.


--
Atenciosamente
Raphael Rodrigues Nogueira
Phone: (94) 9153-7552
Skype: raphael.r.nogueira

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--

Reginaldo O. de Jesus

unread,
Nov 26, 2018, 3:55:11 PM11/26/18
to OdooBrasil
Já estão disponível os mudulos onde baixo ?

Raphaël Valyi

unread,
Nov 27, 2018, 8:59:05 AM11/27/18
to openerp...@googlegroups.com
Ola Reginaldo,

infelizmente ficamos atarefados em outras coisas (migraçao, Shopinvader...). Mas ate tou mergulhando nisso de novo. Realmente o python-sped com os layouts dinamico ficou bem melhor. O problema eh que eles usaram apenas para ECD e ECF e nao as EFDs, mas tou ate trabalhando nessa parte das EFDs, porque inclusive temos um interesse grande em poder checar se o python-sped esta adherente com as ultimas especificacoes e ate que ponto. Nosso objetivo na Akretion eh mostrar para potenciais clientes quao perto estamos de realisar o SPED no Odoo e poder orcar de fazer isso em projetos de forma crivel e sem tomar prejuizo (porque dependente como vc faz isso pode custar anos-homens de trabalho).

Tentamos sempre manter o canal https://github.com/OCA/l10n-brazil como cana oficial para conversar sobre roadmap do projeto (nos pull requests), mas a KMEE ate nos perguntou disso de forma privada recentemente entao tivemos isso numa conversa privada onde concordamos entre os 3 PSC do projeto de extrair um, modulo fiscal do l10n_br_account que vai servir de dependencia tanto para os modulos de documentos fiscais (NFe, NFSe...) quanto os modulos de SPED, sendo que vc pode querer fazer um sem o outro. Entao depois de finalizar  a migracao para a v10, segue esse tipo de melhoria.

Noticias em breve.

--
Você recebeu essa mensagem porque está inscrito no grupo "OdooBrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasi...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

Reginaldo O. de Jesus

unread,
Nov 27, 2018, 2:47:59 PM11/27/18
to OdooBrasil
Infelizmente agora não vou contribuir no desenvolvimento , mas pode conta comigo para fazer os testes.
Reply all
Reply to author
Forward
0 new messages