Account sub account in multi companies context

postlogistics, coliposte, chronoposte, gls use this concept. name is licence for postlogistics but appeared like the same concept. For companies with multi-company implementation it seems to be mandatory Surely we can share the implementation (at least some fields) and basic behavior. I suggest to define the chronopost implementation on this matter turn in generic way and check if we could go in this way for odoo version 8 or 7

florian-dacosta : Chronopost Case

---

 I have to handle multi-accounts and subaccount. For that, Instead of implementing my config fields (account, password, etc...) directly on res.company, I create a new object (chronopost.account) with all these fields and add a one2many relation on res.company. This way, the company can handle many accounts of the same carrier. I believe this is generic to all carrier since a company an decide to have 1 accounts only for professional client and particular.

For the sub account, I just add a field parent_id on my relation (chronopost.account) so one account can have many subaccounts. This feature may not be generic, for instance postlogistics have licence instead of sub account, and it's more complicated to handle this with a simple parent_id.

Ideas to make it generic

---

1) (florian) Put a one2many on res.company, relation with a new class carrier.config.account containing fields account - password - file_format - type (type of carrier) - parent_id In the specific carrier modules, we would have to inherit this new class to add the fields custom for our carrier. A normal account would not have parent_id. A sub account would have a parent_id. ==> The problem I see, is that if many carrier are implemented, the class will have a lot of fields, usefull only for 1 carrier. But we could handle the view hiding fields depending of the type. Also, I am not sure thise is easy for postlogistics which have licence instead of subaccount.

(yannick) could be a xml view nightmare to ensure a field is visible for carrier A & B but not C.

2) (florian) Add a new abstract class carrier.config.account which would have basic fieds account - password - file_format - type. In the specifics carrier modules, we would have to inherits this class with specific-carrier-name.config.account where the abstract class would be a template. In the specific class, we could add an field in case of sub_account or licence...and others custom fields. ==> The main problem is, this way, we can't define the one2many relation on res.company in the base_delivery_carrier_lablel, because it has to be a relation with the new custom class, and we'll have to have a one2many relation on res.company for each carrier we implement.

(yannick) this one make more sens to me than (1) you will already need to add fields specific to your carrier. Adding a one2many to the right classes on res_company in each module looks good.

3) (david) Implement a full flexible management of this concept (a bit complex but few redundancy) : - have a model 'carrier.account' (in base_delivery_carrier_label module) to store basic fields like told florian : name, account code, url, password, carrier_name/type, company_id, etc - have a model to store specific carrier fields which inherits from 'carrier.account'

It also allows to store account and subaccount (or licence) if any Fields repartition could be : fields used by 80% of carriers are in 'carrier.account' others in inherits (20-80% rule) We can use 'carrier.account' model to share default behaviors in methods or use method like an interface to uses cases

In first look, in general, things are not generic (especially with carrier) but if you have a flexible way to store/define objects, common rules can be shared.

Global remarks: - (yannick) file_format: in postlogistics file_format is an option as depending on delivery method I could want a specific file format. This is maybe caused by the multiple possibilities of service for one license. one license -> multiple format. Thus I would prefer not having it there. - type: I wish inherits were simplier to use... this needs to be defined by view and could be invisible. - 2 and 3 are != ? - (mathieu) One thing that is a major requirement for us is to be able to batch generate shipping labels. Therefore we need to have an option in the "More" menu or the tree view to generate labels for many stock.picking at once. If you think that shouldn't be generic, at least having a second module that inherits from base_delivery_carrier_label would be the minimum to keep that behavior generic across carriers. - (mathieu) We also need to retreive the cost of the delivery to later generate invoice in the process. There are multiple values like base cost, taxes, surcharge (like fuel surcharge) so those fields could be located in the stock.picking object. - (mathieu) This page is year old. I hope this will get some attention. There are lots of features that would be present like getting price for all services, getting automatically the cheapest service for a carrier or for all carrier, listing only available services, cancel shipping label, track delivery status. That's what I'm thinking at right now... Still a lot to do.