Message 22077

Message id


2015-08-10 0:44 GMT+02:00 Cédric Krier <>:
> Cédric Krier <> added the comment:
> On 2015-08-05 15:38, Albert Cervera i Areny wrote:
>> Regarding the fact that multi-company should be a rare case: I see it is very frequent to have several companies. I've just checked with real cases and from the latest 14 customers we've got, 7 have more than one company. Of those 7, 2 of them have 2 companies just for fiscal reasons. In the other 4 cases there are:
>> - In two cases there are 2 companies doing the same activity
>> - In the other three cases there are +4 companies doing the same actiity
> Maybe it is your business target but it makes no doubt that there are
> more single companies in the world than groups that need to be managed
> by a single application.
> Or maybe it is just a local fiscal specificity that creates such weird
> company setups.
> Most of the time when such multi-company setup exist for fiscal reason,
> they don't require to have multi-company in the system because it is
> just a fiscal thing and not a business configuration.
>> I can understand that we should try not to make things more complex if only one company is envolved, but I'd like to remark that I don't see it as such a strange case. Also, personally I don't think the o2m on party with a tab on "Company dependent fields" make things much more complex for users as the first company in form-view can be shown by default (just like addresses in party).
> I still don't agree. Your UI suggest that everything is linked to
> company but as I explained that not a correct goal otherwise the current
> design will be OK. More over, it will require to group all "company"
> stuff in one tab even if those properties has no link together instead
> of grouping by logical usage.
> And again, your proposal makes the UI much more complex for the simple
> and most common cases.
>> Regarding the API I must say that like Raimon I also see it a little bit complex to have a class per field.
> I never said it is a rule.

That's why I said that maybe it's me that doesn't fully understand how
you intend to use the proposed API...

Do you intend to have a:

class ConfigurationAccounting(_ConfigurationValue, ModelSQL, ValueMixin):
    'Party Configuration Accounting'
    __name__ = 'party.configuration.accounting'

Which would store all party accounting parameters or something like that?

>> After all, in the Party model we'll have several fields that depend on company but probably no fields that will depend on warehouse or other parameters.
> So what?
>> Also, probably working on the party module is not a very good example because IMHO both properties should be replaced by simple Many2One fields.
> They can not.

What I mean is that I think that default language should not be
company-dependent so a simple Many2One on the configuration would be

>> I find myself thinking that the patch tries to plan that another module will extend the lang field and allows overriding the default value by adding a pattern but I think we cannot pretend that core modules are ready for those customizations out of the box.
> I don't understand why you say that. I tried to setup a new design
> pattern for Tryton as we already have some because exactly such pattern
> allows us to say the system is ready for customizations out of the box.
>> I mean, another module could make the default country company-dependent, for example, and we don't want to have to modify the core party module for that.
> I don't understand this sentence.
>> Could you update the patch including the account module (that includes company too)? Maybe that would make some things clearer for me...
> I don't know when I will have the time to continue this work.
> _______________________________________________
> Tryton issue tracker <>
> <>
> _______________________________________________
Date User Action Args
2015-08-10 10:00:35albertcasetrecipients: + ced
2015-08-10 10:00:35albertcalinkissue2349 messages
2015-08-10 10:00:34albertcacreate

Showing 10 items. Show all history (warning: this could be VERY long)