← Back to team overview

openerp-brazil-team team mailing list archive

Re: Status e possível aceleração da tradução

 

Henrique,

Como você disse, o que me atraiu no OpenERP foram a excelente arquitetura, a velocidade com que o projeto está andando, e a flexibilidade de se ter o código-fonte eliminando riscos, lock-ins, etc. Como não estou "desesperado" para implantar o sistema, a falta de funcionalidade no curto prazo não é um deal-breaker.

Na minha empresa, precisamos melhorar os controles da unidade de varejo, que hoje roda com um sistema desenvolvido internamente. A maior barreira para implementar o OpenERP é o PDV. O módulo de PDV do é muito fraco e não resolve o problema de integração loja-matriz. Então tomei a seguinte decisão: 1) Usar um PDV de terceiros já adaptado a ECF, TEF, ergonomia, etc. nas lojas; 2) Integrar o PDV com o ERP via troca de mensagens XML. Uma arquitetura bem parecida com a que você descreveu (GEMCO+ORACLE).

Isso faz pouco mais de 2 meses e não estou full-time nesse projeto. Ainda não chegamos na etapa de treinar funcionários. Primeiro estou aprendendo como funciona o OpenERP (regras de negócio, modelo de dados, a estrutura MVC, etc.) e desenvolvendo o módulo de integração com PDV. Um esboço da especificação (um pouco desatualizado) está aqui: http://www.bluwiki.com/go/OpenERP_POS

Particularmente, é o primeiro projeto open-source que participo ativamente e devo dizer que estou gostando da experiência. Usando a modularização do OpenERP separei o projeto em dois módulos um que eu chamei de MBI que monta uma estrutura genérica de serialização e transmissão do XML usando o ActiveMQ; e outro que usa essa plataforma para integrar com o PDV. O primeiro módulo já está quase pronto para uso, inclusive em uso pelo Dukai - um sérvio que me ajudou bastante - para integrar várias instâncias do OpenERP. A velocidade com que tudo ocorreu me animou bastante.

Att,

Cloves Almeida



Henrique Meira escreveu:
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





References