A Dilluns, 5 de desembre de 2011 14:33:30, Cédric Krier va escriure: > > > This is to be proven. > > > > > > > > Well, if the field is a Many2One as it currently is, you cannot have an > > invoice with several moves. How would you do that? > > I don't know but it will depend of the requirements.
Then you'd need a good number of changes anyway, I think. So I don't think it's a good reason for not to use the correct field type (of course, if we agreed that One2One is the correct one). > > > > nor a move > > > > with several invoices, so that makes sense to me. > > > > > > > > > > > > Yes but this can be done with a uniq constraint on the move field of > > > invoice. > > > > > > > > Isn't it exactly why you created a One2One field type? > > No, One2One has a different representation at the database level. > I think it is really right to have a Many2One on the invoice because it > is the invoice who create the move. > It will never be the move that creates the invoice but with a One2One > field it is what it "allow". Ok. I understand that the db representation is different and that most invoices will have a account move and many account moves will not have an invoice. At the same time, from my POV, those field types represent how data is connected, not how it is created. We're talking about data structures not processes. I mean, if we have a One2One field type that we think it should not be used when there's a one-to-one relationship, when should we use it? IMHO it has perfect sense in this case... -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
