Carrier Exchange specification

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 profesional client and partiular.

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 redondancy) :
- 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 != ?

Carriers Options Management
===========================
Up to now delivery methods options have 3 states : optional, optional by default and mandatory. It's not sufficient.
Things that can be done :
- allow to have select field or other field type.
(yannick) Selection field would solve the need of optionnal mandatory option. I mean you need at least option A or option B.
- split optional and optional state : developper might define optional option and user/admin could choose 'by default' or not
(yannick) what you mean is that you want to be able to set which options are mandatory and which ones are optional in XML file. Then let the "delivery method configuration manager" (who ever could this user be) define which option should be added by default. And this should only be possible for optionnal option thus hidden for mandatory options.

I think things what have be done in postlogistics for options management could be useful in base module or at least concept

(yannick) about options one thing which is important in postlogistics is which option depends on other. That's why a template option comes with fields like 'postlogistics_basic_service_ids' and a type field on template option to set compatibilities and ease a bit the job of the "delivery method configuration manager".

(yannick) GUI: I wonder if anything could be done to show those option by forging the view of delivery.method a bit like in user access right panel. It could makes things simplier for the user.

Thanks for your comments

Work items:
[florian-dacosta] (akretion) propose a generic implementation: DONE
[yvaucher-c2c] : give feedback on proposal: DONE