Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • Friendly reminder – Pending PR review in OCA/l10n-colombia

    Dear OCA Contributors,

    I hope this message finds you well.

    I would like to kindly inform you that on September 25th I submitted a Pull Request to the OCA/l10n-colombia repository (see link below):

    🔗 PR #22 – OCA/l10n-colombia

    It is still pending review, so I just wanted to bring it to your attention in case it has gone unnoticed. Please let me know if any additional changes or adjustments are required from my side.

    Thank you very much for your time and for all the great work you do for the community.

    Best regards,
    Yan Chirino

    by Yan Chirino - 10:16 - 2 Oct 2025
  • OCA 2025 AGA Delegates Campaign - CLOSES Friday 3rd October
    Hello OCA Contributors

    Just a reminder that the opportunity to apply to become a Delegate this year closes this Friday 3rd October.

    So far we have had 9 applicants for the 10 spots available.

    The 2025 OCA Delegates Campaign is now open. Until October 3rd, you can apply to be an OCA Delegate if you are a current paid Member.
    If you are already a Delegate, you don't need to apply again. This is for 10 new Delegates.

    Why?
    The Delegate Assembly is the Association’s supreme authority. Each Delegate member is entitled to one vote at the Delegate Assembly. Decisions of the Delegate Assembly are taken by a majority vote of the Delegate members present and voting. For further details, please read the Bylaws.

    How?
    To apply as a candidate, you have to:
    • sign the CLA (if not already done)
    • have a valid membership. Make sure to purchase your membership or renew it (you should have received a quotation for your renewal earlier this year).
    • fill in this survey
    If you aren't sure if you have renewed/paid your membership for 2025 please contact me.

    The campaign will be closed on October 3rd, 2025.

    Then what?
    The vote will be open from October 6th - October 17th. Current OCA Delegates will have to vote for 10 new Delegates among the candidates.

    The results of the election will be announced on October 20th, 2025.

    The 10 new Delegates will then take part with the existing Delegates in :
    • the 2025 OCA Board Member Campaign from October 20th - October 31st, 2025
    • the 2025 OCA Financial Auditor Campaign from October 20th - October 31st, 2025
    • the 2025 General Assembly from November 3rd to November 14th 2025.
    • 2025 Board announced - week beginning November 17th, 2025 
    If you have any questions please get in touch.

    Warmest regards,
    Rebecca
    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 05:51 - 30 Sep 2025
  • October OCA Events Schedule

    📣 Don't miss our upcoming events for OCA members in October!

    - October 1: Webinar - Manage your social media from Odoo with the new OCA modules V17
    - October 7: Support Group Session - OCA Consultant
    - October 13 to 24: Online Training - OWL
    - October 22: Webinar - Why OCA modules are like Magic Beans
    - October 28: Webinar - OCA from 2013 to now, the history!

    Register here : https://odoo-community.org/event
    **100% discount for OCA members**

    by Julie LeBrun (OCA) - 05:39 - 25 Sep 2025

    1 attachments 1 attachments

    Calendar October 2025.png
  • Beyond LLM guidelines and generated contributions

    Hi everybody,

    First, thank you for the great time at the OCA Days and I hope you are enjoying the OXP.

    The ongoing discussion on LLM guidelines ~~had me triggered~~ got me thinking.

    I would like to give a different perspective on LLMs and what we as a community should care about.

    Let's talk about digital sovereignty and power-consumption. Most LLMs used by developers made by big tech companies [0]. These companies have built huge data centers that use an incredible amount of power to run LLMs. They have plans to build nuclear reactors to support the power demand. Anyone who is seriously concerned with digital sovereignty and cares about the environment knows that we need to become independent of big tech and use less energy.

    > Supporting AI tools by big tech is a step into the wrong direction.

    Moreover, the AI hype is igniting the next level of data collecting and user tracking. The data we generate when interacting with an AI chat and the like is incredibly valuable. As of now the tech bros still have no viable business model and burn money at an incredible amount [1].

    Every week a new model is released and we feel pressured to use AI.  Let us take a break and take it slow moving forward. We are not forced to do anything (at least for now).

    I ask the OCA members to do better than creating an OpenAI account, installing Claude desktop or click the Copilot icon. Use tools and create workflows that respect your privacy and the privacy of others. Make sure your stack uses less energy over time, works independent and is controllable.

    > Let us create guides on how to do better.

    Here is an example, not show off, but simply to share:
    The LLMs I am using are hosted by Infomaniak in Switzerland [2]. They are using "green" energy. I pay per token and I know where the data is stored. On the command line, I am using the LLM cli     [3] by Simon Willison (LLM reseacher). Every LLM tool that supports the OpenAI API standard can be connected to an Infomaniak LLM. There are great scripts that help your write better code [4]. I don't have any kind of IDE integration [5]. I like to write code and not press tab tab tab ...

    Is somebody interested to create guides on how to work (better) with LLMs and create contributions that help the ecosystem?

    Kind regards,

    Janik

    [0]: https://en.wikipedia.org/wiki/Big_Tech
    [1]: https://www.wheresyoured.at/the-haters-gui/
    [2]: https://www.infomaniak.com/en/hosting/ai-tools
    [3]: https://llm.datasette.io/
    [4]: https://notes.billmill.org/blog/2025/07/An_AI_tool_I_find_useful.html
    [5]: https://janikvonrotz.ch/2025/01/27/work-with-llms-on-the-command-line/





    by Janik von Rotz - 11:05 - 19 Sep 2025
  • Integration of knowledge or dms with onlyoffice ?
    Hello

    At oxp, I met https://www.onlyoffice.com/ who developped a connector with odoo's document app...

    AFAIK it's LGPL and they run infomaniak Kdrive

    I was wondering if we could have the same with knowledge and/or dms.

    WDYT ?

    Best regards


    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com
    www.invitu.com
    by Cyril VINH-TUNG - 04:20 - 18 Sep 2025

    6 replies 6 replies

  • Slides for OpenUpgrader module for Odoo at OCA Days 2025
    Hi all,
    as Alexandre did, I share the slides from the talk about an OpenUpgrade automatization tool I did: https://docs.google.com/presentation/d/1671gOwuPqaJD9mfsYzxcp0YgyEf8SUaRwrzSUhGdZvw/edit?usp=sharing

    Maybe there is a place to put them in the OCA Website to simplify finding them in the future?

    Sergio Corato
    by Sergio Corato - 09:51 - 18 Sep 2025
  • Guidelines for LLM generated contributions 
    Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
    by Stefan Rijnhart - 09:40 - 18 Sep 2025

    32 replies 32 replies

    • RE: Guidelines for LLM generated contributions

      Thanks Stuart for the decent & constructive reply.

      Copyright is indeed an issue industry wise, as you mentioned, with many lawsuits in place but no clear direction. This is due to how LLM models are trained and how data converted into tokens, relations, and weights and stored into multi-dimensional vector space. Certain paths may represent a piece of copyrighted artifact.

      Yes, I do supervise my AI agents very strictly. Vibe coding, or whatever they call it, does not work in writing code for Odoo or any enterprise/ERP level codebase. In such complex codebase best is to treat AI agent as normal employees flow, keeping a human at last step is a must. It is crazy to see an LLM getting lazy like if it is the last hour before weekend, but it happened many times. Since those AI Agents are trained using humans data/traces, it includes good and bad behaviors and it requires some skills similar to managing normal team.

      I do respect and admire OCA brand very much and I know code quality is very high in general. It is not easy to get a module into OCA repository. OCA guidelines & policies are really rail guarding the quality and the brand.

      I think of LLM-OCA subject as two parts: 1) list of concerns and clarifications that would result into guidelines & policies, 2) AI tools and their usage. Even though there are many AI tools/agents but the ones that can really work in such codebase are very few.

       

      It is my pleasure to be part of it, it is always a joy to contribute.

       

      Sincerely,

      Hussain H.

       

      From: Stuart J Mackintosh <notifications@odoo-community.org>
      Sent: Thursday, October 9, 2025 7:18 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Guidelines for LLM generated contributions

       

       

      Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

      Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

      In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

      Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

      Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

      Best wishes,

      Stuart.

       

       

      On 09/10/2025 10:22, Hussain Hammad wrote:

      Hi All,

       

      I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

       

      Proper decision comes from facts and understanding these facts.

       

      I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

       

      Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

       

      I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

       

       

      Sincerely,

       

      Hussain Hammad  |  Solutions Unity Co.
      6957 Abdullah Bin Harith Street, Shati District

      Tarout 32617, Saudi Arabia

      +966 56 963 4488  
      hussain@solutionsunity.com

      www.solutionsunity.com

       

       

      From: Joël Grand-Guillaume <notifications@odoo-community.org>
      Sent: Monday, September 29, 2025 10:27 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Guidelines for LLM generated contributions

       

       

       

      ...

      Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

      +1 - Transparency is key in this first steps - this will maintain trust.

       

      What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

      +1 to have the governance working group leading this topic

       

      Best wishes,

      Stuart.

       

      On 27/09/2025 15:07, Raphaël Valyi wrote:

      Hello,

       

      I think IA policies and risks/benefits may vary a lot depending on the use cases...

       

      The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

       

      As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

       

      Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

       

      For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

       

      But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

       

      As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

       

      But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

       

      But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

       

      Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

       

      But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

       

      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

       

       

       

      On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

       

      Indeed - it would be of benefit for OCA to have a position.

      Best wishes,

      Stuart.

       

      On 27/09/2025 09:27, Frederik Kramer wrote:

      Hi Stuart, hi all,

      very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

      Best Frederik

       

      Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

       

      Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

      Brief overview of policies:

      - The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
      - Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
      - Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
      - Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
      - Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

      This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

      Best wishes,

      Stuart.

       

      On 24/09/2025 11:01, Stuart J Mackintosh wrote:

       

      I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

      Best wishes,

      Stuart.

       

      On 24/09/2025 10:47, Graeme Gellatly wrote:

      I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

       

      It also gives valuable information to both the reviewer and ultimately the users. 

       

      It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

       

       

      On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

      Hello all,

      It begs the question of what is "AI generated code".
      AI can assist code writing from code completion suggestions, to full design and code writing.
      Or just assist with code reviews or issue resolution, without writing code.

      In the end AI is just a tool.
      Irresponsible use can happen with AI or any other automation tool.

      What really matters is the behavior of people using these tools.
      I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
      This could be fitted into a code of conduct for the community.

      Thanks
      Daniel

      On 18/09/2025 08:41, Stefan Rijnhart wrote:

      Dear all,

       

      at least one contributor is planning again to flood the OCA projects 
      with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
      This volume is likely made possible through automation, with an LLM 
      generating the actual migration code (on top of, hopefully, a more 
      deterministic tool like OCA's odoo-module-migrator).

       

      Regardless of the volume and the submitter, if the submitter has 
      reviewed, refined and tested the code generated by an LLM, this should 
      not be a problem but as a reviewer I'd like to know what I can expect. 
      Holger Brunn pointed out to me that in other projects, this may be 
      covered by a demand in the guidelines to disclose LLM usage and its 
      extend. For an example, see 
      https://github.com/ghostty-org/ghostty/pull/8289/files.

       

      I would very much like to see such an addition to the OCA guidelines. 
      Additionally, I would like to suggest that the basic premise (the 
      generated code is indeed first self-reviewed, refined and tested) is 
      also made explicit, and that it is unacceptable to pass on reviewer 
      comments to the LLM only to copy back the LLM's response (which has 
      happened to me on one or two occassions).

       

      Can I have a temperature check for your support for such an addition to 
      the guidelines? Or do you have other ideas or perspectives on the matter?

       

      Cheers,
      Stefan

       

       

       

       

       

      -- 
      Opener B.V. - Business solutions driven by open source collaboration

       

      Stefan Rijnhart - Consultant/developer

       

      mail:stefan@opener.amsterdam
      tel: +31 (0) 6 1447 8606
      web:https://opener.amsterdam

       

       

       

      --

      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

       

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-10
      Mobil:  +49 179 3901819
              
      Email: frederik.kramer@initos.com
      Web:   www.initos.com
              
      Geschäftsführung:
      Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

      Sitz der Gesellschaft: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      by Hussain Hammad - 04:26 - 11 Oct 2025
    • Re: Guidelines for LLM generated contributions


      Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

      Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

      In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

      Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

      Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

      Best wishes,

      Stuart.



      On 09/10/2025 10:22, Hussain Hammad wrote:

      Hi All,

       

      I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

       

      Proper decision comes from facts and understanding these facts.

       

      I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

       

      Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

       

      I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

       

       

      Sincerely,

       

      Hussain Hammad  |  Solutions Unity Co.
      6957 Abdullah Bin Harith Street, Shati District

      Tarout 32617, Saudi Arabia

      +966 56 963 4488  
      hussain@solutionsunity.com

      www.solutionsunity.com

       

       

      From: Joël Grand-Guillaume <notifications@odoo-community.org>
      Sent: Monday, September 29, 2025 10:27 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Guidelines for LLM generated contributions

       

       

       

      ...

      Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

      +1 - Transparency is key in this first steps - this will maintain trust.

       

      What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

      +1 to have the governance working group leading this topic

       

      Best wishes,

      Stuart.

       

      On 27/09/2025 15:07, Raphaël Valyi wrote:

      Hello,

       

      I think IA policies and risks/benefits may vary a lot depending on the use cases...

       

      The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

       

      As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

       

      Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

       

      For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

       

      But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

       

      As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

       

      But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

       

      But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

       

      Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

       

      But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

       

      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

       

       

       

      On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

       

      Indeed - it would be of benefit for OCA to have a position.

      Best wishes,

      Stuart.

       

      On 27/09/2025 09:27, Frederik Kramer wrote:

      Hi Stuart, hi all,

      very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

      Best Frederik

       

      Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

       

      Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

      Brief overview of policies:

      - The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
      - Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
      - Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
      - Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
      - Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

      This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

      Best wishes,

      Stuart.

       

      On 24/09/2025 11:01, Stuart J Mackintosh wrote:

       

      I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

      Best wishes,

      Stuart.

       

      On 24/09/2025 10:47, Graeme Gellatly wrote:

      I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

       

      It also gives valuable information to both the reviewer and ultimately the users. 

       

      It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

       

       

      On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

      Hello all,

      It begs the question of what is "AI generated code".
      AI can assist code writing from code completion suggestions, to full design and code writing.
      Or just assist with code reviews or issue resolution, without writing code.

      In the end AI is just a tool.
      Irresponsible use can happen with AI or any other automation tool.

      What really matters is the behavior of people using these tools.
      I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
      This could be fitted into a code of conduct for the community.

      Thanks
      Daniel

      On 18/09/2025 08:41, Stefan Rijnhart wrote:

      Dear all,
       
      at least one contributor is planning again to flood the OCA projects 
      with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
      This volume is likely made possible through automation, with an LLM 
      generating the actual migration code (on top of, hopefully, a more 
      deterministic tool like OCA's odoo-module-migrator).
       
      Regardless of the volume and the submitter, if the submitter has 
      reviewed, refined and tested the code generated by an LLM, this should 
      not be a problem but as a reviewer I'd like to know what I can expect. 
      Holger Brunn pointed out to me that in other projects, this may be 
      covered by a demand in the guidelines to disclose LLM usage and its 
      extend. For an example, see 
      https://github.com/ghostty-org/ghostty/pull/8289/files.
       
      I would very much like to see such an addition to the OCA guidelines. 
      Additionally, I would like to suggest that the basic premise (the 
      generated code is indeed first self-reviewed, refined and tested) is 
      also made explicit, and that it is unacceptable to pass on reviewer 
      comments to the LLM only to copy back the LLM's response (which has 
      happened to me on one or two occassions).
       
      Can I have a temperature check for your support for such an addition to 
      the guidelines? Or do you have other ideas or perspectives on the matter?
       
      Cheers,
      Stefan
       
       
       
       
       
      -- 
      Opener B.V. - Business solutions driven by open source collaboration
       
      Stefan Rijnhart - Consultant/developer
       
      mail:stefan@opener.amsterdam
      tel: +31 (0) 6 1447 8606
      web:https://opener.amsterdam
       
       

       

      --

      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

       

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-10
      Mobil:  +49 179 3901819
              
      Email: frederik.kramer@initos.com
      Web:   www.initos.com
              
      Geschäftsführung:
      Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

      Sitz der Gesellschaft: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      _______________________________________________
      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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      by Stuart J Mackintosh - 06:16 - 9 Oct 2025

      1 attachments 1 attachments

      logo.png
    • RE: Guidelines for LLM generated contributions

      Hi All,

       

      I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

       

      Proper decision comes from facts and understanding these facts.

       

      I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

       

      Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

       

      I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

       

       

      Sincerely,

       

      Hussain Hammad  |  Solutions Unity Co.
      6957 Abdullah Bin Harith Street, Shati District

      Tarout 32617, Saudi Arabia

      +966 56 963 4488  
      hussain@solutionsunity.com

      www.solutionsunity.com

       

       

      From: Joël Grand-Guillaume <notifications@odoo-community.org>
      Sent: Monday, September 29, 2025 10:27 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Guidelines for LLM generated contributions

       

       

       

      ...

      Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

      +1 - Transparency is key in this first steps - this will maintain trust.

       

      What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

      +1 to have the governance working group leading this topic

       

      Best wishes,

      Stuart.

       

      On 27/09/2025 15:07, Raphaël Valyi wrote:

      Hello,

       

      I think IA policies and risks/benefits may vary a lot depending on the use cases...

       

      The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

       

      As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

       

      Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

       

      For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

       

      But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

       

      As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

       

      But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

       

      But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

       

      Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

       

      But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

       

      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

       

       

       

      On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

       

      Indeed - it would be of benefit for OCA to have a position.

      Best wishes,

      Stuart.

       

      On 27/09/2025 09:27, Frederik Kramer wrote:

      Hi Stuart, hi all,

      very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

      Best Frederik

       

      Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

       

      Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

      Brief overview of policies:

      - The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
      - Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
      - Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
      - Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
      - Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

      This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

      Best wishes,

      Stuart.

       

      On 24/09/2025 11:01, Stuart J Mackintosh wrote:

       

      I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

      Best wishes,

      Stuart.

       

      On 24/09/2025 10:47, Graeme Gellatly wrote:

      I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

       

      It also gives valuable information to both the reviewer and ultimately the users. 

       

      It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

       

       

      On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

      Hello all,

      It begs the question of what is "AI generated code".
      AI can assist code writing from code completion suggestions, to full design and code writing.
      Or just assist with code reviews or issue resolution, without writing code.

      In the end AI is just a tool.
      Irresponsible use can happen with AI or any other automation tool.

      What really matters is the behavior of people using these tools.
      I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
      This could be fitted into a code of conduct for the community.

      Thanks
      Daniel

      On 18/09/2025 08:41, Stefan Rijnhart wrote:

      Dear all,
       
      at least one contributor is planning again to flood the OCA projects 
      with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
      This volume is likely made possible through automation, with an LLM 
      generating the actual migration code (on top of, hopefully, a more 
      deterministic tool like OCA's odoo-module-migrator).
       
      Regardless of the volume and the submitter, if the submitter has 
      reviewed, refined and tested the code generated by an LLM, this should 
      not be a problem but as a reviewer I'd like to know what I can expect. 
      Holger Brunn pointed out to me that in other projects, this may be 
      covered by a demand in the guidelines to disclose LLM usage and its 
      extend. For an example, see 
      https://github.com/ghostty-org/ghostty/pull/8289/files.
       
      I would very much like to see such an addition to the OCA guidelines. 
      Additionally, I would like to suggest that the basic premise (the 
      generated code is indeed first self-reviewed, refined and tested) is 
      also made explicit, and that it is unacceptable to pass on reviewer 
      comments to the LLM only to copy back the LLM's response (which has 
      happened to me on one or two occassions).
       
      Can I have a temperature check for your support for such an addition to 
      the guidelines? Or do you have other ideas or perspectives on the matter?
       
      Cheers,
      Stefan
       
       
       
       
       
      -- 
      Opener B.V. - Business solutions driven by open source collaboration
       
      Stefan Rijnhart - Consultant/developer
       
      mail:stefan@opener.amsterdam
      tel: +31 (0) 6 1447 8606
      web:https://opener.amsterdam
       
       

       

      --

      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

       

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-10
      Mobil:  +49 179 3901819
              
      Email: frederik.kramer@initos.com
      Web:   www.initos.com
              
      Geschäftsführung:
      Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

      Sitz der Gesellschaft: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      by Hussain Hammad - 10:21 - 9 Oct 2025

      1 attachments 1 attachments

      image001.png
    • Re: Guidelines for LLM generated contributions


      ...

      Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

      +1 - Transparency is key in this first steps - this will maintain trust.
       

      What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

      +1 to have the governance working group leading this topic

       

      Best wishes,

      Stuart.


      On 27/09/2025 15:07, Raphaël Valyi wrote:
      Hello,

      I think IA policies and risks/benefits may vary a lot depending on the use cases...

      The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

      As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

      Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

      For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

      But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

      As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

      But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

      But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

      Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

      But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.



      On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:


      Indeed - it would be of benefit for OCA to have a position.

      Best wishes,

      Stuart.


      On 27/09/2025 09:27, Frederik Kramer wrote:
      Hi Stuart, hi all,

      very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

      Best Frederik


      Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:


      Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

      Brief overview of policies:

      - The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
      - Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
      - Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
      - Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
      - Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

      This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

      Best wishes,

      Stuart.


      On 24/09/2025 11:01, Stuart J Mackintosh wrote:


      I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

      Best wishes,

      Stuart.


      On 24/09/2025 10:47, Graeme Gellatly wrote:
      I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

      It also gives valuable information to both the reviewer and ultimately the users. 

      It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf


      On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
      Hello all,

      It begs the question of what is "AI generated code".
      AI can assist code writing from code completion suggestions, to full design and code writing.
      Or just assist with code reviews or issue resolution, without writing code.

      In the end AI is just a tool.
      Irresponsible use can happen with AI or any other automation tool.

      What really matters is the behavior of people using these tools.
      I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
      This could be fitted into a code of conduct for the community.

      Thanks
      Daniel

      On 18/09/2025 08:41, Stefan Rijnhart wrote:
      Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan





-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

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


      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]


      _______________________________________________
      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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-10
      Mobil:  +49 179 3901819
              
      Email: frederik.kramer@initos.com
      Web:   www.initos.com
              
      Geschäftsführung:
      Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

      Sitz der Gesellschaft: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      _______________________________________________
      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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      by Joël Grand Guillaume - 09:26 - 29 Sep 2025
    • Re: Guidelines for LLM generated contributions


      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

      Good points and well made - yes, this future is coming and OCA and community must be at the front of it.

      I feel that a clear OCA position is important as without it, there is risk of collaborators working with different rules and assumptions which ultimately costs time and energy. So this is the opportunity for the community to work out what are the shared rules for this new world. If there is insufficient information owing to the rapidly changing landscape, then soft guidance may be the OCA position for now. 

      Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

      What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

      Best wishes,

      Stuart.


      On 27/09/2025 15:07, Raphaël Valyi wrote:
      Hello,

      I think IA policies and risks/benefits may vary a lot depending on the use cases...

      The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

      As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

      Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

      For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

      But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

      As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

      But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

      But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

      Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

      But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

      How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.



      On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:


      Indeed - it would be of benefit for OCA to have a position.

      Best wishes,

      Stuart.


      On 27/09/2025 09:27, Frederik Kramer wrote:
      Hi Stuart, hi all,

      very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

      Best Frederik


      Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:


      Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

      Brief overview of policies:

      - The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
      - Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
      - Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
      - Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
      - Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

      This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

      Best wishes,

      Stuart.


      On 24/09/2025 11:01, Stuart J Mackintosh wrote:


      I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

      Best wishes,

      Stuart.


      On 24/09/2025 10:47, Graeme Gellatly wrote:
      I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

      It also gives valuable information to both the reviewer and ultimately the users. 

      It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf


      On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
      Hello all,

      It begs the question of what is "AI generated code".
      AI can assist code writing from code completion suggestions, to full design and code writing.
      Or just assist with code reviews or issue resolution, without writing code.

      In the end AI is just a tool.
      Irresponsible use can happen with AI or any other automation tool.

      What really matters is the behavior of people using these tools.
      I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
      This could be fitted into a code of conduct for the community.

      Thanks
      Daniel

      On 18/09/2025 08:41, Stefan Rijnhart wrote:
      Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan




-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

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


      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]


      _______________________________________________
      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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-10
      Mobil:  +49 179 3901819
              
      Email: frederik.kramer@initos.com
      Web:   www.initos.com
              
      Geschäftsführung:
      Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

      Sitz der Gesellschaft: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155

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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      _______________________________________________
      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

      --

      Stuart J Mackintosh

      Business & digital technology consultant

      Open Digital Consulting Co

      Open Digital Consulting Co Logo

      UK: +44 20 36 27 90 40

      FR: +33 1 89 48 00 40

      Email: sjm@opendigital.cc

      Web: https://opendigital.cc

      IM: xmpp:sjm@opendigital.cc

      by Stuart J Mackintosh - 05:31 - 28 Sep 2025

      1 attachments 1 attachments

      logo.png

  • Slides for Making Odoo Faster talk at OCA Days 2025
    Hello, 

    For those interested, the slides for the talk Making Odoo Faster
    Analyzing Odoo’s Speed that I gave yesterday are available here:


    --
    Alexandre Fayolle
    Senior Software Engineer and Architect

    Camptocamp France SAS
    http://www.camptocamp.com

    by Alexandre Fayolle - 10:26 - 17 Sep 2025

    2 replies 2 replies

  • Oferta de empleo de Consultor/a Odoo

    Buenos días, 

    Me pongo en contacto con vosotros ya que actualmente disponemos de una oferta de empleo que podría resultar de interés para vuestros/as asociados/as. 

    Estamos buscando un perfil de Consultor Odoo para Valladolid en modalidad híbrida y me preguntaba si sería posible publicar la oferta en vuestra página web para que pudieran inscribirse las personas interesadas en la misma.

    En el siguiente enlace puedes ver todos los detalles de la oferta: https://www.jobfie.es/trabajo/13896540/Valladolid/consultora-erp-odoo-contrato-indefinido

    Cualquier duda quedo a vuestra disposición.

    Gracias de antemano, un saludo.

    --
    FIRMA SANDRA RODRIGUEZ
    Logo
    Sandra Rodríguez
    Jobfie | Portal de empleo
    Responsable de operaciones
     
    sandra.rodriguez@jobfie.es
    Valladolid, España
    www.jobfie.es
    facebook icon
    twitter icon
    youtube icon
     
    linkedin icon
    instagram icon
    El contenido de este correo electrónico es confidencial y está destinado únicamente al destinatario especificado en el mensaje. Está estrictamente prohibido compartir cualquier parte de este mensaje con terceros, sin el consentimiento por escrito del remitente. Si recibió este mensaje por error, responda a este mensaje y continúe con su eliminación, para que podamos asegurarnos de que ese error no ocurra en el futuro.

    Libre de virus.www.avast.com
    by "Sandra Rodriguez" <sandra.rodriguez@jobfie.es> - 11:25 - 16 Sep 2025
  • Application for PSC Role – RMA Repository
    Dear contributors,

    I would like to apply for the PSC role for the RMA repository.

    Over the last months, I have been actively contributing to the RMA repository, working on several improvements to the base module to provide a more flexible and configurable workflow depending on the operation. I have also introduced new modules that add important features, such as RMA reasons, lot/serial number tracking, and I am currently working on the integration between RMA and the repair module.

    I believe I can contribute to maintaining and evolving this stack by reviewing, testing, and supporting new contributors.

    You can find my PRs here: https://github.com/OCA/rma/pulls/sbejaoui

    Best regards,

    --
    Souheil Bejaoui
    Software engineer


    Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
    Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
    Zone industrielle 22 | L-8287 Kehlen | Luxembourg
    by Souheil Bejaoui - 10:41 - 16 Sep 2025

    2 replies 2 replies

  • OCA Days 2025 Streaming

    Hi all,

    Here are the links to the OCA Days Streaming:

    odoocommunity1 => Mosane 5+6 
    odoocommunity2 => Mosane 2+3 
    odoocommunity3 => Mosane 7+8+9

    Here is the agenda: 

    Have a great day,
    Rebecca
    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 10:20 - 16 Sep 2025

    2 replies 2 replies

  • OCA AGA Delelgates Campaign open now - till October 3rd
    Hello OCA Contributors

    I hope this finds you all well.
    It is that time of year again for the OCA Annual General Assembly

    The 2025 OCA Delegates Campaign is now open. Until October 3rd, you can apply to be an OCA Delegate if you are a current paid Member.
    If you are already a Delegate, you don't need to apply again. This is for 10 new Delegates.

    Why?
    The Delegate Assembly is the Association’s supreme authority. Each Delegate member is entitled to one vote at the Delegate Assembly. Decisions of the Delegate Assembly are taken by a majority vote of the Delegate members present and voting. For further details, please read the Bylaws.

    How?
    To apply as a candidate, you have to:
    • sign the CLA (if not already done)
    • have a valid membership. Make sure to purchase your membership or renew it (you should have received a quotation for your renewal earlier this year).
    • fill in this survey
    If you aren't sure if you have renewed/paid your membership for 2025 please contact me.

    The campaign will be closed on October 3rd, 2025.

    Then what?
    The vote will be open from October 6th - October 17th. Current OCA Delegates will have to vote for 10 new Delegates among the candidates.

    The results of the election will be announced on October 20th, 2025.

    The 10 new Delegates will then take part with the existing Delegates in :
    • the 2025 OCA Board Member Campaign from October 20th - October 31st, 2025
    • the 2025 OCA Financial Auditor Campaign from October 20th - October 31st, 2025
    • the 2025 General Assembly from November 3rd to November 14th 2025.
    • 2025 Board announced - week beginning November 17th, 2025 
    If you have any questions please get in touch.

    Warmest regards,
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 11:25 - 15 Sep 2025
  • The Consultant Working Group is looking for you!

    Dear members,
    Did you know we have a working group for consultant / functional people?

    We are looking for new members in this group so if you are interested, please contact me (Julie) at julie@odoo-community.org.

    The “Raison d’être” of the group is to help and attract functional people (non-technical) to contribute to the OCA.

    Here are the requirements to be part of this group:
    - More than 3 years of experience with OCA tools (GitHub, Weblate…) and modules
    - More than 3 years of experience as a Consultant on Odoo
    - More than 3 years of experience with Odoo
    - Availability (1 wg meeting a month + 4h /month to contribute)
    - Approval from the majority of the actual members of the WG

    We will meet at the OCA Days on Monday morning so if you are interested, come and meet us (and contact me to let me know).

    P.S. In October, we will start a series of Support group meeting for functional / consultant so even if you don't meet the requirements to be part of the group, you can still attend these meetings.

    More info here : https://odoo-community.org/event/oca-consultants-support-group-session-2025-10-07-206/register

    by Julie LeBrun (OCA) - 10:21 - 13 Sep 2025

    2 replies 2 replies

    • Re: The Consultant Working Group is looking for you!
      Hello Michel,
      As discussed in person, the criterias are guides to ensure that people in the WG have enough experience in the OCA processes, tools and modules to help other people.  This experience needed is a functional one not a technical one. 

      I hope you understand better now.
      See you!

      Le lun. 15 sept. 2025 à 18:30, <mstroom@office-everywhere.com> a écrit :

      Dear Julie,

      I'm not sure why 3 years of experience is required for non-technical volunteer work in the 'Consultant / Functional Workgroup.' In my opinion, it's actually better for consultants not to have technical knowledge, and those with IT expertise can join other workgroups.

      What seems more important is finding people who are enthusiastic, willing to consistently contribute their free time, and committed to staying involved, even without compensation.

      Wishing you and the other Consultant / Functional Workgroup members the best in finding the right contributors. I also hope you’ll all consider dropping the 3-year Odoo experience requirement in favor of prioritizing commitment.

      Looking forward to seeing all OCA members at OCA Days 2025 in Liège.
      Let's have a drink next week, Julie. I’m also curious to hear why the workgroup is asking for 3 years of experience.


      Best, Michel.

      Office Everywhere
      Business Partner Odoo

      t: +31 6 53360677
      e: mstroom@office-everywhere.com
      w: Office-Everywhere.com


      On 2025-09-13 10:21, Julie LeBrun (OCA) wrote:

      Dear members,
      Did you know we have a working group for consultant / functional people?

      We are looking for new members in this group so if you are interested, please contact me (Julie) at julie@odoo-community.org.

      The "Raison d'être" of the group is to help and attract functional people (non-technical) to contribute to the OCA.

      Here are the requirements to be part of this group:
      - More than 3 years of experience with OCA tools (GitHub, Weblate...) and modules
      - More than 3 years of experience as a Consultant on Odoo
      - More than 3 years of experience with Odoo
      - Availability (1 wg meeting a month + 4h /month to contribute)
      - Approval from the majority of the actual members of the WG

      We will meet at the OCA Days on Monday morning so if you are interested, come and meet us (and contact me to let me know).

      P.S. In October, we will start a series of Support group meeting for functional / consultant so even if you don't meet the requirements to be part of the group, you can still attend these meetings.

      More info here : https://odoo-community.org/event/oca-consultants-support-group-session-2025-10-07-206/register

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



      --
      Julie LeBrun
      Content Creator & Training Manager
      by Julie LeBrun (OCA) - 02:56 - 17 Sep 2025
    • Re: The Consultant Working Group is looking for you!

      Dear Julie,

      I'm not sure why 3 years of experience is required for non-technical volunteer work in the 'Consultant / Functional Workgroup.' In my opinion, it's actually better for consultants not to have technical knowledge, and those with IT expertise can join other workgroups.

      What seems more important is finding people who are enthusiastic, willing to consistently contribute their free time, and committed to staying involved, even without compensation.

      Wishing you and the other Consultant / Functional Workgroup members the best in finding the right contributors. I also hope you’ll all consider dropping the 3-year Odoo experience requirement in favor of prioritizing commitment.

      Looking forward to seeing all OCA members at OCA Days 2025 in Liège.
      Let's have a drink next week, Julie. I’m also curious to hear why the workgroup is asking for 3 years of experience.


      Best, Michel.

      Office Everywhere
      Business Partner Odoo

      t: +31 6 53360677
      e: mstroom@office-everywhere.com
      w: Office-Everywhere.com


      On 2025-09-13 10:21, Julie LeBrun (OCA) wrote:

      Dear members,
      Did you know we have a working group for consultant / functional people?

      We are looking for new members in this group so if you are interested, please contact me (Julie) at julie@odoo-community.org.

      The "Raison d'être" of the group is to help and attract functional people (non-technical) to contribute to the OCA.

      Here are the requirements to be part of this group:
      - More than 3 years of experience with OCA tools (GitHub, Weblate...) and modules
      - More than 3 years of experience as a Consultant on Odoo
      - More than 3 years of experience with Odoo
      - Availability (1 wg meeting a month + 4h /month to contribute)
      - Approval from the majority of the actual members of the WG

      We will meet at the OCA Days on Monday morning so if you are interested, come and meet us (and contact me to let me know).

      P.S. In October, we will start a series of Support group meeting for functional / consultant so even if you don't meet the requirements to be part of the group, you can still attend these meetings.

      More info here : https://odoo-community.org/event/oca-consultants-support-group-session-2025-10-07-206/register

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

      by Michel Stroom - 06:30 - 15 Sep 2025
  • Request for Quotes: Improvement of the Odoo DB / sync with GitHub / New Frontend
    Hello,

    The OCA needs to improve its tools (backend and frontend) on Odoo Community Edition.

    Two RFQ's have been issued:

    One company can answer to both RFQ's.

    The RFQ process is described here:

    The deadline for submission has been extended to the 30th September.

    Please share it in your network of experts ;)
    Thanks!
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 05:51 - 12 Sep 2025

    1 replies 1 replies

  • Licence question: using AGPL and Odoo proprietary modules on the same server
    Hi,

    After years of only working on Odoo community, we are starting to have several enterprise clients.

    The OCA website at https://odoo-community.org/resources/faq indicates:

    Can I run OCA AGPL modules and closed source modules on the same instance?
    Yes, as long as closed source modules do not depend on AGPL ones and respect the license of its dependencies defined in the “depends” key of its manifest file (and vice versa).


    Will we be able to use AGPL modules and paid ones?

    Odoo projects will be able to use AGPL modules or paid modules under proprietary licenses, but it is not possible to combine both. Combining LGLPv3 modules and proprietary modules is fine however, so we encourage current owners licensing under AGPL to move to LGPLv3 too, in order to avoid complications for end users.

    My CEO believes that this using both AGPL and proprietary modules, even if they do not have dependencies, is not allowed by the AGPL license.
    I’ve searched a bit on the mailing list (that started in 2015) but I have not found no discussion on the subject.
    On what basis does the OCA position comes from?

    Regards,
    --
    Vincent Hatakeyama
    Directeur du pôle développement " Orbeet
    Tel +33 1 83 62 72 88 Email vincent.hatakeyama@orbeet.io
    Adresse 27, boulevard Saint-Martin
    75003 Paris         		Site web https://orbeet.io
    Image bannière
    by "Vincent Hatakeyama" <vincent.hatakeyama@orbeet.io> - 10:36 - 8 Sep 2025

    52 replies 52 replies

    • Re: Licence question: using AGPL and Odoo proprietary modules on the same server
      One last thing. IMO, throw away any ideas of dual licensing. That is the worst of all the discussion here. For 1 OCA, cannot do it imo, but for 2, Bradley Kuhn has spent the last 10 years chastising the relicense industry and how it is leading free software licensing to even more restrictive copyleft just to protect themselves from these unscrupulous actors hiding behind CLAs to defy authors wishes. And it is hard to disagree with him on this.

      Le dim. 14 sept. 2025, 09:05, Graeme Gellatly <graeme@moahub.nz> a écrit :
      Sorry on that point. Of course, whatever the original author decides.  There is only 3 realistic choices anyway.

      For me it is nearly always AGPL. I was not advocating OCA relicense to AGPL by any stretch, just encouraging its use and not to throw it away over some vendor FUD.

      Le dim. 14 sept. 2025, 08:37, Joël Grand-Guillaume <notifications@odoo-community.org> a écrit :
      Dear community,


      I strongly agree with Maxine here. The OCA accept any OSI compliant licences and since the begining it has always left the choice to the contributors among available ones.

      I invite you to read our FAQ under chapter licences & CLA: https://odoo-community.org/resources/faq

      It explains what's needed. If you feel there is something not clear enough or missing, please write your proposal to: support AT odoo-community.org

      Looking forward to meeting you in person at the OCA days, a good place to discuss it if you feel the need for it.

      Best regards,

      Joël 





      Le sam. 13 sept. 2025, 22:21, Maxime Chambreuil <notifications@odoo-community.org> a écrit :
      Hello,

      Since everybody is giving its opinion, here is mine.

      I think the license the contributor decides to put in the modules he is contributing to the OCA is his choice and should not be judged. We are a community, not a team or company. We don't necessarily share the same objectives and we don't necessarily aim for the same impact or result when contributing.

      The only thing the OCA should do on this topic is educate so contributors make the right choice reflecting their values in complete awareness of the pros and cons. A page or blog post on the oca website comparing the different licenses, with pros and cons, with correct/incorrect legal/illegal behavior.

      My 2 cents on the license. More to come on the contributions in the other thread later.

      Cheers
      --
      Maxime Chambreuil
      Desde mi móvil
      From: Raphaël Valyi <notifications@odoo-community.org>
      Sent: Saturday, September 13, 2025 6:36:58 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Licence question: using AGPL and Odoo proprietary modules on the same server
       
      Eventually we could create a simple OCA tutorial that would give an example use case where a company needs customizations that depend both on OCA AGPL and LGPL modules and need to protect some IP. We could give a few guidelines how to split the codebase between AGPL and LGPL derivatives.

      Obviously there would always be a grey area where people would carefully craft glue modules to action OCA AGPL code without explicitly depending on it.

      But eventually we could still cover the most obvious cases. This could help to:

      - limit the FUD about AGPL
      - incentivate more actors to publish what should be published

      Would it be risky for the OCA to publish such guidelines if a court finally interpret things differently? Should we officially cover the EE case as well?


      Finally about AGPL enforcement in general: one thing is the AGPL be violated by some final users. Just like piracy in general, it's hard to avoid indeed.

      But at least the AGPL should ideally protect us against massive violation by big SaaS players (because of the legal risks). Without such protection, a big actor (Odoo SA themselves?) would easily put all OCA modules authors out of business by creating superior private derivatives without any attribution, much like some open source editors complained GAFAM like companies created unfriendly forks of their products.

      Notice however that if the OCA starts selling double license exceptions, we will not even be sure we could name and shame or even sue some company who is obviously extending an OCA module without publishing it back. So I think it would just incentivate piracy, not a net positive for me...



      On Sat, Sep 13, 2025, 8:47 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:




>




> The simplest way is to just not accept the license and not propagate 




> the AGPL licensed work. As long as you are using it unmodified, there 




> is no requirement to accept. Clause 9 is quite clear. 




> Conveyance/propagation as a combined work is easily avoided.





-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      _______________________________________________
      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 - 11:16 - 13 Sep 2025
    • Re: Licence question: using AGPL and Odoo proprietary modules on the same server
      Sorry on that point. Of course, whatever the original author decides.  There is only 3 realistic choices anyway.

      For me it is nearly always AGPL. I was not advocating OCA relicense to AGPL by any stretch, just encouraging its use and not to throw it away over some vendor FUD.

      Le dim. 14 sept. 2025, 08:37, Joël Grand-Guillaume <notifications@odoo-community.org> a écrit :
      Dear community,


      I strongly agree with Maxine here. The OCA accept any OSI compliant licences and since the begining it has always left the choice to the contributors among available ones.

      I invite you to read our FAQ under chapter licences & CLA: https://odoo-community.org/resources/faq

      It explains what's needed. If you feel there is something not clear enough or missing, please write your proposal to: support AT odoo-community.org

      Looking forward to meeting you in person at the OCA days, a good place to discuss it if you feel the need for it.

      Best regards,

      Joël 





      Le sam. 13 sept. 2025, 22:21, Maxime Chambreuil <notifications@odoo-community.org> a écrit :
      Hello,

      Since everybody is giving its opinion, here is mine.

      I think the license the contributor decides to put in the modules he is contributing to the OCA is his choice and should not be judged. We are a community, not a team or company. We don't necessarily share the same objectives and we don't necessarily aim for the same impact or result when contributing.

      The only thing the OCA should do on this topic is educate so contributors make the right choice reflecting their values in complete awareness of the pros and cons. A page or blog post on the oca website comparing the different licenses, with pros and cons, with correct/incorrect legal/illegal behavior.

      My 2 cents on the license. More to come on the contributions in the other thread later.

      Cheers
      --
      Maxime Chambreuil
      Desde mi móvil
      From: Raphaël Valyi <notifications@odoo-community.org>
      Sent: Saturday, September 13, 2025 6:36:58 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Licence question: using AGPL and Odoo proprietary modules on the same server
       
      Eventually we could create a simple OCA tutorial that would give an example use case where a company needs customizations that depend both on OCA AGPL and LGPL modules and need to protect some IP. We could give a few guidelines how to split the codebase between AGPL and LGPL derivatives.

      Obviously there would always be a grey area where people would carefully craft glue modules to action OCA AGPL code without explicitly depending on it.

      But eventually we could still cover the most obvious cases. This could help to:

      - limit the FUD about AGPL
      - incentivate more actors to publish what should be published

      Would it be risky for the OCA to publish such guidelines if a court finally interpret things differently? Should we officially cover the EE case as well?


      Finally about AGPL enforcement in general: one thing is the AGPL be violated by some final users. Just like piracy in general, it's hard to avoid indeed.

      But at least the AGPL should ideally protect us against massive violation by big SaaS players (because of the legal risks). Without such protection, a big actor (Odoo SA themselves?) would easily put all OCA modules authors out of business by creating superior private derivatives without any attribution, much like some open source editors complained GAFAM like companies created unfriendly forks of their products.

      Notice however that if the OCA starts selling double license exceptions, we will not even be sure we could name and shame or even sue some company who is obviously extending an OCA module without publishing it back. So I think it would just incentivate piracy, not a net positive for me...



      On Sat, Sep 13, 2025, 8:47 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:




>




> The simplest way is to just not accept the license and not propagate 




> the AGPL licensed work. As long as you are using it unmodified, there 




> is no requirement to accept. Clause 9 is quite clear. 




> Conveyance/propagation as a combined work is easily avoided.





-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      _______________________________________________
      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 - 11:06 - 13 Sep 2025
    • Re: Licence question: using AGPL and Odoo proprietary modules on the same server
      I have zero time for what academics think, honestly. As for reddit, omg.  That whole thread was basically the 2009 Microsoft FUD parroted word for word with a bit of Oracle post Sun acquisition thrown in.

      Court cases and precedent are what matter. Public is a fairly precise definition in law and  the MS interpretation just defies belief. 

      I am 100% comfortable with where I sit, I know everybody disagrees with me here, and I am fine with it.






      Le sam. 13 sept. 2025, 23:47, Frederik Kramer <notifications@odoo-community.org> a écrit :
      Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:


>


> The simplest way is to just not accept the license and not propagate 


> the AGPL licensed work. As long as you are using it unmodified, there 


> is no requirement to accept. Clause 9 is quite clear. 


> Conveyance/propagation as a combined work is easily avoided.



-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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 - 11:01 - 13 Sep 2025
    • Re: Licence question: using AGPL and Odoo proprietary modules on the same server
      Dear community,


      I strongly agree with Maxine here. The OCA accept any OSI compliant licences and since the begining it has always left the choice to the contributors among available ones.

      I invite you to read our FAQ under chapter licences & CLA: https://odoo-community.org/resources/faq

      It explains what's needed. If you feel there is something not clear enough or missing, please write your proposal to: support AT odoo-community.org

      Looking forward to meeting you in person at the OCA days, a good place to discuss it if you feel the need for it.

      Best regards,

      Joël 





      Le sam. 13 sept. 2025, 22:21, Maxime Chambreuil <notifications@odoo-community.org> a écrit :
      Hello,

      Since everybody is giving its opinion, here is mine.

      I think the license the contributor decides to put in the modules he is contributing to the OCA is his choice and should not be judged. We are a community, not a team or company. We don't necessarily share the same objectives and we don't necessarily aim for the same impact or result when contributing.

      The only thing the OCA should do on this topic is educate so contributors make the right choice reflecting their values in complete awareness of the pros and cons. A page or blog post on the oca website comparing the different licenses, with pros and cons, with correct/incorrect legal/illegal behavior.

      My 2 cents on the license. More to come on the contributions in the other thread later.

      Cheers
      --
      Maxime Chambreuil
      Desde mi móvil
      From: Raphaël Valyi <notifications@odoo-community.org>
      Sent: Saturday, September 13, 2025 6:36:58 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Licence question: using AGPL and Odoo proprietary modules on the same server
       
      Eventually we could create a simple OCA tutorial that would give an example use case where a company needs customizations that depend both on OCA AGPL and LGPL modules and need to protect some IP. We could give a few guidelines how to split the codebase between AGPL and LGPL derivatives.

      Obviously there would always be a grey area where people would carefully craft glue modules to action OCA AGPL code without explicitly depending on it.

      But eventually we could still cover the most obvious cases. This could help to:

      - limit the FUD about AGPL
      - incentivate more actors to publish what should be published

      Would it be risky for the OCA to publish such guidelines if a court finally interpret things differently? Should we officially cover the EE case as well?


      Finally about AGPL enforcement in general: one thing is the AGPL be violated by some final users. Just like piracy in general, it's hard to avoid indeed.

      But at least the AGPL should ideally protect us against massive violation by big SaaS players (because of the legal risks). Without such protection, a big actor (Odoo SA themselves?) would easily put all OCA modules authors out of business by creating superior private derivatives without any attribution, much like some open source editors complained GAFAM like companies created unfriendly forks of their products.

      Notice however that if the OCA starts selling double license exceptions, we will not even be sure we could name and shame or even sue some company who is obviously extending an OCA module without publishing it back. So I think it would just incentivate piracy, not a net positive for me...



      On Sat, Sep 13, 2025, 8:47 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:



>



> The simplest way is to just not accept the license and not propagate 



> the AGPL licensed work. As long as you are using it unmodified, there 



> is no requirement to accept. Clause 9 is quite clear. 



> Conveyance/propagation as a combined work is easily avoided.




-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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 Joël Grand Guillaume - 10:36 - 13 Sep 2025
    • Re: Licence question: using AGPL and Odoo proprietary modules on the same server
      Hello,

      Since everybody is giving its opinion, here is mine.

      I think the license the contributor decides to put in the modules he is contributing to the OCA is his choice and should not be judged. We are a community, not a team or company. We don't necessarily share the same objectives and we don't necessarily aim for the same impact or result when contributing.

      The only thing the OCA should do on this topic is educate so contributors make the right choice reflecting their values in complete awareness of the pros and cons. A page or blog post on the oca website comparing the different licenses, with pros and cons, with correct/incorrect legal/illegal behavior.

      My 2 cents on the license. More to come on the contributions in the other thread later.

      Cheers
      --
      Maxime Chambreuil
      Desde mi móvil
      From: Raphaël Valyi <notifications@odoo-community.org>
      Sent: Saturday, September 13, 2025 6:36:58 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Licence question: using AGPL and Odoo proprietary modules on the same server
       
      Eventually we could create a simple OCA tutorial that would give an example use case where a company needs customizations that depend both on OCA AGPL and LGPL modules and need to protect some IP. We could give a few guidelines how to split the codebase between AGPL and LGPL derivatives.

      Obviously there would always be a grey area where people would carefully craft glue modules to action OCA AGPL code without explicitly depending on it.

      But eventually we could still cover the most obvious cases. This could help to:

      - limit the FUD about AGPL
      - incentivate more actors to publish what should be published

      Would it be risky for the OCA to publish such guidelines if a court finally interpret things differently? Should we officially cover the EE case as well?


      Finally about AGPL enforcement in general: one thing is the AGPL be violated by some final users. Just like piracy in general, it's hard to avoid indeed.

      But at least the AGPL should ideally protect us against massive violation by big SaaS players (because of the legal risks). Without such protection, a big actor (Odoo SA themselves?) would easily put all OCA modules authors out of business by creating superior private derivatives without any attribution, much like some open source editors complained GAFAM like companies created unfriendly forks of their products.

      Notice however that if the OCA starts selling double license exceptions, we will not even be sure we could name and shame or even sue some company who is obviously extending an OCA module without publishing it back. So I think it would just incentivate piracy, not a net positive for me...



      On Sat, Sep 13, 2025, 8:47 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:


>


> The simplest way is to just not accept the license and not propagate 


> the AGPL licensed work. As long as you are using it unmodified, there 


> is no requirement to accept. Clause 9 is quite clear. 


> Conveyance/propagation as a combined work is easily avoided.



-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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 - 10:21 - 13 Sep 2025

  • Sharepoint Integration

    Hello OCA Members,

     

    is there an oca app for sharepoint integration existing? I need an app where I can directly integrate sharepoint in odoo, without synchronize the data.

    This will be helpful.

    Thank you!

    Regards,

    Matthias

     

    Matthias Ellmerer

     

    signature_2198048941
    digitalisierung & software

     

    signature_95927516signature_3070776534signature_2920975368


    📍 Sonnendorf 33a, 6334 Schwoich | Austria
    📞 +43 664 353 87 33 · 🌐 implema.at  

     

    by Matthias Ellmerer - 08:36 - 5 Sep 2025

    4 attachments 4 attachments

    image004[20].png
    image003[62].png
    image002[27].png
    image001[79].png

    4 replies 4 replies

    • Re: Text Maintenance in Orders
      You can use base_comment_template and make a simple extension:

      Regards.
      by Pedro M. Baeza - 08:56 - 3 Dec 2025
    • Text Maintenance in Orders

      Hello OCA Members,

       

      before developing an text module, I will ask if there is still existing in the oca environment. In general I need a text module with pre defined text per products in different languages. Here in detail:

      • Creation of predefined text blocks for quotations and quotation templates per products.

      • Multilingual text modules must be supported (= 1 product, multiple languages)

      • Insertion of text modules into order lines like an internal note with the possibility to format the text.

      • Editing of text modules in the quotation via pop-up windows, also multilingual,

      • Transfer of texts from the quotation to the order(confirmation) and invoice.

       

      Thank you!

      Regards,

      Matthias

       

      Matthias Ellmerer

       

      signature_2198048941
      digitalisierung & software

       

      signature_95927516signature_3070776534signature_2920975368


      📍 Sonnendorf 33a, 6334 Schwoich | Austria
      📞 +43 664 353 87 33 · 🌐 implema.at  

       

      by Matthias Ellmerer - 11:25 - 30 Nov 2025

      4 attachments 4 attachments

      image004[20].png
      image003[62].png
      image002[27].png
      image001[79].png
    • Re: Sharepoint Integration
      Here it's a way to link an odoo record to a folder into sharepoint/msdrive https://github.com/OCA/storage/pull/481
      The widget allows you to manage the linked folder content from within odoo and directly jump into the msdrive/sharepoint UI if needed.
      A talk is planned at the OCA/Days to present this new addon and the base one referenced By Enric.
      Any help to improve or fund the investment we have made at ACSONE in these add-ons is welcome. If you need additional features, we can also discuss this and provide our assistance.

      Kind regards

      Laurent Mignon




      On Fri, Sep 5, 2025 at 8:37 AM Matthias Ellmerer <notifications@odoo-community.org> wrote:

      Hello OCA Members,

       

      is there an oca app for sharepoint integration existing? I need an app where I can directly integrate sharepoint in odoo, without synchronize the data.

      This will be helpful.

      Thank you!

      Regards,

      Matthias

       

      Matthias Ellmerer

       

      signature_2198048941
      digitalisierung & software

       

      signature_95927516signature_3070776534signature_2920975368


      📍 Sonnendorf 33a, 6334 Schwoich | Austria
      📞 +43 664 353 87 33 · 🌐 implema.at  

       

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



      --
      Laurent Mignon
      Technical lead / Management Team
      T: +32 2 8883148


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

      by Laurent Mignon - 09:15 - 5 Sep 2025
    • Re: Sharepoint Integration
      Check this



      We were involved in the base module and I think Acsone might publish the sharepoint integration

      Kind regards,

      Enric Tobella Alomar
      CEO & Founder


      On Fri, 5 Sept 2025, 08:37 Matthias Ellmerer, <notifications@odoo-community.org> wrote:

      Hello OCA Members,

       

      is there an oca app for sharepoint integration existing? I need an app where I can directly integrate sharepoint in odoo, without synchronize the data.

      This will be helpful.

      Thank you!

      Regards,

      Matthias

       

      Matthias Ellmerer

       

      signature_2198048941
      digitalisierung & software

       

      signature_95927516signature_3070776534signature_2920975368


      📍 Sonnendorf 33a, 6334 Schwoich | Austria
      📞 +43 664 353 87 33 · 🌐 implema.at  

       

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

      by Enric Tobella Alomar - 08:45 - 5 Sep 2025
  • Seeking Advice on Handling Customs Duties in Odoo ERP for International Procurement in China

    Dear OCA Community,

    I hope this message finds you well. I am writing to seek your guidance and advice regarding the handling of customs duties in Odoo ERP for international procurement operations in China.

    Here is a brief overview of our business scenario:

    Customs Duties in China

    We encounter two types of customs duties, both denominated in CNY (Chinese Yuan):

    1. Price-based duty: Calculated as unit price × exchange rate × duty rate (e.g., 10%).

    2. Quantity-based duty: Calculated as a fixed amount per unit, such as ¥800 per ton.

    International Procurement

    We import goods from other countries into China. The procurement currency is USD, but customs duties must be paid in CNY.

    Sales Operations

    For some sales orders, we quote prices in USD and collect both the(product value) and(customs duties and VAT) from customers separately.

    Challenges We Face

    • Odoo’s tax calculation does not account for multi-currency scenarios, so we have not configured customs duties as taxes on products.

    • Since customs duties are collected in CNY while our procurement and sales are in USD, we are unable to reflect duties accurately on purchase or sales orders.

    • In procurement, we make payments to suppliers (in USD) and to customs (in CNY). Currently, we manually create bills for customs duties and calculate the amounts.

    • In sales, we need to collect both the product value and duties from customers in CNY, and we also manually calculate the duty amounts on invoices.

    We would greatly appreciate any suggestions or insights from the community on how to effectively handle these challenges in Odoo. Specifically:

    1. Is there a recommended way to configure customs duties in Odoo to support multi-currency scenarios?

    2. How can we automate the calculation and recording of customs duties for both procurement and sales operations?

    3. Are there any existing modules or workflows within Odoo or the OCA ecosystem that could address these requirements?

    Thank you in advance for your time and support. We look forward to your valuable feedback and ideas.

    Best regards,



    feihu.zhang

    feihu.zhang@live.com

    by feihu.zhang - 04:46 - 5 Sep 2025

    2 replies 2 replies

    • Re: Seeking Advice on Handling Customs Duties in Odoo ERP for International Procurement in China
      If I'm not missing any details, this should be out of the box:
      • These duties can be configured as Taxes on the invoice.
      • Odoo does account for multicurrency. The USD invoice amount is converted to CNY. The duties would be computed in USD, but would then be converted to USD in your accounting records, and you will use those CNY amount to pay the taxes.
      • At best, you need a UX customization to also display the CNY converted amounts in your documents.

      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]


      On 9/5/2025 3:47 AM, 张 飞虎 wrote:

      Dear OCA Community,

      I hope this message finds you well. I am writing to seek your guidance and advice regarding the handling of customs duties in Odoo ERP for international procurement operations in China.

      Here is a brief overview of our business scenario:

      Customs Duties in China

      We encounter two types of customs duties, both denominated in CNY (Chinese Yuan):

      1. Price-based duty: Calculated as unit price × exchange rate × duty rate (e.g., 10%).

      2. Quantity-based duty: Calculated as a fixed amount per unit, such as ¥800 per ton.

      International Procurement

      We import goods from other countries into China. The procurement currency is USD, but customs duties must be paid in CNY.

      Sales Operations

      For some sales orders, we quote prices in USD and collect both the(product value) and(customs duties and VAT) from customers separately.

      Challenges We Face

      • Odoo’s tax calculation does not account for multi-currency scenarios, so we have not configured customs duties as taxes on products.

      • Since customs duties are collected in CNY while our procurement and sales are in USD, we are unable to reflect duties accurately on purchase or sales orders.

      • In procurement, we make payments to suppliers (in USD) and to customs (in CNY). Currently, we manually create bills for customs duties and calculate the amounts.

      • In sales, we need to collect both the product value and duties from customers in CNY, and we also manually calculate the duty amounts on invoices.

      We would greatly appreciate any suggestions or insights from the community on how to effectively handle these challenges in Odoo. Specifically:

      1. Is there a recommended way to configure customs duties in Odoo to support multi-currency scenarios?

      2. How can we automate the calculation and recording of customs duties for both procurement and sales operations?

      3. Are there any existing modules or workflows within Odoo or the OCA ecosystem that could address these requirements?

      Thank you in advance for your time and support. We look forward to your valuable feedback and ideas.

      Best regards,



      feihu.zhang

      feihu.zhang@live.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 Daniel Reis - 05:56 - 5 Sep 2025
    • Re: Seeking Advice on Handling Customs Duties in Odoo ERP for International Procurement in China
      Hello:

      I understand that the goal is to automate the calculation of customs duties and properly manage multi-currency scenarios, which involves a dynamic daily update of the exchange rates between currencies. This update would generate automatic accounting adjustments for each transaction, which seems like a suitable solution. Furthermore, each customs-related transaction should be customized based on specific duty rules, which can vary by customs type (price or quantity).

      This customization should also be dynamic, as duties can change over time, which means customs configurations must be flexible and adaptable. It is essential that this customs payment process be properly validated to ensure accuracy in the accounting records.

      My question is whether it would be best to include customs duties within a single document or invoice, or if it would be preferable to do so separately to ensure better traceability and control of each customs transaction. Since in this case the import payment is made in dollars, I would suggest reflecting the import payment in a separate document, and a separate document for the customs duty payment, which is made in yuan. This would be my suggestion, as separating both payments into separate documents would facilitate traceability and control of each transaction, allowing for clear monitoring of the costs associated with the import and customs duties.

      If I recall correctly. I haven't seen a dedicated module that provides this required functionality.

      Regards

      El jue, 4 sept 2025 a las 21:47, 张 飞虎 (<notifications@odoo-community.org>) escribió:

      Dear OCA Community,

      I hope this message finds you well. I am writing to seek your guidance and advice regarding the handling of customs duties in Odoo ERP for international procurement operations in China.

      Here is a brief overview of our business scenario:

      Customs Duties in China

      We encounter two types of customs duties, both denominated in CNY (Chinese Yuan):

      1. Price-based duty: Calculated as unit price × exchange rate × duty rate (e.g., 10%).

      2. Quantity-based duty: Calculated as a fixed amount per unit, such as ¥800 per ton.

      International Procurement

      We import goods from other countries into China. The procurement currency is USD, but customs duties must be paid in CNY.

      Sales Operations

      For some sales orders, we quote prices in USD and collect both the(product value) and(customs duties and VAT) from customers separately.

      Challenges We Face

      • Odoo’s tax calculation does not account for multi-currency scenarios, so we have not configured customs duties as taxes on products.

      • Since customs duties are collected in CNY while our procurement and sales are in USD, we are unable to reflect duties accurately on purchase or sales orders.

      • In procurement, we make payments to suppliers (in USD) and to customs (in CNY). Currently, we manually create bills for customs duties and calculate the amounts.

      • In sales, we need to collect both the product value and duties from customers in CNY, and we also manually calculate the duty amounts on invoices.

      We would greatly appreciate any suggestions or insights from the community on how to effectively handle these challenges in Odoo. Specifically:

      1. Is there a recommended way to configure customs duties in Odoo to support multi-currency scenarios?

      2. How can we automate the calculation and recording of customs duties for both procurement and sales operations?

      3. Are there any existing modules or workflows within Odoo or the OCA ecosystem that could address these requirements?

      Thank you in advance for your time and support. We look forward to your valuable feedback and ideas.

      Best regards,



      feihu.zhang

      feihu.zhang@live.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 DANIEL CARRION - 05:46 - 5 Sep 2025
  • Last chance to register to the OCA Days in-person training!

    The OCA Days are coming fast! Registrations for the in-person training will close next Wednesday September 10, 2025.
    Don't miss this opportunity!

    Registration : https://odoo-community.org/event/oca-days-2025-liege-2025-09-15-2025-09-17-174/register

    20% discount for OCA members.

    by Julie LeBrun (OCA) - 04:57 - 4 Sep 2025

    4 attachments 4 attachments

    OCA Days 2025 Training - Runboat.png
    OCA Days 2025 Training - OpenUpgrade.png
    OCA Days 2025 Training - Customer Project.png
    OCA Days 2025 Training - MIS Builder.png
  • py3o reporting engine
    I worked on the py3o reporting engine last week (modules report_py3o and report_py3o_fusion_server from https://github.com/OCA/reporting-engine), and managed to implement a new version of report_py3o_fusion_server that works with a direct link between Odoo and libreoffice running as a daemon via the UNO interface. This implementation by-passes py3o-fusion and py3o-renderserver, which are 2 deprecated software components that are still in python2. I have already deployed it in production on 2 odoo servers. The limitation of this implementation is that it only works when libreoffice is running on the same server as Odoo (running as daemon in headless mode) whereas py3o-fusion and py3o-renderserver allowed to have libreoffice running on another server than Odoo.

    It is available as a draft pull request here :


    On this draft PR, I have detailed my ideas for the future of the report_py3o* modules, and how we could implement a solution that allows to have libreoffice running on another server than Odoo. If you are using report_py3o and feel concerned about the future of this project, please come on this draft pull request to read my ideas for the future and give your opinion about it !

    --
    Alexis de Lattre
    by Alexis de Lattre - 06:16 - 2 Sep 2025
  • Multi-Company + Website Issue
    Hi everyone,

    I'm reaching out to get some insights from the community on a multi-company scenario we're running into with Odoo.

    The Issue:
    We have a setup where multiple companies share the same website. Odoo currently ties a website to a single company, which is fine for pricing (we use GeoIP to show region-specific pricelists). But when a customer places an order, Odoo assigns that order to the company linked to the website, not necessarily the customer's regional company.

    Example:
    A US customer sees US pricing, but the order still gets created under the LATAM company because that's how the website is configured. This leads to accounting and operational misalignment.

    Any guidance, existing OCA modules, or suggestions on how to approach this would be greatly appreciated. If there's interest, I'd also be happy to help spec out a solution we will contribute back to the community.

    Best regards,

    Binhex Logo
    Jorge Elena Poblet
    Founder & CEO
    Binhex
    j.elena@binhex.cloud
    Office (Spain) : +34 622 40 08 08
    Office (USA): +1 561 403 4406
    Offices:
    Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
    Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
    Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
    Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
    LinkedIn Twitter Facebook YouTube
    Start for free: Try Odoo Community in the cloud

    This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
    Privacy Policy
    by Jorge Elena Poblet - 10:41 - 29 Aug 2025