Archives
Contributors
-
Re: Please help review/suggest budget_management
Hi Kitti,thanks a lot. I will review that module until the end of the week.For sure i will give you a feedback.Best regardsThorsten Vocks
openBIG.orgAm Mo., 9. Sept. 2019 um 14:27 Uhr schrieb Kitti Upariphutthiphong <kittiu@ecosoft.co.th>:Hi Thorsten,I have just created budget_management_sale,Please feel free to test and let me know if it works for your case.KittiOn Mon, Aug 26, 2019 at 6:43 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Hi Thorsten,Thank you for your comments. That's certainly doable as budget_management_sale, and I have added it as pending todo list in the PR.Kind regards,On Mon, Aug 26, 2019 at 5:21 PM Thorsten Vocks <thorsten.vocks@big-consulting.net> wrote:Hello,in our german localisation project we also use mis_builder as a base ground to create our country specific P&L and balance sheet reports:https://github.com/OCA/l10n-germany/tree/11.0/l10n_de_skr03_mis_reports
https://github.com/OCA/l10n-germany/tree/11.0/l10n_de_skr04_mis_reports
I have just reviewed your detailed description and i think it is a very good contribution.I would definitely also like a module budget_management_sale. That could help us a lot in nearly all EU countries to control a specificrequirement due to VAT threshold rules required for B2C retail business. In the combination with some new taxes, fiscalpositions and accounts per EU countries who receive goods from the main company located in another EU country a sales user wouldreceive a warning if sales to another EU country would pass the budgeted limit for that country.That would allow us to get a warning toknow when we have to deactivate a certain countrywise defined fiscal position in order to switch to the new fiscal position which shouldbe used after overpassing the threshold / budgeted values.As especially retailers sometimes have automated workflows (f.e. sale order confirmation and invoice creation is automated),furthermore it would be good to switch off the automatic warning / notification or to select between warning / notification and activity or messagenotification in order to not strictly stop the sale workflow in any case. I also could imagine a functionality to select a server action, in our specificuse case the deactivation and reassignation of a new fiscal position including the required onchange of the taxes on the sale order lines(in order to have 100% automatic calculation of the right taxes).If such a module budget_management_sale would exist I could imagine that we would create a module budget_management_sale_b2c_retail_skr03and budget_management_sale_b2c_retail_skr04 in our german localisation project with a dependency to budget_management_sale. In our modulewe would create all the required accounts, taxes, fiscal positions to enable a quick setup. Furthermore we will define the required mis_template anda budget for the year 2019, a budget control sheet with the pre-defined values published by the EU tax authorities.Thanks again for your contribution and i am looking forward to further feedback from others, especially from other localisation projects if they couldimagine same use case for their own country.Best regardsThorsten Vocks
openBIG.org
Dipl. Kaufmann (FH)
Porscheweg 4-6
49661 Cloppenburg
Phone: +49 4471 8409000
Fax: +49 4471 84090009
Mail: thorsten.vocks@openbig.org
Am Sa., 24. Aug. 2019 um 08:12 Uhr schrieb Kitti Upariphutthiphong <kittiu@ecosoft.co.th>:Dear all,I would like to invite anyone interested in budgeting to help review the PR I am doing on budget management.I do understand that, budget management is quite specific to organization. But I have tried to put my own experiences in the generic way, and try to cover the basic use of real budget control in organizations.The PR is still marked as work in progress, though I am kinda done on my side.Please if you case help test (or read) and share your experiences or suggest features.Note: All I did is to make use of mis_builder_budget as much as it is already excellent tool.Many thanks,Kitti U._______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Thorsten Vocks - 08:40 - 10 Sep 2019 -
Re: Please help review/suggest budget_management
Hi Thorsten,I have just created budget_management_sale,Please feel free to test and let me know if it works for your case.KittiOn Mon, Aug 26, 2019 at 6:43 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Hi Thorsten,Thank you for your comments. That's certainly doable as budget_management_sale, and I have added it as pending todo list in the PR.Kind regards,On Mon, Aug 26, 2019 at 5:21 PM Thorsten Vocks <thorsten.vocks@big-consulting.net> wrote:Hello,in our german localisation project we also use mis_builder as a base ground to create our country specific P&L and balance sheet reports:https://github.com/OCA/l10n-germany/tree/11.0/l10n_de_skr03_mis_reports
https://github.com/OCA/l10n-germany/tree/11.0/l10n_de_skr04_mis_reports
I have just reviewed your detailed description and i think it is a very good contribution.I would definitely also like a module budget_management_sale. That could help us a lot in nearly all EU countries to control a specificrequirement due to VAT threshold rules required for B2C retail business. In the combination with some new taxes, fiscalpositions and accounts per EU countries who receive goods from the main company located in another EU country a sales user wouldreceive a warning if sales to another EU country would pass the budgeted limit for that country.That would allow us to get a warning toknow when we have to deactivate a certain countrywise defined fiscal position in order to switch to the new fiscal position which shouldbe used after overpassing the threshold / budgeted values.As especially retailers sometimes have automated workflows (f.e. sale order confirmation and invoice creation is automated),furthermore it would be good to switch off the automatic warning / notification or to select between warning / notification and activity or messagenotification in order to not strictly stop the sale workflow in any case. I also could imagine a functionality to select a server action, in our specificuse case the deactivation and reassignation of a new fiscal position including the required onchange of the taxes on the sale order lines(in order to have 100% automatic calculation of the right taxes).If such a module budget_management_sale would exist I could imagine that we would create a module budget_management_sale_b2c_retail_skr03and budget_management_sale_b2c_retail_skr04 in our german localisation project with a dependency to budget_management_sale. In our modulewe would create all the required accounts, taxes, fiscal positions to enable a quick setup. Furthermore we will define the required mis_template anda budget for the year 2019, a budget control sheet with the pre-defined values published by the EU tax authorities.Thanks again for your contribution and i am looking forward to further feedback from others, especially from other localisation projects if they couldimagine same use case for their own country.Best regardsThorsten Vocks
openBIG.org
Dipl. Kaufmann (FH)
Porscheweg 4-6
49661 Cloppenburg
Phone: +49 4471 8409000
Fax: +49 4471 84090009
Mail: thorsten.vocks@openbig.org Am Sa., 24. Aug. 2019 um 08:12 Uhr schrieb Kitti Upariphutthiphong <kittiu@ecosoft.co.th>:Dear all,I would like to invite anyone interested in budgeting to help review the PR I am doing on budget management.I do understand that, budget management is quite specific to organization. But I have tried to put my own experiences in the generic way, and try to cover the basic use of real budget control in organizations.The PR is still marked as work in progress, though I am kinda done on my side.Please if you case help test (or read) and share your experiences or suggest features.Note: All I did is to make use of mis_builder_budget as much as it is already excellent tool.Many thanks,Kitti U._______________________________________________
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 Kitti Upariphutthiphong - 02:26 - 9 Sep 2019 -
Re: Odoo iCal synchronization Caldav
Theres this approach from Holger!Mit freundlichen Grüßen
We look forward to see you. Best Regards
Dipl. Ing. (Fh) Georg Notter
Agent ERP GmbH
www.agenterp.com
Dear colleagues,
I know it's a longstanding topic. But I do not understand that the need is not important.
Before OpenERP knew how to do caldav. Now it's a Google sync tool that is not wonderful at all.
Caldav is robust and can handle end-to-end.
I found a module of Open Tech S.L but I have trouble implementing it.
If anyone has a solution ! I am very interested.Best regards,www.semper-connect.frSébastien COURATINSemper Connect
68 Rue George Coubard91 800 BOUSSY-SAINT-ANTOINE01 85 48 06 55
télécharger mon application de prise en main à distance
Administration-informatique-événementiel
Demeurez numériquement libre ...
Post-scriptum
Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et Semper Connect. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n’êtes pas destinataire de ce message, merci d'en avertir immédiatement l’expéditeur._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Georg Notter - 07:55 - 7 Sep 2019 -
Odoo iCal synchronization Caldav
Dear colleagues,
I know it's a longstanding topic. But I do not understand that the need is not important.
Before OpenERP knew how to do caldav. Now it's a Google sync tool that is not wonderful at all.
Caldav is robust and can handle end-to-end.
I found a module of Open Tech S.L but I have trouble implementing it.
If anyone has a solution ! I am very interested.Best regards,www.semper-connect.frSébastien COURATINSemper Connect
68 Rue George Coubard91 800 BOUSSY-SAINT-ANTOINE01 85 48 06 55
télécharger mon application de prise en main à distance
Administration-informatique-événementiel
Demeurez numériquement libre ...
Post-scriptum
Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et Semper Connect. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n’êtes pas destinataire de ce message, merci d'en avertir immédiatement l’expéditeur.
by Sébastien COURATIN - 07:41 - 7 Sep 2019 -
Re: Service definition modules
+1 for OCA/contractMAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.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
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions_______________________________________________
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
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions
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 ofalso existing in v10 with agreement_sale and agreement_accountThe objective here is just to have a minimal object, agnostic and versatile objectagreement means : "commercial term conditions" exactly (with your customers and suppliers)Maxime based its work about legal_agreement on top of itThen I propose than you build your modules on top of these, adding your needs on this simple objectEDI 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 ctsChef de projetOdoo Développement / IntégrationLe 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 -
Request for new repository sale-terms-conditions
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 - 10:26 - 5 Sep 2019 -
Re: Service definition modules
Good catch Pedro, this module (https://github.com/OCA/delivery-carrier/blob/11.0/partner_delivery_schedule/models/partner_delivery_schedule.py) is indeed doing the delivery schedule cc @Alexandre Fayolle )But the sets of modules we're talking about is more about defining parameters on terms, that can be customized at customer level. So it is more a generic way to deal with terms and parameters linked to customer orders.Then each of those parameter will probably call some features (distributed across several area: deliveries, invoicing, etc..)So we're looking to where we should push those set of modules (for the parameters as described here https://github.com/OCA/stock-logistics-warehouse/issues/694).Can we vote ?1) include in delivery2) Include in sale-workflow3) include in contract4) or agreed for a new repo sale-term-conditionI vote for 4) as it is not only linked to deliveries or sales nor contract (in the meaning of the current set of modules that mostly deal with contract with customers, not really on the definition of services.Regards,JoëlOn Thu, Sep 5, 2019 at 1:12 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> 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
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions
by Joël Grand Guillaume - 09:51 - 5 Sep 2019 -
Re: Service definition modules
Hi Alexandre,If I understand the purpose, sale term condition, it's the exact scope ofalso existing in v10 with agreement_sale and agreement_accountThe objective here is just to have a minimal object, agnostic and versatile objectagreement means : "commercial term conditions" exactly (with your customers and suppliers)Maxime based its work about legal_agreement on top of itThen I propose than you build your modules on top of these, adding your needs on this simple objectEDI 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 ctsChef de projetOdoo Développement / IntégrationLe 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
by David BEAL - 09:50 - 5 Sep 2019 -
Re: Service definition modules
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.
by Pedro M. Baeza - 01:11 - 5 Sep 2019 -
Re: Service definition modules
For me "sale_terms_conditions" is the better name.
Antonio M. VigliottiPresidente eletto associazione Odoo Italia
Mobile (+39) 342.8740910
Il 04/09/2019 18:16, Alexandre Fayolle ha scritto:
I see what you mean... This module is about the services you agree to provide to a customer as part of a sales, as part of the terms and conditions of the sale orders, and not about service products that are sold in the sale order. Do you think sale_terms_conditions be a better name? Something else? Alexandre On 04/09/2019 17:32, Maxime Chambreuil wrote: > I am not sure the term service is a good fit here, as everything seems > to be related to products. > > What about OCA/sale-delivery? > > *MAXIME CHAMBREUIL* > PROJECT MANAGER/CONSULTANT > *O:* 1.855.877.2377 EXT. 710 > *M:* 602.427.5632 > *E:* MChambreuil@OpenSourcelntegrators.com > <mailto:mchambreuil@OpenSourcelntegrators.com?subject=Email Reply> > > P.O. BOX 940, HIGLEY, AZ 85236 > > > > > > > > > On Wed, Sep 4, 2019 at 10:12 AM Stéphane Bidoul > wrote: > > A new repo sounds good to me. Do we need a new PSC too? > > On Wed, Sep 4, 2019 at 4:52 PM Joël Grand-Guillaume > <joel.grandguillaume@camptocamp.com > <mailto:joel.grandguillaume@camptocamp.com>> wrote: > > Hi, > > I vote for option #1: "new repository > oca/sale-service-definition, all the addons go there" > > Those sets of modules make sense on it own and will allow anyone > to contribute a new parameter. > > Cheers, > > Joël > > > On Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis > wrote: > > Hi Alex, > > > Great news! > > Just a little remark : IMHO, this business process should > maybe be a little bit generic as you may want to manage it > on customer level for purchases. > > On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle > <alexandre.fayolle@camptocamp.com > <mailto:alexandre.fayolle@camptocamp.com>> wrote: > > 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 > > _______________________________________________ > 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 > > > > -- > __________________________________________ > /*Denis Roussel* > //Software Engineer// > //Acsone SA, Succursale de Luxembourg/ > /Tel : //+352 20 21 10 20 19 / > /Fax : +352 20 21 10 21 / > /Gsm : //+352 691 50 60 88 / > / > / > *Acsone sa/nv* > Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium > Zone Industrielle 22 | L-8287 Kehlen | Luxembourg > www.acs*on*e.eu > > _______________________________________________ > 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 > > > > -- > > > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Joël Grand-Guillaume* > Department Head > Business Solutions > > +41 21 619 10 28 > www.camptocamp.com > > > _______________________________________________ > 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 > <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
by Antonio M. Vigliotti - 08:31 - 4 Sep 2019 -
Re: Service definition modules
I see what you mean... This module is about the services you agree to provide to a customer as part of a sales, as part of the terms and conditions of the sale orders, and not about service products that are sold in the sale order. Do you think sale_terms_conditions be a better name? Something else? Alexandre On 04/09/2019 17:32, Maxime Chambreuil wrote: > I am not sure the term service is a good fit here, as everything seems > to be related to products. > > What about OCA/sale-delivery? > > *MAXIME CHAMBREUIL* > PROJECT MANAGER/CONSULTANT > *O:* 1.855.877.2377 EXT. 710 > *M:* 602.427.5632 > *E:* MChambreuil@OpenSourcelntegrators.com > <mailto:mchambreuil@OpenSourcelntegrators.com?subject=Email Reply> > > P.O. BOX 940, HIGLEY, AZ 85236 > > > > > > > > > On Wed, Sep 4, 2019 at 10:12 AM Stéphane Bidoul > wrote: > > A new repo sounds good to me. Do we need a new PSC too? > > On Wed, Sep 4, 2019 at 4:52 PM Joël Grand-Guillaume > <joel.grandguillaume@camptocamp.com > <mailto:joel.grandguillaume@camptocamp.com>> wrote: > > Hi, > > I vote for option #1: "new repository > oca/sale-service-definition, all the addons go there" > > Those sets of modules make sense on it own and will allow anyone > to contribute a new parameter. > > Cheers, > > Joël > > > On Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis > wrote: > > Hi Alex, > > > Great news! > > Just a little remark : IMHO, this business process should > maybe be a little bit generic as you may want to manage it > on customer level for purchases. > > On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle > <alexandre.fayolle@camptocamp.com > <mailto:alexandre.fayolle@camptocamp.com>> wrote: > > 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 > > _______________________________________________ > 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 > > > > -- > __________________________________________ > /*Denis Roussel* > //Software Engineer// > //Acsone SA, Succursale de Luxembourg/ > /Tel : //+352 20 21 10 20 19 / > /Fax : +352 20 21 10 21 / > /Gsm : //+352 691 50 60 88 / > / > / > *Acsone sa/nv* > Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium > Zone Industrielle 22 | L-8287 Kehlen | Luxembourg > www.acs*on*e.eu > > _______________________________________________ > 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 > > > > -- > > > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Joël Grand-Guillaume* > Department Head > Business Solutions > > +41 21 619 10 28 > www.camptocamp.com > > > _______________________________________________ > 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 > <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 - 06:15 - 4 Sep 2019 -
Re: Service definition modules
Service is not a good name. It is confusing, because there is service are usually used as not physical products (Fees, reparation services...)Enric Tobella Alomaretobella@creublanca.esCentros Médicos Creu BlancaTel: 902 202 230Tanto este mensaje como los documentos que, en su caso, lleve como anexos,
pueden contener información reservada y/o confidencial, destinada exclusivamente
para el uso del destinatario o la persona responsable de entregarlo al mismo,
estando su uso no autorizado prohibido legalmente.
Su contenido no constituye un compromiso para Creu Blanca (la empresa remitente)
salvo ratificación escrita por ambas partes. En caso de su recepción por error,
rogamos nos lo comunique por igual vía, se abstenga de realizar copias del mensaje
o documentos adjuntos, remitirlo o facilitarlo a un tercero, y proceda en su defecto,
a su eliminación.From: Maxime Chambreuil <mchambreuil@opensourceintegrators.com>
To: "Contributors" <contributors@odoo-community.org>
Date: Wed, 04 Sep 2019 15:32:16 -0000
Subject: Re: Service definition modules
I am not sure the term service is a good fit here, as everything seems to be related to products.What about OCA/sale-delivery?MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236 On Wed, Sep 4, 2019 at 10:12 AM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:A new repo sounds good to me. Do we need a new PSC too?On Wed, Sep 4, 2019 at 4:52 PM Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:Hi,I vote for option #1: "new repository oca/sale-service-definition, all the addons go there"Those sets of modules make sense on it own and will allow anyone to contribute a new parameter.Cheers,JoëlOn Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis <denis.roussel@acsone.eu> wrote:Hi Alex,Great news!Just a little remark : IMHO, this business process should maybe be a little bit generic as you may want to manage it on customer level for purchases.On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote: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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Luxembourg
Tel : +352 20 21 10 20 19
Fax : +352 20 21 10 21
Gsm : +352 691 50 60 88Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions_______________________________________________
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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Tanto este mensaje como los documentos que, en su caso, lleve como anexos,
pueden contener información reservada y/o confidencial, destinada exclusivamente
para el uso del destinatario o la persona responsable de entregarlo al mismo,
estando su uso no autorizado prohibido legalmente.
Su contenido no constituye un compromiso para Creu Blanca (la empresa remitente)
salvo ratificación escrita por ambas partes. En caso de su recepción por error,
rogamos nos lo comunique por igual vía, se abstenga de realizar copias del mensaje
o documentos adjuntos, remitirlo o facilitarlo a un tercero, y proceda en su defecto,
a su eliminación.
by Enric Tobella Alomar - 05:45 - 4 Sep 2019 -
Re: Service definition modules
I am not sure the term service is a good fit here, as everything seems to be related to products.What about OCA/sale-delivery?
MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236 On Wed, Sep 4, 2019 at 10:12 AM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:A new repo sounds good to me. Do we need a new PSC too?On Wed, Sep 4, 2019 at 4:52 PM Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:Hi,I vote for option #1: "new repository oca/sale-service-definition, all the addons go there"Those sets of modules make sense on it own and will allow anyone to contribute a new parameter.Cheers,JoëlOn Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis <denis.roussel@acsone.eu> wrote:Hi Alex,Great news!Just a little remark : IMHO, this business process should maybe be a little bit generic as you may want to manage it on customer level for purchases.On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote: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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Luxembourg
Tel : +352 20 21 10 20 19
Fax : +352 20 21 10 21
Gsm : +352 691 50 60 88Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions_______________________________________________
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 Maxime Chambreuil - 05:31 - 4 Sep 2019 -
Re: Service definition modules
A new repo sounds good to me. Do we need a new PSC too?On Wed, Sep 4, 2019 at 4:52 PM Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:Hi,I vote for option #1: "new repository oca/sale-service-definition, all the addons go there"Those sets of modules make sense on it own and will allow anyone to contribute a new parameter.Cheers,JoëlOn Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis <denis.roussel@acsone.eu> wrote:Hi Alex,Great news!Just a little remark : IMHO, this business process should maybe be a little bit generic as you may want to manage it on customer level for purchases.On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote: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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Luxembourg
Tel : +352 20 21 10 20 19
Fax : +352 20 21 10 21
Gsm : +352 691 50 60 88Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 05:11 - 4 Sep 2019 -
Re: Service definition modules
Hi,I vote for option #1: "new repository oca/sale-service-definition, all the addons go there"Those sets of modules make sense on it own and will allow anyone to contribute a new parameter.Cheers,JoëlOn Wed, Sep 4, 2019 at 10:57 AM Roussel, Denis <denis.roussel@acsone.eu> wrote:Hi Alex,Great news!Just a little remark : IMHO, this business process should maybe be a little bit generic as you may want to manage it on customer level for purchases.On Wed, Sep 4, 2019 at 10:47 AM Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote:
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Luxembourg
Tel : +352 20 21 10 20 19
Fax : +352 20 21 10 21
Gsm : +352 691 50 60 88Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSJoël Grand-GuillaumeDepartment HeadBusiness Solutions
by Joël Grand Guillaume - 04:51 - 4 Sep 2019
