Modulo Brasil
Sidnei Brianti
Raphael Valyi
--
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.
Sidnei Brianti
Raphael Valyi
Danimar Ribeiro
Raphael Valyi
- as coisas de nfse
- as sua lib de transmissao de nfe/nfse. Acho que ela troca o pysped de forma bem mais razoavel. Ate sou dos que mais protestaram do repo da OCA depender da lib pysped pela baixa qualidade do codigo (apesar que serveu bem). Mas no caso da sua lib, nao vejo problema depender dela.
Diego Ribeiro
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.
--
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.
Danimar Ribeiro
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.
Raphael Valyi
Diego Ribeiro
Raphael Valyi
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.
Raphael Valyi
Luis Felipe Miléo
Pessoal
Vou contar a história do que se passou no último ano da KMEE, como e porque refatoramos a Localização Brasileira. Tudo começou em outubro do ano passado, a v10 foi lançada com muitas mudanças e então o pessoal que trabalha com Odoo no Brasil logo começou a se movimentar para que a localização estivesse na nova versão.
No mesmo outubro também aconteceu a Python Brasil em Florianópolis onde tive conheci pessoalmente o Danimar e o Makleim sócios da TrustCode. Durante os dias do evento, na presença também do Leonardo Rochael, pudemos conversar bastante sobre a arquitetura da localização, problemas e burocracias que impactam os contribuidores e inclusive fizemos alguns Hangouts com o Renato da Akretion.
Na época todos gostariam de realizar mudanças na localização, principalmente na parte fiscal para permitir a emissão e o registro de outros documentos fiscais (são mais de 40 tipos) para então viabilizar o SPED FISCAL. Ficou claro que este seria o primeiro passo para criar uma localização que tenha aderência ao mercado nacional, visto que todas as empresas hoje no Brasil estão obrigadas a emitir documentos fiscais sejam eletrônicos ou não.
A primeira vez em que vi o Odoo foi em uma palestra do Leonardo Santagada na Python Brasil de 2011. Desde aquele dia comecei a estudar o sistema, a comunidade e que normas deveriam ser seguidas. Ao longo desses anos foi possível trocar muito conhecimento e conhecer pessoas extraordinárias através de treinamentos, listas de discussão, conversas de bar e mais recentemente com a formalização da OCA. Sabia que para contribuir para a OCA era preciso ter paciência e tive toda a calma para depois de anos de contribuição de coordenando a equipe da KMEE enviar minha solicitação de PSC (Que demorou 9 meses para ser respondida... https://odoo-community.org/groups/contributors-15/contributors-48183?mode=date&date_begin=2016-10-01&date_end=2016-11-01). Então em novembro a solicitação foi aprovada e comecei a reservar um tempo para trabalhar diretamente no projeto e comecei a refletir sobre algumas questões.
Primeira delas o projeto nunca teve um roadmap, havia muito pouco direcionamento e esforço em atender por completo o mercado brasileiro. A maioria dos contribuidores estavam focados em projetos complexos onde os clientes buscavam a versatilidade do Odoo para atender o seus negócios e atingir um grande crescimento e muitos desses projetos nem eram projetos Brasileiros / ou não usavam a localização 100%. Então a localização sempre contou com problemas estruturais em módulos muito importantes: Fiscal, Financeiro e Contábil. Não por falta de contribuidores de qualidade, pois te garanto que os contribuidores Brasileiros são muito bons, mas por falta de roadmap e visão de transformar a localização em um Produto.
Ovo ou a galinha: Mas o que você faz quando o cliente atinge um super resultado e precisa de obrigações contábeis e fiscais? Fala para seu cliente trocar para um grande player? E como você financia o projeto da localização?
Desde o início da KMEE em 2011 sempre procurei ensinar a equipe e outros membros da comunidade através de treinamentos ou de forma informal. E acho válido ressaltar que recentemente ultrapassamos a marca de 100 desenvolvedores com conhecimento razoável no framework no Brasil. Infelizmente podemos contar em uma mão aqueles que estão diretamente envolvidos com a Localização, mas isso fica pra outra conversa.
Logo depois da Python Brasil, a aprovação do PSC, ocorreu em dezembro o encontro da comunidade do Odoo, conversamos bastante sobre esses problemas, mas no sprint no dia seguinte começamos a migrar os módulos da mesma forma que estávamos acostumados. Aproveitei a presença do Leonel @leonelpf, contador e programador para esclarecer algumas questões implorantes.
Da esquerda para a direita: Luis Mileo, Raphael, Renato, Leonarno Rochael, Hendrix, Albert, Luiz Divino, Magno, Daniel, Leonel.
Na mesma época em Novembro/Dezembro o Aristides Caldeira passou a compor o nosso time. Ele tem um histórico longo de desenvolvimento de ERPs e no desenvolvimento de aplicações para a parte fiscal. Quando o conheci em 2012 no Treinamento Técnico ministrado pelo Raphael e o Renato em São Paulo ele já tinha desenvolvido um ERP em Delphi, criado o PySPED e um emissor de SPED FISCAL em DJANGO baseado no PySPED. Ná época ele foi trabalhar no sul em um ERP fechado baseado no framework (6.1) do Odoo, mas que não utiliza os módulos do core, e eu segui com a KMEE. E neste ano trocamos muito conhecimento referente aos desafios de se desenvolver um ERP Completo, o que poderíamos utilizar do core e o que precisaríamos reescrever.
Quando começamos a migrar a camada fiscal surgiram algumas perguntas sem resposta, que se alongaram até Janeiro, quando na primeira semana de 2017 o Fabien da Odoo S.A. mandou um email para mim e para o Renato com algumas perguntas:
Me lembro que passei dois dias escrevendo uma resposta para o Fabien, em uma carta que tornei pública recentemente (https://docs.google.com/a/kmee.com.br/document/d/11OJJLOF0kY6h2IzD5tjrycvAhjsZINCj1gcBiPT8O3A/edit?usp=sharing), com dados de mercado e detalhes que precisavam ser corrigidos tanto no core do Odoo quanto na localização, tudo com base as conversas que andava tendo com nossos contadores, o Ari e também com o Leonel.
Então comecei a movimentar as coisas para resolvermos os problemas estruturais no fim de Janeiro rolou um vídeo, para falarmos de roadmap:
https://www.youtube.com/watch?v=El6hMyBA9rg
E o primeiro passo seria criar um emissor fiscal com o mínimo de dependências possíveis do core, que inclusive fosse possível utilizá-lo como uma API para emissão de NF-E/NFC-E/SAT/NFS-E e outros documentos fiscais. Uma semana depois fizemos um segundo hangout (que tenho que localizar o vídeo, mas desde os problemas que ocorreram na migração da 7 para a 8, me acostumei a documentar tudo para evitar novas discussões), quando expliquei alguns pontos essenciais da arquitetura e alguns detalhes que tinha conversado com uma amiga da SAP e um projeto multinacional da documentos eletrônicos com o HANA.
Na sequência o Ari Caldeira fez um PR com um grande módulo sped que era capaz:
- Emitir documentos fiscais de diferentes tipos estruturado a partir do manual do SPED FISCAL e não do manual da NF-E ou outro documento fiscal que precise de integração.
- Continha um motor de impostos próprio;
- E as tabelas necessárias para emissão do SPED FISCAL.
Me coloquei a disposição do Renato para explicar os detalhes da implementação e nos encontramos algumas vezes no Google Campus. Então nos dois e o Magno realizamos os primeiros passos no sentido de tornar este módulo melhor estruturado e integrá-lo a localização Brasileira.
Na sequência voltei para MG e passei uns dias tentando integrar o motor de impostos do SPED no motor de impostos do core, mas cheguei a conclusão que seria muito melhor sobrescrever os comportamentos do motor de impostos do core, pois não foi possível criar uma integração entre o account.tax e os modelos sped.aliquota.icms.proprio, sped.aliquota.icms.st, sped.aliquota.ipi, sped.aliquota.iss, sped.aliquota.pis.cofins, sped.aliquota.simples.anexo
Dado este primeiro passo, vários novos modelos foram adicionados ao módulo l10n_br_base que obteve os campos necessários para emissão dos registros abaixo e suas respectivas tabelas:
REGISTRO 0100: DADOS DO CONTABILISTA;
REGISTRO 0150: TABELA DE CADASTRO DO PARTICIPANTE;
REGISTRO 0175: ALTERAÇÃO DA TABELA DE CADASTRO DE PARTICIPANTE;
REGISTRO 0190: IDENTIFICAÇÃO DAS UNIDADES DE MEDIDA;
REGISTRO 0200: TABELA DE IDENTIFICAÇÃO DO ITEM (PRODUTO E SERVIÇOS);
REGISTRO 0205: ALTERAÇÃO DO ITEM;
REGISTRO 0220: FATORES DE CONVERSÃO DE UNIDADES;
REGISTRO 0400: TABELA DE NATUREZA DA OPERAÇÃO/PRESTAÇÃO;
Em março nossa equipe começou a escrever um documento de ROADMAP da localização:
https://github.com/OCA/l10n-brazil/pull/527
E nosso Segundo Epic foi para diminuir a dependência do módulo contábil e criar um módulo de gestão financeira. Um passo muito importante pois quem está ciente das alterações da versão 11 a contabilidade foi drasticamente reduzida ( acredito que o Fabien entendeu o recado da carta escrita e soube reduzir a intervenção da contabilidade e deixar esta questão para as localizações, mas na minha opinião ainda tem coisa que precisa ser melhor estruturada e o módulo account deveria ser dividido em dois, onde o motor de impostos e a forma de pagamento e outros itens fiquem separados do account para permitir por exemplo instalar o módulo sale s/ instalar o account).
Então começamos a analisar os módulos financeiros dos ERPs concorrentes e averiguar com nossos clientes suas necessidades de gestão financeira. Iniciamos um projeto longo de construção de um módulo financeiro 100% independente da contabilidade. Capaz de gerar relatórios que nem o Odoo Enterprise nem a OCA conseguem obter, uma necessidade importante do mercado brasileiro que trabalha com diversas formas de parcelamento de contas a pagar e a receber, cheques, financiamentos, cartões, boletos.
E falo isso novamente com propriedade, pois tivemos um papel importante no módulo de emissão de boletos e conciliação de extratos a partir da contabilidade. Módulo que, dependendo da operação da empresa funciona muito bem, mas que está sujeito a uma série limitações e impacta a emissão do SPED CONTÁBIL.
Atualmente o módulo financeiro que desenvolvemos é capaz:
Controle de contas à pagar;
Controle de contas à receber;
Controle de contas recebidas;
Controle de contas pagas;
Controle de cheques;
Cadastro de contas bancárias independente de diário;
Parcelamentos;
Insere importantes modificações nas formas de pagamento e modo de pagamento;
Emissão de Boletos registrados;
Emissão de Ordens de pagamento;
Emissão de Pagamento de salários;
Emissão de Guias de Recolhimento;
Emissão de Guia de Sindicato;
Relatórios:
Fluxo de Caixa;
Entradas e Saídas;
Extrato;
Inadimplência;
Aging;
Dashboard(ainda em desenvolvimento);
O terceiro passo foi a integração do financeiro com o fiscal e com o contábil, onde fizemos um motor de contabilização (sim, tentei utilizar o action_move_create e explorar a abordagem criada pelo pessoal da ThinkOpen, mas não foi o suficiente, o Brasil precisa de muito mais).
Nosso primeiro grande objetivo era gerar o DRE e integrar os lançamentos contábeis de forma “suave” entre os financeiro e o fiscal. Permitindo que o faturista e o financeiro operem de duas maneiras:
Contabilidade Online: Ao confirmar os documentos fiscais e financeiros o lançamento contábil é criado e postado automaticamente, mas esta abordagem requer um grau de configuração e experiência muito alta;
Contabilidade Manual: Posterior à confirmação do documento fiscal ou do documento financeiro o contador deve configurar o modelo de contabilização para então criar o lançamento contábil correspondente.
Passado esta fase voltamos nosso foco no restante da integração do sistema, atuando diretamente no módulos de vendas, compras e estoque. Para tanto criamos uma abstração interessante para permitir que qualquer modelo de negócio ganhe características de um documento fiscal, possua o motor de imposto, cálculo de lucratividade e margem conforme a tributação brasileira e possa ser facilmente convertido em um documento fiscal.
Esta semana nosso time migrou os módulos descritos acima para a versão 11. E também em alguns módulos:
Port da folha de pagamento para a versão 11; https://github.com/kmee/l10n-brazil/pull/285
Adequação ao e-social https://github.com/kmee/l10n-brazil/pull/275
Geração do arquivo do SPED FISCAL;
- Geração do SPED ECF e ECF;
To: openerp...@googlegroups.com
Sent: Saturday, October 21, 2017 2:02:37 PM
Subject: Re: [openerpbrasil.org] Modulo Brasil
Raphael Valyi
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para openerp-brasil+unsubscribe@googlegroups.com.
--
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.
Raphael Valyi
Ola Luis,Realmente vcs andam fazendo muito trabalho. Um problema porem eh que a OCA tem um foco na qualidade e nao tanto na quantidade. Vc pode achar ruim, eu tb posso achar, mas eh assim. Entao eh meio complicado construir em cima de uma porrada de codigo que nao tem test e depois querer que a OCA se vira para assimilar os PR's e fazer merge de tudo...Quando O Renato e o Magno se encontraram com vcs nos sprints uns 5 meses atras e que eu falei com vc por hangout, nos estavamos dispostos a refatorar o tax engine para integra-lo na OCA. Porem a gente deixou claro que testes unitarios era o primeiro passo para que isso possa ser feito.So que em vez de focar nisso, vcs focaram parece em adicionar funcionalidades por cima, e a coisa continuando sem teste unitarios nehnum... Se vcs nao dam retorno nem fazem outros PRs na OCA fica complicado saber o que cada um faz no repo dele e se ele pretende ou nao integrar isso na OCA neh...Eu acho que a intecao de voces eh boa e vc ve que com tempo estamos conseguindo incorporar os trabalhos para os boletos e tb estamos muito positivo com o modulo hr_resource que faz a ligacao com o repo incubador HR. Estamos fazendo isso na v8 ainda mas depois sera facil migrar aquilo para a v11.Sobre a parte fiscal, tem ideias boas e o tax engine realmente interessa. So que vou te demostrar ainda que uns 70% daquele codigo eh inutil (e nao tem Ruby na jogada nao rsrs). Quer apostar?Eu tb tinha uma certa admiraçao pelo Aristides, ate que os PRs de vcs sem tests me fez botar o narriz naquiilo... Em 4 dias eu descobri que 80% do codigo do pysped era tipo uma fraude, algo totalmente inutil e que ficamos dias debugando isso a cada mudanca de esquema, tipo com a ultima NT. Uma semana depois eu descobri que uns 70% daqueles modulos sped_* que o Ari fez tb sao inuteis.Nao accredita? Pois bem, daqui alguns dias vou te mostrar ainda...E ai voltamos naquela questao: a gente quer sim intergrar aquele tax engine e a melhoria da gestao de informacao fiscal. Mas para isso ser feito com qualidade eh nao milhares de linhas de codigo inutil dificil de se manter depois, vai precisar refatorar umas coisas. E ai a falta de teste unitarios pega de novo...Acho que todos buscamos a mesma coisa: uma localizacao mais madura. Na vdd eu fico puto de nao ter conseguindo fazer o que eu consegui fazer agoa la em 2014 que a gente teria avançado muito. Entao vamos integrar aquele tax engine, mas sobre a manutencao da informacao fiscal, acho vamos fazer uma contra proposta bem mais leve para manter e que vai se integrar de forma bem mais suave no codigo existente, paciença que vou te mostrar.Eh um pouco que nem a parte dos boletos, vcs partiram para escrever/manter milhares de linhas de codigo. E a gente fez com 300 linhas: 150 de cliente Python e 150 para expor uma lib madura em Ruby. Enfim a parte limpa daquilo estamos integrando na OCA (branch v8) e depois cada um extende como bem entende. Mas pelo menos ninguem imposa uma divida tecnologica para o outro.Sobre a parte financeira. Bem, na Akretion fizemos altos relatorios financeiros la para 2013 ainda quando nosso maior cliente em Sao Paulo era um fornecedor da Volkswagen. Os caras movimentavam uns 40 000 R$ por dia e queria saber qualquer variacao de fluxo de 500 R$ daqui 2 semanas... Com aquela coisa brasileira que a empresa paga em 10x, recebe em 10x... Altas visoes SQL que o Florian fez para botar as condicoes de pagamentos parcelados nas vendas e compras e que inntegramos ao trabalho da Noviat...Mas acabou que a Volkswagen meteu um preju de varios milhoes nos caras e eles voltaram na barriga da mae: em 1 ano voltaram de 500 para 30 funcionarios e o projeto "OpenERP" entao acabou e tb acabou nosso trabalho com o financeiro, que ironia rsrsrsMas enfim aproveitei da minha estadia nos Odoo Experience e sprint da OCA para bater um papo sobre isso com os especialistas. A Noviat me falou que hoje faria aquilo com o OCA/mis_builder. E Depois falei com a Acsone e chegamos na conclusao que para ser flexivel e generico realmente teria que usar o OCA/mis_builder.A gente olhou um pouco com o Renato esse modulo financeiro. Acho o seguiente: hoje ainda tem dificuldade para botar a porra do tax engine compativel com a localizacao existante no modulo l10n_br_base, entao vamos deixar esse modulo fiscal para revisar depois... Mas se vc oferecer a mesma funcionalidade feito com o mis_builder, ai realmente a gente pode avaliar com mais prioridade. Por hoje eu sugeraria de deixar isso dentro de um repo da Kmee, mas enfim vamos ver se a gente consegue ir ate esse modulo...Do restante, eh perfeitamente normal cada empresa oferecer modulos super avancados e que nem todos vao na OCA. Na Akretion temos 300 repo, a OCA so tem 156 entao a maioria do nosso trabalho nao vai na OCA e todo mundo faz assim. Acho que so faz sentido quando algum modulo eh estruturante suficentemente, que a comunidade do repo consegue dar conta etc...Vamos nao esquecer que o OCA/l10n_brazil eh um dos repos mais complexo da OCA e que tem pouca gente experiente e disposto a ajudar (e que nem venha me falar que eh por causa do repo ou sei la o que, pois ha eh um dos projeto com mais cainais de conversa/organizacao e nao tem brasileiros muito ativos nos outros repos da OCA, eh bem ocasional quando acontece algum PR num repo da OCA de alguem do Brasil).Bem eh isso. Tou esperando o Renato terminar a migracao e tenho um plano para conseguir integrar o tax-engine e a melhoria da manutencao da informacao fiscal. Iremos continuar esse papo nos PRs da OCA nos proximos dias entao.Uma coisa eu digo para vcs: A localizacao do Odoo na v11 vai arrebentar tudo!!! Eu finalmente enxergo que vai ser quasi tao facil trabalhar com o Odoo no Brasil quanto em qualquer outro pais... Isso nao eh pouca coisa para um ERP...Uma ultima coisa: os testes que precisa no tax engine sao testes unitarios. Testes de integracao no ja temos na localizaçao. Basta injectar o tax engine dentro, se passa os testes, tamos felizes. So que para poder fazer aquilo vai precisar refatorar muito. E sem teste unitario fica impossivel...Abraço