openerp-brazil-team team mailing list archive

[Henrique Meira <henrique@xxxxxxxxx>]

Oi Cloves, tudo bem?

Como mencionei no e-mail anterior acredito que nos organizando podemos
utilizar o Rosetta mesmo.

Você iniciou esta implantação do OpenERP há quanto tempo? Você pode ir
relatando os aspectos técnicos e funcionais que vem enfrentando neste
projeto? Quais os módulos irá utilizar? Pq varejo não é brincadeira
!!!! :D   E com relação a treinamento? Como está preparando seus
usuários?

Sobre o frente de caixa, estivemos discutindo o assunto internamente e
estamos pensando em criar uma solução baseada no ACBR
(http://acbr.sourceforge.net/) e tentar torna-la "oficial" no OpenERP
tropicalizado. Este assunto já está esgotado no seu projeto ou
gostaria de discutir esta possibilidade? Se quiser falar sobre SPED e
NF-e talvez eu possa lhe ajudar.

Com toda certeza o OpenERP não é um software de prateleira, ainda bem!
Este sistema me parece muito bem "arquiteturado" e o fato de ser
modular (de verdade) me atraiu muito. Ele me parece possibilitar uma
configuração adequada para cada tipo de empresa, não apenas ramo de
atividade, mas cultura corporativa.

abraços,

henrique.




2009/11/10 Cloves Almeida <cjalmeida@xxxxxxxxx>:
> Olá Henrique,
>
> Está devagar mas está andando :)
>
> Em relação a tradução da interface, mesmo que com as limitações do Rosetta,
> é melhor que nada. Tem muitos módulos que estão no zero em respeito à
> tradução. E dá para aproveitar muito da localização pt_PT.
>
> Eu estou comprometido em implementar o OpenERP na minha empresa (manufatura
> e varejo, ~50 usuários, médio porte). Como parte do processo, vi a
> necessidade de desenvolver uma integração com soluções externas de frente de
> caixa - a legislação sobre esse tipo de sistema é coisa de doido, melhor
> ficar fora do escopo do OpenERP. Imagino que até o fim do ano estará pronto
> uma interface genérica que integra com frentes de caixa via XML. Parte da
> especificação está aqui: http://www.bluwiki.com/go/OpenERP_POS . Ainda não
> olhei NF-e, e SPED, mas como PDV, são soluções padronizadas que acho mais
> interessante integrar com o OpenERP que desenvolver internamente. O custo é
> baixo e em boa parte dos casos você pode financiar junto ao BNDES (aliás,
> Raphael, isso é um assunto interessante para integradores, se quiser lhe
> passo mais informações)
>
> Hoje estou dedicado umas 15h semanais nesse projeto, mas a partir da semana
> que vem pretendo colocar mais uma pessoa nisso. Quando a integração com POS
> estiver pronta e rodando um projeto piloto em produção, muito provavelmente
> iremos contratar alguém para nos ajudar a implementar no resto da empresa.
>
> Com certeza o OpenERP não é um "software de prateleira", mas até ai, nenhum
> ERP o é. Em comparação com outros ERP open-source, é de longe o mais bem
> construído. E para empresas de médio porte, como a minha, é uma solução
> melhor que Microsiga, Datasul ou SAP BO, quando a localização estiver pronta
> - só falta integradores.
>
> No que puder ajudar, estou a disposição.
>
> Att,
>
> Cloves Almeida
>
>
> Raphaël Valyi escreveu:
>>
>> Ola Henrique,
>>
>> Bom, primeiro vi seu log no IRC hoje. Voce nao se encontrou com o Cloves
>> que esta trabalanho com OpenERP em Goias (cjalmeida no #openobject) por
>> pouco, e geralmente fico la tanbem (rvalyi), menos hoje mas ou menos.
>>
>> Bom, vc acertou, a traduçao esta meia paradinha, seria bom ela avançar
>> melhor.
>> O negocio é que nao esta simples, o unico jeito que e editora Tiny
>> consegue integrar é se o pessoal usa a ferramento Rosetta do Launchpad,
>> assim que nos explicamos nesse tutorial:
>> http://www.openerpbrasil.org/localizacao-brasileira/traducao-em-geral
>>
>> Mas ainda tem 3 problemas:
>> 1) é complicado ter feedback sobre que vc esta traduzindo, vc tem que
>> mandar no Launchpad, alterar de vez, baixar, testar, se tiver errado tem que
>> corregir la senao vc ja atrapahla todo mundo.
>> 2) para funcionar direito, os committer da Tiny tem que exportar os termos
>> mais atuais para ser traduzidos no Rosetta, se nao for vaoi faltar coisas na
>> hora de importar as traduçoes no OpenERP de volta. Acho que agora que a 5.0
>> esta mais estabilizada, isso é menos problema.
>> 3) Mesmo assim, ainda precisa Tiny fazer uma operaçao para importar as
>> traduçoes do Launchpad de volta nas branches do OpenERP para todo mundo se
>> beneficiar
>> Tiny esta completamente sobre-carregada porque esta tendo suncesso
>> international muito grande, entao nem isso os caras estao conseguindo fazer
>> direito.
>>
>> Para resolver esse cresciemento, Tiny acabou de deixar publico que estava
>> procurando fundos:
>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a0Wy0DITQBiA
>> <http://www.bloomberg.com/apps/news?pid=20601204&sid=a0Wy0DITQBiA>
>>
>> Nao tem perigro, por conhecer bem o Fabien Pinckaers, posso segurar que o
>> cara so vai vender poucas shares e tudo ficara no open com mesmo espirito,
>> diferentementes de algums outros (Compiere, Openbravo que venderam a alma
>> tb).
>>
>> Isso permittira conseguir mais pessoas na Tiny e cuidar melhor da
>> comunidade. Ate um cara so cuidando da comunidade gigante é preciso, nem
>> isso eles tem. Realmente, acho que poucas pessoas fazem ideas dos milagros
>> que fizearm ate agora com tantas poucas pessoas competentes que eles tem.
>>
>>
>> Ainda que bem carregado, recentemente aceitei de dar uma força para Tiny
>> tipo um dia por semana antes que eles conseguem um cara full time para isso.
>> Ainda nao ta assinado, mas se consiguo me livrar um pouco das nossas
>> integraçoes OpenERP, eu faço logo, nao farei mais do que 1 dia/semana porque
>> nao posso deixar de cuidar da minha empresa Akretion.com que precisa crescer
>> é alcançar massa critica.
>>
>> Mas na verdade, minha preocupaçao esta muito mais com a versao 5.2 que
>> tera freeze em final de Decembro do que a tropicalizaçao porque o OpenERP so
>> sera democratico e com mercado grande apenas se melhora muita coisa, apesar
>> de ja estar liderando os ERP's livres.
>> Quero ter certeza que nos implementamos apenas a parte importante dessa
>> listinha: https://blueprints.launchpad.net/~rvalyi
>> <https://blueprints.launchpad.net/%7Ervalyi>
>> e das outras listinhas que outros tem.
>> So para lembrar, ainda por falta de recursos humanos imediatos, Tiny esta
>> parada em cilcos de release de um ano. Quer dizer se perdemos esse trem,
>> perderemos muito tempo, fora a pequena elite que ja consegue usar do jeito
>> que esta. Tropilcalizaçao podera chegar depois equanto melhorias na
>> arquitectura. Para mim pelo menos é menos importante.
>>
>> Mas mesmo assim, se eu do essa força para Tiny, meu objetivo vai ser de
>> conseguir melhor integrar as contribuçoes, inclusive de localizaçao.
>>
>>
>> Bom, outro problema que nos temos é que nao basta so traduzir. Por iser,
>> pode nao gostar, mas os caras da Tiny, inclusive do Fabien Pinckaers ficaram
>> um tempinho com ingles bem ruim. A consequencia disso, é que tem chave de
>> traduçao que vai precisar trocar porque:
>> 1) é vergonha na cara, principlamente tira uma parte da comunidade que vao
>> perfirir escutar o ingles perfeito da Compiere o Openbravo
>> 2) os caras que usam no paises que falam ingles, nao tem camada de
>> traduçao entao levam os erros na cara direito.
>> 3) em algums paises, os tradutores estao com as maiores dificultades
>> tanbem para traduzir porque nao entendem algums termes em ingles errado
>> So para falar, nao ficou melhor com os outros, pelo menos pouco tempo
>> atras, toda camada javascript era em espanol, e ate mais do que javascript
>> so...
>>
>> Acho que o assunto fico bem resumido aqui:
>>  http://openobject.com/forum/topic13662.html
>>
>>
>> Bom, tem o curto e longo prazo. Podem ajudar nos dois sentidos:
>> A curto parzo, tem que arguentar o Rosetta e os erros de ingles e tem que
>> puxar o saco da Tiny para que eles integram novas traduçoes.
>> No prazo medio/longo, vamos ter que atualizar essas traduçoes quando o
>> ingles sera corrigido, parte porderia ser automatica talvez.
>>
>> Eu, pessoalmente, nao escrevo portugues direito, porque como vc repara sou
>> gringo (frances), entao tenho muito mais valor agredado em agilizar esses
>> fluxos com porcessos é soluçoes tecnicas do que contribuir tradiçoes
>> aproximativas. Para completar o quadro o brasileiro experimentado do nosso
>> team Akretion, Renato Lima, tambem esta super carregado com trabalho que
>> ainda nao largou e projetos gringos...
>>
>>
>>
>> Eu tenho logo duos propostas para fazer para Tiny (vou ligar para eles
>> amanha, qui hoje mas fiquei enrolado com conexao Magento - OpenERP):
>>
>> 1) vou propor de organizar um jeito de fazer alteraçoes importantes do
>> codigo/traduçoes para versao 5.2 mas de um jeito que vai dar para migrar.
>> Porque quando teve varias mudanças entre verçoes 4.2 e 5.0, migraçao ficou
>> coisa quasi impossivel. Ja que a versao 5.0 é melhor a tentaçao poderia ser
>> do imobilismo. Acho que OpenERP precisa sim ir para frente, incuindo as
>> inumerosas controbuçoes a redor do mundo (depois de filtrar claro), mas
>> deixar o cominho de migraçao explicito.
>> Se Tiny gostar do meu plano, logo voltarei a explicar esse. Isso
>> permittira de resolver isso http://openobject.com/forum/topic13662.html
>>  como inumerosas coisas para mudar.
>>
>> 2) Confesso que nao conheço o assunto super bem, mas acho que o melhor
>> seria um modulo para integrar traduçoes feitas localmente no OpenERP direito
>> no Launchpad, usando webservices da Launchpad. So que mesmo que planejado
>> ainda nao vi essa API para Rosetta. Talvez pode ser contorneado, usando HTTP
>> e/ou bzr se conseguimos fazer bzr e Rosetta funcionar melhor junto.
>> De qualquer jeito, vou ver isso com Tiny amanha, depois falo quais sao as
>> pistas.
>>
>>
>> Sobre traduçao de coisas tipo;
>>
>>    1o. Conhecer as pessoas envolvidas e como anda o projeto de tradução.
>>
>>
>> Bom, acho que as vc vai ver a pessoas mais ativas nessa lista, mesmo que
>> ainda pouca ativa.
>>
>>    2o. De acordo com o cenário apresentado me oferecer para ajudar e
>>    também, juntamente com minha empresa, patrocinar (financeiramente) a
>>    conclusão do projeto.
>>
>>
>> Olha, nos Akretion.com somos integradores experimentados com OpenERP, os
>> primeiros parceiros da oficial no Brasil.
>> Se vc pagar por isso, podemos dar prioridade a isso sobre nossos outros
>> projetos gringos (ou temos pelos menos uma pessoa que nao tem muito
>> conhecimento technico mas poderia trabalhar nisso junto com nos), vc que
>> sabe.
>> Daqui nao muito tempo tembam faremos formaçoes, no Rio primeiro, talvez
>> Sao Paulo depois.
>>
>>
>>    A ideia é ser bastante expansível, incluindo não apenas textos,
>>    rótulos
>>    e mensagens do programa, mas também os principais documentos como o
>>    openerp_book.pdf.
>>
>>
>> Bom, sobre isso: o maior erro que pode ser feito é de traduzir esses
>> documentos sem usar a mesma ferramenta do que Tiny. Por iser, o passado
>> mostra que ja évoluiu muito OpenERP e a documentaçao dele, e ainda precisa
>> que muda.
>> Caso vc nao usar Sphinx e Launchpad para traduzir, vc nao vai saber o que
>> vai ter que alterar no tempo. Vai te levar um ano para traduzir e quando for
>> feito, essa traduçao ja vai estar passando informaçoes erradas, que vao
>> atrapalhar as pessoas e a imagem do produto ao inves de ajuda-los.
>> Isso foi que aconteceu com o wiki frances, Tiny quis ate tira-lo do ar por
>> isso.
>>
>> Na minha opiniao temos que aceitar que em primeiro lugar, as pessoa vao
>> ter que falar ingles para integrar o OpenERP (talvez nao para apenas usar
>> depois de fomaçao, se a tropicalizaçao for boa), senao terao que ir brincar
>> com Stoq ou Totvs. Como ja falei, isso ainda é verdade la na França mesmo
>> com mais de 20 integradores oficiais e comunidade eu diria 20 vezes maior
>> desde algmus anos. Isso ate a comunide estar grande suficente para encarar a
>> traduçao completa e atualizada; accredito que so poderemos fazer isso dentro
>> de um ou dois anos infelizmente. Olha so, nao a tropicalizaçao avança
>> direito, ja quer mainter a traduçao de 1500 paginas de documentaçao super
>> tecnica?
>> E bom lembrar que é open source. Open source tem pouco dinheiro, e so
>> consegue se sustentar se for international, mas em final, vence.
>>
>> Enquanto isso, sou pessoalmente a favor de artigos de blog com assunto
>> definido e dominado (ja que o perimetro integral das 1500 paginas nao vai
>> ser, talvez com vc pode encontrar aqui na espanha:
>>  http://www.openerpsite.com/ ) para divulgar o OpenERP no Brasil enquanto
>> isso. Isso é a idea por tras do portal openerpbrasil.org
>> <http://openerpbrasil.org> (que tem vantagem se ser independente) que
>> mentionara esses artigos e dara visibilidade a eles. Tenho que dizer que bem
>> poucos tais artigos ainda foram contribuidos infelizmente.
>>
>>
>>    p.s.: Alguém pode me dizer onde devo procurar pessoas interessadas em
>>    módulos específicos para o Brasil? Como por exemplo NF-e, SPED
>>    Fiscal e
>>    Contábil, Frente de Caixa, etc...
>>
>>
>> Akretion, pelo menos esta trabalhando nisso:
>> https://blueprints.launchpad.net/openerp.pt-br-localiz/+specs?show=all
>>
>> So que tanbem, vamos no nosso ritmo. Para nois, isso nao traz nehnum lucro
>> enquanto o telefone nao para de tocar com projetos la na Europa. Nos
>> balançamos o esforço entre os dois e ja somos quem mais fazem por aqui ate
>> que se prova o contrario. Pessoalmente acho triste que tem que ser gringo
>> que vem liderar a localizaçao brasileira...
>> Nos tambem estamos envolvidos em monte de outros modulos para comunidade,
>> algums atuais:
>> http://github.com/rvalyi/ooor
>> https://launchpad.net/magentoerpconnect
>>
>>
>> Assim que falei, nos acabamos de entregar uma versao melhorada do modulo
>> report_intrastat que em principio vai permittir de implementar:
>>
>> https://blueprints.launchpad.net/openerp.pt-br-localiz/+spec/extencao-fatura-em-nf
>> O que sera mais um paso na direçao de Nota Fiscal electronica.
>>
>> So para lembrar, apesar de nao ainda nao divulgado (por falta de tempo), o
>> plano de contas brasileira oficial ja esta na branch do modulo l10_n_br.
>>
>> Logo que nos temos a estrutura de dados para lidar completamente com Nota
>> Fiscal, podemos pensar no exporte par NFE, veja so o grafe das dependenças:
>> https://blueprints.launchpad.net/openerp.pt-br-localiz/+spec/exporte-nfe
>>
>> So para avisar, nos na Akretion esperaremos cliente brasileiro financiar o
>> exporte XML para NFE, agora se alguem que contribuir antes, seja bem vindo.
>>
>> Nos analisemos a situaçao, nao da para ter os webservices para o OpenERP
>> se comunicar com a Receita Federal diraitamente, o especificaçao é uma droga
>> que parace que so foi feito para presevar o monopole de quem implementou. Na
>> argentina e no Equador é muito mais simples, so no Brasil a especificaçao é
>> tao laboriosa... O que vai ter que fazer, e criar exporte XML para o
>> software Java da NFE que ele comunicara com a receita Federal.
>>
>>
>> Bom, é isso ai. Logo que tenho o feedback da Tiny para traduçoes, eu volto
>> a falar. Enquanto isso, tem muitas coisas que vc pode ajudar ou nos contar
>> para suporte (so que com antecedencia porque nos estamos cheio de trabalho).
>>
>>
>> Abraço
>>
>>
>> Raphaël Valyi
>> http://www.akretion.com.br  - primeiro integrador OpenERP parceiro da Tiny
>> no Brasil
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-brazil-team
>> Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-brazil-team
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>