Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: AW: BI and reporting tools
    I am interested in using BI to help with decision-making on in-process inventory.  There are industrial processes where materials are kept in process for a period of time to all maturation (winemaking, food processing, crystal growing, and many other things.  Sometimes you can use a very deterministic recipe, but more often than not, you have a range of outcomes to plan for.  I would like to use the Odoo data record (registered in Mfg Orders) to build a body of knowledge linked to history by product and product family to help users manage rough cut planning and refine recipes.  Ultimately, I would like to use the past MO data for analysis and as a reference in real time.  This was a hot topic for leveraging SAP HANA, but I left the SAP ecosystem before I could see that in practice (to the extent that something happened with the idea.)

    I like the idea of putting the datasets in Postgres since most of my implementations are quite small-scale, and I am thinking it would be easier to reuse a focused decision-support dataset via an Odoo custom model.

    Any thoughts?





    On Thu, Apr 17, 2025 at 5:38 AM Victor Champonnois <notifications@odoo-community.org> wrote:

    Thank you for your replies, I will have a look at Metabase.

    Thank you also for the tips about foreign data wrapper and Metabase models. Real time reporting is indeed an important feature.

    Have a nice day,

    Victor Champonnois - Coop IT Easy
    On 16/04/25 10:47, David Brühlmeier wrote:
    Hi Victor,

    We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.

    In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.

    Hope this helps!
    Dave



    Von: Victor Champonnois <notifications@odoo-community.org>
    Gesendet: Mittwoch, 16. April 2025 10:32
    An: Contributors <contributors@odoo-community.org>
    Betreff: BI and reporting tools
     

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy

    _______________________________________________
    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 joel.patrick - 04:10 - 17 Apr 2025
  • Re: AW: BI and reporting tools

    Thank you for your replies, I will have a look at Metabase.

    Thank you also for the tips about foreign data wrapper and Metabase models. Real time reporting is indeed an important feature.

    Have a nice day,

    Victor Champonnois - Coop IT Easy
    On 16/04/25 10:47, David Brühlmeier wrote:
    Hi Victor,

    We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.

    In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.

    Hope this helps!
    Dave



    Von: Victor Champonnois <notifications@odoo-community.org>
    Gesendet: Mittwoch, 16. April 2025 10:32
    An: Contributors <contributors@odoo-community.org>
    Betreff: BI and reporting tools
     

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy

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

    by Victor - 11:36 - 17 Apr 2025
  • Re: BI and reporting tools
    Hi Victor,

    On a related issue I wish WilldooIT had carried on developing the Odoo Pentaho module.

    Regards,
    Bill

    From: Victor Champonnois <notifications@odoo-community.org>
    Sent: 16 April 2025 10:32
    To: Contributors <contributors@odoo-community.org>
    Subject: BI and reporting tools
     

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy

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

    by Bill Made - 10:45 - 17 Apr 2025
  • Re: AW: BI and reporting tools

    We also Use Metabase for some of our projects, which works nicely.

    We do a daily replication of the database, to not disturb operations, and provide end users with pre defined models for the Odoo database.


    Op 16-04-2025 om 10:47 schreef David Brühlmeier:
    In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.
    --
    Met vriendelijke groet - Kind Regards - Mit freundlichen Grüßen,

    Thomas Pot

    Open2Bizz B.V. dé Odoo specialist

    https://www.open2bizz.nl
    https://care-software.com

    Mauritslaan 56 | 6161 HW | Geleen (NL)

    Maak meteen een afspraak voor een online demo van Odoo / Care-Software:
    klik hier

    LinkedIn Connectie maken
    by Thomas Pot - 12:21 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests.  Although maybe there is a better way we can do that.

    merges:
        - origin $ODOO_VERSION
        # Can't merge 1439 at the moment because of this
        # test-requirements.txt commit:
        # befd64bd07aaa293026b648bc06494d6f1b466fc
        #- origin refs/pull/1438/head # 'account_payment_mode'
        #- origin refs/pull/1439/head # 'account_payment_partner'
        #- origin refs/pull/1440/head # 'account_payment_order'

    On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
    I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:

    - The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
    - The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
    - It contains a lot of datamodel changes apart from the main question, which are the same problematic.

    And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...

    I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.

    Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.

    Regards.

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

    by Graeme Gellatly - 11:06 - 16 Apr 2025
  • AW: BI and reporting tools
    Hi Victor,

    We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.

    In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.

    Hope this helps!
    Dave



    Von: Victor Champonnois <notifications@odoo-community.org>
    Gesendet: Mittwoch, 16. April 2025 10:32
    An: Contributors <contributors@odoo-community.org>
    Betreff: BI and reporting tools
     

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy

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


    by David Brühlmeier - 10:46 - 16 Apr 2025
  • Re: BI and reporting tools

    Some of our customers use PowerBI themselves, connected via ODBC to the database.

    On 4/16/25 10:32, Victor Champonnois wrote:

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy

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

    by Tom Blauwendraat - 10:45 - 16 Apr 2025
  • BI and reporting tools

    Hi,

    I am researching different ways to do BI (business intelligence) and reporting with Odoo.

    I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database. 

    On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).

    I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.

    I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?

    The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.

    Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?

    If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?

    Thank you for your inputs !

    -- 
Victor Champonnois - Coop IT Easy
    by Victor - 10:32 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:

    - The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
    - The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
    - It contains a lot of datamodel changes apart from the main question, which are the same problematic.

    And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...

    I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.

    Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.

    Regards.

    by Pedro M. Baeza - 09:22 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    Well, I attended the meeting (I lost last 10 minutes only) and I have a different opinion on some of the results.

    About the first point of the meeting, Pedro expressed his concerns on how Alexis acts as PSC (disappearing for months without answering direct questions and so on). In my opinion, this is not happening on Banking only, but right now it is not a problem. Even Alexis confirmed that he acts this way. Also, Pedro felt that trusting in this change as Alexis might disappear again leaving the problems for other people. Alexis was unable to confirm his future implication on the project and expected changes. As Banking PSC, this is a risk that we shouldn't take.

    About the part of quality of the code. It is not clear that current code is not as good as new one. At the end this is an opinion of Alexis and Pedro has a different opinion about it. However, Pedro was open to changes on the code if Alexis proposes them. On a personal perspective, I will give priority to this kind of PRs.

    There was also a relevant point. By using Alexis fork as base, we have lost history of changes and contributors that made changes on these modules. This shouldn't happen. We should keep contributor history.

    Also, it is clear that the main changes proposed are not "native". If we check Odoo Commits, it is clear that this fields are only to prefill the account.payment when created from the wizard. Nothing more. You can see the commit that created these fields.


    We can try to guess what Odoo will do in the next years, but right now, it is clear that this is not the expected usage. I would not recommend to use this because it is clear that it is not the "native" use of the code. We are making use of an opinionated view of a model that has nothing to do with the original goal of the model according to odoo commits.

    So, I think we should not call it native as we are using something that can be confusing for users. They will see account_payment_order and account_payment_order_native. Without this information, they will use the native one, as the name seems better, but as I expresed, it is not native as the native use of this is different.

    Kind regards,

    El mié, 16 abr 2025 a las 1:17, Graeme Gellatly (<notifications@odoo-community.org>) escribió:
    For me I think this is perhaps not the optimal way. It will become a nightmare as things converge, doing migrations etc for the average user. I would personally feel better if the modules were not renamed and we created say a 18.0-experimental (or future or native or whatever name) branch in the existing repo which is kept synced with 18.0 except these modules.

    On Wed, Apr 16, 2025 at 10:22 AM Alexis de Lattre <notifications@odoo-community.org> wrote:
    Thanks Virginie for your summary of Friday's meeting.

    In the end, I think there is user demand for both solutions:
    - Pedro's proposal, which is more conservative with focus on stability of the code and stability of the datamodel,
    - my proposal, which is more "bleeding-edge" with focus on innovation and adopting the latest datamodel of Odoo SA, with re-write of large parts of the OCA/bank-payment code base.
    I think OCA could host both solutions, with a perspective for re-unification in v19+ if the community that continued with the account.payment.mode object decides to switch to the native datamodel.
    In fact, one of the numerous improvements that I proposed in my "revolution" PR for v16.0 (https://github.com/OCA/bank-payment/pull/1174) has been adopted in OCA/bank-payment v16: support the "in_payment" status on invoices ; it is a good example that my revolution PR also benefits to the official 16.0 branch.

    During Friday's meeting, I also noticed the difference of judgement on the current code quality of OCA/bank-payment: I personally think that the quality of the current code is pretty poor ; Pedro didn't share my concern on this. The consequence is that, for me, a (partial) re-write of OCA/bank-payment was really needed ; that's what I did in my revolution PR for v16. I can understand that re-writing OCA/bank-payment can raise fears and worries for stability and that some users may prefer to delay the adoption. But I know other OCA devs share my concern about the need for a big cleanup/re-write of OCA/bank-payment and support my v16 revolution PR.

    So my proposal is the following: create a new OCA project called bank-payment-native (feel free to propose a better name) with a 18.0 branch that will host my 18.0 migration PRs. To avoid naming conflicts, I would rename the modules:
    - account_payment_order => account_payment_order_native
    - account_banking_pain_base => account_payment_sepa_base (or account_payment_iso20022_base ?)
    - account_banking_sepa_direct_debit => account_payment_sepa_direct_debit (or account_payment_iso20022_direct_debit ?)
    - account_banking_sepa_credit_transfer => account_payment_sepa_credit_transfer (or account_payment_iso20022_credit_transfer ?)
    - account_banking_mandate => account_payment_mandate
    - account_banking_mandate_sale => account_payment_mandate_sale
    - account_payment_sale => account_payment_sale_native
    The modules account_payment_mode and account_payment_partner are already replaced by a single module account_payment_base_oca in my v18 migration PR.
    Again, feel free to propose better module names.

    My proposal to create a new OCA bank-payment project may seem a bit extreme because this has never happened before in OCA. But, on the other side, the alternative proposal to keep account.payment.mode involves hiding 3 native fields of the "account" module (2 native fields on res.partner "property_outbound_payment_method_line_id" & "property_inbound_payment_method_line_id" and 1 native field on account.move "preferred_payment_method_line_id"), which also never happened before in OCA AFAIK.

    I think the OCA Banking PSC (https://odoo-community.org/psc-teams/banking-10) should decide in the coming days if they agree with the creation of this new OCA project "bank-payment-native" or not (I talked about this with Virginie Dewulf today and she also thinks that it is the role of the Banking PSC to take this decision).

    Regards,

    Alexis

    Le mar. 15 avr. 2025 à 10:43, Virginie Dewulf <virginie@odoo-community.org> a écrit :
    Hello everyone,

    Last Friday, we had a meeting with Alexis, Pedro, a few PSC of bank project and with Benoit Guillot and Denis Roussel who are Board members and part of the new "Community Health" Working group.

    Thanks a lot to those who came and in particular to Alexis and Pedro for the constructive discussion on a Friday night!

    We could clarify different aspects:

    1/ a part linked to the expected behavior of a maintainer of a module (mainly stick around, answer to other's reviews and follow up of "his" modules and PRs...) which was a part of the discussion in this emails thread. There is no concrete outcome on this topic: it was about sharing feelings and fears of maintaining something done by another and not getting the expected support for it afterwards.

    2/ the almost philosophical question about "how to make big changes and refactors inside the OCA code?". 
    We agreed that it is accepted to make one PR changing code on various modules. The only constraint is that one PR must make sense on its whole and should ideally not change various aspects/logics at once. The goal of this is to make the work of reviewers easier: they should be able to understand why the changes occur and how they are implemented. We agreed that there is a part of subjectivity here as well but we encourage people to work in a logical way as much as possible when creating new PR's, as well as making meaningful commits. However when there are huge refactors, having one commit per change is not always easy (you change something in commit 4 then change it again in commit 6 together with another thing, it is really more R&D). In this case it is not meaningful to review the PR commit per commit, but it is best to review the final outcome as a whole. 
    ==> I encourage authors to clarify how they expect the reviewers to do their job and make their life as easy as possible.

    3/ on the bank payment topic now:
    * Alexis' proposal [3] will most certainly offer an improved code quality as a whole and is normally keeping all current features as is (with light changes in the user interface, like a menu will change place but nothing crazy, as we work with Odoo where this happens a lot)

    * The way the PR's has been done make it hard for reviewers to make sure everything will be kept as is, no issue is introduced etc. It is thus hard to make a quick review on this on version 18.

    * As the current version of the code is (almost) ready in v18 [3] based on Tecnativa's migration work, this version could be merged into v18 right now (wait for the last point of this email though).

    * However, in Alexis' refactor, there is a full refactor of the XML generation that can be included in v18 (no impact on the screens or the features for the end-users, and it is a separated part easy to review). Pedro proposed to work on that together with Alexis and have it integrated in version 18 (even in v16 if requested).

    * In Alexis' refactor, the refactor includes the use of standard Odoo field. In the OCA history, we usually use the standard fields as much as possible. However it is also risky as we don't know if Odoo will change the way it is used/coded in the following version (well, this is our daily life, right?!). 
    As for this specific case, it is really not clear why Odoo decided to use those fields (the feature doesn't look finished [2]), it might be even riskier to use them from version 18.
    => Alexis would like to get internal Odoo accounting team's insight about their intention on this fields.
    => Pedro will action his network to get an answer on that

    * Based on Odoo's intention regarding the fields in question, Pedro and Alexis will work on Alexis' refactor to have it finalized and reviewed for version 19, so that only one stronger solution is kept inside the OCA. 

    (Indeed, there is no urgency on Alexis' side to have the big refactored code and improvements in v18 merged into OCA code -- he wanted to have a better version of this existing module as a final purpose, whatever the version.)

    Conclusion
    We ended the meeting with this last idea, on which Alexis would reflect and decide if he agrees to proceed this way. We agreed that we are waiting for his answer's by this Friday the 18th April.

    And finally, we also mentioned the next Spanish OCA Days where Alexis and Pedro could start working on the v19 common option, if we go into this direction.

    For those interested to join this event, here are the info, from 2nd to 4th June 2025, in Cartagena (Murcie, Spain):
    (I'll be there and I hope to see you there as well!)

    References:
    [1] PR for migration to 18 for account payment mode https://github.com/OCA/bank-payment/pull/1438, the one for account payment partner https://github.com/OCA/bank-payment/pull/1439
    [3] Alexis' refactor proposition

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le lun. 14 avr. 2025 à 22:22, Akim Juillerat <notifications@odoo-community.org> a écrit :
    Hello

    The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

    I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

    Best regards

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Akim Juillerat
    Business solutions
    Software architect
    +41 62 544 03 78

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10


    On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
    Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:






> Hello contributors,






> Thanks for sharing your opinions on this important topic.






> *Proposed next steps:* A






> continuous chain of emails won't help to find a common solution. With






> the "Community Health" WG, I propose to organize an online meeting with






> the concerned parties to find a way towards an agreement. Luc's






> suggestion of having a few days together is a good one, if there is no






> agreement online. The Spanish Odoo Days will be held in June soon: this






> could be a good opportunity.






> The result of the meeting will be shared in this thread to keep a public track of the conversation.






> *A reminder of our intention as a community* We






> are all on the same team, trying to find an open source way in the Odoo






> ecosystem that changes every year. I sometimes picture Odoo S.A. as a






> big and super fast boat on the sea of ERPs. The OCA is a gathering of






> hundreds of small little sailboat (=our PSC teams responsible for






> managing several repos), trying to follow the wind and stay together as






> much as possible. But it is sometimes really hard and chaotic (like with






> the account apocalypse in v13).






> *The underlying problematic of this discussion* Here






> we have an important question: who is the captain of this specific






> sailboat? As each part of the sailboat has been built by a different






> contributor and sometimes taken care for several years by another, who






> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?






> This is the






> question that we will need to answer as a community, because those






> discussions happened in the past and will continue to arise. And to not






> loose our time and energy on fighting between each others, we will need






> proper governance guidelines on this.






> This will be a task for the






> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn






> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).






> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20






> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :






> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.






> https://github.com/OCA/bank-payment/graphs/contributors [4]






> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:






> User






> Created PRs






> Merged PRs






> Comments






> Reviews






> OCI






> pedrobaeza






> 49






> 49






> 776






> 539






> 623






> victoralmau






> 72






> 68






> 38






> 64






> 147






> HaraldPanten






> -






> -






> 93






> 80






> 90






> alexis-via






> 41






> 22






> 84






> 48






> 86






> carlosdauden






> 9






> 8






> 12






> 60






> 74






> ValentinVinagre






> 5






> 5






> 40






> 49






> 63






> sergio-teruel






> 5






> 4






> 11






> 35






> 45






> luc-demeyer






> 26






> 14






> 38






> 15






> 40






> joao-p-marques






> 12






> 12






> 19






> 18






> 38






> etobella






> 16






> 15






> 14






> 12






> 35






> ramiadavid






> 11






> 10






> 9






> 19






> 35






> Tisho99






> 15






> 15






> 24






> 10






> 34






> MiquelRForgeFlow






> 12






> 11






> 16






> 15






> 33






> rousseldenis






> 7






> 4






> 28






> 19






> 31






> StefanRijnhart






> 5






> 4






> 20






> 20






> 31






> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.






> Kind regards,






> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:






> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.






> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.






> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.






> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.






> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.






> Best regards,






> -Stéphane






> _______________________________________________






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






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






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






> 






> --






> *Enric Tobella Alomar* CEO & Founder






> www.dixmit.com [11]






> _______________________________________________






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






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






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






> 






> 






> _______________________________________________






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






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






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






> 






> 






> 






> [1] https://odoo-community.org/about/psc-guide






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






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






> [4] https://github.com/OCA/bank-payment/graphs/contributors






> [5] mailto:notifications@odoo-community.org






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






> [7] https://github.com/OCA/bank-payment/pull/1439






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






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






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






> [11] http://www.dixmit.com






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






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






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






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






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






> 

mit freundlichen Grüßen,
Peter Niederlag






-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

    _______________________________________________
    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

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



    --
    Enric Tobella Alomar
    CEO & Founder

    by Enric Tobella Alomar - 09:11 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    For me I think this is perhaps not the optimal way. It will become a nightmare as things converge, doing migrations etc for the average user. I would personally feel better if the modules were not renamed and we created say a 18.0-experimental (or future or native or whatever name) branch in the existing repo which is kept synced with 18.0 except these modules.

    On Wed, Apr 16, 2025 at 10:22 AM Alexis de Lattre <notifications@odoo-community.org> wrote:
    Thanks Virginie for your summary of Friday's meeting.

    In the end, I think there is user demand for both solutions:
    - Pedro's proposal, which is more conservative with focus on stability of the code and stability of the datamodel,
    - my proposal, which is more "bleeding-edge" with focus on innovation and adopting the latest datamodel of Odoo SA, with re-write of large parts of the OCA/bank-payment code base.
    I think OCA could host both solutions, with a perspective for re-unification in v19+ if the community that continued with the account.payment.mode object decides to switch to the native datamodel.
    In fact, one of the numerous improvements that I proposed in my "revolution" PR for v16.0 (https://github.com/OCA/bank-payment/pull/1174) has been adopted in OCA/bank-payment v16: support the "in_payment" status on invoices ; it is a good example that my revolution PR also benefits to the official 16.0 branch.

    During Friday's meeting, I also noticed the difference of judgement on the current code quality of OCA/bank-payment: I personally think that the quality of the current code is pretty poor ; Pedro didn't share my concern on this. The consequence is that, for me, a (partial) re-write of OCA/bank-payment was really needed ; that's what I did in my revolution PR for v16. I can understand that re-writing OCA/bank-payment can raise fears and worries for stability and that some users may prefer to delay the adoption. But I know other OCA devs share my concern about the need for a big cleanup/re-write of OCA/bank-payment and support my v16 revolution PR.

    So my proposal is the following: create a new OCA project called bank-payment-native (feel free to propose a better name) with a 18.0 branch that will host my 18.0 migration PRs. To avoid naming conflicts, I would rename the modules:
    - account_payment_order => account_payment_order_native
    - account_banking_pain_base => account_payment_sepa_base (or account_payment_iso20022_base ?)
    - account_banking_sepa_direct_debit => account_payment_sepa_direct_debit (or account_payment_iso20022_direct_debit ?)
    - account_banking_sepa_credit_transfer => account_payment_sepa_credit_transfer (or account_payment_iso20022_credit_transfer ?)
    - account_banking_mandate => account_payment_mandate
    - account_banking_mandate_sale => account_payment_mandate_sale
    - account_payment_sale => account_payment_sale_native
    The modules account_payment_mode and account_payment_partner are already replaced by a single module account_payment_base_oca in my v18 migration PR.
    Again, feel free to propose better module names.

    My proposal to create a new OCA bank-payment project may seem a bit extreme because this has never happened before in OCA. But, on the other side, the alternative proposal to keep account.payment.mode involves hiding 3 native fields of the "account" module (2 native fields on res.partner "property_outbound_payment_method_line_id" & "property_inbound_payment_method_line_id" and 1 native field on account.move "preferred_payment_method_line_id"), which also never happened before in OCA AFAIK.

    I think the OCA Banking PSC (https://odoo-community.org/psc-teams/banking-10) should decide in the coming days if they agree with the creation of this new OCA project "bank-payment-native" or not (I talked about this with Virginie Dewulf today and she also thinks that it is the role of the Banking PSC to take this decision).

    Regards,

    Alexis

    Le mar. 15 avr. 2025 à 10:43, Virginie Dewulf <virginie@odoo-community.org> a écrit :
    Hello everyone,

    Last Friday, we had a meeting with Alexis, Pedro, a few PSC of bank project and with Benoit Guillot and Denis Roussel who are Board members and part of the new "Community Health" Working group.

    Thanks a lot to those who came and in particular to Alexis and Pedro for the constructive discussion on a Friday night!

    We could clarify different aspects:

    1/ a part linked to the expected behavior of a maintainer of a module (mainly stick around, answer to other's reviews and follow up of "his" modules and PRs...) which was a part of the discussion in this emails thread. There is no concrete outcome on this topic: it was about sharing feelings and fears of maintaining something done by another and not getting the expected support for it afterwards.

    2/ the almost philosophical question about "how to make big changes and refactors inside the OCA code?". 
    We agreed that it is accepted to make one PR changing code on various modules. The only constraint is that one PR must make sense on its whole and should ideally not change various aspects/logics at once. The goal of this is to make the work of reviewers easier: they should be able to understand why the changes occur and how they are implemented. We agreed that there is a part of subjectivity here as well but we encourage people to work in a logical way as much as possible when creating new PR's, as well as making meaningful commits. However when there are huge refactors, having one commit per change is not always easy (you change something in commit 4 then change it again in commit 6 together with another thing, it is really more R&D). In this case it is not meaningful to review the PR commit per commit, but it is best to review the final outcome as a whole. 
    ==> I encourage authors to clarify how they expect the reviewers to do their job and make their life as easy as possible.

    3/ on the bank payment topic now:
    * Alexis' proposal [3] will most certainly offer an improved code quality as a whole and is normally keeping all current features as is (with light changes in the user interface, like a menu will change place but nothing crazy, as we work with Odoo where this happens a lot)

    * The way the PR's has been done make it hard for reviewers to make sure everything will be kept as is, no issue is introduced etc. It is thus hard to make a quick review on this on version 18.

    * As the current version of the code is (almost) ready in v18 [3] based on Tecnativa's migration work, this version could be merged into v18 right now (wait for the last point of this email though).

    * However, in Alexis' refactor, there is a full refactor of the XML generation that can be included in v18 (no impact on the screens or the features for the end-users, and it is a separated part easy to review). Pedro proposed to work on that together with Alexis and have it integrated in version 18 (even in v16 if requested).

    * In Alexis' refactor, the refactor includes the use of standard Odoo field. In the OCA history, we usually use the standard fields as much as possible. However it is also risky as we don't know if Odoo will change the way it is used/coded in the following version (well, this is our daily life, right?!). 
    As for this specific case, it is really not clear why Odoo decided to use those fields (the feature doesn't look finished [2]), it might be even riskier to use them from version 18.
    => Alexis would like to get internal Odoo accounting team's insight about their intention on this fields.
    => Pedro will action his network to get an answer on that

    * Based on Odoo's intention regarding the fields in question, Pedro and Alexis will work on Alexis' refactor to have it finalized and reviewed for version 19, so that only one stronger solution is kept inside the OCA. 

    (Indeed, there is no urgency on Alexis' side to have the big refactored code and improvements in v18 merged into OCA code -- he wanted to have a better version of this existing module as a final purpose, whatever the version.)

    Conclusion
    We ended the meeting with this last idea, on which Alexis would reflect and decide if he agrees to proceed this way. We agreed that we are waiting for his answer's by this Friday the 18th April.

    And finally, we also mentioned the next Spanish OCA Days where Alexis and Pedro could start working on the v19 common option, if we go into this direction.

    For those interested to join this event, here are the info, from 2nd to 4th June 2025, in Cartagena (Murcie, Spain):
    (I'll be there and I hope to see you there as well!)

    References:
    [1] PR for migration to 18 for account payment mode https://github.com/OCA/bank-payment/pull/1438, the one for account payment partner https://github.com/OCA/bank-payment/pull/1439
    [3] Alexis' refactor proposition

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le lun. 14 avr. 2025 à 22:22, Akim Juillerat <notifications@odoo-community.org> a écrit :
    Hello

    The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

    I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

    Best regards

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Akim Juillerat
    Business solutions
    Software architect
    +41 62 544 03 78

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10


    On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
    Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:





> Hello contributors,





> Thanks for sharing your opinions on this important topic.





> *Proposed next steps:* A





> continuous chain of emails won't help to find a common solution. With





> the "Community Health" WG, I propose to organize an online meeting with





> the concerned parties to find a way towards an agreement. Luc's





> suggestion of having a few days together is a good one, if there is no





> agreement online. The Spanish Odoo Days will be held in June soon: this





> could be a good opportunity.





> The result of the meeting will be shared in this thread to keep a public track of the conversation.





> *A reminder of our intention as a community* We





> are all on the same team, trying to find an open source way in the Odoo





> ecosystem that changes every year. I sometimes picture Odoo S.A. as a





> big and super fast boat on the sea of ERPs. The OCA is a gathering of





> hundreds of small little sailboat (=our PSC teams responsible for





> managing several repos), trying to follow the wind and stay together as





> much as possible. But it is sometimes really hard and chaotic (like with





> the account apocalypse in v13).





> *The underlying problematic of this discussion* Here





> we have an important question: who is the captain of this specific





> sailboat? As each part of the sailboat has been built by a different





> contributor and sometimes taken care for several years by another, who





> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?





> This is the





> question that we will need to answer as a community, because those





> discussions happened in the past and will continue to arise. And to not





> loose our time and energy on fighting between each others, we will need





> proper governance guidelines on this.





> This will be a task for the





> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn





> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).





> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20





> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :





> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.





> https://github.com/OCA/bank-payment/graphs/contributors [4]





> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:





> User





> Created PRs





> Merged PRs





> Comments





> Reviews





> OCI





> pedrobaeza





> 49





> 49





> 776





> 539





> 623





> victoralmau





> 72





> 68





> 38





> 64





> 147





> HaraldPanten





> -





> -





> 93





> 80





> 90





> alexis-via





> 41





> 22





> 84





> 48





> 86





> carlosdauden





> 9





> 8





> 12





> 60





> 74





> ValentinVinagre





> 5





> 5





> 40





> 49





> 63





> sergio-teruel





> 5





> 4





> 11





> 35





> 45





> luc-demeyer





> 26





> 14





> 38





> 15





> 40





> joao-p-marques





> 12





> 12





> 19





> 18





> 38





> etobella





> 16





> 15





> 14





> 12





> 35





> ramiadavid





> 11





> 10





> 9





> 19





> 35





> Tisho99





> 15





> 15





> 24





> 10





> 34





> MiquelRForgeFlow





> 12





> 11





> 16





> 15





> 33





> rousseldenis





> 7





> 4





> 28





> 19





> 31





> StefanRijnhart





> 5





> 4





> 20





> 20





> 31





> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.





> Kind regards,





> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:





> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.





> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.





> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.





> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.





> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.





> Best regards,





> -Stéphane





> _______________________________________________





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





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





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





> 





> --





> *Enric Tobella Alomar* CEO & Founder





> www.dixmit.com [11]





> _______________________________________________





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





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





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





> 





> 





> _______________________________________________





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





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





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





> 





> 





> 





> [1] https://odoo-community.org/about/psc-guide





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





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





> [4] https://github.com/OCA/bank-payment/graphs/contributors





> [5] mailto:notifications@odoo-community.org





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





> [7] https://github.com/OCA/bank-payment/pull/1439





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





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





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





> [11] http://www.dixmit.com





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





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





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





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





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





> 

mit freundlichen Grüßen,
Peter Niederlag





-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

    _______________________________________________
    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 - 01:16 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    Thanks Virginie for your summary of Friday's meeting.

    In the end, I think there is user demand for both solutions:
    - Pedro's proposal, which is more conservative with focus on stability of the code and stability of the datamodel,
    - my proposal, which is more "bleeding-edge" with focus on innovation and adopting the latest datamodel of Odoo SA, with re-write of large parts of the OCA/bank-payment code base.
    I think OCA could host both solutions, with a perspective for re-unification in v19+ if the community that continued with the account.payment.mode object decides to switch to the native datamodel.
    In fact, one of the numerous improvements that I proposed in my "revolution" PR for v16.0 (https://github.com/OCA/bank-payment/pull/1174) has been adopted in OCA/bank-payment v16: support the "in_payment" status on invoices ; it is a good example that my revolution PR also benefits to the official 16.0 branch.

    During Friday's meeting, I also noticed the difference of judgement on the current code quality of OCA/bank-payment: I personally think that the quality of the current code is pretty poor ; Pedro didn't share my concern on this. The consequence is that, for me, a (partial) re-write of OCA/bank-payment was really needed ; that's what I did in my revolution PR for v16. I can understand that re-writing OCA/bank-payment can raise fears and worries for stability and that some users may prefer to delay the adoption. But I know other OCA devs share my concern about the need for a big cleanup/re-write of OCA/bank-payment and support my v16 revolution PR.

    So my proposal is the following: create a new OCA project called bank-payment-native (feel free to propose a better name) with a 18.0 branch that will host my 18.0 migration PRs. To avoid naming conflicts, I would rename the modules:
    - account_payment_order => account_payment_order_native
    - account_banking_pain_base => account_payment_sepa_base (or account_payment_iso20022_base ?)
    - account_banking_sepa_direct_debit => account_payment_sepa_direct_debit (or account_payment_iso20022_direct_debit ?)
    - account_banking_sepa_credit_transfer => account_payment_sepa_credit_transfer (or account_payment_iso20022_credit_transfer ?)
    - account_banking_mandate => account_payment_mandate
    - account_banking_mandate_sale => account_payment_mandate_sale
    - account_payment_sale => account_payment_sale_native
    The modules account_payment_mode and account_payment_partner are already replaced by a single module account_payment_base_oca in my v18 migration PR.
    Again, feel free to propose better module names.

    My proposal to create a new OCA bank-payment project may seem a bit extreme because this has never happened before in OCA. But, on the other side, the alternative proposal to keep account.payment.mode involves hiding 3 native fields of the "account" module (2 native fields on res.partner "property_outbound_payment_method_line_id" & "property_inbound_payment_method_line_id" and 1 native field on account.move "preferred_payment_method_line_id"), which also never happened before in OCA AFAIK.

    I think the OCA Banking PSC (https://odoo-community.org/psc-teams/banking-10) should decide in the coming days if they agree with the creation of this new OCA project "bank-payment-native" or not (I talked about this with Virginie Dewulf today and she also thinks that it is the role of the Banking PSC to take this decision).

    Regards,

    Alexis

    Le mar. 15 avr. 2025 à 10:43, Virginie Dewulf <virginie@odoo-community.org> a écrit :
    Hello everyone,

    Last Friday, we had a meeting with Alexis, Pedro, a few PSC of bank project and with Benoit Guillot and Denis Roussel who are Board members and part of the new "Community Health" Working group.

    Thanks a lot to those who came and in particular to Alexis and Pedro for the constructive discussion on a Friday night!

    We could clarify different aspects:

    1/ a part linked to the expected behavior of a maintainer of a module (mainly stick around, answer to other's reviews and follow up of "his" modules and PRs...) which was a part of the discussion in this emails thread. There is no concrete outcome on this topic: it was about sharing feelings and fears of maintaining something done by another and not getting the expected support for it afterwards.

    2/ the almost philosophical question about "how to make big changes and refactors inside the OCA code?". 
    We agreed that it is accepted to make one PR changing code on various modules. The only constraint is that one PR must make sense on its whole and should ideally not change various aspects/logics at once. The goal of this is to make the work of reviewers easier: they should be able to understand why the changes occur and how they are implemented. We agreed that there is a part of subjectivity here as well but we encourage people to work in a logical way as much as possible when creating new PR's, as well as making meaningful commits. However when there are huge refactors, having one commit per change is not always easy (you change something in commit 4 then change it again in commit 6 together with another thing, it is really more R&D). In this case it is not meaningful to review the PR commit per commit, but it is best to review the final outcome as a whole. 
    ==> I encourage authors to clarify how they expect the reviewers to do their job and make their life as easy as possible.

    3/ on the bank payment topic now:
    * Alexis' proposal [3] will most certainly offer an improved code quality as a whole and is normally keeping all current features as is (with light changes in the user interface, like a menu will change place but nothing crazy, as we work with Odoo where this happens a lot)

    * The way the PR's has been done make it hard for reviewers to make sure everything will be kept as is, no issue is introduced etc. It is thus hard to make a quick review on this on version 18.

    * As the current version of the code is (almost) ready in v18 [3] based on Tecnativa's migration work, this version could be merged into v18 right now (wait for the last point of this email though).

    * However, in Alexis' refactor, there is a full refactor of the XML generation that can be included in v18 (no impact on the screens or the features for the end-users, and it is a separated part easy to review). Pedro proposed to work on that together with Alexis and have it integrated in version 18 (even in v16 if requested).

    * In Alexis' refactor, the refactor includes the use of standard Odoo field. In the OCA history, we usually use the standard fields as much as possible. However it is also risky as we don't know if Odoo will change the way it is used/coded in the following version (well, this is our daily life, right?!). 
    As for this specific case, it is really not clear why Odoo decided to use those fields (the feature doesn't look finished [2]), it might be even riskier to use them from version 18.
    => Alexis would like to get internal Odoo accounting team's insight about their intention on this fields.
    => Pedro will action his network to get an answer on that

    * Based on Odoo's intention regarding the fields in question, Pedro and Alexis will work on Alexis' refactor to have it finalized and reviewed for version 19, so that only one stronger solution is kept inside the OCA. 

    (Indeed, there is no urgency on Alexis' side to have the big refactored code and improvements in v18 merged into OCA code -- he wanted to have a better version of this existing module as a final purpose, whatever the version.)

    Conclusion
    We ended the meeting with this last idea, on which Alexis would reflect and decide if he agrees to proceed this way. We agreed that we are waiting for his answer's by this Friday the 18th April.

    And finally, we also mentioned the next Spanish OCA Days where Alexis and Pedro could start working on the v19 common option, if we go into this direction.

    For those interested to join this event, here are the info, from 2nd to 4th June 2025, in Cartagena (Murcie, Spain):
    (I'll be there and I hope to see you there as well!)

    References:
    [1] PR for migration to 18 for account payment mode https://github.com/OCA/bank-payment/pull/1438, the one for account payment partner https://github.com/OCA/bank-payment/pull/1439
    [3] Alexis' refactor proposition

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le lun. 14 avr. 2025 à 22:22, Akim Juillerat <notifications@odoo-community.org> a écrit :
    Hello

    The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

    I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

    Best regards

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Akim Juillerat
    Business solutions
    Software architect
    +41 62 544 03 78

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10


    On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
    Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:




> Hello contributors,




> Thanks for sharing your opinions on this important topic.




> *Proposed next steps:* A




> continuous chain of emails won't help to find a common solution. With




> the "Community Health" WG, I propose to organize an online meeting with




> the concerned parties to find a way towards an agreement. Luc's




> suggestion of having a few days together is a good one, if there is no




> agreement online. The Spanish Odoo Days will be held in June soon: this




> could be a good opportunity.




> The result of the meeting will be shared in this thread to keep a public track of the conversation.




> *A reminder of our intention as a community* We




> are all on the same team, trying to find an open source way in the Odoo




> ecosystem that changes every year. I sometimes picture Odoo S.A. as a




> big and super fast boat on the sea of ERPs. The OCA is a gathering of




> hundreds of small little sailboat (=our PSC teams responsible for




> managing several repos), trying to follow the wind and stay together as




> much as possible. But it is sometimes really hard and chaotic (like with




> the account apocalypse in v13).




> *The underlying problematic of this discussion* Here




> we have an important question: who is the captain of this specific




> sailboat? As each part of the sailboat has been built by a different




> contributor and sometimes taken care for several years by another, who




> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?




> This is the




> question that we will need to answer as a community, because those




> discussions happened in the past and will continue to arise. And to not




> loose our time and energy on fighting between each others, we will need




> proper governance guidelines on this.




> This will be a task for the




> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn




> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).




> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20




> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :




> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.




> https://github.com/OCA/bank-payment/graphs/contributors [4]




> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:




> User




> Created PRs




> Merged PRs




> Comments




> Reviews




> OCI




> pedrobaeza




> 49




> 49




> 776




> 539




> 623




> victoralmau




> 72




> 68




> 38




> 64




> 147




> HaraldPanten




> -




> -




> 93




> 80




> 90




> alexis-via




> 41




> 22




> 84




> 48




> 86




> carlosdauden




> 9




> 8




> 12




> 60




> 74




> ValentinVinagre




> 5




> 5




> 40




> 49




> 63




> sergio-teruel




> 5




> 4




> 11




> 35




> 45




> luc-demeyer




> 26




> 14




> 38




> 15




> 40




> joao-p-marques




> 12




> 12




> 19




> 18




> 38




> etobella




> 16




> 15




> 14




> 12




> 35




> ramiadavid




> 11




> 10




> 9




> 19




> 35




> Tisho99




> 15




> 15




> 24




> 10




> 34




> MiquelRForgeFlow




> 12




> 11




> 16




> 15




> 33




> rousseldenis




> 7




> 4




> 28




> 19




> 31




> StefanRijnhart




> 5




> 4




> 20




> 20




> 31




> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.




> Kind regards,




> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:




> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.




> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.




> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.




> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.




> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.




> Best regards,




> -Stéphane




> _______________________________________________




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




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




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




> 




> --




> *Enric Tobella Alomar* CEO & Founder




> www.dixmit.com [11]




> _______________________________________________




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




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




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




> 




> 




> _______________________________________________




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




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




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




> 




> 




> 




> [1] https://odoo-community.org/about/psc-guide




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




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




> [4] https://github.com/OCA/bank-payment/graphs/contributors




> [5] mailto:notifications@odoo-community.org




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




> [7] https://github.com/OCA/bank-payment/pull/1439




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




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




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




> [11] http://www.dixmit.com




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




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




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




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




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




> 

mit freundlichen Grüßen,
Peter Niederlag




-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

    _______________________________________________
    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 Alexis de Lattre - 12:20 - 16 Apr 2025
  • Re: The future of oca/bank-payment
    Hello everyone,

    Last Friday, we had a meeting with Alexis, Pedro, a few PSC of bank project and with Benoit Guillot and Denis Roussel who are Board members and part of the new "Community Health" Working group.

    Thanks a lot to those who came and in particular to Alexis and Pedro for the constructive discussion on a Friday night!

    We could clarify different aspects:

    1/ a part linked to the expected behavior of a maintainer of a module (mainly stick around, answer to other's reviews and follow up of "his" modules and PRs...) which was a part of the discussion in this emails thread. There is no concrete outcome on this topic: it was about sharing feelings and fears of maintaining something done by another and not getting the expected support for it afterwards.

    2/ the almost philosophical question about "how to make big changes and refactors inside the OCA code?". 
    We agreed that it is accepted to make one PR changing code on various modules. The only constraint is that one PR must make sense on its whole and should ideally not change various aspects/logics at once. The goal of this is to make the work of reviewers easier: they should be able to understand why the changes occur and how they are implemented. We agreed that there is a part of subjectivity here as well but we encourage people to work in a logical way as much as possible when creating new PR's, as well as making meaningful commits. However when there are huge refactors, having one commit per change is not always easy (you change something in commit 4 then change it again in commit 6 together with another thing, it is really more R&D). In this case it is not meaningful to review the PR commit per commit, but it is best to review the final outcome as a whole. 
    ==> I encourage authors to clarify how they expect the reviewers to do their job and make their life as easy as possible.

    3/ on the bank payment topic now:
    * Alexis' proposal [3] will most certainly offer an improved code quality as a whole and is normally keeping all current features as is (with light changes in the user interface, like a menu will change place but nothing crazy, as we work with Odoo where this happens a lot)

    * The way the PR's has been done make it hard for reviewers to make sure everything will be kept as is, no issue is introduced etc. It is thus hard to make a quick review on this on version 18.

    * As the current version of the code is (almost) ready in v18 [3] based on Tecnativa's migration work, this version could be merged into v18 right now (wait for the last point of this email though).

    * However, in Alexis' refactor, there is a full refactor of the XML generation that can be included in v18 (no impact on the screens or the features for the end-users, and it is a separated part easy to review). Pedro proposed to work on that together with Alexis and have it integrated in version 18 (even in v16 if requested).

    * In Alexis' refactor, the refactor includes the use of standard Odoo field. In the OCA history, we usually use the standard fields as much as possible. However it is also risky as we don't know if Odoo will change the way it is used/coded in the following version (well, this is our daily life, right?!). 
    As for this specific case, it is really not clear why Odoo decided to use those fields (the feature doesn't look finished [2]), it might be even riskier to use them from version 18.
    => Alexis would like to get internal Odoo accounting team's insight about their intention on this fields.
    => Pedro will action his network to get an answer on that

    * Based on Odoo's intention regarding the fields in question, Pedro and Alexis will work on Alexis' refactor to have it finalized and reviewed for version 19, so that only one stronger solution is kept inside the OCA. 

    (Indeed, there is no urgency on Alexis' side to have the big refactored code and improvements in v18 merged into OCA code -- he wanted to have a better version of this existing module as a final purpose, whatever the version.)

    Conclusion
    We ended the meeting with this last idea, on which Alexis would reflect and decide if he agrees to proceed this way. We agreed that we are waiting for his answer's by this Friday the 18th April.

    And finally, we also mentioned the next Spanish OCA Days where Alexis and Pedro could start working on the v19 common option, if we go into this direction.

    For those interested to join this event, here are the info, from 2nd to 4th June 2025, in Cartagena (Murcie, Spain):
    (I'll be there and I hope to see you there as well!)

    References:
    [1] PR for migration to 18 for account payment mode https://github.com/OCA/bank-payment/pull/1438, the one for account payment partner https://github.com/OCA/bank-payment/pull/1439
    [3] Alexis' refactor proposition

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le lun. 14 avr. 2025 à 22:22, Akim Juillerat <notifications@odoo-community.org> a écrit :
    Hello

    The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

    I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

    Best regards

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Akim Juillerat
    Business solutions
    Software architect
    +41 62 544 03 78

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10


    On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
    Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:



> Hello contributors,



> Thanks for sharing your opinions on this important topic.



> *Proposed next steps:* A



> continuous chain of emails won't help to find a common solution. With



> the "Community Health" WG, I propose to organize an online meeting with



> the concerned parties to find a way towards an agreement. Luc's



> suggestion of having a few days together is a good one, if there is no



> agreement online. The Spanish Odoo Days will be held in June soon: this



> could be a good opportunity.



> The result of the meeting will be shared in this thread to keep a public track of the conversation.



> *A reminder of our intention as a community* We



> are all on the same team, trying to find an open source way in the Odoo



> ecosystem that changes every year. I sometimes picture Odoo S.A. as a



> big and super fast boat on the sea of ERPs. The OCA is a gathering of



> hundreds of small little sailboat (=our PSC teams responsible for



> managing several repos), trying to follow the wind and stay together as



> much as possible. But it is sometimes really hard and chaotic (like with



> the account apocalypse in v13).



> *The underlying problematic of this discussion* Here



> we have an important question: who is the captain of this specific



> sailboat? As each part of the sailboat has been built by a different



> contributor and sometimes taken care for several years by another, who



> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?



> This is the



> question that we will need to answer as a community, because those



> discussions happened in the past and will continue to arise. And to not



> loose our time and energy on fighting between each others, we will need



> proper governance guidelines on this.



> This will be a task for the



> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn



> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).



> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20



> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :



> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.



> https://github.com/OCA/bank-payment/graphs/contributors [4]



> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:



> User



> Created PRs



> Merged PRs



> Comments



> Reviews



> OCI



> pedrobaeza



> 49



> 49



> 776



> 539



> 623



> victoralmau



> 72



> 68



> 38



> 64



> 147



> HaraldPanten



> -



> -



> 93



> 80



> 90



> alexis-via



> 41



> 22



> 84



> 48



> 86



> carlosdauden



> 9



> 8



> 12



> 60



> 74



> ValentinVinagre



> 5



> 5



> 40



> 49



> 63



> sergio-teruel



> 5



> 4



> 11



> 35



> 45



> luc-demeyer



> 26



> 14



> 38



> 15



> 40



> joao-p-marques



> 12



> 12



> 19



> 18



> 38



> etobella



> 16



> 15



> 14



> 12



> 35



> ramiadavid



> 11



> 10



> 9



> 19



> 35



> Tisho99



> 15



> 15



> 24



> 10



> 34



> MiquelRForgeFlow



> 12



> 11



> 16



> 15



> 33



> rousseldenis



> 7



> 4



> 28



> 19



> 31



> StefanRijnhart



> 5



> 4



> 20



> 20



> 31



> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.



> Kind regards,



> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:



> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.



> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.



> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.



> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.



> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.



> Best regards,



> -Stéphane



> _______________________________________________



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



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



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



> 



> --



> *Enric Tobella Alomar* CEO & Founder



> www.dixmit.com [11]



> _______________________________________________



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



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



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



> 



> 



> _______________________________________________



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



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



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



> 



> 



> 



> [1] https://odoo-community.org/about/psc-guide



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



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



> [4] https://github.com/OCA/bank-payment/graphs/contributors



> [5] mailto:notifications@odoo-community.org



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



> [7] https://github.com/OCA/bank-payment/pull/1439



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



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



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



> [11] http://www.dixmit.com



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



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



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



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



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



> 

mit freundlichen Grüßen,
Peter Niederlag



-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

    _______________________________________________
    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 Virginie Dewulf - 10:41 - 15 Apr 2025
  • Re: The future of oca/bank-payment
    Hello

    The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

    I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

    Best regards

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Akim Juillerat
    Business solutions
    Software architect
    +41 62 544 03 78

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10


    On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
    Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:


> Hello contributors,


> Thanks for sharing your opinions on this important topic.


> *Proposed next steps:* A


> continuous chain of emails won't help to find a common solution. With


> the "Community Health" WG, I propose to organize an online meeting with


> the concerned parties to find a way towards an agreement. Luc's


> suggestion of having a few days together is a good one, if there is no


> agreement online. The Spanish Odoo Days will be held in June soon: this


> could be a good opportunity.


> The result of the meeting will be shared in this thread to keep a public track of the conversation.


> *A reminder of our intention as a community* We


> are all on the same team, trying to find an open source way in the Odoo


> ecosystem that changes every year. I sometimes picture Odoo S.A. as a


> big and super fast boat on the sea of ERPs. The OCA is a gathering of


> hundreds of small little sailboat (=our PSC teams responsible for


> managing several repos), trying to follow the wind and stay together as


> much as possible. But it is sometimes really hard and chaotic (like with


> the account apocalypse in v13).


> *The underlying problematic of this discussion* Here


> we have an important question: who is the captain of this specific


> sailboat? As each part of the sailboat has been built by a different


> contributor and sometimes taken care for several years by another, who


> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?


> This is the


> question that we will need to answer as a community, because those


> discussions happened in the past and will continue to arise. And to not


> loose our time and energy on fighting between each others, we will need


> proper governance guidelines on this.


> This will be a task for the


> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn


> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).


> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20


> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :


> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.


> https://github.com/OCA/bank-payment/graphs/contributors [4]


> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:


> User


> Created PRs


> Merged PRs


> Comments


> Reviews


> OCI


> pedrobaeza


> 49


> 49


> 776


> 539


> 623


> victoralmau


> 72


> 68


> 38


> 64


> 147


> HaraldPanten


> -


> -


> 93


> 80


> 90


> alexis-via


> 41


> 22


> 84


> 48


> 86


> carlosdauden


> 9


> 8


> 12


> 60


> 74


> ValentinVinagre


> 5


> 5


> 40


> 49


> 63


> sergio-teruel


> 5


> 4


> 11


> 35


> 45


> luc-demeyer


> 26


> 14


> 38


> 15


> 40


> joao-p-marques


> 12


> 12


> 19


> 18


> 38


> etobella


> 16


> 15


> 14


> 12


> 35


> ramiadavid


> 11


> 10


> 9


> 19


> 35


> Tisho99


> 15


> 15


> 24


> 10


> 34


> MiquelRForgeFlow


> 12


> 11


> 16


> 15


> 33


> rousseldenis


> 7


> 4


> 28


> 19


> 31


> StefanRijnhart


> 5


> 4


> 20


> 20


> 31


> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.


> Kind regards,


> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:


> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.


> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.


> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.


> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.


> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.


> Best regards,


> -Stéphane


> _______________________________________________


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


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


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


> 


> --


> *Enric Tobella Alomar* CEO & Founder


> www.dixmit.com [11]


> _______________________________________________


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


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


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


> 


> 


> _______________________________________________


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


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


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


> 


> 


> 


> [1] https://odoo-community.org/about/psc-guide


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


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


> [4] https://github.com/OCA/bank-payment/graphs/contributors


> [5] mailto:notifications@odoo-community.org


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


> [7] https://github.com/OCA/bank-payment/pull/1439


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


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


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


> [11] http://www.dixmit.com


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


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


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


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


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


> 

mit freundlichen Grüßen,
Peter Niederlag


-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

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

    by Akim Juillerat - 10:21 - 14 Apr 2025
  • Re: Odoo14: increment time precision for BoM operations
    Hi Jacob

    I found a similar but slightly better solution by extending this nice module https://apps.odoo.com/apps/modules/14.0/crnd_web_float_full_time_widget which provide an enhanced float_time widget and allows to set milliseconds on it.. then inherited a couple of views, so the datas on GUI can be filled / presented in milliseconds.. we're waiting for the customer validation, didn't find a better solution yet, but this might be enough I hope. 

    I appreciate your help, regards

    --
    Francesco



    Il giorno lun 14 apr 2025 alle ore 18:52 Jacob Christ <notifications@odoo-community.org> ha scritto:
    I don't know how this is used downstream in Odoo but could you just assume that the field is in millisecond and just dividing any totals by 1000 later on?  Manual and yucky but it might be helpful until a better solution presents itself.

    Jacob Christ
    +1 (714) 269-7256 Cell

    On Mon, Apr 14, 2025, 2:39 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
    Hi, 

    We have a customer who needs a better precision for the "Duration" field of the BoM operations. 

    By default this field is handled with a precision of 1.0 seconds, so if you produce a single unit in, for example, 1.44 seconds, the overall production time cannot be properly estimated as you can only round by 1 second or 2 seconds.

    Do you have any recommendations on how to effectively handle this scenario?

    Thanks

    --Francesco Ballerini

    _______________________________________________
    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 Francesco Ballerini - 08:56 - 14 Apr 2025
  • Re: Odoo14: increment time precision for BoM operations
    I don't know how this is used downstream in Odoo but could you just assume that the field is in millisecond and just dividing any totals by 1000 later on?  Manual and yucky but it might be helpful until a better solution presents itself.

    Jacob Christ
    +1 (714) 269-7256 Cell

    On Mon, Apr 14, 2025, 2:39 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
    Hi, 

    We have a customer who needs a better precision for the "Duration" field of the BoM operations. 

    By default this field is handled with a precision of 1.0 seconds, so if you produce a single unit in, for example, 1.44 seconds, the overall production time cannot be properly estimated as you can only round by 1 second or 2 seconds.

    Do you have any recommendations on how to effectively handle this scenario?

    Thanks

    --Francesco Ballerini

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

    by Jacob Christ - 06:52 - 14 Apr 2025
  • Re: Swiss long term real estate

    Hi Pierre thanks a lot for your answer but what we need is a little bit different

    The usecase is this:

    1) we receive the invoice (one or more) from the gas provider for the entire building (and the same for light and so on)

    2) at the end of the year, we need to split the gas amount to the single apartment based of the months occupied but the single month have different weight (January 18.20% of the annual cost, February 14.80%, etc.)

    3) we need to split a lot of buildings with a lot of apartments

    Any ideas?

    Thanks

    Il 09.04.2025 17:07, Pierre Verkest ha scritto:
    Hi Stefano, 

    It's not clear to me if your cost come from a supplier invoice or something else, from accounting perspective, I've the feeling you are speaking of cutoff features to spread expenses over the entire fiscal period - I'm not an accounting and I've never works on switzerland -, I've implement something based on prorata temporis in account_move_cutoff (module presented at last OCA days https://www.youtube.com/watch?v=7N39fjX0nBs) that I'm currently porting to v17.0.

    We have already 2 distribution methods, you could add a new one if needed.

    hope this helps,

    Le mer. 9 avr. 2025 à 16:42, Stefano Sforzi <notifications@odoo-community.org> a écrit :
    Hello,

I have a prospect focus in long term real estate administration based in 
Switzerland.

we have a law that requires the distribution of some costs such as gas, 
elevators, etc. based on various factors.
An example is heating where a state table is imposed divided into months 
with January 18.20% of the annual cost, February 14.80%, etc. .
What I am looking for is a form that offers the possibility of dividing 
the annual amount of heating costs based on the months.
Do you have any ideas?



-- 

Stefano Sforzi
Tel (CH): +41 91 210 23 40
Tel (IT): +39 0331 158 7090
https://www.agilebg.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

    -- 

Tel (CH): +41 91 210 23 40
Tel (IT): +39 011 198 25481
http://www.agilebg.com
    by AGILE BUSINESS GROUP SAGL - 12:11 - 14 Apr 2025
  • Odoo14: increment time precision for BoM operations
    Hi, 

    We have a customer who needs a better precision for the "Duration" field of the BoM operations. 

    By default this field is handled with a precision of 1.0 seconds, so if you produce a single unit in, for example, 1.44 seconds, the overall production time cannot be properly estimated as you can only round by 1 second or 2 seconds.

    Do you have any recommendations on how to effectively handle this scenario?

    Thanks

    --Francesco Ballerini
    by Francesco Ballerini - 11:37 - 14 Apr 2025
  • Re: Follow-up for specific product e-Commerce 
    Hi Marco,

We curently do that using standard ecommerce email feature : an email is 
automaticaly sent to the customer upon validating or abandoning his basket. 
Our email template is heavily customised of course. For example if a very 
heavy product is bought, the text is totaly different. It is enough for us.

Hope this help
Xavier


Le vendredi 11 avril 2025, 15:18:02 heure d’été d’Europe centrale Marco Morra 
a écrit :

> Dear Odoo Community Contributors,

> I hope this message finds you well.

> I'm currently working on an automation for my e-commerce based on Odoo, and

> I would like some guidance regarding the best approach to achieve it. My

> goal is to trigger the sending of a specific email upon the purchase of a

> particular product. Ideally, each product should have its own tailored

> email sent to the customer after the purchase is confirmed. I was

> considering using the Marketing Automation  module to implement this

> workflow, but I’m open to alternative solutions if there is a more

> appropriate or efficient way to achieve this result. Could you kindly

> advise on the best practice or point me towards existing modules or

> community projects that might help? Thank you very much in advance for your

> support and the amazing work you all do!
    by xavier - 09:46 - 11 Apr 2025
  • Re: Follow-up for specific product e-Commerce
    Dear Marco,

    Isn't your need covered by native product_email_template module ?

    <https://github.com/odoo/odoo/tree/18.0/addons/product_email_template>

    Best Regards,
    Rémi


    Le 11 avril 2025 13:18:02 UTC, Marco Morra <notifications@odoo-community.org> a écrit :
    Dear Odoo Community Contributors,
    I hope this message finds you well.
    I'm currently working on an automation for my e-commerce based on Odoo, and I would like some guidance regarding the best approach to achieve it.
    My goal is to trigger the sending of a specific email upon the purchase of a particular product. Ideally, each product should have its own tailored email sent to the customer after the purchase is confirmed. I was considering using the Marketing Automation module to implement this workflow, but I’m open to alternative solutions if there is a more appropriate or efficient way to achieve this result.
    Could you kindly advise on the best practice or point me towards existing modules or community projects that might help?
    Thank you very much in advance for your support and the amazing work you all do!



    Best Regards,


    Marco Morra

    Marco Morra
    Founder

    Digisolve di Morra Marco
    Mobile     / +39 329 112 6861
    Email / marco.morra@digisolve.it
    Sito web / www.digisolve.it
    telephone
    web
    whatsapp

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

    by Rémi Cazenave - 07:55 - 11 Apr 2025