Archives
Contributors
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 HeadBusiness Solutions
by Joël Grand Guillaume - 11:20 - 5 Sep 2019
Reference
-
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