openerp-brazil-team team mailing list archive

[Joe Pimentel <joe.b.pimentel@xxxxxxxxx>]

Olá Celso,

Diagrama de classes: Eu também estou com essa dúvida.


Acho que o ideal seria importarmos o OpenERP no programa Dia, mas pelo que
pude observar até agora,  não existe a funcionalidade de engenharia reversa
para o código do OpenERP. O que existe no Dia é, a partir de um diagrama
desenhado, conseguir gerar o código do módulo.
Existe uma resposta no launchpad pra essa pergunta mas acho que não entendi
direito a resposta ou ela realmente não foi respondida de acordo (
https://answers.launchpad.net/openobject-server/+question/66205).

Tentei várias outras ferramentas UML mas apesar de conseguir importar o
código python, não obtive sucesso em exibir corretamente as relações entre
classes e seus atributos em nenhuma porque as relações de herança e
referência assim como as colunas não são código python mas sim atributos
mascarados como "_inherit = 'res.partner.address' " ou "_columns = {
'column':  fields.char('Número', size=10) }".

Ou seja, acho que qualquer ferramenta UML terá que ter um plugin específico
para o OpenERP (ou para a camada de persistência que ele utiliza).

-- 
Joe Bertoli Pimentel
joe.b.pimentel@xxxxxxxxx


2009/5/18 Celso Canaan <celso.canaan@xxxxxxxxxxxx>

> Bom dia...
>
> Nós não encontramos outra solução a não ser quebrar a restrição do nome.
> Como homônimo não é tão frequente, tratamos como exceção.
> Criamos e controlamos a entidade pessoa com um id e configuramos nosso
> Erp para  minimizar erros com redundâncias, emitindo avisos de
> confirmação e em alguns casos bloqueando.
>
> Uma dúvida: como vejo um diagrama de classes no OpenErp?
>
> Celso.
>
> -------- Mensagem original --------
> De: Luiz Franca <luiz@xxxxxxxxxxxxxxxxxxxxx>
> Para: Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
> Cc: OpenErp Brasil <openerp-brazil-team@xxxxxxxxxxxxxxxxxxx>,
> marcelo.ferrari <marcelo.ferrari@xxxxxxxxxxxx>
>
>
> 2009/5/17 Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
>        [...]
>
>
>        Razão Social - Não existe este atributo.
>        É necessário? No meu entendimento não (me corrijam se eu estiver
>        errado).
>        Este seria o mesmo atributo do Nome do Parceiro. Para resolver
>        os problemas referentes a filiais / departamentos com Nome de
>        Parceiro diferentes utilizariamos a estrutura da empresa (eu
>        preferiria chamar de estrutura do parceiro pois pode ser
>        aplicado também para PF).
>        Quando desejarmos a Razão Social do Parceiro utilizariamos o
>        campo Nome do próprio parceiro (departamento, filial, dependente
>        - no caso de PF) e quando desejarmos a Razão Social do Parceiro
>        Principal (Matriz ou responsável) utilizaríamos o campo Nome do
>        Parceiro Principal (segundo a estrutura do parceiro).
>        Unicidade? Já que manteríamos o name da classe res_partner,
>        teríamos que manter esta restrição. (Pessoal: aqui podemos ter
>        algum problema?)
>
>
>        --
>        Joe Bertoli Pimentel
>
> Concordo com voce Joe, acho que o nome do Partner deve ser a razão
> social.
> Para empresas/Filiais, existiria um partner e tantos address quanto
> fossem as lojas(filiais/matriz).
> Acredito que para as prefeituras /autarquias, seria a mesma coisa.
> Porem temos um problema quanto a pessoa física. Homônimos. como
> resolver?
> Não estou vendo outra alternativa a não ser quebrar a restrição Unique.
> Alguem tem alguma outra sugestão?
>
> []s
> --
> Luiz Fernando Maciel França
> Sig Informática Ltda.
> Rua João Pereira Amorim, 700
> Bairro Jardim Arizona
> 35.700-373 - Sete Lagoas - MG - Brasil
> (31)3773-1043
> Skype: lfmfsig
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
> Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
> More help   : https://help.launchpad.net/ListHelp
>
>