Message 22076

Author
ced
Date
2015-08-10.00:44:26
Message id
22076

Content

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.

> 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.

> 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.
History
Date User Action Args
2015-08-10 00:44:42cedsetrecipients: + ohuisman, eric, albertca, resteve, pokoli, angel, guillemNaN, unicode2013
2015-08-10 00:44:41cedlinkissue2349 messages
2015-08-10 00:44:26cedcreate

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