Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: Goodbye runbot, welcome runboat
    Thank you very much!

    I somehow can't see this thread on the OCA website for a 403 error, though: https://odoo-community.org/groups/contributors-15/contributors-234170

    -- 
    Yoshi Tashiro


    On Fri, Jan 28, 2022 at 2:07 AM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Dear contributors,

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.


    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

    image.png

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

    I also monitor the OCA Infrastructure discord channel from time to time.

    Best regards, and happy testing!

    -sbi

    --
    Stéphane Bidoul
    Operations Director
    M: +32 498 72 46 54
    http://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

    by Yoshi Tashiro. - 02:40 - 28 Jan 2022
  • RE: Goodbye runbot, welcome runboat

    Thank you so much for this great work!

     

     

    De: Stéphane Bidoul <stephane.bidoul@acsone.eu>
    Enviado el: jueves, 27 de enero de 2022 18:08
    Para: Contributors <contributors@odoo-community.org>
    Asunto: Goodbye runbot, welcome runboat

     

    Dear contributors,

     

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

     

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.

     

     

    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

     

     

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

     

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

     

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

     

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

     

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

     

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

     

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

     

    I also monitor the OCA Infrastructure discord channel from time to time.

     

    Best regards, and happy testing!

     

    -sbi

     

    --

    Stéphane Bidoul

    Operations Director
    M: +32 498 72 46 54

    by Rafael Blasco (Moduon) - 07:06 - 27 Jan 2022

    1 attachments 1 attachments

    image002.png
  • Re: New repositories : cooperative and participative supermarket
    Hi Robin,

    +1 for the three repos.



    On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
    Hi Denis,

    Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :

    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.

    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)

    - oca/cooperative would hold the modules allowing to
    - Subscribe to a share, transfer a share or sell a share from the cooperative,
    - Share subscription can be done online,
    - Manage the cooperator registry of a cooperative,
    - Generate legal reports for company and cooperators.

    - oca/shift-planning would hold the modules allowing to
    - Create a planning template of work shifts of the company
    - Generate the shifts based on these templates,
    - Allow partners to subscribe to regular tasks,
    - Allow partners to subscribe to any task with available spot,
    - Track the attendance to the shifts.

    - oca/vertical-cooperative-supermarket* glues all these together to
    - Track who can work in the cooperative
    - Track who can shop in the cooperative
    - welcome screens and member cards

    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    +32 488 86 57 40
    On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:
    Hi Denis,

    Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)
     • oca/cooperative would hold the modules allowing to
     • Subscribe to a share, transfer a share or sell a share from the cooperative,
     • Share subscription can be done online,
     • Manage the cooperator registry of a cooperative,
     • Generate legal reports for company and cooperators.
     • oca/shift-planning would hold the modules allowing to
     • Create a planning template of work shifts of the company 
     • Generate the shifts based on these templates,
     • Allow partners to subscribe to regular tasks,
     • Allow partners to subscribe to any task with available spot,
     • Track the attendance to the shifts.
     • oca/vertical-cooperative-supermarket* glues all these together to
     • Track who can work in the cooperative
     • Track who can shop in the cooperative
    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
    Hi Robin,


    That's great to hear this!

    My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.

    For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.

    Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !



    On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
    Hi all,

    At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
    cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
    beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.

    We will need to 
    remove all references to Obeesdoo and Easy My Coop (debranding) ;
    split modules by features ; 
    cover more code with unit tests.
    These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.

    Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
    cooperative with all modules in beta-stage while we debrand them. 
    shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
    vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
    What do you think ? Is there room for these projects at the OCA ?

    You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.

    All inputs welcome,

    Robin Keunen

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe


    --

    Denis RousselSoftware EngineerT    : +32 2 888 31 49M : +32 472 22 00 57
    Val Benoit, Quai Banning 6 | B-4000 Liège | BelgiumAtrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg_______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post 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



    --

    Denis Roussel
    Software Engineer
    T    : +32 2 888 31 49
    M : +32 472 22 00 57


    Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
    Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
    Zone industrielle 22 | L-8287 Kehlen | Luxembourg
    by Denis Roussel - 06:56 - 27 Jan 2022
  • Re: New repositories : cooperative and participative supermarket
    Hi Robin,

    With this explanation, the 3 repos you propose sound good to me, with a well-defined scope that does not seem to overlap with anything else in OCA.

    +1

    -sbi

    On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
    Hi Denis,

    Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :

    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.

    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)

    - oca/cooperative would hold the modules allowing to
    - Subscribe to a share, transfer a share or sell a share from the cooperative,
    - Share subscription can be done online,
    - Manage the cooperator registry of a cooperative,
    - Generate legal reports for company and cooperators.

    - oca/shift-planning would hold the modules allowing to
    - Create a planning template of work shifts of the company
    - Generate the shifts based on these templates,
    - Allow partners to subscribe to regular tasks,
    - Allow partners to subscribe to any task with available spot,
    - Track the attendance to the shifts.

    - oca/vertical-cooperative-supermarket* glues all these together to
    - Track who can work in the cooperative
    - Track who can shop in the cooperative
    - welcome screens and member cards

    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    +32 488 86 57 40
    On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:
    Hi Denis,

    Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)
     • oca/cooperative would hold the modules allowing to
     • Subscribe to a share, transfer a share or sell a share from the cooperative,
     • Share subscription can be done online,
     • Manage the cooperator registry of a cooperative,
     • Generate legal reports for company and cooperators.
     • oca/shift-planning would hold the modules allowing to
     • Create a planning template of work shifts of the company 
     • Generate the shifts based on these templates,
     • Allow partners to subscribe to regular tasks,
     • Allow partners to subscribe to any task with available spot,
     • Track the attendance to the shifts.
     • oca/vertical-cooperative-supermarket* glues all these together to
     • Track who can work in the cooperative
     • Track who can shop in the cooperative
    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
    Hi Robin,


    That's great to hear this!

    My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.

    For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.

    Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !



    On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
    Hi all,

    At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
    cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
    beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.

    We will need to 
    remove all references to Obeesdoo and Easy My Coop (debranding) ;
    split modules by features ; 
    cover more code with unit tests.
    These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.

    Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
    cooperative with all modules in beta-stage while we debrand them. 
    shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
    vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
    What do you think ? Is there room for these projects at the OCA ?

    You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.

    All inputs welcome,

    Robin Keunen

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe


    --

    Denis RousselSoftware EngineerT    : +32 2 888 31 49M : +32 472 22 00 57
    Val Benoit, Quai Banning 6 | B-4000 Liège | BelgiumAtrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg_______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post 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 Stéphane Bidoul - 06:50 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Great ! Looking forward to see the runboat in action !

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    On 27 Jan 2022, 18:16 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
    Great news Stéphane!

    I'm sure it will help us for faster developments/testing.

    Many thanks!

    On Thu, Jan 27, 2022 at 6:07 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Dear contributors,

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.


    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

    image.png

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

    I also monitor the OCA Infrastructure discord channel from time to time.

    Best regards, and happy testing!

    -sbi

    --
    Stéphane Bidoul
    Operations Director
    M: +32 498 72 46 54
    http://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



    --

    Denis Roussel
    Software Engineer
    T    : +32 2 888 31 49
    M : +32 472 22 00 57

    Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
    Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
    Zone industrielle 22 | L-8287 Kehlen | Luxembourg

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

    by Robin Keunen - 06:30 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Great work! Congratulations and thanks!!

    Ing. Juan José Scarafía

    (+54 9 341) 3 278039

    twitter: @jjscarafia

    github: @jjscarafia



    El jue, 27 ene 2022 a la(s) 14:16, Pedro M. Baeza (Tecnativa) (pedro.baeza@tecnativa.com) escribió:
    Thanks for the excellent work, Stéphane and Alexandre.

    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 Juan José Scarafía - 06:26 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Nice!

    Congratz for the launch of runboat.

    Did you break a bottle on it before launching it to the ocean? :)

    Yannick Vaucher
    Business Solutions Architect

    Camptocamp SA
    PSE A, CH-1015 Lausanne
    Phone: +41 21 619 10 30
    Office: +41 21 619 10 10


    On Thu, 27 Jan 2022 at 18:16, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:
    Thanks for the excellent work, Stéphane and Alexandre.

    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 Yannick Payot - 06:26 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Really good job, guys!  👏👏

    El jue, 27 ene 2022 a las 18:16, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:
    Thanks for the excellent work, Stéphane and Alexandre.

    Regards.

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



    --

     

    Harald Panten López

    CEO

    Sygel Technology S.L

    		 
    		+34 637 88 42 41
    		harald.panten@sygel.es
    		https://www.sygel.es
    		C/ Àlaba 61, 5ª planta, 08005, Barcelona
     
     
     
    by Harald Panten Lopez - 06:26 - 27 Jan 2022
  • Re: New repositories : cooperative and participative supermarket
    Hi Denis,

    Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :

    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.

    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)

    - oca/cooperative would hold the modules allowing to
    - Subscribe to a share, transfer a share or sell a share from the cooperative,
    - Share subscription can be done online,
    - Manage the cooperator registry of a cooperative,
    - Generate legal reports for company and cooperators.

    - oca/shift-planning would hold the modules allowing to
    - Create a planning template of work shifts of the company
    - Generate the shifts based on these templates,
    - Allow partners to subscribe to regular tasks,
    - Allow partners to subscribe to any task with available spot,
    - Track the attendance to the shifts.

    - oca/vertical-cooperative-supermarket* glues all these together to
    - Track who can work in the cooperative
    - Track who can shop in the cooperative
    - welcome screens and member cards

    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:
    Hi Denis,

    Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
    The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
    Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
    The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.

    As for refining the topics, I can try to rephrase :-)
     • oca/cooperative would hold the modules allowing to
     • Subscribe to a share, transfer a share or sell a share from the cooperative,
     • Share subscription can be done online,
     • Manage the cooperator registry of a cooperative,
     • Generate legal reports for company and cooperators.
     • oca/shift-planning would hold the modules allowing to
     • Create a planning template of work shifts of the company 
     • Generate the shifts based on these templates,
     • Allow partners to subscribe to regular tasks,
     • Allow partners to subscribe to any task with available spot,
     • Track the attendance to the shifts.
     • oca/vertical-cooperative-supermarket* glues all these together to
     • Track who can work in the cooperative
     • Track who can shop in the cooperative
    * once cleaned up from all sale, purchase, pos, ... customisations.

    I hope it’s clearer that way,

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
    Hi Robin,


    That's great to hear this!

    My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.

    For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.

    Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !



    On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
    Hi all,

    At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
    cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
    beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.

    We will need to 
    remove all references to Obeesdoo and Easy My Coop (debranding) ;
    split modules by features ; 
    cover more code with unit tests.
    These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.

    Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
    cooperative with all modules in beta-stage while we debrand them. 
    shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
    vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
    What do you think ? Is there room for these projects at the OCA ?

    You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.

    All inputs welcome,

    Robin Keunen

    Robin Keunen 
    Coop IT Easy 
    robin@coopiteasy.be 
    +32 488 86 57 40
    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe


    --

    Denis RousselSoftware EngineerT    : +32 2 888 31 49M : +32 472 22 00 57
    Val Benoit, Quai Banning 6 | B-4000 Liège | BelgiumAtrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg_______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe
    by Robin Keunen - 06:21 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Thanks for the excellent work, Stéphane and Alexandre.

    Regards.
    by Pedro M. Baeza - 06:16 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Great news Stéphane!

    I'm sure it will help us for faster developments/testing.

    Many thanks!

    On Thu, Jan 27, 2022 at 6:07 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Dear contributors,

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.


    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

    image.png

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

    I also monitor the OCA Infrastructure discord channel from time to time.

    Best regards, and happy testing!

    -sbi

    --
    Stéphane Bidoul
    Operations Director
    M: +32 498 72 46 54
    http://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



    --

    Denis Roussel
    Software Engineer
    T    : +32 2 888 31 49
    M : +32 472 22 00 57


    Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
    Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
    Zone industrielle 22 | L-8287 Kehlen | Luxembourg
    by Denis Roussel - 06:16 - 27 Jan 2022
  • Re: Goodbye runbot, welcome runboat
    Congrats!! Keep up the good work :)

    El jue, 27 ene 2022 a las 18:07, Stéphane Bidoul (<stephane.bidoul@acsone.eu>) escribió:
    Dear contributors,

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.


    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

    image.png

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

    I also monitor the OCA Infrastructure discord channel from time to time.

    Best regards, and happy testing!

    -sbi

    --
    Stéphane Bidoul
    Operations Director
    M: +32 498 72 46 54
    http://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

    by Alexandre Díaz - 06:10 - 27 Jan 2022
  • Goodbye runbot, welcome runboat
    Dear contributors,

    As you may have noticed, a new tool arrived in the OCA landscape: runboat.

    It is a runbot replacement that is specially tailored to OCA needs. Its key feature is that it prepares Odoo environments from GitHub commits, and once they are initialized they are kept in a dormant state, ready to start in seconds when needed for testing. This way we can have a very large number of environments ready to use (up to 10 000 on our current machine), so there is a great chance that the branch you want to test is readily available and there is no wait for functional people wanting to contribute.


    It is currently enabled for branches 10 to 15. And the test environment corresponding to each PR or commit is linked as part of the GitHub checks (look at the red cross or green check mark).

    image.png

    Soon, links to runboat will be added to the README.md files of all repos for branches 13, 14 and 15.

    You can also open it for a repo and Odoo version with a link like this: https://runboat.odoo-community.org/builds?repo=oca/mis-builder&target_branch=14.0

    It is currently not enabled for branches older than 10, although in principle it should work for 8 and 9 too. If you need it and want to help make it happen, do not hesitate to get in touch on discord.

    Since runboat is proving to work very well and is much more resource efficient than runbot, while at the same time providing a better user experience, we can now shutdown runbot, in order to save on OCA server costs.

    With the help of Alexandre Fayolle, we are going to do that in the coming weeks, so prepare to say goodbye to runbot!

    Most existing links to runbot.odoo-community.org will then redirect to runboat.

    In the meantime, if you notice issues do not hesitate to get in touch by @ mentioning me on the PRs for which the runboat build would fail and you don't readily understand why or how to fix it. This will also help prepare for the move from Travis to GitHub actions which we are also planning in the first part of 2022.

    I also monitor the OCA Infrastructure discord channel from time to time.

    Best regards, and happy testing!

    -sbi

    --
    Stéphane Bidoul
    Operations Director
    M: +32 498 72 46 54
    http://acsone.eu/
    by Stéphane Bidoul - 06:06 - 27 Jan 2022

    1 attachments 1 attachments

    image.png
  • Spanish Payroll
    Hi all,

    Does enyone have experience in Spanish Payroll app ?

    We have a very interesting Odoo project, but we lack the experience required for this module in particular.

    We are looking for working with someone to help us implement this particular app.

    Regards

    Jorge Elena Poblet

    Consultor Tecnológico

    Gerente | Binhex Systems Solutions S.L.



    		+34 822 179 267 | +34 622 40 08 08
    		j.elena@binhex.es
    		https://binhex.es
    		Calle Lepanto, 3A, Santa Cruz de Tenerife, Islas Canarias, España



    facebook

    		linkedin

    		instagram

    Aviso legal:
    Protección de datos. - Binhex Systems Solutions, S.L. le informa que su dirección de correo electrónico, así como el resto de sus datos personales serán usados para nuestra relación y poder prestarle nuestros servicios. Dichos datos son necesarios para poder relacionarnos con usted, lo que nos permite el uso de su información dentro de la legalidad. Asimismo, podrán tener conocimiento de su información aquellas entidades que necesiten tener acceso a la misma para que podamos prestarle nuestros servicios. Conservaremos sus datos durante nuestra relación y mientras nos obliguen las leyes aplicables. En cualquier momento puede dirigirse a nosotros para saber qué información tenemos sobre usted, rectificarla si fuese incorrecta y eliminarla una vez finalizada nuestra relación. También tiene derecho a solicitar el traspaso de su información a otra entidad (portabilidad). Para solicitar alguno de estos derechos, deberá realizar una solicitud escrita a nuestra dirección, junto con una fotocopia de su DNI:
    Binhex Systems Solutions, S.L., con dirección en Calle Lepanto 3, 2A, CP 38005, Santa Cruz de Tenerife (Santa Cruz de Tenerife). En caso de que entienda que sus derechos han sido desatendidos, puede formular una reclamación en la Agencia Española de Protección de Datos (www.agpd.es).
    Confidencialidad. - El contenido de esta comunicación, así como el de toda la documentación anexa, es confidencial y va dirigida al destinatario del mismo. En el supuesto de que usted no fuera el destinatario, le solicitamos que nos lo indique y no comunique su contenido a terceros, procediendo a su destrucción.
    Exención de responsabilidad. - El envío de la presente comunicación no implica la obligación por parte del remitente de controlar la ausencia de virus, gusanos, troyanos y/o cualquier otro programa informático dañino, correspondiendo al destinatario disponer de las herramientas de hardware y software necesarias para garantizar tanto la seguridad de su sistema de información como la detección y eliminación de programas informáticos dañinos. Binhex Systems Solutions, S.L. no se responsabiliza de los daños y perjuicios que tales programas informáticos puedan causar al destinatario.

    by Jorge Elena Poblet - 04:51 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially
    Hi,

    Yes. It is a well known problem. The 2D PaperCutting Problem, a lot less complex than the 3D one, aka Travelling Salesperson.

    As for where it goes. I don't know. As I say, I solved differently. Using Unbuild style you start from the raw material so it was never an issue. But to start you can just use a rule of thumb.

    On Thu, Jan 27, 2022 at 9:37 PM Radovan Skolnik <radovan@skolnik.info> wrote:
    Graeme,

this is what I was looking for and sort of confirms my suspicion that without 
special handling Odoo would sum contents of all lots of same kind into one 
(which perfectly makes sense when dealing with units, weights, volumes and 
such that can be added/joined).

Question though if I may: where should that pseudo-code fit in? Is that 
supposed to be extension somewhere in MRP BoM process where appropriate 
materials are being looked for when manufacturing the final product? Dumb 
question maybe but haven't had much experience with MRP yet.

Your algorithm actually reminds me very much of a thing I was doing just not a 
year ago as a favour to a friend who builds pergolas using alluminium joists 
of certain fixed size. From the design you receive required cutting sizes and 
you need to optimize how to cut the source material with the least waste.

But that was written in Excel and Visual Basic :-) However it is basically the 
same as what you have outlined.

Best regards

	Radovan

P.S.: BTW, have you had a chance to have a look at my comment regarding 
variant_seller_ids for product.[template|product]? Is till consider that thing 
broken and not following the desired design...

On štvrtok 27. januára 2022 9:17:06 CET Graeme Gellatly wrote:
    by Graeme Gellatly - 10:05 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially 
    Graeme,

this is what I was looking for and sort of confirms my suspicion that without 
special handling Odoo would sum contents of all lots of same kind into one 
(which perfectly makes sense when dealing with units, weights, volumes and 
such that can be added/joined).

Question though if I may: where should that pseudo-code fit in? Is that 
supposed to be extension somewhere in MRP BoM process where appropriate 
materials are being looked for when manufacturing the final product? Dumb 
question maybe but haven't had much experience with MRP yet.

Your algorithm actually reminds me very much of a thing I was doing just not a 
year ago as a favour to a friend who builds pergolas using alluminium joists 
of certain fixed size. From the design you receive required cutting sizes and 
you need to optimize how to cut the source material with the least waste.

But that was written in Excel and Visual Basic :-) However it is basically the 
same as what you have outlined.

Best regards

	Radovan

P.S.: BTW, have you had a chance to have a look at my comment regarding 
variant_seller_ids for product.[template|product]? Is till consider that thing 
broken and not following the desired design...

On štvrtok 27. januára 2022 9:17:06 CET Graeme Gellatly wrote:

> Hi,

> I've solved a similar problem. A bit more complicated, slitting coil into

> multiple widths, weights and lengths. No way to join. That was custom based

> around MRP Unbuild but a lot of the concepts still apply. Unbuild is still

> potentially an option. But in basic terms 1. Use Lot tracking. 2. Use

> orderpoints or similar. Now for the automatic reorder you might want some

> custom code for reordering. In pseudocode. a. counters = [[lot qty], [lot

> qty]] for finished_good in finished_goods.sorted(length desc):   find lot

> raw material that can handle   if found decrement counter.   if not found:

> buy some, break b.  if all lots < <some_length>: order

> c. Rule of thumb orderpoint. I hold 3 rolls. so 3 x max length of finished

> as total rolls means I need to order some more. Or whatever suites. It will

> be easiest that way. On Thu, Jan 27, 2022 at 7:11 PM Radovan Skolnik <

> radovan@skolnik.info [1] > wrote: Hello,

> thank you for all the answers.I guess I have to test this thoroughly. My

> worry is generally this: let's say I have 2 lots/rolls each with 50m raw

> cable remaining. I need to produce 100m final cable. I think the system

> would consider I have enough of raw cable for this. Because that would work

> for certain scenarios. Imagine you need 100kg of something to prdouce

> something else. If you have 2 lots each with 50kg you're good to go - you

> just combine 50kg from each. Similarily if it was pieces. All these can be

> joined / added. I am talking about scenario where partial residual amounts

> cannot be added together to create a larger piece / amount. Hope I am

> making myself clear. Best regards

> Radovan

> 

> On štvrtok 27. januára 2022 0:17:23 CET James Dominy wrote:

> > Hello Radovan,

> > I would track your rolls of cable using Lots, this way when the order

> > calls

> > for 25, 50, or 100 m of cable if the lot does not have the qty needed to

> > produce the ethernet cable it will use the lot that has enough for the

> > finished product. On Wed, Jan 26, 2022 at 3:57 PM Radovan Skolnik <

> > 

> >  radovan@skolnik.info [2] [1] > wrote: Daniel,

> > 

> > thank you for answer. Yes it does make sense. But will it cover scenario

> > where I have let's say 2 rolls with 50m remaining on each and I want to

> > produce 100m final cable? Because in such case a completely new roll

> > should

> > be ordered as I cannot join those 2 50m pieces together... So it comes to

> > a

> > requirement here that you just do not track the total number of meters

> > remaining but you need to track each roll individually. Similar example

> > would be a woodmaker who needs certain sizes of wood for various products

> > (chair, table, ...) and he procures wood in 3m planks. What is your

> > opinion? Best regards

> > Radovan

> > 

> > On streda 26. januára 2022 21:51:47 CET Daniel Reis wrote:

> > > I believe you need to use different Units of Measure (UoM).

> > > In this case, the "Cable" Product is purchased in "Rolls" and used

> > > in "Meters".

> > > The "Roll" UoM should be configured to convert to Meters at a rate

> > > of 1:1000.

> > > This way you track your cable stock in meters available, and you

> > > order to your supplier in rolls.

> > > Dos this make sense?

> > > Thanks

> > > Daniel

> > > 

> > > On 26/01/22 20:37, Radovan Skolnik

> > > wrote:

> > > 

> > > Hello,

> > > sorry for asking stupid questions here but I hope someone can provide

> > > some

> > > wisdom here that I am missing. Let's imagine this scenario: I produce

> > > Ethernet cables of various lengths - i.e. 25m, 50m, 75m, 100m, ... Each

> > > such final cable requires 2 connectors and that particular amount of

> > > "raw"

> > > cable. I can only buy raw cable in rolls of 1000m. So when I buy a new

> > > roll

> > > and produce one final 50m cable, 950m of raw cable remains. When I

> > > produce

> > > another of 100m length, 850m of raw cable remains. When my remaining raw

> > > cable on certain roll is 50m I cannot produce 100m final cable and need

> > > to

> > > order another raw cable roll. So the idea is tracking remaining quantity

> > > of

> > > somethings (products? lots? ...) that is bought at certain size and is

> > > being gradually consumed. There can of course be more of these (i.e. I

> > > have

> > > bought 3 rolls at the same time). Is there a way on how to model this?

> > > Manufacturing is not really my domain and looking through code of

> > > various

> > > modules I didn't find anything that would resemble such thing. Thank you

> > > very much. Best regards

> > > Radovan Skolnik

> > > 

> > > 

> > > _______________________________________________

> > > Mailing-List:  https://odoo-community.org/groups/contributors-15 [3] [2]

> > > [1] Post to: mailto:  contributors@odoo-community.org [4] [3] [2]

> > > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [5] [4] [3]

> > > 

> > > 

> > > 

> > > --

> > > DANIEL

> > > REIS*

> > > MANAGING DIRECTOR

> > > M:*

> > > +351 919 991 307

> > > E:*

> > > dreis@OpenSourceIntegrators.com [4]

> > > A:*

> > > Avenida da República 3000, Estoril Office B, #34

> > > 

> > > 

> > > None [5] None [6] None [7]

> > > 

> > > 

> > > _______________________________________________

> > > Mailing-List:  https://odoo-community.org/groups/contributors-15 [6] [5]

> > > [8] Post to: mailto:  contributors@odoo-community.org [7] [6]

> > > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [8] [7] [9]

> > > 

> > > 

> > > 

> > > [1]  https://odoo-community.org/groups/contributors-15 [9] [8]

> > > [2] mailto:  contributors@odoo-community.org [10] [9]

> > > [3]  https://odoo-community.org/groups?unsubscribe [11] [10]

> > > [4] mailto: dreis@OpenSourceIntegrators.com [11]

> > > [5]  https://www.magentointegrators.com/ [12] [12]

> > > [6]  https://www.hadoopintegrators.com/ [13] [13]

> > > [7]  https://www.usaodoo.com/ [14] [14]

> > > [8]  https://odoo-community.org/groups/contributors-15 [15] [15]

> > > [9]  https://odoo-community.org/groups?unsubscribe [16] [16]

> > 

> > _______________________________________________

> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [17] [17]

> > Post to: mailto:  contributors@odoo-community.org [18] [18]

> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [19] [19]

> > 

> > --

> > * James Dominy *

> > CEO

> > * Lunel, Inc *

> > Saratoga Springs, UT

> > 719-888-9582

> > 

> >  jamesdominy@lunelerp.com [20] [20]

> > 

> > *  www.lunel.co [21] [21]

> > *

> > 

> > _______________________________________________

> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [22] [22]

> > Post to: mailto: contributors@odoo-community.org [23]

> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [24] [23]

> > 

> > 

> > 

> > [1] mailto: radovan@skolnik.info [25]

> > [2]  https://odoo-community.org/groups/contributors-15 [26]

> > [3] mailto: contributors@odoo-community.org [27]

> > [4]  https://odoo-community.org/groups?unsubscribe [28]

> > [5]  https://odoo-community.org/groups/contributors-15 [29]

> > [6] mailto: contributors@odoo-community.org [30]

> > [7]  https://odoo-community.org/groups?unsubscribe [31]

> > [8]  https://odoo-community.org/groups/contributors-15 [32]

> > [9] mailto: contributors@odoo-community.org [33]

> > [10]  https://odoo-community.org/groups?unsubscribe [34]

> > [11] mailto: dreis@OpenSourceIntegrators.com [35]

> > [12]  https://www.magentointegrators.com/ [36]

> > [13]  https://www.hadoopintegrators.com/ [37]

> > [14]  https://www.usaodoo.com/ [38]

> > [15]  https://odoo-community.org/groups/contributors-15 [39]

> > [16]  https://odoo-community.org/groups?unsubscribe [40]

> > [17]  https://odoo-community.org/groups/contributors-15 [41]

> > [18] mailto: contributors@odoo-community.org [42]

> > [19]  https://odoo-community.org/groups?unsubscribe [43]

> > [20] mailto: james@lunelerp.com [44]

> > [21]  http://www.lunel.co [45]

> > [22]  https://odoo-community.org/groups/contributors-15 [46]

> > [23]  https://odoo-community.org/groups?unsubscribe [47]

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [48]

> Post to: mailto: contributors@odoo-community.org [49]

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [50]

> 

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [51]

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [52]

> 

> 

> 

> [1] mailto:radovan@skolnik.info

> [2] mailto:radovan@skolnik.info

> [3] https://odoo-community.org/groups/contributors-15

> [4] mailto:contributors@odoo-community.org

> [5] https://odoo-community.org/groups?unsubscribe

> [6] https://odoo-community.org/groups/contributors-15

> [7] mailto:contributors@odoo-community.org

> [8] https://odoo-community.org/groups?unsubscribe

> [9] https://odoo-community.org/groups/contributors-15

> [10] mailto:contributors@odoo-community.org

> [11] https://odoo-community.org/groups?unsubscribe

> [12] https://www.magentointegrators.com/

> [13] https://www.hadoopintegrators.com/

> [14] https://www.usaodoo.com/

> [15] https://odoo-community.org/groups/contributors-15

> [16] https://odoo-community.org/groups?unsubscribe

> [17] https://odoo-community.org/groups/contributors-15

> [18] mailto:contributors@odoo-community.org

> [19] https://odoo-community.org/groups?unsubscribe

> [20] mailto:jamesdominy@lunelerp.com

> [21] http://www.lunel.co

> [22] https://odoo-community.org/groups/contributors-15

> [23] mailto:contributors@odoo-community.org

> [24] https://odoo-community.org/groups?unsubscribe

> [25] mailto:radovan@skolnik.info

> [26] https://odoo-community.org/groups/contributors-15

> [27] mailto:contributors@odoo-community.org

> [28] https://odoo-community.org/groups?unsubscribe

> [29] https://odoo-community.org/groups/contributors-15

> [30] mailto:contributors@odoo-community.org

> [31] https://odoo-community.org/groups?unsubscribe

> [32] https://odoo-community.org/groups/contributors-15

> [33] mailto:contributors@odoo-community.org

> [34] https://odoo-community.org/groups?unsubscribe

> [35] mailto:dreis@OpenSourceIntegrators.com

> [36] https://www.magentointegrators.com/

> [37] https://www.hadoopintegrators.com/

> [38] https://www.usaodoo.com/

> [39] https://odoo-community.org/groups/contributors-15

> [40] https://odoo-community.org/groups?unsubscribe

> [41] https://odoo-community.org/groups/contributors-15

> [42] mailto:contributors@odoo-community.org

> [43] https://odoo-community.org/groups?unsubscribe

> [44] mailto:james@lunelerp.com

> [45] http://www.lunel.co

> [46] https://odoo-community.org/groups/contributors-15

> [47] https://odoo-community.org/groups?unsubscribe

> [48] https://odoo-community.org/groups/contributors-15

> [49] mailto:contributors@odoo-community.org

> [50] https://odoo-community.org/groups?unsubscribe

> [51] https://odoo-community.org/groups/contributors-15

> [52] https://odoo-community.org/groups?unsubscribe
    by Radovan Skolnik - 09:35 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially
    Hi,

    I've solved a similar problem. A bit more complicated, slitting coil into multiple widths, weights and lengths. No way to join. That was custom based around MRP Unbuild but a lot of the concepts still apply. Unbuild is still potentially an option.

    But in basic terms
    1. Use Lot tracking.
    2. Use orderpoints or similar. Now for the automatic reorder you might want some custom code for reordering. In pseudocode.
    a.

    counters = [[lot qty], [lot qty]]
    for finished_good in finished_goods.sorted(length desc):
      find lot raw material that can handle
      if found decrement counter.
      if not found: buy some, break

    b. 
    if all lots < <some_length>: order

    c. Rule of thumb orderpoint.
    I hold 3 rolls. so 3 x max length of finished as total rolls means I need to order some more. Or whatever suites. It will be easiest that way.

    On Thu, Jan 27, 2022 at 7:11 PM Radovan Skolnik <radovan@skolnik.info> wrote:
    Hello,

thank you for all the answers.I guess I have to test this thoroughly. My worry is generally this: let's say I have 2 lots/rolls each with 50m raw cable remaining. I need to produce 100m final cable. I think the system would consider I have enough of raw cable for this. Because that would work for certain scenarios. Imagine you need 100kg of something to prdouce something else. If you have 2 lots each with 50kg you're good to go - you just combine 50kg from each. Similarily if it was pieces. All these can be joined / added. I am talking about scenario where partial residual amounts cannot be added together to create a larger piece / amount.

Hope I am making myself clear. Best regards

	Radovan


On štvrtok 27. januára 2022 0:17:23 CET James Dominy wrote:


> Hello Radovan,


> I would track your rolls of cable using Lots, this way when the order calls


> for 25, 50, or 100 m of cable if the lot does not have the qty needed to


> produce the ethernet cable it will use the lot that has enough for the


> finished product. On Wed, Jan 26, 2022 at 3:57 PM Radovan Skolnik <


> radovan@skolnik.info [1] > wrote: Daniel,


> thank you for answer. Yes it does make sense. But will it cover scenario


> where I have let's say 2 rolls with 50m remaining on each and I want to


> produce 100m final cable? Because in such case a completely new roll should


> be ordered as I cannot join those 2 50m pieces together... So it comes to a


> requirement here that you just do not track the total number of meters


> remaining but you need to track each roll individually. Similar example


> would be a woodmaker who needs certain sizes of wood for various products


> (chair, table, ...) and he procures wood in 3m planks. What is your


> opinion? Best regards


> Radovan


> 


> On streda 26. januára 2022 21:51:47 CET Daniel Reis wrote:


> > I believe you need to use different Units of Measure (UoM).


> > In this case, the "Cable" Product is purchased in "Rolls" and used


> > in "Meters".


> > The "Roll" UoM should be configured to convert to Meters at a rate


> > of 1:1000.


> > This way you track your cable stock in meters available, and you


> > order to your supplier in rolls.


> > Dos this make sense?


> > Thanks


> > Daniel


> > 


> > On 26/01/22 20:37, Radovan Skolnik


> > wrote:


> > 


> > Hello,


> > sorry for asking stupid questions here but I hope someone can provide some


> > wisdom here that I am missing. Let's imagine this scenario: I produce


> > Ethernet cables of various lengths - i.e. 25m, 50m, 75m, 100m, ... Each


> > such final cable requires 2 connectors and that particular amount of "raw"


> > cable. I can only buy raw cable in rolls of 1000m. So when I buy a new


> > roll


> > and produce one final 50m cable, 950m of raw cable remains. When I produce


> > another of 100m length, 850m of raw cable remains. When my remaining raw


> > cable on certain roll is 50m I cannot produce 100m final cable and need to


> > order another raw cable roll. So the idea is tracking remaining quantity


> > of


> > somethings (products? lots? ...) that is bought at certain size and is


> > being gradually consumed. There can of course be more of these (i.e. I


> > have


> > bought 3 rolls at the same time). Is there a way on how to model this?


> > Manufacturing is not really my domain and looking through code of various


> > modules I didn't find anything that would resemble such thing. Thank you


> > very much. Best regards


> > Radovan Skolnik


> > 


> > 


> > _______________________________________________


> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [2] [1]


> > Post to: mailto: contributors@odoo-community.org [3] [2]


> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [4] [3]


> > 


> > 


> > 


> > --


> > DANIEL


> > REIS*


> > MANAGING DIRECTOR


> > M:*


> > +351 919 991 307


> > E:*


> > dreis@OpenSourceIntegrators.com [4]


> > A:*


> > Avenida da República 3000, Estoril Office B, #34


> > 


> > 


> > None [5] None [6] None [7]


> > 


> > 


> > _______________________________________________


> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [5] [8]


> > Post to: mailto: contributors@odoo-community.org [6]


> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [7] [9]


> > 


> > 


> > 


> > [1]  https://odoo-community.org/groups/contributors-15 [8]


> > [2] mailto: contributors@odoo-community.org [9]


> > [3]  https://odoo-community.org/groups?unsubscribe [10]


> > [4] mailto: dreis@OpenSourceIntegrators.com [11]


> > [5]  https://www.magentointegrators.com/ [12]


> > [6]  https://www.hadoopintegrators.com/ [13]


> > [7]  https://www.usaodoo.com/ [14]


> > [8]  https://odoo-community.org/groups/contributors-15 [15]


> > [9]  https://odoo-community.org/groups?unsubscribe [16]


> 


> _______________________________________________


> Mailing-List: https://odoo-community.org/groups/contributors-15 [17]


> Post to: mailto: contributors@odoo-community.org [18]


> Unsubscribe: https://odoo-community.org/groups?unsubscribe [19]


> 


> --


> * James Dominy *


> CEO


> * Lunel, Inc *


> Saratoga Springs, UT


> 719-888-9582


> jamesdominy@lunelerp.com [20]


> * www.lunel.co [21]


> *


> 


> _______________________________________________


> Mailing-List: https://odoo-community.org/groups/contributors-15 [22]


> Post to: mailto:contributors@odoo-community.org


> Unsubscribe: https://odoo-community.org/groups?unsubscribe [23]


> 


> 


> 


> [1] mailto:radovan@skolnik.info


> [2] https://odoo-community.org/groups/contributors-15


> [3] mailto:contributors@odoo-community.org


> [4] https://odoo-community.org/groups?unsubscribe


> [5] https://odoo-community.org/groups/contributors-15


> [6] mailto:contributors@odoo-community.org


> [7] https://odoo-community.org/groups?unsubscribe


> [8] https://odoo-community.org/groups/contributors-15


> [9] mailto:contributors@odoo-community.org


> [10] https://odoo-community.org/groups?unsubscribe


> [11] mailto:dreis@OpenSourceIntegrators.com


> [12] https://www.magentointegrators.com/


> [13] https://www.hadoopintegrators.com/


> [14] https://www.usaodoo.com/


> [15] https://odoo-community.org/groups/contributors-15


> [16] https://odoo-community.org/groups?unsubscribe


> [17] https://odoo-community.org/groups/contributors-15


> [18] mailto:contributors@odoo-community.org


> [19] https://odoo-community.org/groups?unsubscribe


> [20] mailto:james@lunelerp.com


> [21] http://www.lunel.co


> [22] https://odoo-community.org/groups/contributors-15


> [23] 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 - 09:15 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially 
    Hello,

thank you for all the answers.I guess I have to test this thoroughly. My worry is generally this: let's say I have 2 lots/rolls each with 50m raw cable remaining. I need to produce 100m final cable. I think the system would consider I have enough of raw cable for this. Because that would work for certain scenarios. Imagine you need 100kg of something to prdouce something else. If you have 2 lots each with 50kg you're good to go - you just combine 50kg from each. Similarily if it was pieces. All these can be joined / added. I am talking about scenario where partial residual amounts cannot be added together to create a larger piece / amount.

Hope I am making myself clear. Best regards

	Radovan


On štvrtok 27. januára 2022 0:17:23 CET James Dominy wrote:

> Hello Radovan,

> I would track your rolls of cable using Lots, this way when the order calls

> for 25, 50, or 100 m of cable if the lot does not have the qty needed to

> produce the ethernet cable it will use the lot that has enough for the

> finished product. On Wed, Jan 26, 2022 at 3:57 PM Radovan Skolnik <

> radovan@skolnik.info [1] > wrote: Daniel,

> thank you for answer. Yes it does make sense. But will it cover scenario

> where I have let's say 2 rolls with 50m remaining on each and I want to

> produce 100m final cable? Because in such case a completely new roll should

> be ordered as I cannot join those 2 50m pieces together... So it comes to a

> requirement here that you just do not track the total number of meters

> remaining but you need to track each roll individually. Similar example

> would be a woodmaker who needs certain sizes of wood for various products

> (chair, table, ...) and he procures wood in 3m planks. What is your

> opinion? Best regards

> Radovan

> 

> On streda 26. januára 2022 21:51:47 CET Daniel Reis wrote:

> > I believe you need to use different Units of Measure (UoM).

> > In this case, the "Cable" Product is purchased in "Rolls" and used

> > in "Meters".

> > The "Roll" UoM should be configured to convert to Meters at a rate

> > of 1:1000.

> > This way you track your cable stock in meters available, and you

> > order to your supplier in rolls.

> > Dos this make sense?

> > Thanks

> > Daniel

> > 

> > On 26/01/22 20:37, Radovan Skolnik

> > wrote:

> > 

> > Hello,

> > sorry for asking stupid questions here but I hope someone can provide some

> > wisdom here that I am missing. Let's imagine this scenario: I produce

> > Ethernet cables of various lengths - i.e. 25m, 50m, 75m, 100m, ... Each

> > such final cable requires 2 connectors and that particular amount of "raw"

> > cable. I can only buy raw cable in rolls of 1000m. So when I buy a new

> > roll

> > and produce one final 50m cable, 950m of raw cable remains. When I produce

> > another of 100m length, 850m of raw cable remains. When my remaining raw

> > cable on certain roll is 50m I cannot produce 100m final cable and need to

> > order another raw cable roll. So the idea is tracking remaining quantity

> > of

> > somethings (products? lots? ...) that is bought at certain size and is

> > being gradually consumed. There can of course be more of these (i.e. I

> > have

> > bought 3 rolls at the same time). Is there a way on how to model this?

> > Manufacturing is not really my domain and looking through code of various

> > modules I didn't find anything that would resemble such thing. Thank you

> > very much. Best regards

> > Radovan Skolnik

> > 

> > 

> > _______________________________________________

> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [2] [1]

> > Post to: mailto: contributors@odoo-community.org [3] [2]

> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [4] [3]

> > 

> > 

> > 

> > --

> > DANIEL

> > REIS*

> > MANAGING DIRECTOR

> > M:*

> > +351 919 991 307

> > E:*

> > dreis@OpenSourceIntegrators.com [4]

> > A:*

> > Avenida da República 3000, Estoril Office B, #34

> > 

> > 

> > None [5] None [6] None [7]

> > 

> > 

> > _______________________________________________

> > Mailing-List:  https://odoo-community.org/groups/contributors-15 [5] [8]

> > Post to: mailto: contributors@odoo-community.org [6]

> > Unsubscribe:  https://odoo-community.org/groups?unsubscribe [7] [9]

> > 

> > 

> > 

> > [1]  https://odoo-community.org/groups/contributors-15 [8]

> > [2] mailto: contributors@odoo-community.org [9]

> > [3]  https://odoo-community.org/groups?unsubscribe [10]

> > [4] mailto: dreis@OpenSourceIntegrators.com [11]

> > [5]  https://www.magentointegrators.com/ [12]

> > [6]  https://www.hadoopintegrators.com/ [13]

> > [7]  https://www.usaodoo.com/ [14]

> > [8]  https://odoo-community.org/groups/contributors-15 [15]

> > [9]  https://odoo-community.org/groups?unsubscribe [16]

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [17]

> Post to: mailto: contributors@odoo-community.org [18]

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [19]

> 

> --

> * James Dominy *

> CEO

> * Lunel, Inc *

> Saratoga Springs, UT

> 719-888-9582

> jamesdominy@lunelerp.com [20]

> * www.lunel.co [21]

> *

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [22]

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [23]

> 

> 

> 

> [1] mailto:radovan@skolnik.info

> [2] https://odoo-community.org/groups/contributors-15

> [3] mailto:contributors@odoo-community.org

> [4] https://odoo-community.org/groups?unsubscribe

> [5] https://odoo-community.org/groups/contributors-15

> [6] mailto:contributors@odoo-community.org

> [7] https://odoo-community.org/groups?unsubscribe

> [8] https://odoo-community.org/groups/contributors-15

> [9] mailto:contributors@odoo-community.org

> [10] https://odoo-community.org/groups?unsubscribe

> [11] mailto:dreis@OpenSourceIntegrators.com

> [12] https://www.magentointegrators.com/

> [13] https://www.hadoopintegrators.com/

> [14] https://www.usaodoo.com/

> [15] https://odoo-community.org/groups/contributors-15

> [16] https://odoo-community.org/groups?unsubscribe

> [17] https://odoo-community.org/groups/contributors-15

> [18] mailto:contributors@odoo-community.org

> [19] https://odoo-community.org/groups?unsubscribe

> [20] mailto:james@lunelerp.com

> [21] http://www.lunel.co

> [22] https://odoo-community.org/groups/contributors-15

> [23] https://odoo-community.org/groups?unsubscribe
    by Radovan Skolnik - 07:11 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially
    Hello Radovan,

    First, to track your raw materials you should automatically be able to do it. Let’s say you buy rolls of cable every time to produce your own cables. The cable on hand quantity should get always be updated whenever you purchase new stock.

    The BOM will look like this:
    1. Certain amount of roll cable (maybe 50m for 50m final Ethernet cable)
    2. 2 connectors

    Now let’s say you have 21 manufacturing order or 21x50= 1050meter manufacturing order. But let’s say you have 1000m (1roll) in stock. The system in the MO will automatically show you that you don’t have enough stock to produce 1050m cable. If you have single MO, you can modify that or if you have 21 MO you can complete the extra MO later when stock arrives.

     If you want to automatically order the raw materials after certain quantity, you can use replenishment order.

    Secondly, use multiple UOM for sales and purchase. By that you can purchase in rolls but produce/sale in meters and consume accordingly.

    Regards,
    Md. Tanzilul Hasan Khan



    On Jan 27, 2022 at 2:37 AM, <Radovan Skolnik> wrote:

    Hello,

sorry for asking stupid questions here but I hope someone can provide some wisdom here that I am missing.

Let's imagine this scenario: I produce Ethernet cables of various lengths - i.e. 25m, 50m, 75m, 100m, ... Each such final cable requires 2 connectors and that particular amount of "raw" cable. I can only buy raw cable in rolls of 1000m.

So when I buy a new roll and produce one final 50m cable, 950m of raw cable remains. When I produce another of 100m length, 850m of raw cable remains. When my remaining raw cable on certain roll is 50m I cannot produce 100m final cable and need to order another raw cable roll.

So the idea is tracking remaining quantity of somethings (products? lots? ...) that is bought at certain size and is being gradually consumed. There can of course be more of these (i.e. I have bought 3 rolls at the same time).

Is there a way on how to model this? Manufacturing is not really my domain and looking through code of various modules I didn't find anything that would resemble such thing.

Thank you very much. Best regards

	Radovan Skolnik
    by ponkhi403 - 04:56 - 27 Jan 2022
  • Re: Manufacturing advice needed - materials of measured units being consumed partially
    Hello Radovan,

    I would track your rolls of cable using Lots, this way when the order calls for 25, 50, or 100 m of cable if the lot does not have the qty needed to produce the ethernet cable it will use the lot that has enough for the finished product.

    On Wed, Jan 26, 2022 at 3:57 PM Radovan Skolnik <radovan@skolnik.info> wrote:
    Daniel,

thank you for answer. Yes it does make sense. But will it cover scenario where I have let's say 2 rolls with 50m remaining on each and I want to produce 100m final cable? Because in such case a completely new roll should be ordered as I cannot join those 2 50m pieces together... So it comes to a requirement here that you just do not track the total number of meters remaining but you need to track each roll individually. Similar example would be a woodmaker who needs certain sizes of wood for various products (chair, table, ...) and he procures wood in 3m planks. What is your opinion?

Best regards

	Radovan

On streda 26. januára 2022 21:51:47 CET Daniel Reis wrote:


> I believe you need to use different Units of Measure (UoM).


> In this case, the "Cable" Product is purchased in "Rolls" and used


> in "Meters".


> The "Roll" UoM should be configured to convert to Meters at a rate


> of 1:1000.


> This way you track your cable stock in meters available, and you


> order to your supplier in rolls.


> Dos this make sense?


> Thanks


> Daniel


> 


> On 26/01/22 20:37, Radovan Skolnik


> wrote:


> 


> Hello,


> sorry for asking stupid questions here but I hope someone can provide some


> wisdom here that I am missing. Let's imagine this scenario: I produce


> Ethernet cables of various lengths - i.e. 25m, 50m, 75m, 100m, ... Each


> such final cable requires 2 connectors and that particular amount of "raw"


> cable. I can only buy raw cable in rolls of 1000m. So when I buy a new roll


> and produce one final 50m cable, 950m of raw cable remains. When I produce


> another of 100m length, 850m of raw cable remains. When my remaining raw


> cable on certain roll is 50m I cannot produce 100m final cable and need to


> order another raw cable roll. So the idea is tracking remaining quantity of


> somethings (products? lots? ...) that is bought at certain size and is


> being gradually consumed. There can of course be more of these (i.e. I have


> bought 3 rolls at the same time). Is there a way on how to model this?


> Manufacturing is not really my domain and looking through code of various


> modules I didn't find anything that would resemble such thing. Thank you


> very much. Best regards


> Radovan Skolnik


> 


> 


> _______________________________________________


> Mailing-List: https://odoo-community.org/groups/contributors-15 [1]


> Post to: mailto:contributors@odoo-community.org [2]


> Unsubscribe: https://odoo-community.org/groups?unsubscribe [3]


> 


> 


> 


> --


> DANIEL


> REIS*


> MANAGING DIRECTOR


> M:*


> +351 919 991 307


> E:*


> dreis@OpenSourceIntegrators.com [4]


> A:*


> Avenida da República 3000, Estoril Office B, #34


> 


> 


> None [5]  None [6]  None [7]


> 


> 


> _______________________________________________


> Mailing-List: https://odoo-community.org/groups/contributors-15 [8]


> Post to: mailto:contributors@odoo-community.org


> Unsubscribe: https://odoo-community.org/groups?unsubscribe [9]


> 


> 


> 


> [1] https://odoo-community.org/groups/contributors-15


> [2] mailto:contributors@odoo-community.org


> [3] https://odoo-community.org/groups?unsubscribe


> [4] mailto:dreis@OpenSourceIntegrators.com


> [5] https://www.magentointegrators.com/


> [6] https://www.hadoopintegrators.com/


> [7] https://www.usaodoo.com/


> [8] https://odoo-community.org/groups/contributors-15


> [9] 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



    --
    James Dominy
    CEO
    Lunel, Inc
    Saratoga Springs, UT
    719-888-9582
    jamesdominy@lunelerp.com
    www.lunel.co
    by James Dominy - 12:16 - 27 Jan 2022