Closed rvalyi closed 4 years ago
crsilveira
commented
8 years ago O Danimar para a emissão da NFSe Paulista fez todos os procedimentos necessários (criar, assinar, enviar, etc ...) sem a utilização da pySped, não poderiamos seguir este mesmo caminho pra NFe ?!
rvalyi
commented
8 years ago @crsilveira no caso da NFSe era mais facil parece. Hoje realmente a ideia e de continuar usando um pouco o Pysped para as notas de produto mas tb preparar o futuro no qual poderiamos usar outra implementacao... Do restante vamos ter que integrar o que o Danimar fez com a OCA. Para isso e essential que finalizemos esse PR do @renatonlima antes: https://github.com/OCA/l10n-brazil/pull/363 caso quiser ajudar a revisar fique a vontade...
mbello
commented
8 years ago Honestamente, acho uma perda de tempo dedicar tanto tempo mantendo uma solução como o pySped se temos tantas opções de emissores pagos, baratos e de excelente qualidade e que agregariam muito pois passariam maior confiabilidade em relação à solução.
Por exemplo, temos o módulo cloud do Manager eDoc da Tecnospeed, além de diversos outros. Se for para criar essa façade, que seja criada de forma que suporte o componente Cloud da Tecnospeed, seria uma forma de garantir que a implementação é genérica o suficiente.
renatonlima
commented
8 years ago @mbello
Se você dar uma olhada em algumas mensagens minhas do google group do Odoo Brasil, você vai ver que sempre falei que o Odoo tem que ter uma interface genérica para não ficar preso apenas em uma solução, já que a comunidade é pequena manter um projeto de transmissão sozinho seria um trabalho inviável, já que hoje temos o trabalho da localização.
Na medida que mais pessoas entraram no projeto e ajudaram a manter o pysped adotamos o PySPED por ser a solução mais fácil para fazer o envio da NFe dentro do Odoo, mas hoje existe praticamente 4 pessoas em todo brasil mantendo atividade no PySPED e eu vejo que vamos ter problemas futuro em manter o PySPED sozinhos.
Eu acho que você não entendeu a proposta deste issue, hoje o Odoo usa apenas o PySPED para serializar a invoice em XML e transmiti-la e a ideia de se criar um facede é abstrair os métodos de manipulação da NFe de uma forma que fique fácil a acoplar outro tipo de solução, hoje se você observar no módulo nfe existe várias partes do código que depende do PySPED e a ideia é criar um facede para padronizar os objetos e métodos que manipulam a NFe e depois refatorar o modulo nfe e continuar usando o PySPED, mas desta forma podemos facilmente no futuro trocar para outra lib caso o PySPED não seja mais mantido ou o Odoo passe para o Python 3. O @danimaribeiro me falou que estava trabalhando em uma lib de NFe e NFSe e esta facedo seria o primeiro passo para poder trabalhar com outro tipo de lib ou solução para a serialização e transmissão da NFe.
danimaribeiro
commented
8 years ago Ainda está em dev https://github.com/danimaribeiro/PyTrustNFe Ta ficando legal, mais limpo e o básico esta vindo com testes já.
Porém o que quero deixar claro é que não é tão dificil assim como se fala para manter a lib de NFe, o que é dificil é manter o pysped.
rvalyi
commented
8 years ago enfim o lance e ter opcao. O que queremos fazer aqui e so criar essa abstracao para que mais solucoes de transmissao pudesse existir e que a situacao melhora.
mbello
commented
8 years ago O que eu quis dizer é que essa façade deve ser genérica o suficiente para suportar o uso de um componente externo SaaS como o Tecnospeed e outros.
O risco é fazer uma façade semi-genérica que no final das contas adicionaria um nível de abstração sem permitir um ganho real.
Danimar, o modulo da NFe em si pode ser simples, mas se vc integra com um Tecnospeed (que é barato), você ganha o suporte a NFSe de centenas de cidades, NFCe, MDFe, etc...
Além disso, vc ganha o storage por 5 anos, serviço externo de validação de NFe mais avançado do que temos no Odoo e existem ferramentas que integram com esses SaaS e fazem auditoria das notas, etc.
Fazer parte de um ecossistema como o da Tecnospeed (e há outras ótimas opções também) traz vários benefícios. Além disso, como já disse anteriormente, clientes maiores preferem que esse tipo de solução tenha o respaldo de um grande nome da indústria, soluções home-made em parte fiscal e tributária é complicado.
Por fim, se temos recursos escassos pq desperdiçar isso reinventando a roda? Por mais simples que isso seja, vc não faz um módulo de NFe com menos de uma semana de trabalho. E pode ter certeza que seus Natais serão muito mais estressantes se vc optar por manter essa solução, pergunte ao Miléo como foi o último Natal dele (claro que aquelas notas técnicas exigiam mudanças no Odoo, mas ter que mudar só o Odoo seria mais fácil do que mudar as duas coisas).
Acho que na comunidade a gente confunde o fato do Odoo ser opensource com a noção de que tudo tem que ter uma alternativa de código aberto.
Penso que, se pudéssemos entrar em um acordo entre os parceiros de integrar o Odoo com soluções de documentos eletrônicos, integração bancária (o Interbanco da eSales é fantástico), TEF, gateway de pagamentos, etc - Seria ótimo, mas teria que escolher o serviço que seja aceito pelos parceiros para não ser algo de um ou de outro parceiro.
Além disso, essas conexões podem representar uma fonte extra de renda aos integradores pois esses serviços pagam comissão aos dev.
Em 7 de out de 2016 1:49 PM, "Raphaël Valyi" notifications@github.com escreveu:
enfim o lance e ter opcao. O que queremos fazer aqui e so criar essa abstracao para que mais solucoes de transmissao pudesse existir e que a situacao melhora.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-252303285, or mute the thread https://github.com/notifications/unsubscribe-auth/AAndQIsgFEspJ_SDEoBwqHPApoOLh2Izks5qxnghgaJpZM4J72Eb .
renatonlima
commented
8 years ago @danimaribeiro
O que eu quis dizer é que o difícil é manter a localização do Odoo e uma lib de NFe com a quantidade de dev que existia há uns 2 anos atrás e fazer isso mesmo hoje não é fácil, hoje tem quantas pessoas que trabalham no projeto (localização e NFe)? sendo otimista umas 6 a 8 pessoas.
Eu acho legal da sua parte trabalhar em uma nova lib o código é infinitamente melhor que o PySPED, mas é muito importante que em volta deste projeto tenha mais pessoas para manter e alcançar uma massa critica, seria muito bom levar isso na comunidade python brasil (até falar em um lighttalk na pycon Brasil) quando você comentou comigo sobre este trabalho, eu dei a minha opinião que seria legal ter uma sinergia principalmente com o pessoal que trabalha no PyNFe para ter mais pessoas trabalhando no projeto garantindo a evolução e manutenção da lib e não correr o risco de acontecer o que esta acontecendo com o PySPED, onde @aricaldeira que é o criador do projeto não trabalhando no projeto recentemente e não existe pessoas para mante-lo e evolui-lo. Hoje praticamente é eu, você, @mileo e algumas contribuições esporádicas que manter o PySPED.
@mbello
O que estamos planejando e discutindo aqui é exatamente dar opções para as pessoas que usam o Odoo emitir NFes tenha opções além do PySPED, como eu falei mensagem anterior, implementando esta interface vai permitir as pessoas acoplar outras soluções seja a PySPED, PyNFe a lib que o danimar esta trabalhando ou outro serviço que você mencionou. ninguém aqui falou em construir uma solução semi-genérica mas poder ter uma estrutura que possa dar liberdade de escolha para quem quer usar. Lembrando que você pode integrar hoje o Odoo com outras ferramentas de envio de NFe, fazendo a exportação dos arquivos XML gerado pelo Odoo, se eu não me engano teve uma pessoa que fez a integração com uma ferramenta destas na versão 6.1.
O primeiro passo que temos que dar e em promover uma interface acoplável para transmissão, e dar esta liberdade de escolha para quem quer usar o Odoo.
Algumas coisas também precisam ser esclarecidas, o projeto ser open source e isso não significa apenas que o código seja aberto, mas que tenha liberdade, da forma como você colocou se tivéssemos investido em integrar com uma ferramenta existente no mercado, não teríamos esta liberdade. O open source não é apenas filosofia, é um modelo de negócio, e em muitos casos torna-lo sustentável é um desafio, eu trabalho desde 2009 com o OpenERP/Odoo e minha empresa sempre teve a principal fonte de renda vinda do OpenERP/Odoo, então eu sei muito bem deste desafio de se financiar, pois somos a empresa que mais investiu e financiou o projeto da localização, a sua visão sobre desenvolver produtos e serviços é correta em financiar o ecosistema, mas do outro lado temos que ter pelo menos uma estrutura genérica e open source que permita que permita as pessoas tenham a liberdade de escolha e que possa atrair pessoas para o eco sistema.
Muitas pessoas chegaram até nós e outros integradores pelo fato da solução ser open source e logo após contrataram serviços profissionais destes integradores e isso é fruto da liberdade do projeto.
rvalyi
commented
8 years ago @mbello eu apoio que o Odoo possa ser integrado com libs tipo Tecnospeed. Um parceiro chamado Agitis tinha feito isso na 6.1 mas ate onde eu ele acabou quebrando a cara assim como 90% dos parceiros aqui no Brasil. Mas enfim se conseguiu mais ou menos na 6,1, com certeza o que vamos fazer agora vai permitir usar outras libs numa boa.
Agora eu acho que vai existir sim solucoes open source confiaveis e open source de transmissao de NFe finalmente. Mas pessoalmente tenho mais fe que isso aconteca no mundo do Java e ou .Net pelo fato que sao tecnologias onde tem mais investimento legacy e onde a questao do SOAP fica mole enquanto e um saco no Python.
Do restante penso a mesma coisa sobre boletos e CNAB: na minha opinao foi desperdiciado recursos para re-inventar a roda onde temos solucoes open source maduras e bem mantidas...
Alias, parabenizo tb o Danimar pela iniciativa da libe de NFe dele. Porem, digo o seguiente: o Odoo ainda esta em Python 2.7 e nao se tem certeza se isso vai mudar na v11. Hoje quem faz Python seriamente ta no Python 3+ ja ha um bom tempo. E e por isso que hoje quem mantem o PyNFe faz-lo apenas para Python 3. Logo por mais boa que sera sua lib para Python 2+ ela nao tera muita popularidade. Ai vc vai ter que manter ela para Python 2+ para a galera do Odoo < v11 e talvez fazer uma versao 3+ para Odoo 11+ ou entao fazer uma versao que funciona no Python 2+ e 3+ mas nessa altura nao e facil nao...
Enfim por isso que digo o primeiro passo e fazer esse refactor. O segundo passo sera de botar uma arquitetura client-server para nao impor o runtime do Odoo para o transmissor. Alias sera assim que funcionaria para um Tecnospeed da vida provavelmente.
danimaribeiro
commented
8 years ago Muito legal na teoria, porém a prática diz outra coisa.
Primeiro commit meu para criar o módulo de NFe foi em 2013, porém até hoje esta é a unica opção de envio, não vi ninguém até hoje criar outra opção depois que foi feito o módulo. Dizer que deve ser genérico para que seja possível plugar outro componente na realidade não funciona.
Agora, concordo que devem ser bem modularizado para que seja fácil manutenção.
Resumindo:
l10n_br_account - Faz o cálculo de impostos e deixa os mesmos disponíveis no account.invoice l10n_br_nfe - Cria um documento eletronico com todos os campos e busca os dados calculados do account.invoice, e tem a implementação default de envio. l10n_br_boleto - Busca os dados do account.invoice para emitir e enviar o boleto.
Se você quiser extender, criar outro módulo você tem a total flexibilidade, pois é só criar criar o seu "l10n_br_nfe_super_ultra_power" que vai fazer a mesma coisa que o l10n_br_nfe, pega os dados prontos do account.invoice e envia para onde vc quiser, mesma coisa vale para boleto.
Ou seja não precisa de nenhuma implementação generica com facade, é só deixar bem explicito qual o papel de cada módulo, isto permite que a empresa decida qual módulo vai usar.
renatonlima
commented
8 years ago @danimaribeiro
Para explicar a teoria precisamos falar da prática primeiro. Desde quando comecei o projeto da localização em 2009, quando ainda nem existia o PySPED a unica solucão possível e viável na época era exportar um arquivo TXT ou XML para o emissor de NFe, já que naquela altura o meu foco era primeiro ter uma localização que fizesse o calculo dos impostos e tivesse as informações necessárias para a geração da NFe o que já era uma tarefa monumental se considerar toda nossa legislação brasileira. Com o passar dos anos e o surgimento de libs (PyNFe e PySPED) que tinham como objetivo fazer a transmissão da NFe e com as iniciativas do @mileo e sua, foi iniciado o projeto https://github.com/odoo-brazil/odoo-brazil-eletronic-documents e escolhido o PySPED para fazer a transmissão direta dentro do Odoo o que foi uma grande evolução.
Contudo hoje o ponto que eu vejo mais critico e o que mais me preocupa na localização é a integração com a NFe, porque hoje dependemos de uma solução que funciona, mas tem graves problemas:
Hoje funciona, mas hoje a maioria das pessoas que utilizam o Odoo os problemas mais comuns são relacionado a transmissão da NFe, o que é um ponto extremamente critico, porque se os impostos não foram calculados ou se não for definido um código fiscal (CFOP, CST, CEST e etc) automaticamente é possível informa manualmente no objeto account.invoice, e enviar a NFe.
Hoje se tiver algum problema na transmissão do Odoo, é possível exportar o XML e enviar para o emissor gratuito, porem um fato importante é que a partir de 01/01/2017 o Emissor gratuito não será mais mantido e não haverá mais como que usa o Odoo contar com esta saída caso tenha problemas para transmitir a NFe, e isso é muito critico para o Odoo contar com o PySPED como solução de transmissão, pelos motivos listados acima.
A transmissão é o ponto critico e tem potencial de causar muitos prejuízos para uma empresa que usa o Odoo, imagine a empresa vai fazer o faturamento do dia, confirma os pedidos que vão sair hoje, separa o material no estoque, chama a transportadora para coletar, faz o embarque da mercadoria e na hora gerar as NFes dentro do Odoo, não consegue transmitir, hoje se acontece isso você tem duas opcões:
Estamos falando em uma situação que pode afetar muito uma empresa que usa o Odoo, pois se a empresa não consegue faturar hoje, imagina todo contratempo operacional, e o prejuízo financeiro, além de que se a empresa não faturou hoje, o que o cliente deveria pagar daqui a 28 dias não vai pagar em 28, vai pagar em 29 ou 30, isso pode até impactar no fluxo de caixa. ou seja o faturamento é o ponto mais sensível da empresa.
Eu não concordo com a sua visão sobre o que é a pratica e a sua discordância sobre a teoria desta proposta, explico abaixo:
O fato de hoje existir apenas o PySPED não significa que temos que usar apenas ele, já que conta com graves problemas, precisamos trabalhar para solucionar isso, pois a partir de 01/01/2017 não vamos poder contar com o Emissor gratuito da Sefaz, e vamos contar apenas com o PySPED para fazer a transmissão dentro do Odoo, e com todos os problemas acima você acha isso é razoável?
Isso pode até funcionar, mas imagine, hoje o modulo nfe implementar botões, altera a visão e controla o fluxo de transmissão, retorno, consulta, cancelamento, carta de correção, da forma que é hoje se você for fazer o modulo "nfe_super_ultra_power" você vai ter que refazer todas estas implementações.
E o que estamos propondo com esta discussão é tirar a dependência do PySPED no modulo nfe abstrair em um facede os objetos e métodos de comunicação e serializacão, criar um novo módulo nfe_pysped que implementa o facede e ai sim poderíamos criar o módulo "nfe_super_ultra_power" e também poder contar com outras soluções que tenha uma API como nfe_tecnosped, nfe_neogrid e etc e tornar possível que o @mbello comentou acima, sem ter a necessidade de rescrever em duplicidade códigos.
Você realmente não vê necessidade de se implementar este padrão no módulo nfe? Porque isso iria beneficiar também o suporte ao trabalho que você esta fazendo em uma outra lib para transmissão.
Hoje você e o @mielo são os principais contribuidores do repositório https://github.com/odoo-brazil/odoo-brazil-eletronic-documents, são commits (PSC) deste repositório, é muito importante que na próxima reunião vocês possamos trabalhar em um roadmap discutirmos este assunto, porque com o fim do emissor gratuito vamos precisar decidir o que vamos fazer:
Vamos refatorar o PySPED, colocar testes melhora-lo?
Você havia comentado comigo que estava trabalhando em um projeto de lib para transmitir a NFe, então já suponho que você não vai se envolver com o PySPED mais. Na minha opinião a raiz dos problemas do PySPED citados acima, é não ter tido uma massa desenvolvedores suficiente para mante-lo e evolui-lo. Quando você comentou comigo sobre seu trabalho eu disse que seria importante ter massa crítica de pessoas trabalhando no projeto da lib para não acontecer o que aconteceu com o PySPED. Será se vale a pena trabalhar em uma nova lib em Python 2.7, levando em conta que hoje existe o PyNFe que esta em python 3 e a galera que trabalha com pyhton em django, flask e etc, já estão usando python 3. Será se isso é estrategicamente viável? Porque eu vejo que tem o grande potencial de acontecer com a sua lib o que aconteceu com o PySPED, já que temos mais pessoas trabalhando e usando o PyNFe, são seria melhor juntarmos esforços com o pessoal do PyNFe?
De qualquer forma o trabalhamos que esta sendo proposto aqui também iria beneficiar o seu trabalho já que para você fazer um módulo nfe_trust_nfe_super_ultra_power você escreveria menos código.
Minha opinião sobre o assunto e que se vamos trabalhar para trocar o pySPED por outra lib, temos que trabalhar em uma solução que facilite não depender exclusivamente de uma lib, por com a experiencia que tivemos com o PySPED não é uma boa opção.
Como você e o @mileo são os commits do repo nfe, seria muito bem vindo vocês pensarem nestes pontos citados acima e planejarem uma pauta para discutirmos na próxima reunião
@leorochael seria bom você acompanhar esta discussão
leorochael
commented
8 years ago Minha opinião de 18 anos trabalhando com código Open Source, dois quais 15 em aplicativos web complexos, dos quais 4 em ERPs, mas dos quais apenas 1 em Odoo:
Primeiramente concordo que:
Se o projeto PySPED tivesse mais mantenedores, que respondessem com maior rapidez, talvez nós não estaríamos aqui discutindo fazer uma façade dele, assim como ninguém discute fazer uma façade sobre a biblioteca lxml (para pegar um exemplo arbitrário).
Projetos Open Source que dependem apenas de um único desenvolvedor com controle sobre o código, e que se recusam a compartilhar esse controle, ao mesmo tempo em que não respondem rapidamente às necessidades da comunidade, são um risco para todos os que dependem dele.
Porém discordo de que devamos investir esforço de desenvolvimento fazendo uma "façade". Façades adicionam complexidade em um código que, neste caso, deveria ter sua complexidade urgentemente reduzida.
O que é necessário é que a implementação de NFe seja radicalmente refatorada para extirpar do account.invoice toda e qualquer referência à NFe. E não: separar as views não é o suficiente.
A NFe dentro do Odoo é um caso específico de representar no Odoo uma visão de um documento externo: A Nota Fiscal Eletrônica, cuja representação canônica existe dentro dos servidores do Governo Brasileiro, e cuja representação no Odoo deve ser um mero espelho dessa representação canônica.
E como em todos os casos de representar internamente um documento cuja versão canônica é externa ao Odoo, não deveríamos jamais misturar essa representação com um objeto interno ao Odoo, como o account.invoice.
Portanto a NFe, do ponto de vista do Odoo, precisa ser um modelo independente do account.invoice (no máximo um "inherits"), tendo seu próprio workflow, representando justamente o estado de sincronização desta visão do Odoo em relação à versão canônica (i.e. com estados "rascunho", "em transmissão", "transmitido", além dos estados necessários para representar notas fiscais emitidas por fornecedores).
Este modelo da NFe independente, com suas visões e estados independentes, deve estar em um módulo que:
account.invoice. Exceto talvez adicionar campos related no modelo e em views.Talvez esse módulo possa ter uma implementação de como representar a NFe em alguns formatos, como por exemplo XML ou PDF (danfe). Mas mesmo isso pode ser feito em um segundo módulo à parte.
Uma vez isto feito, podemos então ter módulos que dependem do módulo acima para implementar mecanismos específicos de representação e transmissão da NFe.
Dessa forma, não precisamos de uma façade, que eu entendo ser uma camada de abstração que oferece uma interface uniforme para utilizar mecanismos distintos de transmissão.
Ao invés disso, devemos fazer com que a NFe (e não o account.invoice), ofereça uma interface uniforme que módulos distintos de transmissão da NFe utilizem para obter os dados necessários para trabalhar e para informar a situação desse trabalho.
Em todo caso, acredito que esse é um assunto que seja complexo demais para tentarmos resolver online por meios textuais, como demonstrado pela quantidade de texto digitado apena nesta issue.
Precisamos nos encontrar pessoalmente para discutirmos o caminho a seguir neste e em outros assuntos que impactam a migração da localização para a v10 do Odoo da maneira mais rápida e simples possível.
E por último, gostaria de reforçar quão perigoso é ter um projeto Open Source com apenas um mantenedor (ou cujos poucos mantenedores são todos da mesma empresa) que reluta em adicionar outros desenvolvedores competentes como mantenedores, e do qual vários outros projetos ou empresas dependem. A pluralidade dos mantenedores de um projeto aumenta não só a responsividade a comunidade de utilizadores do código, como também serve para manter todos os mantenedores alinhados com o bem estar da comunidade ao invés de seus próprios interesses.
O que aconteceu com o PySPED pode acontecer com qualquer projeto, inclusive com o l10n-brazil. E a única maneira de evitar isso é através da pluralidade de mantenedores, e de uma comunicação mais constante entre eles.
rvalyi
commented
8 years ago @leorochael, vamos responder detalhadamente na parte tecnica. Porem eu nao sei de onde vc tira que somos "relutante" a adicionar mantenedores. Criamos o projeto em 2009, as outras pessoas so chegaram porque fizemos isso, criamos o forum que hoje tem umas 1300 pessoas. Co-criamos a fundacao OCA junto com 4 outras empresas para dar a estrutura para escalar o projeto de forma open source. Hoje temos uma Pauta daqui pouco que inclue a inclusao de Luis Mileo da empresa Kmee como novo PSC, mesmo que ele comecou a fazer commits uns 4 anos depois no projeto.
Hoje assim como os outros repo da OCA, cada um pode propor PR e fazer revisoes. Os outros projetos tb nao vao ser a mae de ninguem para dizer o que cada um tem que fazer sendo que muita gente nao quer nem aprender Python ou olhar o Odoo primeiro (nao e seu caso). Pelo contrario a Akretion quando viu que gente que nem o Luis Mileo tinha algum potential de ajudar, ate deu um curso tecnico de 5 dia de graca para treinar ele em 2012, acolhemos ele uma semana na sede da Akretion no Rio entao. Quando vc considera que fizemos o primeiro hangout la em 2011 sabe, gastamos o maior tempo para tentar crescer a comunidade, porem sem demagogia porque ate recentemente o codigo do Odoo era bem zoado e a grande maioria das empresas atuando aqui no Brasil so fazia merda, prometia e nao entregava. Com a Odoo SA que tb tava na beira da explosao e que tinha que sempre pegar mais dinheiro emprestado de VC e prometer sempre mais a lua e gente aqui ignorante o suficente para ficar accreditando todo que os caras falavam, vc tinham um coktail bem perigroso com risco se super aquecimento serissimo.
Nao sei se vc soube, mas o site openerpbrasil.org que fizemos la em 2012, gerava 40% do traffico para odoo.com na epoca porque eu ja tinha subido a comunidade na Franca antes de dinamisar a comunidade aqui no Brasil com Renato, isso foi reconhecido publicamente pelo Fabrice Henrion, o direitor USA da Odoo no community days de 2013. Ou seja divulgacao fizemos legal, porem quando 90% dos parceiros da Odoo SA no Brasil nao ficavam um ano no mercado aqui no Brasil ou ate 50% la em mercados bem mais maduros como da Franca e que a Odoo SA queria tentar jogar a culpa em quem tava mais perto to fogo (nois), a gente realmente achou mais razoavel mandar um pouco mais a real sobre o projeto independentemente do que os investidores da Odoo SA queriam ou algums iluminados aqui que todos quebraram a cara inclusive.
Hoje o codigo da v10 parece legal e vai permitir finalmente capitalizar, Mas nem sempre foi assim, espero que vc fica conciente disso... Inclusive so e bom desse jeito hoje por causa da pressao que botamos na OCA.
Agora mesmo que a gente esta disposto a abrir a lista de PSC, nesse repo do que se trata (vamos tb extender), hoje uma fotografia atualizada sobre os committers da isso: https://github.com/rvalyi/l10n-brazil/graphs/contributors
Desculpa mas nao tem muita gente merescendo de ser PSC perto do que o Renato ou eu fizemos. O Luis sim e vamos aceitar com algumas condicoes. Ate o quarto commiter hoje, o Magno e da Akretion sabe...
A gente simplesmente e muito bem organizado com open source e o odoo desde que criamos a empresa em 2009. Olha so essa outra metrica de download dos modulos da Odoo no app store: a Akretion nada menos e do que o maior contribuidor individual na escala mundial: https://www.odoo.com/apps/modules/statistics
ficamos feliz quando tem algumas empresas que nem a Kmee que fazem o jogo do open source. Mas meu amigo vc tem que ver que aqui no Brasil tb tem muita picareta e que tem muita gente que e duas caras e que nem todo mundo que fica se vitimizando de nao poder fazer commit esta disposto a realmente ajudar de forma open source. Oportunismo para tentar tomar conta do projeto isso nao falta, mas gente que se coloca humildamente no lugar dele e aceita de fazer o trabalho que fazemos isso tem muito pouco...
De restante, ve os criterios de aceitacao dos PR na OCA. Hoje o gargalho nao e a falta de commiter longe disso. Hoje o gargalho e a falta de review e de PR e quasi sempre foi assim...
leorochael
commented
8 years ago Oi @rvalyi.
Em primeiro lugar, gostaria de agradecer todo o esforço que a Akretion fez até aqui, tanto na localização brasileira, como na comunidade Odoo como um todo.
Só vou comentar um aspecto da sua resposta, pois em todos os outros aspectos, não tenho nada para discordar:
Porem eu nao sei de onde vc tira que somos "relutante" a adicionar mantenedores.
Eu estava falando do PySPED, e de como é perigoso quando projetos agem com governança semelhante. E que nenhum projeto, nem mesmo a localização brasileira, está livre desses perigos.
Mas se você quer evidência do quanto a direção atual do l10n-brazil tem relutado em acrescentar desenvolvedores, eu preciso apenas apontar quantos meses fazem que o Mileo pediu para ser PSC, sendo aprovado por outros membros da OCA, e ainda não foi aprovado pelos atuais PSCs do l10n-brazil.
Adiciono isso a minha experiência em passar em um hangout de mais de uma hora diretamente com o @renatonlima, no qual e ele afirmou várias vezes que o Miléo era um contribuidor competente, mas mesmo assim se recusou a simplesmente enviar um e-mail confirmando a aprovação do Mileo como PSC, sem dar uma boa razão para isto. E já se passaram vários dias desde esse Hangout, eliminando qualquer desculpa que ele poderia ter para tal comportamento.
Nada nem ninguém pode tirar o mérito da Akretion em trazer a localização brasileira do Odoo até onde chegou, ou mesmo o mérito em, junto a outros participantes da OCA, ter mantido a Odoo s.a. minimamente honesta.
Por outro lado, como comentei com o @renatonlima durante o hangout, o principal fator de saúde de uma comunidade de Software Livre é a motivação de seus contribuidores, que deriva diretamente da confiança em sua equipe de mantenedores. E nada abala mais essa confiança do que ver a equipe de mantenedores agindo contra (ou, no caso, se recusando a agir a favor) do benefício da comunidade .
Nada justifica a atitude de não ter confirmado o Miléo como PSC até agora.
rvalyi
commented
8 years ago @leorochael sobre a parte tecnica: pensamos nesse tipo de coisa claro, nessa coisa ai de inherits e seprara os dados... Se o pysped tivesse feito muito bem seria possivel fazer isso, Porem do jeito que ele tava feito so dava para usar para serializar.
Temos que pensar na estrategia e no timing. Podemos ver um pouco essas questoes que vc proponhe. Mas na ausencia de uma lib tao abstrata e robusta, isso iria atrasar muito a migracao na v10. Se a gente pensa muito bem talvez a gente consegue progressivamente extrair algum codigo do account.invoice e fazer isso por etapas.
O importante e acertar bem o modelo relacional se tiver que mudar algo porque e o que vai ter que mudar se depois a gente fica evoluindo a abstracao desse jeito.
Eu tb acho que isso seria interessante apenas se esse modelo de NFe independente do Odoo fosse realmente usado por outros projetos. Ai na v10 temos que usar python 2.7, na v11 teremos que usar Python 3. Sera se isso vai sincronisar legal com algum outro projeto que vai realmente agregar mais massa critica no projeto? Sera se vale a pena. Vamos debater do assunto.
Que vc chama de facade ou de alguma outra abstracao, o mais importante para gente e estruturar os repos satelites da OCA, delegar mais commiters nisso inclusive para escalar o projeto e poder ter implementacao alternativas de forma que o futuro possa ser preparado ao mesmo tempo que podemos ja usar o que funciona legal.
Bem agora ja e a hora da reunao mas vamos debater de todo isso com tempo. Eu realmente nao fico feliz quando vejo gente que fica mitando sobre a organizacao do projeto ou quer burlar a meritocracia, mas sobre as questoes tecnicas queremos debater com o maior interesse. Continuamos depois.
rvalyi
commented
8 years ago @leorochael enrolamos um pouco para aceitar o Luis, foi mal. Minha mulher morreu no fim de 2014 e ganhei 2 anos de depressao com isso, acabou afetando um pouco ate uns meses atras, mas hoje tou firme e forte de novo. Espero que todos entendem que fatores pessoas assim impactam.
realmente o Luis fazia bastante coisas e ficou uns 4 ou 5 meses fazendo muito menos e agora accordou de novo. Temos que ver as coisas no tempo tb. Aqui varias empresas tentaram dar golpe no projeto, nao vou fazer aqui fofoca mas vc encontra e pode ver que todos inclusive se deram mal, inclusive todos que tentaram fechar com Odoo SA para tentar bolar algumas coisa fechada, Entao a gente ta muito com pe atras porque e brincadeira nao. Vc tem o Danimar tb que chegou a fazer algumas contribs valiosas mas recentemente fez muito menos. A gente tem que realmente avaliar a motivacao a longo prazo. Muita gente erra o business model, chega com tudo e um ano depois quando nao e mais questao de oportunismo nao ajuda mais (nao digo isso de alguem especificamente aqui mas vimos isso demais desde o inicio do projeto).
No final muito pouca gente ficou uns 2 anos ou mais nesse mercado aqui, o tempo para aprender, contribuir e a gente ter certeza que que e confiavel e nao e para fazer bagunca.
Mas o Luis ta dentro sim. Recentemente enrolou tb porque como condicao a gente quer botar umas tarefas para juntar o repo do odoo-brazil/odoo-brazil-eletronic-documents na OCA, o que parece uma urgencia absoluta agora com a fim do emissor e ate na questao a manutencao do pessoal na 8.0. Muita gente la aprovou sem conhecer muito a realidade do nosso projeto, queriamos botar algumas condicoes assim como a OCA nos permite. Porque a final a Akretion fez uns 80% desse repo. Podemos aceitar outras pessoas mas tb nao queremos bagunca e isso tem que ser bem definido.
Bom vamos fazer essa reunao.
mbello
commented
8 years ago Eu insisto que, na prática, a Akretion e/ou a Kmee deveriam escolher um bom serviço de emissão de nota SAAS (neogrid, tecnospeed, oobj, inventti, etc) e implementar o conector para esse serviço, fechando um acordo com a empresa escolhida. A Akretion e/ou Kmee fazem a manutenção da integração e, em troca, ganham comissão pelo serviço SAAS que é contratado pelo usuário final.
De verdade, não sei se os clientes de vocês que querem Odoo são tão"pobres" assim, mas para nenhuma empresa de faturamento acima de R$ 1 milhão/ano (ou talvez até menos) vale a pena correr riscos com soluções in-house se elas podem utilizar um serviço de uma empresa mais conhecida e que costuma ser muito barato. Um emissor NFe SAAS terá validações, manutenção dos XML pelo prazo legal, geração personalizada da DANFE, etc que não faz sentido querer desenvolver tudo isso de novo no Odoo. Eu sei que tudo isso é muito fácil, qualquer um pode fazer um script que faz upload dos XMLs para o Glacier da Amazon, etc... mas tem muita coisa muito fácil por fazer no Odoo, vocês não precisam ficar perdendo tempo fazendo as coisas "muito fáceis" que já podem ser atendidas de outra forma.
Além disso, não sei se vocês percebem que para uma empresa que estejainteressada em contratar o Odoo hoje, dizer "O Odoo emite NFe através do serviço da Tecnospeed/Neogrid, a um custo baixo por nota emitida" é muito melhor do que dizer "O Odoo tem um emissor de NFe integrado e você poderá emitir NFe sem custo". Ninguém que tem algo a perder quer se arriscar com soluções in-house nessas áreas, imagina um gerente de TI vendo essa conversa e descobrindo que o emissor de NFe do Odoo foi desenvolvido e é mantido por um garoto que acabou de sair da faculdade e faz isso part-time?
Tem mais, se seu cliente utilizar o serviço da Tecnospeed porexemplo, não só terá resolvida a questão das NFS-e para centenas de cidades, mas se o contador desse cliente tiver alguma necessidade específica de receber as NFe a cada X dias, etc, tudo isso pode ser feito pela interface da própria Tecnospeed (ou Neogrid, etc), ou seja, tira também dos ombros do suporte técnico da empresa de vocês a responsabilidade por resolver esses detalhes todos que são muito simples, mas vão somando e no final você percebe que a equipe técnica de vocês pode perde horas e horas fazendo coisas simples enquanto poderia fazer o que realmente tem que ser feito.
Por fim, acho que esse modelo deveria ser aplicado de forma ampla nanossa localização, a integração bancária por exemplo deveria com certeza ser feita através da Neogrid ou do Interbancos da eSales, imagina uma interface única com protocolo único para enviar e receber informação para qualquer banco, etc. De novo aqui uma possibilidade de receita para os integradores que vão manter o código da integração com esse serviço externo, e uma possibilidade de rapidamente adicionar funcionalidades ao Odoo que hoje não existem de forma satisfatória e que se forem desenvolvidos in-house com certeza não ficaria com a mesma qualidade.
Mesma coisa vale para SPED.
Resumindo, essa visão de fazer as coisas todas em casa, reinventandoa roda sempre e deixando de alavancar serviços que já resolvem bem esses problemas é uma visão pouco ambiciosa e que não vai nos levar muito longe. Hoje em dia a rapidez de invovação em TI, particularmente serviços SaaS é muito grande, podemos ganhar velocidade utilizando esses serviços ou continuar a passos lentos com essa visão pobre de que temos que ter uma versão built-in para tudo.
Bom saber que o @mileo será finalmente admitido no PSC.
fnegrini
commented
8 years ago Leonardo,
Sustento a bandeira de termos Documentos Fiscais e Contábeis (invoice) separadas desde 2014. Já tentei argumentar sobre a diminuição da dependência com os códigos odoo (account.invoice) além do fato de que existem inúmeras situações em que contabilizações ocorrem sem a geração de documentos fiscais e vice-versa na tentativa de provar que se tratam de modelos distintos, mas até agora não consegui convencer o pessoal aqui.
Meus 2 centavos... Sem querer gerar mais polêmica, pois tb sei que não contribuo a mais de ano para a localização.
Abs,
Fabio Negrini
Em 24 de outubro de 2016 18:29, Leonardo Rochael Almeida < notifications@github.com> escreveu:
Minha opinião de 18 anos trabalhando com código Open Source, dois quais 15 em aplicativos web complexos, dos quais 4 em ERPs, mas dos quais apenas 1 em Odoo:
Primeiramente concordo que:
1.
PySPED é uma biblioteca complexa, que tem bem mais linhas de código do que são necessárias para fazer o que faz, e que não é muito Pythonica . 2.
Além disso (e também como causa disto) a governança atual do projeto PySPED é muito ruim, basicamente caindo sobre um único desenvolvedor que mantem controle estrito sobre o código fonte, e que não responde com rapidez suficiente a issues e a pull requests para manter o projeto de maneira saudável.
Se o projeto PySPED tivesse mais mantenedores, que respondessem com maior rapidez, talvez nós não estaríamos aqui discutindo fazer uma façade dele, assim como ninguém discute fazer uma façade sobre a biblioteca lxml (para pegar um exemplo arbitrário).
Projetos Open Source que dependem apenas de um único desenvolvedor com controle sobre o código, e que se recusam a compartilhar esse controle, ao mesmo tempo em que não respondem rapidamente às necessidades da comunidade, são um risco para todos os que dependem dele.
Porém discordo de que devamos investir esforço de desenvolvimento fazendo uma "façade". Façades adicionam complexidade em um código que, neste caso, deveria ter sua complexidade urgentemente reduzida.
O que é necessário é que a implementação de NFe seja radicalmente refatorada para extirpar do account.invoice toda e qualquer referência à NFe. E não: separar as views https://github.com/OCA/l10n-brazil/pull/363 não é o suficiente.
A NFe dentro do Odoo é um caso específico de representar no Odoo uma visão de um documento externo: A Nota Fiscal Eletrônica, cuja representação canônica existe dentro dos servidores do Governo Brasileiro, e cuja representação no Odoo deve ser um mero espelho dessa representação canônica.
E como em todos os casos de representar internamente um documento cuja versão canônica é externa ao Odoo, não deveríamos jamais misturar essa representação com um objeto interno ao Odoo, como o account.invoice.
Portanto a NFe, do ponto de vista do Odoo, precisa ser um modelo independente do account.invoice (no máximo um "inherits"), tendo seu próprio workflow, representando justamente o estado de sincronização desta visão do Odoo em relação à versão canônica (i.e. com estados "rascunho", "em transmissão", "transmitido", além dos estados necessários para representar notas fiscais emitidas por fornecedores).
Este modelo da NFe independente, com suas visões e estados independentes, deve estar em um módulo que:
- Não pode fazer nenhuma modificação no comportamento do account.invoice. Exceto talvez adicionar campos related no modelo e em views.
- Não deve conter uma implementação do mecanismo de transmissão. Apenas uma representação dos dados e dos estados necessários para gerar uma NFe.
Talvez esse módulo possa ter uma implementação de como representar a NFe em alguns formatos, como por exemplo XML ou PDF (danfe). Mas mesmo isso pode ser feito em um segundo módulo à parte.
Uma vez isto feito, podemos então ter módulos que dependem do módulo acima para implementar mecanismos específicos de representação e transmissão da NFe.
Dessa forma, não precisamos de uma façade, que eu entendo ser uma camada de abstração que oferece uma interface uniforme para utilizar mecanismos distintos de transmissão.
Ao invés disso, devemos fazer com que a NFe (e não o account.invoice), ofereça uma interface uniforme que módulos distintos de transmissão da NFe utilizem para obter os dados necessários para trabalhar e para informar a situação desse trabalho.
Em todo caso, acredito que esse é um assunto que seja complexo demais para tentarmos resolver online por meios textuais, como demonstrado pela quantidade de texto digitado apena nesta issue.
Precisamos nos encontrar pessoalmente para discutirmos o caminho a seguir neste e em outros assuntos que impactam a migração da localização para a v10 do Odoo da maneira mais rápida e simples possível.
E por último, gostaria de reforçar quão perigoso é ter um projeto Open Source com apenas um mantenedor (ou cujos poucos mantenedores são todos da mesma empresa) que reluta em adicionar outros desenvolvedores competentes como mantenedores, e do qual vários outros projetos ou empresas dependem. A pluralidade dos mantenedores de um projeto aumenta não só a responsividade a comunidade de utilizadores do código, como também serve para manter todos os mantenedores alinhados com o bem estar da comunidade ao invés de seus próprios interesses.
O que aconteceu com o PySPED pode acontecer com qualquer projeto, inclusive com o l10n-brazil. E a única maneira de evitar isso é através da pluralidade de mantenedores, e de uma comunicação mais constante entre eles.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-255856464, or mute the thread https://github.com/notifications/unsubscribe-auth/AEd14sP01Yubu4Ok3fVBd6k25tLHcxAUks5q3RUegaJpZM4J72Eb .
aricaldeira
commented
8 years ago Oi, pessoal, tudo joia?
Colocaram meu email na discussão, e faz tempo que minha caixa de entrada não pipoca tanto rsrs
Seguinte, tenho muito a dizer sobre esse assunto, o que você acham de organizar um hangout?
Só precisa ser depois das 18:30, que é quando chego em casa.
Assunto: alinhar com os interessados uma forma de fazer a NF-e de vez no Odoo, e de quebra resolver outras questões da localização.
O que acham?
Em 25 de outubro de 2016 16:24, fnegrini notifications@github.com escreveu:
Leonardo,
Sustento a bandeira de termos Documentos Fiscais e Contábeis (invoice) separadas desde 2014. Já tentei argumentar sobre a diminuição da dependência com os códigos odoo (account.invoice) além do fato de que existem inúmeras situações em que contabilizações ocorrem sem a geração de documentos fiscais e vice-versa na tentativa de provar que se tratam de modelos distintos, mas até agora não consegui convencer o pessoal aqui.
Meus 2 centavos... Sem querer gerar mais polêmica, pois tb sei que não contribuo a mais de ano para a localização.
Abs,
Fabio Negrini
Em 24 de outubro de 2016 18:29, Leonardo Rochael Almeida < notifications@github.com> escreveu:
Minha opinião de 18 anos trabalhando com código Open Source, dois quais 15 em aplicativos web complexos, dos quais 4 em ERPs, mas dos quais apenas 1 em Odoo:
Primeiramente concordo que:
1.
PySPED é uma biblioteca complexa, que tem bem mais linhas de código do que são necessárias para fazer o que faz, e que não é muito Pythonica . 2.
Além disso (e também como causa disto) a governança atual do projeto PySPED é muito ruim, basicamente caindo sobre um único desenvolvedor que mantem controle estrito sobre o código fonte, e que não responde com rapidez suficiente a issues e a pull requests para manter o projeto de maneira saudável.
Se o projeto PySPED tivesse mais mantenedores, que respondessem com maior rapidez, talvez nós não estaríamos aqui discutindo fazer uma façade dele, assim como ninguém discute fazer uma façade sobre a biblioteca lxml (para pegar um exemplo arbitrário).
Projetos Open Source que dependem apenas de um único desenvolvedor com controle sobre o código, e que se recusam a compartilhar esse controle, ao mesmo tempo em que não respondem rapidamente às necessidades da comunidade, são um risco para todos os que dependem dele.
Porém discordo de que devamos investir esforço de desenvolvimento fazendo uma "façade". Façades adicionam complexidade em um código que, neste caso, deveria ter sua complexidade urgentemente reduzida.
O que é necessário é que a implementação de NFe seja radicalmente refatorada para extirpar do account.invoice toda e qualquer referência à NFe. E não: separar as views https://github.com/OCA/l10n- brazil/pull/363 não é o suficiente.
A NFe dentro do Odoo é um caso específico de representar no Odoo uma visão de um documento externo: A Nota Fiscal Eletrônica, cuja representação canônica existe dentro dos servidores do Governo Brasileiro, e cuja representação no Odoo deve ser um mero espelho dessa representação canônica.
E como em todos os casos de representar internamente um documento cuja versão canônica é externa ao Odoo, não deveríamos jamais misturar essa representação com um objeto interno ao Odoo, como o account.invoice.
Portanto a NFe, do ponto de vista do Odoo, precisa ser um modelo independente do account.invoice (no máximo um "inherits"), tendo seu próprio workflow, representando justamente o estado de sincronização desta visão do Odoo em relação à versão canônica (i.e. com estados "rascunho", "em transmissão", "transmitido", além dos estados necessários para representar notas fiscais emitidas por fornecedores).
Este modelo da NFe independente, com suas visões e estados independentes, deve estar em um módulo que:
- Não pode fazer nenhuma modificação no comportamento do account.invoice. Exceto talvez adicionar campos related no modelo e em views.
- Não deve conter uma implementação do mecanismo de transmissão. Apenas uma representação dos dados e dos estados necessários para gerar uma NFe.
Talvez esse módulo possa ter uma implementação de como representar a NFe em alguns formatos, como por exemplo XML ou PDF (danfe). Mas mesmo isso pode ser feito em um segundo módulo à parte.
Uma vez isto feito, podemos então ter módulos que dependem do módulo acima para implementar mecanismos específicos de representação e transmissão da NFe.
Dessa forma, não precisamos de uma façade, que eu entendo ser uma camada de abstração que oferece uma interface uniforme para utilizar mecanismos distintos de transmissão.
Ao invés disso, devemos fazer com que a NFe (e não o account.invoice), ofereça uma interface uniforme que módulos distintos de transmissão da NFe utilizem para obter os dados necessários para trabalhar e para informar a situação desse trabalho.
Em todo caso, acredito que esse é um assunto que seja complexo demais para tentarmos resolver online por meios textuais, como demonstrado pela quantidade de texto digitado apena nesta issue.
Precisamos nos encontrar pessoalmente para discutirmos o caminho a seguir neste e em outros assuntos que impactam a migração da localização para a v10 do Odoo da maneira mais rápida e simples possível.
E por último, gostaria de reforçar quão perigoso é ter um projeto Open Source com apenas um mantenedor (ou cujos poucos mantenedores são todos da mesma empresa) que reluta em adicionar outros desenvolvedores competentes como mantenedores, e do qual vários outros projetos ou empresas dependem. A pluralidade dos mantenedores de um projeto aumenta não só a responsividade a comunidade de utilizadores do código, como também serve para manter todos os mantenedores alinhados com o bem estar da comunidade ao invés de seus próprios interesses.
O que aconteceu com o PySPED pode acontecer com qualquer projeto, inclusive com o l10n-brazil. E a única maneira de evitar isso é através da pluralidade de mantenedores, e de uma comunicação mais constante entre eles.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-255856464, or mute the thread https://github.com/notifications/unsubscribe-auth/ AEd14sP01Yubu4Ok3fVBd6k25tLHcxAUks5q3RUegaJpZM4J72Eb
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-256124249, or mute the thread https://github.com/notifications/unsubscribe-auth/AALU1neu-bgZcow0ZLwFvwxNc9UjgiGrks5q3klDgaJpZM4J72Eb .
Aristides Caldeira Taŭga Tecnologia aristides.caldeira@tauga.com.br (47) 3023-2664
rvalyi
commented
8 years ago @leorochael @fnegrini @danimaribeiro sobre separar o objeto: realmente, ultimamente com o @renatonlima falamos muito de botar um inherits para separar quando o Renato comecou aquele trabalho de separacao das visoes por documento fiscal ( https://github.com/OCA/l10n-brazil/pull/363 ). Nao estamos fondamentalmente contra a ideia.
Mas foi uma questao de prioridades... De qualquer jeito era precisa separar as visoes como o Renato fez certo? Isso era prioritario ate porque simplifica muito a migracao, antes de pular na v9/10... A partir da v8 o inherits realmente funciona legal mas antes so quem nao mexia fundo no Odoo para confiar cegamente que isso era possivel na epoca da 5, 6 ou 7...
Ai beleza algums campos sao do documento fiscal e vao numa outra tabela. O que vc faz dos campos que ja existem no account.invoice, como amount, os campos de linha com o nome do produto, o NCM etc... Vc copia eles? abandona dados normalizados no banco? Vale a pena isso so para se masturbar em cima de um modelo objeto mais puro? Talvez mas e debativel...
Vamos la... Vc tem certeza que vai conseguir manter sincronisado todos os campos com os campos calculados, o workflow complexo do invoice? Optimista... Nossa ampla experienca com connectores e-commerce e duplicacao de dados nos ensinou a ficar mais longe possivel da duplicacao de dados...
Bem na v10 talvez seja possivel porque finalmente o workflow do invoice ficou muito simplificado. Mas enfim quero realmente justificar o PORQUE as coisas sao assim hoje. Isso nao foi por acaso nao.
Tem outros aspectos: o que vc faz com os campos relacionais como as linhas de produto? vc cria outra tabela tb, guarda um blob XML daquilo? Se vc cria outra tabela e usa inherits, sera se vc vai conseguir se virar com os campos Fields relacionais do Odoo para mexer com aquele _inherits nas linhas? Ou vai so sincronisar ao escrever no account.invoice?
Enfim nao estamos contra esse debate mas temos nossas duvidas apenas.
Alem disso tem duas coisa importantes: hoje a localizacao funciona bastante bem ja na v8. Na v10 ja vai fazer um bom estrago no mercado se de portar o que ja temos. Da para melhorar e olha que legal somos exactamentes os que mais ficam melhorando isso, ate no core do Odoo para que as coisas funcionam legal, so vcs ver qtos commits temos la no core... Mas enfim, o importante vai ser desenhar etapas successivas com possibilidade de migracao. Porque nao e a primeira vez que a gente escuta falar em historia de big bang...
Hoje a OCA tem um bom framework de migracao de dados. Se vcs olhar nos projetos banking por examplo vcs podem ver que foi feito numeros refatores importantes dentro de uma serie estavel do Odoo (a 8 especialmente) e realmente parece viavel fazer isso na 10.
Mas talvez a primeira etapa vai ser de migrar mais ou menos o que temos com os testes funcionando para garantir um scope funcional igual e ai depois antes de accrescentar mais coisa de NFSe e outros edocs como CTe's ai a gente pode ver se fica razoavel separar as tabelas e abstrair um pouco mais os objetos.
Enfim, esse debatre sim e interessante com certeza, mas nao deve tb ocultar as outras tarefas sendo feitas e que precisam ser feitas.
mileo
commented
8 years ago São duas perguntas simples, por favor votem nelas:
mileo
commented
8 years ago "2." Um documento eletrônico pode existir s/ necessariamente ter uma invoice diretamente ligada a ele?
(No caso do inherits, temos uma relação de um pra um entre os modelos e o documento eletrônico não pode existir s/ a invoice, OBS: preciso confirmar se com o uso do parâmetro delegate no fields isso é possível)
mileo
commented
8 years ago De resto, talk is cheap e vamos prototipar isso como já iniciado #206 E ver se vai dar certo com inherits, se não fazer oq... quer moleza vai trabalhar com outro software.
Então marcamos o hangout!
mbello
commented
8 years ago @rvalyi @renatonlima @mileo @danimaribeiro @leorochael @fnegrini Eu também sempre fui a favor de separar os modelos, mas eu acho que a discussão deve ir além. Os documentos fiscais na minha opinião estão mais próximos da movimentação de estoque do que da invoice em si. Eu nunca vi uma discussão sobre isso, mas para mim o conceito de quants é uma baita ajuda à localização se soubermos explorar esse conceito para resolver muita coisa na localização. Por exemplo, eu posso ter um mesmo produto que às vezes é comprado com importação direta, às vezes é produto importado adquirido no mercado interno e às vezes é adquirido de um fabricante nacional. Hoje, quase nenhum ERP do mercado resolve esse caso de forma elegante, mas se usarmos os quants nós podemos atribuir a cada quant esse tipo de informação, se houve ST na entrada, quanto foi substituído, etc. Na movimentação de estoque da venda, bastaria olhar essas informações das quants para gerar o documento fiscal de saída (e os lançamentos contábeis), além de automatizar todas essas complexidades que não são bem atendidas no Odoo hoje (pois muitas dessas informações vêm de um campo estático no cadastro do produto ao invés de ser alimentado à partir dos documentos fiscais de entrada).
Ou seja, acho que a discussão sobre o objeto documento fiscal deve ir muito além de se é o mesmo objeto que a invoice ou não, vocês deveriam repensar a coisa de forma mais ampla. Em muitos casos, a movimentação de estoque é o que deveria originar o documento fiscal, caso de remessa para industrialização, transporte para feira/evento, até mesmo um caso de remessa em bonificação poderia fazer mais sentido se originar da movimentação do estoque. Sem falar de transferências entre filiais, etc.
Se na venda o documento fiscal for criado à partir também dos quants, as linhas do documento fiscal não bateriam necessariamente com as linhas da invoice, eu poderia por exemplo faturar 10.000 parafusos ao preço X mas na NFe poderia haver 3 linhas, por exemplo 2000 parafusos com origem = importação direta, 5000 parafusos com origem = nacional, 3000 parafusos como importado adquirido no mercado interno, sempre o mesmo parafuso, mas com origens diferentes. Tudo vendido ao mesmo preço, mas lançado no documento fiscal de forma coerente em relação à entrada do produto no estoque da empresa. Enfim, eu me limitei a apenas uma variável complexa de nossa legislação, se aplicarmos às complexidades de ICMS-ST, etc veremos que pode fazer todo o sentido termos um objeto dedicado ao documeto fiscal e ligado ao mesmo tempo à movimentação de estoque e à invoice.
Emissor de NFe:
Quanto ao emissor, quando eu ouço que a prioridade do Danimar agora é escrever um novo emissor de NFe eu tenho vontade de chorar. Fala sério gente, esse problema já foi resolvido por empresas como tecnospeed, neogrid, etc e é muito barato e mais confiável e mais conveniente, se ficarmos com esse pensamento pequeno de que temos que ter solução built-in para tudo vamos seguir a passos de tartaruga, se quisermos ganhar velocidade precisamos alavancar essas soluções SaaS que já existem, e não me limitaria ao emissor de NFe (e de NFSe), mas também a integração bancária e pagamentos (EDI financeiro da Neogrid ou Interbancos da eSales), SPED (não sei quais são as boas soluções), gateway de pagamentos, TEF, etc.
Torço que um dia os principais devs da localização escolham um serviço pago como o principal emissor de NFe do Odoo, ganhem comissão desse serviço de todos que fizerem uso desse serviço e usem essa comissão para manter o código/conector funcionando. É assim que a gente vai avançar, uma empresa que não tem R$ 100 para gastar com uma solução proprietária para emitir NFe não está precisando emitir NFe de forma automática. O mesmo vale para integração bancária (o EDI financeiro da Neogrid custa R$ 160/mês e faz a conciliação de todos os extratos, emissão de boletos, remessa e retorno automática dos arquivos dos bancos e através de um único protocolo é possível fazer interface com todos os muitos bancos suportados). Não podemos ter essa mentalidade "poor man", assim não iremos a lugar nenhum.
mileo
commented
8 years ago @rvalyi qual sua referência para o voto no item 2?
rvalyi
commented
8 years ago @mileo nao sei se entendi bem a sua pergunta, mas vc poderia ter um registro de CTe por examplo sem registro account.invoice, essa e a ideia, nao?
mileo
commented
8 years ago Sim, minha duvida é se isso é legalmente possível. Se isto for necessário não podemos usar inherits
rvalyi
commented
8 years ago @mbello ja pensamos bastante sobre isso dos quants que vc mentionou... A ideia e que hoje um quant tem digamos uma "chave" caracteristica a partir de propriedades como preco do produto, lot etc.. Assim os quants podem ser juntados apenas quando a chave e igual. A ideia e incluir a origem (e talvez outras chaves do Brasil) como parametro para fazer essa chave.
Eu nao me lembro onde foi mas tipo 2 anos atras ja fiz incluir um refator pelo Josse da Odoo SA dentro do core para tornar isso possivel bem com isso na mente.
E ai sim, com essa coisa de quant, o Odoo detona os outros ERP's do mercado. Vc vai ver eu nao duvido que ja na v10 o Odoo vai poder facilemente ser identificado como simplesmente o melhor ERP no Brasil. Talvez faltara propaganda para as mentes nao esclarescida, mas nao duvido que quem entende vai se tocar disso, eu aposto. Mas eu nao acho que esse ponto invalida o debatre que temos hoje de saber se a gente consegue extrair uma parte dos e-doc da nota fiscal ou nao e como.
Sobre technologia de transmissao. Eu concordo com vc. Mas olha so, hoje o Danimar deve fazer nem 2% dos commits nesse projeto (atualizado aqui https://github.com/rvalyi/l10n-brazil/graphs/contributors ). Se ele gastar os dias dele fazendo uma outra lib de transmissao eu diria que e escolha dele mas de fato isso nao vai tirar recursos do projeto da forma como e hoje (sem querer fazer juiz de valor sobre essa opcao). E quem vai querer um transmissor proprietario facilemente podera ter tb etc..
Agora quando vc fala em faturamento e criticidade vc porem tem que considerar que tem empresas que faturam 1 milhao por mes com notas de 50 RS e outras com notas de 100 000 RS. Numa empresa que emite muitas pequenas notas fiscais ai sim concordo completamente com vc, uma empresa assim deveria investir para terceirizar e ter essa tranquilidade, ate usando tecnologia proprietaria se for preciso. Agora uma empresa que emite poucas notas de valor alto, ai nao eles podem muito bem funcionar com a solucao atual pysped/outro. Porque se funciona 95% dos casos, os 5% onde da merda nao vao ser tantos assim e o nosso suporte vai dar conta. mas mesmo assim queremos melhorar a confiabilidade disso, botar os modulos feitos pelo Pysped nos padroes OCA e preparar para poder usar uma outra lib com comunidade maior assim que for possivel (porem do lado da Akretion pretendemos connectar com outra comunidade e nao gastar energia re-escrevendo isso).
fnegrini
commented
8 years ago Gostaria de contribuir com algumas informações que corroboram com o conceito de invoice, etoque e documentos fiscais devem ser modelos diferentes:
Porque Documento Fiscal não é invoice:
Porque Documento fiscal não é estoque:
Alguns exemplos de situações em que os fatos geradores de documentos fiscais se desacoplam das invoices:
Além das considerações acima que são não-técnicas, acredito que há várias vantagens do ponto de vista técnico:
Quanto à forma de isto ser implantado, poderia contribuir na definição desta modelagem, pois trabalho a seis anos na localização do ERP da SAP e vejo que o modelo adotado por eles poderia ser aproveitado no Odoo (mesmo que parcialmente). Teria de ser remotamente, entretanto, pois sou de Curitiba.
Enfim, seguem meus 2 centavos (ou um pouco mais).
Em 25 de outubro de 2016 22:34, Raphaël Valyi notifications@github.com escreveu:
@mbello https://github.com/mbello ja pensamos bastante sobre isso dos quants que vc mentionou... A ideia e que hoje um quant tem digamos uma "chave" caracteristica a partir de propriedades como preco do produto, lot etc.. Assim os quants podem ser juntados apenas quando a chave e igual. A ideia e incluir a origem (e talvez outras chaves do Brasil) como parametro para fazer essa chave.
Eu nao me lembro onde foi mas tipo 2 anos atras ja fiz incluir um refator pelo Josse da Odoo SA dentro do core para tornar isso possivel bem com isso na mente.
E ai sim, com essa coisa de quant, o Odoo detona os outros ERP's do mercado. Vc vai ver eu nao duvido que ja na v10 o Odoo vai poder facilemente ser identificado como simplesmente o melhor ERP no Brasil. Talvez faltara propaganda para as mentes nao esclarescida, mas nao duvido que quem entende vai se tocar disso, eu aposto. Mas eu nao acho que esse ponto invalida o debatre que temos hoje de saber se a gente consegue extrair uma parte dos e-doc da nota fiscal ou nao e como.
Sobre technologia de transmissao. Eu concordo com vc. Mas olha so, hoje o Danimar deve fazer nem 2% dos commits nesse projeto (atualizado aqui https://github.com/rvalyi/l10n-brazil/graphs/contributors ). Se ele gastar os dias dele fazendo uma outra lib de transmissao eu diria que e escolha dele mas de fato isso nao vai tirar recursos do projeto da forma como e hoje (sem querer fazer juiz de valor sobre essa opcao). E quem vai querer um transmissor proprietario facilemente podera ter tb etc..
Agora quando vc fala em faturamento e criticidade vc porem tem que considerar que tem empresas que faturam 1 milhao por mes com notas de 50 RS e outras com notas de 100 000 RS. Numa empresa que emite muitas pequenas notas fiscais ai sim concordo completamente com vc, uma empresa assim deveria investir para terceirizar e ter essa tranquilidade, ate usando tecnologia proprietaria se for preciso. Agora uma empresa que emite poucas notas de valor alto, ai nao eles podem muito bem funcionar com a solucao atual pysped/outro. Porque se funciona 95% dos casos, os 5% onde da merda nao vao ser tantos assim e o nosso suporte vai dar conta. mas mesmo assim queremos melhorar a confiabilidade disso, botar os modulos feitos pelo Pysped nos padroes OCA e preparar para poder usar uma outra lib com comunidade maior assim que for possivel (porem do lado da Akretion pretendemos connectar com outra comunidade e nao gastar energia re-escrevendo isso).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-256218165, or mute the thread https://github.com/notifications/unsubscribe-auth/AEd14oG0VFNJ7FlQU9ReVFjoOP4l_ziiks5q3qAMgaJpZM4J72Eb .
danimaribeiro
commented
8 years ago Como estou com preguiça de escrever, considera que os dois textos do Negrini fui eu que escrevi :)
Possuo o mesmo posicionamento.
aricaldeira
commented
8 years ago Pessoal, acho que meu comentário anterior acabou não chegando pra vocês, então estou respondendo de dentro do github mesmo.
O que o Negrini falou é certo e correto.
Tenho isso tudo feito prum cliente na versão 6.1 ainda: NF-e, NFS-e, entrada de CT-e, NF-e, tudo automatizado, boletos de vários bancos (emissão e tratamento de retorno), financeiro separado da contabilidade, folha rodando (SEFIP, GPS e tudo mais, horistas, mensalistas, comissionistas, autonomos, pro-labore etc.), contabilidade rodando com SPED contábil, tudo tudo.
Preciso expor a situação pra vocês com calma.
Topam combinar um hangout?
renatonlima
commented
8 years ago Olá Pessoal,
Hoje durante o dia estou ocupado bem ocupado por aqui, estou seguindo um pouco a discussão, mas a noite eu vou contribuir com meus 2 cents!
@aricaldeira e @fnegrini Muito bom ver vocês por aqui!
@fnegrini como você trabalhou com o SPED no SAP é importante você participar desta discussão, porque começamos a falar sobre o suporte a serialização e envio da NFe e começamos a falar sobre o conceito da NFe dentro do Odoo
@aricaldeira pensei que o PySPED estava orfão, hoje o PySPED é importante para o projeto da localização do Odoo, podemos fazer um hangout para discutirmos o que você mencionou acima, pois integrar isso a localização seria uma ótima contribuição!
fnegrini
commented
8 years ago Podem contar comigo sim!
Em 26 de outubro de 2016 15:58, Renato Lima notifications@github.com escreveu:
Olá Pessoal,
Hoje durante o dia estou ocupado bem ocupado por aqui, estou seguindo um pouco a discussão, mas mais a noite eu contribuir com meus 2 cents!
@aricaldeira https://github.com/aricaldeira e @fnegrini https://github.com/fnegrini Muito bom ver vocês por aqui!
@fnegrini https://github.com/fnegrini como você trabalhou com o SPED no SAP é importante você participar desta discussão, porque começamos a falar sobre o suporte a serialização e envio da NFe e começamos a falar sobre o conceito da NFe dentro do Odoo
@aricaldeira https://github.com/aricaldeira pensei que o PySPED estava orfão, hoje o PySPED é importante para o projeto da localização do Odoo, podemos fazer um hangout para discutirmos o que você mencionou acima, pois integrar isso a localização seria uma ótima contribuição!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/402#issuecomment-256428294, or mute the thread https://github.com/notifications/unsubscribe-auth/AEd14hBv2JwzJq1ZX-cJ720GiVFMjBVrks5q35TYgaJpZM4J72Eb .
aricaldeira
commented
8 years ago Pessoal,
Horários possíveis pra mim esta semana:
sexta-feira, dia 28/10, as 18:40 sábado, dia 29/10, as 09:30
O que acham?
mileo
commented
8 years ago Pode ser segunda de noite? Essa semana ta foda....
mileo
commented
8 years ago Cc @santagada
mileo
commented
8 years ago @aricaldeira cade o código?
mileo
commented
8 years ago Hangout hj?
aricaldeira
commented
8 years ago Oi, Mileo, sim, as 19:30
O Renato estava em contato comigo, pediu pra ser esse horário
Acho que ele vai contactar vocês diretamente, parece que ele já sabe como organizar isso entre o pessoal da comunidade.
De toda forma, me adicionem como contato no hangouts: aristides ponto caldeira arroba tauga ponto com ponto br
aricaldeira
commented
8 years ago O gmail que vc usa é o mileo arroba kmee ponto com ponto br?
renatonlima
commented
8 years ago Opa pessoal,
Estava combinando com o @aricaldeira um hangout para ele comentar sobre o trabalho que ele mencionou acima, seria bom ele apresentar e explicar sobre como ele pode ajudar a integrar alguns trabalho na localização, hoje estou finalizando alguns assuntos que conversamos na semana passada, então eu sugiro fazer este hangout amanhã terça-feira às 19:30
Hoje o e complicado o codigo OCA da localizacao depender da lib pysped por alguns motivos:
Porem, por outro lado e hoje a forma mais facil de transmitir as NFe de forma totalmente open source com o Odoo.
Podemos pensar em incluir o codigo de transmissao dos documentos fiscais baseado na lib pysped ( repo https://github.com/odoo-brazil/odoo-brazil-eletronic-documents ) na OCA num futuro proximo na condicao de atingir alguns criterios.
Um deles e que seja relativamente facil de trocar o pysped por alguma outra implementacao futuramente.
Uma forma de fazer isso e de criar uma "façade" abstrata do pysped. Veja: https://en.wikipedia.org/wiki/Facade_pattern
a Ideia e que no repo l10n-brazil a gente tenha essa façade, provavelemente no modulo l10n_br_account_product mas talvez alguns metodos poderiam descer ate o l10n_br_account.
Essa façade deve ser abstrata e nao deve depender da lib pysped, porem deve abstrair os metodos do Pysped que serao usados pelos modulos do repo https://github.com/odoo-brazil/odoo-brazil-eletronic-documents Nesse repo sim, teria uma implementacao concreta dos metodos da façade de transmissao e que ira usar o pysped.
Alem disso, sera importante que nehnum metodo do repo odoo-brazil/odoo-brazil-eletronic-documents usa o pysped sem passar pela implementacao concreta dessa façade.
Assim trocando a implementacao concreta da façade por uma outra usando outra biblioteca, sera mais facil migrar para uma outra lib de transmissao.
Nessa façade nao precisa assumir uma arquitetura cliente-server para a lib de transmissao. Porem tera que permitir tal arquitetura para que aceitamos o merge da façade no repo l10n-brazil.
Pontos em aberto:
seria interessante que o API da façade aceita a NFe num formato JSON, com mapeamento automatico, por examplo usando a lib http://lxml.de/objectify.html Dessa maneira, o codigo no repo OCA/l10n-brazil teria so que mapear o invoice com os campos do Odoo para os campos da lib pysped (na verdade muitos nomes de campos devem estar normalizados pelo XSD na NFE), passando os campos num JSON. la na implementacao concreta da façade a lib objectify (ou outra) maperia os campos num objeto de nfe do pysped de forma entao automatica.
Tambem parece razoavel que mantenhamos a serializacao das NFE usando o pysped dentro do repo OCA/l10n-brazil num primeiro momento (como e hoje) numa parte isolada bem identificada. Assim trocar por outra lib de serializacao fica possivel, porem temos uma serializacao padrao dentro do repo hoje, porque essa parte da serializacao nao e tao fragil (a parte da comunicacao com o site da fazenda e muito mais fragil).
cc @renatonlima @mileo