Skip to Content

Contributors

Service definition modules

Hello all,

In relation with the WMS modules Camptocamp is currently working on, I'm
working on a set of modules to manage service definition.

The idea is to be able to store a set of service levels agreed on with
the customer, with a number of parameters which are specified, and have
default values, but can be customized for a given customer, or a given
sale order.

Typically the parameters could be:

* management of backorders
* days of delivery
* hour of delivery
* invoicing per order (with order reference) or invoicing per delivey
* packaging details in the invoice
* product grouping preference (e.g. a customer could ask for an order of
10 product1, 10 product2, 10 product3 to be packages in 10 parcels
containing each 1 product1, 1 product2, 1 product3 instead of 3 packages
containing a singe product reference)
* constraints on the delivery truck (max dimension, max weight)...

The basic set of user stories is available in
https://github.com/OCA/stock-logistics-warehouse/issues/694 (this issue
will be moved to a better place once we've answerd the question below)

I'm planning to build this as a base module providing the models
required to define the service definitions, and set this on a customer
and on a sale order (+ propagation to invoices and deliveries), +
different smaller modules related to the different aspects (deliveries,
packaging, invoicing...)

I would like to propose these as alpha modules in the OCA but I'm unsure
what repository to target:

* option 1: new repository oca/sale-service-definition, all the addons
go there
* option 2: in repository oca/sale-workflow, at least for the base
module, but then I'm not comfortable in adding cross repository
dependencies, because some of the other modules would probably live in
the WMS repository, others in sale-workflow, others in some maybe in
stock-logistics-*
* option 3: in repository oca/contract because this is related to sale
contract, but I'd like to avoid polluting a self contained module with
lots of cross dependencies
* elsewhere ?

Dear contributors, what would be the best course of action in your opinion?


-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
18 rue du Lac Saint André
73 370 Le Bourget-du-Lac
France

http://www.camptocamp.com

by Alexandre Fayolle - 10:46 - 4 Sep 2019

Follow-Ups

  • Re: Service definition modules
    +1 for OCA/contract

    MAXIME CHAMBREUIL
    PROJECT MANAGER/CONSULTANT
    O: 1.855.877.2377 EXT. 710
    M: 602.427.5632
    E: MChambreuil@OpenSourcelntegrators.com
    P.O. BOX 940, HIGLEY, AZ 85236



    On Thu, Sep 5, 2019 at 4:22 AM Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
    +1 for me then for this option. Let's try to see if any synergies are possible.

    On Thu, Sep 5, 2019 at 11:11 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote:
    I had originally given this a look and decided it was not cut for our
    needs, but upon reflection, it does look like at least a nice place to
    host the modules.
    
    If noone objects I'll make the PRs there (and rename my models...)
    
    Alexandre
    
    On 05/09/2019 09:52, David Beal wrote:
    
    
    
    > Hi Alexandre,
    
    
    
    > 
    
    
    
    > If I  understand the purpose, sale term condition, it's the exact scope of
    
    
    
    > 
    
    
    
    > https://github.com/OCA/contract/tree/12.0/agreement
    
    
    
    > https://github.com/OCA/contract/tree/12.0/agreement_sale
    
    
    
    > 
    
    
    
    > also existing in v10 with agreement_sale and agreement_account
    
    
    
    > 
    
    
    
    > The objective here is just to have a minimal object, agnostic and
    
    
    
    > versatile object
    
    
    
    > agreement means : "commercial term conditions" exactly (with your
    
    
    
    > customers and suppliers)
    
    
    
    > 
    
    
    
    > Maxime based its work about legal_agreement on top of it
    
    
    
    > 
    
    
    
    > Then I propose than you build your modules on top of these, adding your
    
    
    
    > needs on this simple object
    
    
    
    > https://github.com/OCA/contract/blob/12.0/agreement/models/agreement.py
    
    
    
    > 
    
    
    
    > EDI repo (and other dependencies) made by Alexis de Lattre use agreement.
    
    
    
    > 
    
    
    
    > If you build another base object, then customer who want to use both
    
    
    
    > will have redondant data !
    
    
    
    > If you want move agrement_sale to another repo, it's not a problem for me.
    
    
    
    > 
    
    
    
    > my 2 cts
    
    
    
    > 
    
    
    
    > Thanks
    
    
    
    > 
    
    
    
    > 
    
    
    
    > David BEAL - akretion.com 
    
    
    
    > Chef de projet
    
    
    
    > Odoo Développement / Intégration
    
    
    
    > 
    
    
    
    > 
    
    
    
    > Le jeu. 5 sept. 2019 à 01:12, Pedro M. Baeza (Tecnativa)
    
    
    
    >  a écrit :
    
    
    
    > 
    
    
    
    >     Please don't use plurals in the module name for following
    
    
    
    >     guidelines. Take also into account
    
    
    
    >     https://github.com/OCA/delivery-carrier/tree/11.0/partner_delivery_schedule
    
    
    
    >     that already allows to set delivery slots for partners, which is one
    
    
    
    >     of the concepts you are defining. If everything is related to
    
    
    
    >     delivery, I would put modules in OCA/delivery-carrier.
    
    
    
    > 
    
    
    
    >     Regards.
    
    
    
    > 
    
    
    
    >     _______________________________________________
    
    
    
    >     Mailing-List: https://odoo-community.org/groups/contributors-15
    
    
    
    >     Post to: mailto:contributors@odoo-community.org
    
    
    
    >     <mailto:contributors@odoo-community.org>
    
    
    
    >     Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    
    
    > 
    
    
    
    > _______________________________________________
    
    
    
    > Mailing-List: https://odoo-community.org/groups/contributors-15
    
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    
    
    > 
    
    
    
    
    
    -- 
    Alexandre Fayolle
    Chef de Projet
    Tel : +33 4 58 48 20 30
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --


    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Joël Grand-Guillaume
    Department Head
    Business Solutions

    +41 21 619 10 28


    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe


    by Maxime Chambreuil - 03:00 - 5 Sep 2019
  • Re: Request for new repository sale-terms-conditions
    Request Cancelled: oca/contract exists and is a suitable place.
    
    On 05/09/2019 10:21, Alexandre Fayolle wrote:
    
    > Hello Pedro,
    
    > 
    
    > Not everything is related to delivery. We have other aspects related to
    
    > order preparation, order invoicing for instance.
    
    > 
    
    > Regarding the naming proposition, I was first thinking of the repository
    
    > name (and should have used hyphens instead of underscores). However,
    
    > "Term & Condition" does not exist in english. This expression is always
    
    > using the plural form. In my opinion you should think of the final 's'
    
    > as part of the spelling, as in "logistics". In any case, I would really
    
    > like to avoid sale_term_multi_and_condition_multi ;-)
    
    > 
    
    > Can we create a new repository sale-terms-conditions?
    
    > 
    
    > Alexandre
    
    > 
    
    > On 05/09/2019 01:12, Pedro M. Baeza (Tecnativa) wrote:
    
    >> Please don't use plurals in the module name for following guidelines.
    
    >> Take also into account
    
    >> https://github.com/OCA/delivery-carrier/tree/11.0/partner_delivery_schedule
    
    >> that already allows to set delivery slots for partners, which is one of
    
    >> the concepts you are defining. If everything is related to delivery, I
    
    >> would put modules in OCA/delivery-carrier.
    
    >>
    
    >> Regards.
    
    >>
    
    >> _______________________________________________
    
    >> Mailing-List: https://odoo-community.org/groups/contributors-15
    
    >> Post to: mailto:contributors@odoo-community.org
    
    >> Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    >>
    
    > 
    
    > 
    
    
    
    -- 
    Alexandre Fayolle
    Chef de Projet
    Tel : +33 4 58 48 20 30
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    

    by Alexandre Fayolle - 11:36 - 5 Sep 2019
  • Re: Service definition modules
    +1 for me then for this option. Let's try to see if any synergies are possible.

    On Thu, Sep 5, 2019 at 11:11 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote:
    I had originally given this a look and decided it was not cut for our
    needs, but upon reflection, it does look like at least a nice place to
    host the modules.
    
    If noone objects I'll make the PRs there (and rename my models...)
    
    Alexandre
    
    On 05/09/2019 09:52, David Beal wrote:
    
    
    > Hi Alexandre,
    
    
    > 
    
    
    > If I  understand the purpose, sale term condition, it's the exact scope of
    
    
    > 
    
    
    > https://github.com/OCA/contract/tree/12.0/agreement
    
    
    > https://github.com/OCA/contract/tree/12.0/agreement_sale
    
    
    > 
    
    
    > also existing in v10 with agreement_sale and agreement_account
    
    
    > 
    
    
    > The objective here is just to have a minimal object, agnostic and
    
    
    > versatile object
    
    
    > agreement means : "commercial term conditions" exactly (with your
    
    
    > customers and suppliers)
    
    
    > 
    
    
    > Maxime based its work about legal_agreement on top of it
    
    
    > 
    
    
    > Then I propose than you build your modules on top of these, adding your
    
    
    > needs on this simple object
    
    
    > https://github.com/OCA/contract/blob/12.0/agreement/models/agreement.py
    
    
    > 
    
    
    > EDI repo (and other dependencies) made by Alexis de Lattre use agreement.
    
    
    > 
    
    
    > If you build another base object, then customer who want to use both
    
    
    > will have redondant data !
    
    
    > If you want move agrement_sale to another repo, it's not a problem for me.
    
    
    > 
    
    
    > my 2 cts
    
    
    > 
    
    
    > Thanks
    
    
    > 
    
    
    > 
    
    
    > David BEAL - akretion.com 
    
    
    > Chef de projet
    
    
    > Odoo Développement / Intégration
    
    
    > 
    
    
    > 
    
    
    > Le jeu. 5 sept. 2019 à 01:12, Pedro M. Baeza (Tecnativa)
    
    
    >  a écrit :
    
    
    > 
    
    
    >     Please don't use plurals in the module name for following
    
    
    >     guidelines. Take also into account
    
    
    >     https://github.com/OCA/delivery-carrier/tree/11.0/partner_delivery_schedule
    
    
    >     that already allows to set delivery slots for partners, which is one
    
    
    >     of the concepts you are defining. If everything is related to
    
    
    >     delivery, I would put modules in OCA/delivery-carrier.
    
    
    > 
    
    
    >     Regards.
    
    
    > 
    
    
    >     _______________________________________________
    
    
    >     Mailing-List: https://odoo-community.org/groups/contributors-15
    
    
    >     Post to: mailto:contributors@odoo-community.org
    
    
    >     <mailto:contributors@odoo-community.org>
    
    
    >     Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    
    > 
    
    
    > _______________________________________________
    
    
    > Mailing-List: https://odoo-community.org/groups/contributors-15
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    
    > 
    
    
    
    
    -- 
    Alexandre Fayolle
    Chef de Projet
    Tel : +33 4 58 48 20 30
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --


    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Joël Grand-Guillaume
    Department Head
    Business Solutions

    +41 21 619 10 28



    by Joël Grand Guillaume - 11:20 - 5 Sep 2019
  • Re: Service definition modules
    I had originally given this a look and decided it was not cut for our
    needs, but upon reflection, it does look like at least a nice place to
    host the modules.
    
    If noone objects I'll make the PRs there (and rename my models...)
    
    Alexandre
    
    On 05/09/2019 09:52, David Beal wrote:
    
    > Hi Alexandre,
    
    > 
    
    > If I  understand the purpose, sale term condition, it's the exact scope of
    
    > 
    
    > https://github.com/OCA/contract/tree/12.0/agreement
    
    > https://github.com/OCA/contract/tree/12.0/agreement_sale
    
    > 
    
    > also existing in v10 with agreement_sale and agreement_account
    
    > 
    
    > The objective here is just to have a minimal object, agnostic and
    
    > versatile object
    
    > agreement means : "commercial term conditions" exactly (with your
    
    > customers and suppliers)
    
    > 
    
    > Maxime based its work about legal_agreement on top of it
    
    > 
    
    > Then I propose than you build your modules on top of these, adding your
    
    > needs on this simple object
    
    > https://github.com/OCA/contract/blob/12.0/agreement/models/agreement.py
    
    > 
    
    > EDI repo (and other dependencies) made by Alexis de Lattre use agreement.
    
    > 
    
    > If you build another base object, then customer who want to use both
    
    > will have redondant data !
    
    > If you want move agrement_sale to another repo, it's not a problem for me.
    
    > 
    
    > my 2 cts
    
    > 
    
    > Thanks
    
    > 
    
    > 
    
    > David BEAL - akretion.com 
    
    > Chef de projet
    
    > Odoo Développement / Intégration
    
    > 
    
    > 
    
    > Le jeu. 5 sept. 2019 à 01:12, Pedro M. Baeza (Tecnativa)
    
    >  a écrit :
    
    > 
    
    >     Please don't use plurals in the module name for following
    
    >     guidelines. Take also into account
    
    >     https://github.com/OCA/delivery-carrier/tree/11.0/partner_delivery_schedule
    
    >     that already allows to set delivery slots for partners, which is one
    
    >     of the concepts you are defining. If everything is related to
    
    >     delivery, I would put modules in OCA/delivery-carrier.
    
    > 
    
    >     Regards.
    
    > 
    
    >     _______________________________________________
    
    >     Mailing-List: https://odoo-community.org/groups/contributors-15
    
    >     Post to: mailto:contributors@odoo-community.org
    
    >     <mailto:contributors@odoo-community.org>
    
    >     Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    > 
    
    > _______________________________________________
    
    > Mailing-List: https://odoo-community.org/groups/contributors-15
    
    > Post to: mailto:contributors@odoo-community.org
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    > 
    
    
    
    -- 
    Alexandre Fayolle
    Chef de Projet
    Tel : +33 4 58 48 20 30
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    

    by Alexandre Fayolle - 11:10 - 5 Sep 2019
  • Re: Service definition modules
    I'm with David. contract is the right repo, if not a new repo called sale_contract. Terms and conditions form part of the contract with the customer, so it is most appropriate name. Indeed they are often called contractual terms.

    On Thu, Sep 5, 2019 at 7:52 PM David Beal <david.beal@akretion.com> wrote:
    Hi Alexandre,

    If I  understand the purpose, sale term condition, it's the exact scope of


    also existing in v10 with agreement_sale and agreement_account

    The objective here is just to have a minimal object, agnostic and versatile object
    agreement means : "commercial term conditions" exactly (with your customers and suppliers)

    Maxime based its work about legal_agreement on top of it

    Then I propose than you build your modules on top of these, adding your needs on this simple object

    EDI repo (and other dependencies) made by Alexis de Lattre use agreement.

    If you build another base object, then customer who want to use both will have redondant data !
    If you want move agrement_sale to another repo, it's not a problem for me.

    my 2 cts

    Thanks


    David BEAL - akretion.com
    Chef de projet
    Odoo Développement / Intégration


    Le jeu. 5 sept. 2019 à 01:12, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :
    Please don't use plurals in the module name for following guidelines. Take also into account https://github.com/OCA/delivery-carrier/tree/11.0/partner_delivery_schedule that already allows to set delivery slots for partners, which is one of the concepts you are defining. If everything is related to delivery, I would put modules in OCA/delivery-carrier.

    Regards.

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe


    by Graeme Gellatly - 10:36 - 5 Sep 2019