Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • New PSC role_policy

    As a follow-up to today’s Role Policy presentation I propose to move this work to a new OCA project.

     

    cf.

     

    Initial PSC members would be

    • Myself

    • Kevin Graveman

    • Els Van Vossel

    • Simon Janssens

     

    Please let me know if you agree/disagree.

     

    Regards,

    Luc

     

    www.noviat.com

    Rusatiralaan 1, 1083 Brussel

    +32 2 808 86 38

     

     

    by Luc De Meyer. - 05:30 - 15 Oct 2020

    1 attachments 1 attachments

    image001.jpg

    11 replies 11 replies

  • V14, python version
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement
    by David BEAL - 09:26 - 14 Oct 2020

    40 replies 40 replies

  • OCA Days - Zoom hosts and moderators - still need a few more
    Hi folks,

    OCA Days are nearly upon us and we do need a few extra hands on deck to "host/moderate", help with the Zoom technical side of things over the two days. There are still a few time slots left.

    If you feel you can help for a couple of hours that would be amazing, please pop your name on the schedule with your email address so we can get in touch.

    Thanks in advance,
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 06:21 - 14 Oct 2020
  • unsubscribe
    Hi all!

    Please unsubscribe this email from all the OCA mailing lists please. I've already try it several times but I keep receiving new emails.

    Thank you!

    --
    Gabriel.
    by Gabriel Davini - 04:45 - 13 Oct 2020
  • OCA Days - Sprint Document
    Hi,

    If you will participate in the code sprint, please add topics you would plan to work on in this document: https://docs.google.com/document/d/1VHx8kKg3THAbxmx89wHZRa35_YfcU8F_g2E9sMlHnTU/edit?usp=sharing

    Do not forget to join the discord server for real time collaboration: https://discord.gg/tNby4ku

    If you need specific additional channel topics on discord, just ask there in the #general channel.

    Best regards,

    -sbi

    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120
    by Stéphane Bidoul - 04:11 - 13 Oct 2020
  • module migration
    Hi all,

    I have a small question about contributions in module migration.

    What is the minimal work that implies adding my name in the contributors section?

    - change version number
    - minimal fix on test or doc
    - other
    - substantial fix

    Potentially when I know the OCA workflow, I may migrate a module with only functional knowledge and luck.

    Thanks to share your opinions

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement
    by David BEAL - 01:11 - 13 Oct 2020

    1 replies 1 replies

    • Re: module migration
      I would say that migrating a module, although it only implies changing the version number as nothing more is required, already means to be in contributors list, as you have followed the procedure to migrate commit history, and so on. The same for doing bugfixes. To be on author list, your contribution have to be significant enough:

      - Migration requires to redo a lot in the module.
      - You add a feature in it that means a high amount of code/testing/etc (for example, adding a full test suite for an untested module - if that module requires testing - should mean a co-authorship).

      Anyway, that can be decided case by case on the PR that adds the changes.

      Regards. 

      El mar., 13 oct. 2020 a las 13:11, David Beal (<david.beal@akretion.com>) escribió:
      Hi all,

      I have a small question about contributions in module migration.

      What is the minimal work that implies adding my name in the contributors section?

      - change version number
      - minimal fix on test or doc
      - other
      - substantial fix

      Potentially when I know the OCA workflow, I may migrate a module with only functional knowledge and luck.

      Thanks to share your opinions

      Regards

      David BEAL - akretion.com
      Consultant
      Odoo Intégration / Développement

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

      by Pedro M. Baeza - 01:20 - 13 Oct 2020
  • calendar colors
    Hello community

    Is there a module or anything that's already been done to select the color of a calendar event according to a type in recent versions (looking for v13.0)?
    For example, in the event modules, the colors are used according to the event type but there's no way to say Type1=red and Type2=blue. This could also be useful in the leaves module to display leaves according to their type (paid leave=green, sickness=red).

    I couldn't find anything useful except old tutorials on how to do it on version 8.0

    Thanks

    --
    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

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

    Camptocamp SA
    Leberngasse 21
    4600 Olten
    Switzerland
    +41 21 619 10 10
    by Akim Juillerat - 12:05 - 13 Oct 2020

    1 replies 1 replies

    • Re: calendar colors
      Hi Akim,

      We've done this for 12.0, and very recently in 14.0.
      Not for 13.0, though.

      I'm not quite happy with the 12.0 implementation, as it requires several overrides, but it works. You can check it out here: https://github.com/druidoo/druidoo-addons/tree/12.0/web_calendar_color_field

      The 14.0 version is much simpler, since Odoo improved the code a bit and partially introduced this feature through filters. Hence I take the opportunity to PR to OCA: https://github.com/OCA/web/pull/1703

      Best,

      Iván Todorovich


      El mar., 13 oct. 2020 a las 7:07, Akim Juillerat (<akim.juillerat@camptocamp.com>) escribió:
      Hello community

      Is there a module or anything that's already been done to select the color of a calendar event according to a type in recent versions (looking for v13.0)?
      For example, in the event modules, the colors are used according to the event type but there's no way to say Type1=red and Type2=blue. This could also be useful in the leaves module to display leaves according to their type (paid leave=green, sickness=red).

      I couldn't find anything useful except old tutorials on how to do it on version 8.0

      Thanks

      --
      camptocamp
      INNOVATIVE SOLUTIONS
      BY OPEN SOURCE EXPERTS

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

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

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

      by Iván Todorovich - 03:55 - 13 Oct 2020
  • weblate
    Hi would like to add translation to weblate but I can't save translates terms.
    Is it a permission setting issue?
    If yes who has admin right and could help me?
    tnx

     --
    Yves Goldberg
    --

    by Yves Goldberg - 08:00 - 13 Oct 2020

    1 replies 1 replies

    • Re: weblate 
      Hi Yves,

Your user has permissions on French translations.

If the problem persists, please send an email with details to
transbot@odoo-community.org.

-sbi

On Tue, Oct 13, 2020 at 8:01 AM Yves Goldberg <yves@ygol.com> wrote:

>

> Hi would like to add translation to weblate but I can't save translates terms.

> Is it a permission setting issue?

> If yes who has admin right and could help me?

> tnx

>

>  --

> Yves Goldberg

> --

>

> _______________________________________________

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

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

> Unsubscribe: https://odoo-community.org/groups?unsubscribe
      by Stéphane Bidoul - 09:06 - 13 Oct 2020
  • Migration to v14 requirement - readony / invisible

    Hello All,


    Some XML modifiers in views disappear: invisible and readonly. They should be assigned through general modifier attrs.

    Can anyone shed light on this?  I see no reference in base Odoo to deprecation of these modifiers?

    Richard

    Richard deMeester

    Senior Development Analyst

    WilldooIT Pty Ltd

    E: richard.demeester@willdooit.com

    M: +61 403 76 76 76

    P: +61 3 9135 1900

    A: 10/435 Williamstown Road, Port Melbourne, Vic 3207

     

     

    Making growth through technology easy

     

     

    DISCLAIMER | This electronic message together with any attachments is confidential. If you are not the recipient, do not copy, disclose, or use the contents in any way. Please also advise us by e-mail that you have received this message in error and then please destroy this email and any of its attachments. WilldooIT Pty. Ltd. is not responsible for any changes made to this message and/or any attachments after sending by WilldooIT Pty. Ltd. WilldooIT Pty. Ltd. use virus scanning software but exclude all liability for virus or anything similar in this email or attachment.

    by Richard deMeester <richard.demeester@willdooit.com> - 02:31 - 13 Oct 2020

    2 attachments 2 attachments

    Outlook-r3mndhi2.png
    Outlook-xhiifrue.jpg

    10 replies 10 replies

  • OCA - 2020 Delegates Campaign - Now Open


    Dear Odoo enthusiasts, OCA members and contributors,


    The 2020 OCA Delegates Campaign is open. From now and until October 23rd 2020, you can apply as an OCA Delegate.


    Why?


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


    How?


    To apply as a candidate, you have to:

    Campaign will be closed on October 23rd, 2020.


    Then what?


    The vote will be open from October 26th to November 6th, 2020. Current OCA Delegates will have to vote for 10 new Delegates among the candidates. 


    The results of the election will be announced on those lists on November 7th, 2020. 


    The 10 new Delegates will then take part with the existing Delegates in :

    • the 2020 OCA Board Member Campaign from November 9th to 20th, 2020

    • the 2020 OCA Financial Auditor Campaign from November 9th to 20th, 2020

    • the 2020 General Assembly from November 23rd to December 2nd, 2020.


    Should you have any questions, please get in touch.


    Warmest regards, Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 02:06 - 12 Oct 2020
  • Odoo and Snaplogic
    Hi Folks,

    I am wondering if someone has already connected Odoo with Snaplogic?
    Is there something available or on-going around the community?

    Thanks for your help.

    __________________________________________
    Cédric Pigeon
    Project Leader
    Acsone SA, Succursale de Luxembourg

    Acsone sa/nv
    Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels  | Belgium
    Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
    www.acsone.eu
    ___________________________________________
    by Cédric Pigeon - 10:40 - 9 Oct 2020
  • 14.0 branches
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120
    by Stéphane Bidoul - 09:21 - 8 Oct 2020

    66 replies 66 replies

  • Is there a way to create account.analytic.line from stock.move? 
    Hello,

we would like to use analytic accounts to track profitability of individual 
sales. So I'd setup automatic creation of analytic account on confirmed sale 
orders which would be propagated to invoices. This would cover the credit 
side. What I am struggling with is the debit side - i.e. costs of products. 
One way would be adding analytic account on POs/POLs but that is not feasible 
because we can have products in stock from past which we decide to sell. So my 
idea is to generate account.analytic.line records from stock.moves and assign 
them value according to average value. Are there any modules that would 
support this? Or should I choose different approach?

Thank you. Best regards

	Radovan Skolnik
    by Radovan Skolnik - 10:15 - 8 Oct 2020

    13 replies 13 replies

    • Re: Is there a way to create account.analytic.line from stock.move?

      Reading all the code I got all confused - you're right it's there in stock_account.

       

      Initially I wanted to report that the code you provided does not seem to work for me - the stock move inside stock picking associated with Sale Order does not receive analytical account information. But I found the culprit later on. The part of code that I initially thought is alredy present in procurement_mto_analytic is this:

       

      def _prepare_procurement_values(self, group_id=False):

              res = super()._prepare_procurement_values(group_id)
              res.update({"account_analytic_id": self.order_id.analytic_account_id.id})
              return res


      However what you posted was this:

      res.update({"analytic_account_id": self.order_id.analytic_account_id.id})

       

      In stock_analytic (in fact in sale) the field is named analytic_account_id but in procurement_mto_analytic it's account_analytic_id. I missed this detail initially and of course it didn't work. Throughout the codebase of stock Odoo both names are used for some reason. The same goes for account-analytic OCA repository.

       

      Best regards

       

      Radovan

       

      On pondelok 12. októbra 2020 17:02:34 CEST Dominique k wrote:

      > look at the module stock_account

      > Regards, Dominique

      > On Mon, 12 Oct 2020 at 20:05, Radovan Skolnik < radovan@skolnik.info [1] >

      > wrote: Oh, now I see (after long staring at various pieces of code).

      > Account Move (account.move) ensures creation of Analytic Entries

      > (account.analytic.line) for Account Move Lines (account.move.line) that are

      > validated. So that way OCA module stock_analytic provides the possibility

      > to create Analytic Entries in _prepare_account_move_line method...

      >

      > OK, now I'll update the code of procurement_mto_analytic (actually only the

      > second part as the first part is there already - or should that be another

      > module or even a new one?) with the code you provided, the analytical

      > account value should be propagated into stock move lines. Now does stock

      > move somehow relate to account move (to generate analytic entries)? Does

      > not seem to me so...

      >

      > Thank you very much for info. Best regards

      >

      > Radovan

      >

      > On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:

      > > in odoo standard, analytic entries (account.analytic.line) are generated

      > > with journal entries (== invoices in v13 onwards). It is also possible to

      > > create analytic entries separately, typically with timesheet. In fact

      > > timesheet entries are analytic lines with the OCA module stock_analytic,

      > > analytic entries are created when a stock move is validated. that is all

      > > as

      > > far as i know. other modules, do not generate analytic lines, instead,

      > > they

      > > add an analytic account to a document, which eventually ends up/link up

      > > as/with a timesheet, an invoice or a stock move. Regards, Dominique

      > > _______________________________________________

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

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

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

      > >

      > >

      > >

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

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

      >

      > _______________________________________________

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

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

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

      >

      >

      >

      > [1] mailto:radovan@skolnik.info

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

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

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

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

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

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

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

       

       

      by Radovan Skolnik - 09:21 - 12 Oct 2020
    • Re: Is there a way to create account.analytic.line from stock.move?
      look at the module stock_account

      Regards,
      Dominique


      On Mon, 12 Oct 2020 at 20:05, Radovan Skolnik <radovan@skolnik.info> wrote:
      Oh, now I see (after long staring at various pieces of code). Account Move
      (account.move) ensures creation of Analytic Entries (account.analytic.line)
      for Account Move Lines (account.move.line) that are validated. So that way OCA
      module stock_analytic provides the possibility to create Analytic Entries in
      _prepare_account_move_line method...

      OK, now I'll update the code of procurement_mto_analytic (actually only the
      second part as the first part is there already - or should that be another
      module or even a new one?) with the code you provided, the analytical account
      value should be propagated into stock move lines. Now does stock move somehow
      relate to account move (to generate analytic entries)? Does not seem to me
      so...

      Thank you very much for info. Best regards

              Radovan

      On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:
      > in odoo standard, analytic entries (account.analytic.line) are generated
      > with journal entries (== invoices in v13 onwards). It is also possible to
      > create analytic entries separately, typically with timesheet. In fact
      > timesheet entries are analytic lines with the OCA module stock_analytic,
      > analytic entries are created when a stock move is validated. that is all as
      > far as i know. other modules, do not generate analytic lines, instead, they
      > add an analytic account to a document, which eventually ends up/link up
      > as/with a timesheet, an invoice or a stock move. Regards, Dominique
      > _______________________________________________
      > Mailing-List: https://odoo-community.org/groups/contributors-15 [1]
      > Post to: mailto:contributors@odoo-community.org
      > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]
      >
      >
      >
      > [1] https://odoo-community.org/groups/contributors-15
      > [2] https://odoo-community.org/groups?unsubscribe




      by dominique.k - 05:01 - 12 Oct 2020
    • Re: Is there a way to create account.analytic.line from stock.move? 
      Oh, now I see (after long staring at various pieces of code). Account Move 
(account.move) ensures creation of Analytic Entries (account.analytic.line) 
for Account Move Lines (account.move.line) that are validated. So that way OCA 
module stock_analytic provides the possibility to create Analytic Entries in 
_prepare_account_move_line method...

OK, now I'll update the code of procurement_mto_analytic (actually only the 
second part as the first part is there already - or should that be another 
module or even a new one?) with the code you provided, the analytical account 
value should be propagated into stock move lines. Now does stock move somehow 
relate to account move (to generate analytic entries)? Does not seem to me 
so...

Thank you very much for info. Best regards

	Radovan

On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:

> in odoo standard, analytic entries (account.analytic.line) are generated

> with journal entries (== invoices in v13 onwards). It is also possible to

> create analytic entries separately, typically with timesheet. In fact

> timesheet entries are analytic lines with the OCA module stock_analytic,

> analytic entries are created when a stock move is validated. that is all as

> far as i know. other modules, do not generate analytic lines, instead, they

> add an analytic account to a document, which eventually ends up/link up

> as/with a timesheet, an invoice or a stock move. Regards, Dominique

> _______________________________________________

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

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

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

> 

> 

> 

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

> [2] https://odoo-community.org/groups?unsubscribe
      by Radovan Skolnik - 02:05 - 12 Oct 2020
    • Re: Is there a way to create account.analytic.line from stock.move?
      in odoo standard, analytic entries (account.analytic.line) are generated with journal entries (== invoices in v13 onwards).
      It is also possible to create analytic entries separately, typically with timesheet. In fact timesheet entries are analytic lines

      with the OCA module stock_analytic, analytic entries are created when a stock move is validated.
      that is all as far as i know.

      other modules, do not generate analytic lines, instead, they add an analytic account to a document, which eventually ends up/link up as/with a timesheet, an invoice or a stock move.

      Regards,
      Dominique
      by dominique.k - 12:25 - 12 Oct 2020
    • Re: Is there a way to create account.analytic.line from stock.move? 
      Which OCA module generates analytic entries (is the same as Analytic Items - 
i.e. account.analytic.line)?

	Radovan

On pondelok 12. októbra 2020 12:00:27 CEST Dominique k wrote:

> I haven't looked at all of the modules related to analytic in OCA.

> In general, the analytic entries are created by invoices, timesheets (odoo

> standard), and stock move (with OCA module)

> 

> however, in order to have the analytic entries, you must first indicate the

> analytic account on the "originator" document. Hence, whenever there is a

> new module, you may want to add an analytic account. e.g. stock_request, or

> purchase_request etc..

> or whatever module you are building:

> subscription, contract, team etc...

> 

> Regards,

> Dominique

> 

> On Mon, 12 Oct 2020 at 17:38, Radovan Skolnik <radovan@skolnik.info> wrote:

> > Great! Thank you very much Dominique.

> > 

> > One more question: as I explained before I want to use this to produce

> > account.analytic.line records to get costs and revenues of cases /

> > project. I

> > see lots of modules in OCA/account-analytic that allow adding analytic

> > account

> > info to various objects. What is the general idea on using this

> > information?

> > Is it creation of those account.analytic.line - i.e. Analytic Items? If

> > so,

> > how are they generated? Or am I missing something here?

> > 

> > Best regards

> > 

> >         Radovan

> > 

> > On pondelok 12. októbra 2020 11:32:38 CEST Dominique k wrote:

> > > indeed. We added few lines of code to propagate the analytic account

> > 

> > from SO

> > 

> > > to stock move. Not sure why it is not a module in OCA. May be because it

> > 

> > is

> > 

> > > very small, and has to rely on a "glue" module ('sale_stock') Anyway, if

> > > you add this (v13), in your code, it would work. (you also need to add a

> > > dependency to 'sale_stock' in your manifest class

> > > SaleOrderLine(models.Model):

> > > _inherit = 'sale.order.line'

> > > def _prepare_procurement_values(self, group_id=False):

> > > res = super(SaleOrderLine,

> > > self)._prepare_procurement_values(group_id=group_id) analytic_id =

> > > self.order_id.analytic_account_id

> > > res['analytic_account_id'] = analytic_id and analytic_id.id [1] or False

> > > return res

> > > 

> > > class StockRule(models.Model):

> > > _inherit = 'stock.rule'

> > > def _get_custom_move_fields(self):

> > > fields = super(StockRule, self)._get_custom_move_fields()

> > > fields += ['analytic_account_id']

> > > return fields

> > > Regards, Dominique

> > > On Mon, 12 Oct 2020 at 16:57, Radovan Skolnik < radovan@skolnik.info

> > 

> > [2] >

> > 

> > > wrote: Aaron,

> > > I cannot seem to get analytic_account_id propagated from SO to outgoing

> > > stock moves (also from PO to incoming stock moves). Is that supposed to

> > > work that way? When PO is created from SO the value is propagated there

> > > though. Best regards

> > > Radovan

> > > 

> > > On štvrtok 8. októbra 2020 17:52:24 CEST Aarón Henríquez Quintana wrote:

> > > > Yes, sorry for that. It only creates analytic entries if you use real

> > 

> > time

> > 

> > > > inventory valuation. Regards.

> > > > On Thu, 8 Oct 2020 at 13:52, Radovan Skolnik <  radovan@skolnik.info

> > 

> > [3]

> > 

> > > > [1] > wrote: Thanx Aaron for info. But do I understand it correctly

> > 

> > that

> > 

> > > > this only propagates analytic account value into different objects but

> > > > does not create account.analytic.line records? I need to get cost of

> > > > products into them as negative amounts to be able to calulate

> > > > profitability of analytic account. Best regards

> > > > Radovan

> > > > 

> > > > On štvrtok 8. októbra 2020 10:42:06 CEST Aarón Henríquez Quintana

> > 

> > wrote:

> > > > > Yes. It is possible. You need a couple of modules:

> > > > >  https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [4] [2] [1]

> > > > >  adds the> >

> > > > > 

> > > > > analytic account to the stock move.

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto

> > 

> > > > >  ck [5]> >

> > > > > 

> > > > > _a [3]>

> > > > > nalytic [2] I use this for passing the analytic form the PO lines to

> > 

> > the

> > 

> > > > > stock moves. I think there is a similar one in the OCA apps but I

> > 

> > don't

> > 

> > > > > remember what it is called.

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy

> > 

> > > > >  ti [6]> >

> > > > > 

> > > > > c [4]>

> > > > > [3] To pass the analytic information from the SO to the stock moves

> > 

> > of

> > 

> > > > > the

> > > > > delivery. Regards.

> > > > > On Thu, 8 Oct 2020 at 10:17, Radovan Skolnik <  radovan@skolnik.info

> > 

> > [7]

> > 

> > > > > [5] [4] > wrote: Hello,

> > > > > we would like to use analytic accounts to track profitability of

> > > > > individual

> > > > > sales. So I'd setup automatic creation of analytic account on

> > 

> > confirmed

> > 

> > > > > sale orders which would be propagated to invoices. This would cover

> > 

> > the

> > 

> > > > > credit side. What I am struggling with is the debit side - i.e.

> > 

> > costs of

> > 

> > > > > products. One way would be adding analytic account on POs/POLs but

> > 

> > that

> > 

> > > > > is not feasible because we can have products in stock from past

> > 

> > which we

> > 

> > > > > decide to sell. So my idea is to generate account.analytic.line

> > 

> > records

> > 

> > > > > from stock.moves and assign them value according to average value.

> > 

> > Are

> > 

> > > > > there any modules that would support this? Or should I choose

> > 

> > different

> > 

> > > > > approach? Thank you. Best regards

> > > > > Radovan Skolnik

> > > > > 

> > > > > 

> > > > > _______________________________________________

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

> > 

> > [8] [6]

> > 

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

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

> > 

> > [8] [7]

> > 

> > > > > _______________________________________________

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

> > 

> > [11]

> > 

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

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

> > 

> > [11]

> > 

> > > > > [9]

> > > > > 

> > > > > 

> > > > > 

> > > > > [1]  https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [14]

> > 

> > [12]

> > 

> > > > > [2]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto

> > 

> > > > >  ck [15]> >

> > > > > 

> > > > > _a [13]>

> > > > > nalytic [3]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy

> > 

> > > > >  ti [16]> >

> > > > > 

> > > > > c [14]>

> > > > > [4] mailto:  radovan@skolnik.info [17] [15]

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

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

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

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

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

> > > > 

> > > > _______________________________________________

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

> > 

> > [21]

> > 

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

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

> > > > 

> > > > 

> > > > _______________________________________________

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

> > 

> > [24]

> > 

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

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

> > > > 

> > > > 

> > > > 

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

> > > > [2]  https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [30]

> > > > [3]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock

> > 

> > > >  _a [31]>

> > > > 

> > > > [4]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti

> > 

> > > >  c [32]>

> > > > 

> > > > [5] mailto: radovan@skolnik.info [33]

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

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

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

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

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

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

> > > > [12]  https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [40]

> > > > [13]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock

> > 

> > > >  _a [41]>

> > > > 

> > > > [14]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti

> > 

> > > >  c [42]>

> > > > 

> > > > [15] mailto: radovan@skolnik.info [43]

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

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

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

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

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

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

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

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

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

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

> > > 

> > > _______________________________________________

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

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

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

> > > 

> > > 

> > > _______________________________________________

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

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

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

> > > 

> > > 

> > > 

> > > [1] http://analytic_id.id

> > > [2] mailto:radovan@skolnik.info

> > > [3] mailto:radovan@skolnik.info

> > > [4] https://apps.odoo.com/apps/modules/12.0/stock_analytic/

> > > [5]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock

> > 

> > > [6]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti

> > 

> > > [7] mailto:radovan@skolnik.info

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

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

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

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

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

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

> > > [14] https://apps.odoo.com/apps/modules/12.0/stock_analytic/

> > > [15]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock

> > 

> > > [16]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti

> > 

> > > [17] mailto:radovan@skolnik.info

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

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

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

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

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

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

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

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

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

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

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

> > > [29] mailto:radovan@skolnik.info

> > > [30] https://apps.odoo.com/apps/modules/12.0/stock_analytic/

> > > [31]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_

> > a

> > 

> > > [32]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic

> > 

> > > [33] mailto:radovan@skolnik.info

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

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

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

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

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

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

> > > [40] https://apps.odoo.com/apps/modules/12.0/stock_analytic/

> > > [41]

> > 

> > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_

> > a

> > 

> > > [42]

> > 

> > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic

> > 

> > > [43] mailto:radovan@skolnik.info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> > > [58] https://odoo-community.org/groups?unsubscribe
      by Radovan Skolnik - 12:11 - 12 Oct 2020

  • OCA 2020 AGA - starts next week with the Delegates Campaign

    Hello OCA Contributors,

    I hope this year has been treating you well. We are looking forward to seeing many of you online at the OCA Days next week.

    I am writing to let you know that the 2020 Annual General Assembly will commence on Monday 12th October:
    • the first step is for current paid members to apply for delegate candidacy 
    • following this the existing paid delegates will vote for 10 new delegates
    • once we have our new delegates, all delegates new and existing will be able to apply for OCA board candidacy and vote in the AGA.
    If this is something you have been thinking about please make sure your membership is up to date and look out for the details on how to apply as a delegate next week.

    Any questions, please get in touch.
    Warmest regards,
    Rebecca

    -- 
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 04:10 - 8 Oct 2020
  • New PMS Proposal

    Hi!

    We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
    and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

    We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

    The work for December includes:

    1. Reservations Management
    2. Revenue Prices
    3. Onboard Services
    4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
    5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
    6. Customer Portal for Pre-Check in and invoice wizard


    Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

    The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

    The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

    The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

    I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



    Thank you very much for your attention and for all your work that has made this project possible!

    by Darío Lodeiros - 10:25 - 6 Oct 2020

    15 replies 15 replies

    • Re: New PMS Proposal
      Thanks Simone!
      I will create a 14.0 branch and a Pr with the current work on WIP.


      El mar., 20 oct. 2020 a las 16:47, Simone Orsi (<simahawk@gmail.com>) escribió:
      Hello Dario,


      There's no branch yet, you are free to set up the ones you like.

      You can bootstrap the repo using https://github.com/OCA/oca-addons-repo-template

      If you have any issues/questions let us know.

      Cheers,

      On Tue, Oct 6, 2020 at 10:26 PM dario <dario@commitsun.com> wrote:

      Hi!

      We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
      and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

      We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

      The work for December includes:

      1. Reservations Management
      2. Revenue Prices
      3. Onboard Services
      4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
      5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
      6. Customer Portal for Pre-Check in and invoice wizard


      Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

      The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

      The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

      The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

      I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



      Thank you very much for your attention and for all your work that has made this project possible!

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.

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

      by dariodafoz - 08:45 - 21 Oct 2020
    • Re: New PMS Proposal
      +1 

      Rafael Blasco <rafael.blasco@tecnativa.com> schrieb am Do. 15. Okt. 2020 um 20:47:

      +1

       

      De: dario [mailto:dario@commitsun.com]
      Enviado el: martes, 6 de octubre de 2020 22:27
      Para: Contributors <contributors@odoo-community.org>
      Asunto: New PMS Proposal

       

      Hi!

      We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
      and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

      We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

      The work for December includes:

      1. Reservations Management
      2. Revenue Prices
      3. Onboard Services
      4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
      5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
      6. Customer Portal for Pre-Check in and invoice wizard


      Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

      The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

      The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

      The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

      I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



      Thank you very much for your attention and for all your work that has made this project possible!

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

      --
      --
      facebook
      		twitter
      		linkedin

      Jens Holze

      Geschäftsführer (des besten Teams ever)

      bloopark systems GmbH & Co. KG

      		+49 391 563069-10
      		jholze@bloopark.de
      		www.bloopark.de
      		Beethovenstr. 4, 39106 Magdeburg
      by Jens Holze - 08:36 - 21 Oct 2020
    • Re: New PMS Proposal

      +1

      El 6/10/20 a las 22:26, dario escribió:

      Hi!

      We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
      and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

      We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

      The work for December includes:

      1. Reservations Management
      2. Revenue Prices
      3. Onboard Services
      4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
      5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
      6. Customer Portal for Pre-Check in and invoice wizard


      Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

      The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

      The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

      The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

      I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



      Thank you very much for your attention and for all your work that has made this project possible!

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

      --
      Ignacio Ibeas
      Acysos S.L. (www.acysos.com)
      Odoo Partner (https://www.odoo.com/es_ES/partners/acysos-s-l-80090)
      Asociado Asociación Española de Odoo (https://www.aeodoo.org/members/acysos-s-l-24)
      Odoo Community Association (https://odoo-community.org/members/acysos-s-l-ignacio-ibeas-760)
      Github (http://www.github.com/acysos)
      Odoo Apps (https://www.odoo.com/apps/modules/browse?author=Acysos S.L.)
      C/ Miguel Astrain 18, 1º Oficina A
      31006 Pamplona, Navarra.
      ignacio@acysos.com
      Tel. 948238905
      ---------------------- // -------------------
      La información contenida en este mensaje de correo electrónico es
      confidencial, para ser leída por la(s) persona(s) a quién se dirige. El
      acceso a este mensaje por otras personas no está autorizado. Si Ud. no es la
      persona a la que va dirigido, cualquier divulgación, copia o distribución de
      la información queda prohibida y puede ser ilegal. Asimismo, cualquier acción
      tomada o dejada de tomar basada en la información contenida en este mensaje
      queda prohibida y puede ser ilegal.
      The information in this e-mail is confidential and may be legally privileged.
      It is intended solely for the addressee. Access to this e-mail by anyone is
      unauthorised. If you are not the intended recipient, any disclousure,
      copying, distribuition or any action taken or omited to be taken in reliance
      on it, is prohibited and may be unlawful.
      by Ignacio Ibeas - 05:35 - 20 Oct 2020
    • Re: New PMS Proposal
      Hello Dario,


      There's no branch yet, you are free to set up the ones you like.

      You can bootstrap the repo using https://github.com/OCA/oca-addons-repo-template

      If you have any issues/questions let us know.

      Cheers,

      On Tue, Oct 6, 2020 at 10:26 PM dario <dario@commitsun.com> wrote:

      Hi!

      We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
      and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

      We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

      The work for December includes:

      1. Reservations Management
      2. Revenue Prices
      3. Onboard Services
      4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
      5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
      6. Customer Portal for Pre-Check in and invoice wizard


      Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

      The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

      The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

      The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

      I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



      Thank you very much for your attention and for all your work that has made this project possible!

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
      by Simone Orsi. - 04:46 - 20 Oct 2020
    • RE: New PMS Proposal

      +1

       

      De: dario [mailto:dario@commitsun.com]
      Enviado el: martes, 6 de octubre de 2020 22:27
      Para: Contributors <contributors@odoo-community.org>
      Asunto: New PMS Proposal

       

      Hi!

      We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
      and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

      We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

      The work for December includes:

      1. Reservations Management
      2. Revenue Prices
      3. Onboard Services
      4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
      5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
      6. Customer Portal for Pre-Check in and invoice wizard


      Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

      The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

      The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

      The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

      I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



      Thank you very much for your attention and for all your work that has made this project possible!

      by Rafael Blasco (Moduon) - 08:46 - 15 Oct 2020

  • OCA Days - Zoom hosts - we need your help
    Hello OCA Contributors,

    We need a bit of extra help for the OCA Days.

    We do need a few more hosts/moderators - basically we need two people on each track throughout the day (we have 2 tracks). The plan is to break this into 3-4 hour blocks through the day to share the load.

    We need one person to run the technical side and one person to moderate the talks.

    If you feel you are able to help out over the OCA Days to do this please get in touch ASAP and I will add you to the list.

    I look forward to hearing from you.
    Warm regards,
    Rebecca


    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 04:06 - 6 Oct 2020

    2 replies 2 replies

    • Re: OCA Days - Zoom hosts - we need your help
      Hi Rebecca,

      I could be available on 15th from 8h:30 to 13:30 preferably as techie..

      Regards,

      Laurent

      --
      Laurent Mignon
      Senior software engineer

      Tel: +32 2 8883148
      Email: laurent.mignon@acsone.eu

      Acsone sa/nv
      Waterloo Atrium | Drève Richelle 167/2 | B-1410 Waterloo

      Génie Civil du Val Benoit, Quai Banning 6 | B-4000 Liège 
      RPM Bruxelles 0835.207.216 RPR Brussel 

      Acsone SA, Succursale de Luxembourg
      22, Zone Industrielle
      | L-8287 Kehlen, Luxembourg
      TVA LU24733605
      | RCS B160400

      On Thu, Oct 8, 2020 at 12:47 AM Rebecca Gellatly <rebecca@o4sb.com> wrote:
      HI folks,

      Please see the link for the Hosts/Moderator/Techie schedule.

      I am guessing the best change over time of hosts will be during the breaks.
      Have a look and see what suits you best, we'll get some training/testing blocks set up over the next few days to go over things.

      Hopefully the spreadsheet is pretty clear - any questions  just ask.
      Once we have confirmed hosts I'll set up a separate email group.

      Thanks,
      Rebecca

      On Wed, Oct 7, 2020 at 3:05 AM Rebecca Gellatly <rebecca@o4sb.com> wrote:
      Hello OCA Contributors,

      We need a bit of extra help for the OCA Days.

      We do need a few more hosts/moderators - basically we need two people on each track throughout the day (we have 2 tracks). The plan is to break this into 3-4 hour blocks through the day to share the load.

      We need one person to run the technical side and one person to moderate the talks.

      If you feel you are able to help out over the OCA Days to do this please get in touch ASAP and I will add you to the list.

      I look forward to hearing from you.
      Warm regards,
      Rebecca


      --
      Rebecca Gellatly
      General Secretary
      Odoo Community Association


      --
      Rebecca Gellatly
      General Secretary
      Odoo Community Association

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

      by Laurent Mignon - 08:06 - 8 Oct 2020
    • Re: OCA Days - Zoom hosts - we need your help
      HI folks,

      Please see the link for the Hosts/Moderator/Techie schedule.

      I am guessing the best change over time of hosts will be during the breaks.
      Have a look and see what suits you best, we'll get some training/testing blocks set up over the next few days to go over things.

      Hopefully the spreadsheet is pretty clear - any questions  just ask.
      Once we have confirmed hosts I'll set up a separate email group.

      Thanks,
      Rebecca

      On Wed, Oct 7, 2020 at 3:05 AM Rebecca Gellatly <rebecca@o4sb.com> wrote:
      Hello OCA Contributors,

      We need a bit of extra help for the OCA Days.

      We do need a few more hosts/moderators - basically we need two people on each track throughout the day (we have 2 tracks). The plan is to break this into 3-4 hour blocks through the day to share the load.

      We need one person to run the technical side and one person to moderate the talks.

      If you feel you are able to help out over the OCA Days to do this please get in touch ASAP and I will add you to the list.

      I look forward to hearing from you.
      Warm regards,
      Rebecca


      --
      Rebecca Gellatly
      General Secretary
      Odoo Community Association


      --
      Rebecca Gellatly
      General Secretary
      Odoo Community Association
      by Rebecca Gellatly - 12:45 - 8 Oct 2020
  • [Delivery]: Scan packages instead of products in Shipping
    Hi all contributors, 

    In Odoo 13 CE, I have implemented the 3 steps delivery process.
    In this process we scan products or the picking itself in order to manage quantities...
    In Pack, products are packed in packages so that in Ship, operators should scan the packages and make sure everything is Ok. That is to say, at this level, operators shouldn't scan products of each package because: 

    1- Package is already done and Zebra labels are already printed and attached.
    2- Even if 1 is not done, scanning all products again is time consuming and should be held by package scanning only. (Each package has its EAN-13)

    I have searched in OCA modules for a module that meets this feature but couldn't find any. 
    Maybe i did not look well into the modules.. 
    Does anyone have an idea ? Any lead is appreciated.

    Regards.


    ᐧ
    by bdmibra - 11:30 - 5 Oct 2020

    1 replies 1 replies

  • black version upgrade for v14 ? 
    Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
    by Stéphane Bidoul - 02:21 - 4 Oct 2020

    11 replies 11 replies

    • Re: black version upgrade for v14 ?
      So 3 it is.

      Thanks for the feedback. I'll create the branches tomorrow.

      -sbi

      Le lun. 5 oct. 2020 à 20:12, Jesús Alan Ramos Rodríguez <alan.ramos@jarsa.com.mx> a écrit :
      +1, I agree with #3


      El dom., 4 de oct. de 2020 a la(s) 23:41, Saran Limpajitkutaporn (saranl@ecosoft.co.th) escribió:
      +1, I agree with #3

      On Mon, Oct 5, 2020 at 7:12 AM Jean-Charles Drubay <jc@komit-consulting.com> wrote:
      +1 for #3


      On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:
      +1 for #3

      On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma

      _______________________________________________
      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

      by Stéphane Bidoul - 10:05 - 5 Oct 2020
    • Re: black version upgrade for v14 ?
      +1, I agree with #3


      El dom., 4 de oct. de 2020 a la(s) 23:41, Saran Limpajitkutaporn (saranl@ecosoft.co.th) escribió:
      +1, I agree with #3

      On Mon, Oct 5, 2020 at 7:12 AM Jean-Charles Drubay <jc@komit-consulting.com> wrote:
      +1 for #3


      On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:
      +1 for #3

      On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma

      _______________________________________________
      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 Jesús Alan Ramos Rodriguez - 08:10 - 5 Oct 2020
    • Re: black version upgrade for v14 ?
      +1, I agree with #3

      On Mon, Oct 5, 2020 at 7:12 AM Jean-Charles Drubay <jc@komit-consulting.com> wrote:
      +1 for #3


      On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:
      +1 for #3

      On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma

      _______________________________________________
      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 saranl - 06:40 - 5 Oct 2020
    • Re: black version upgrade for v14 ?
      +1 for #3


      On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:
      +1 for #3

      On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma

      _______________________________________________
      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 Jean-Charles Drubay - 02:10 - 5 Oct 2020
    • Re: black version upgrade for v14 ?
      +1 for #3

      On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and
backports.

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]

-sbi

[1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma

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

      by Simone Orsi. - 04:30 - 4 Oct 2020

  • New PSC: Animal
    Hello,

    I need to manage a pets register in my neighborhood with information like species, races, size, color, name, photo and owner. I didn't find anything in the OCA or maybe I missed something...

    Is anyone interested to contribute? I think we could host modules for veterinarians, petcare businesses, zoos, circuses, farms, national parks, etc...

    What do you think?

    MAXIME CHAMBREUIL
    PROJECT MANAGER/CONSULTANT
    O: 1.855.877.2377 EXT. 710
    M: 602.427.5632
    E: MChambreuil@OpenSourcelntegrators.com
    P.O. BOX 940, HIGLEY, AZ 85236
    by Maxime Chambreuil - 08:25 - 3 Oct 2020

    4 replies 4 replies

  • [26137] Usage of Py3o templating engine in Odoo projects 
    Dear contributors,
we wanted to have the ability to generate sales and invoice documents 
based on document templates in one of our Odoo projects.
For this purpose, we decided to give the template engine Py3o a try. In 
the end, we came up with some questions
we would like to ask you.


* Have you been able to realize a similar workflow compared to the 
application Microsoft Sharepoint? If that is the case, how did you do this?
* What means did you use the store the data Py3o needs to access during 
filling the template?
* In which way did you store an already generated generated report?

We are looking forward to your feedback and thank you for this in advance.

Best regards,
Manuel


-- 
Mit freundlichen Grüßen

Manuel Engel
Trainee Anwendungsentwicklung


initOS GmbH
An der Eisenbahn 1
21224 Rosengarten

Phone:   +49 4105 56156-22
Fax:     +49 4105 56156-10

Email:   manuel.engel@initos.com
Web:     http://www.initos.com

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

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr: DE815580155
    by Manuel Engel - 02:15 - 2 Oct 2020

    1 replies 1 replies

    • Re: [26137] Usage of Py3o templating engine in Odoo projects 
      Thanks Manuel, 

to clarify the questions at stake of my colleague a bit more precise:

An ERP-System is meant to be the single source of truth.
That's why we we would ideally retain all the structured data
components (e.g. price, uom,...) that go into a Py3o report in the
first place parsed back in the ERP-system (of course with changed
content if it got changed in the Word / LibreOffice world). 

Actually this is what Sharepoint is trying to cover. So our questions
are:

Are there use cases out there that use Py3o to generate odt documents,
let the user manipulate its content in a visual way and store back at
least the structured part of the information "on safe" in the system
and if yes where an how?

For now and for us Py3o is seems to be too clumsy for that and the
technical challenges to solve too vast so that we can hardly imagine
that somebody ever tried to use it in such a use case, but we are
definitely eager to know and would love to hear about alternatives.

An no doing the entire unstructured part of a potential report document
in 1..n text field in the Odoo backend isn't a really god idea either,
we think.

Best Frederik

Am Freitag, den 02.10.2020, 12:16 +0000 schrieb Manuel Engel:

> Dear contributors,

> we wanted to have the ability to generate sales and invoice

> documents 

> based on document templates in one of our Odoo projects.

> For this purpose, we decided to give the template engine Py3o a try.

> In 

> the end, we came up with some questions

> we would like to ask you.

> 

> 

> * Have you been able to realize a similar workflow compared to the 

> application Microsoft Sharepoint? If that is the case, how did you do

> this?

> * What means did you use the store the data Py3o needs to access

> during 

> filling the template?

> * In which way did you store an already generated generated report?

> 

> We are looking forward to your feedback and thank you for this in

> advance.

> 

> Best regards,

> Manuel

> 

> 

> -- 

> Mit freundlichen Grüßen

> 

> Manuel Engel

> Trainee Anwendungsentwicklung

> 

> 

> initOS GmbH

> An der Eisenbahn 1

> 21224 Rosengarten

> 

> Phone:   +49 4105 56156-22

> Fax:     +49 4105 56156-10

> 

> Email:   manuel.engel@initos.com

> Web:     http://www.initos.com

> 

> Geschäftsführung:

> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

> 

> Sitz der Gesellschaft: Rosengarten – Klecken

> Amtsgericht Tostedt, HRB 205226

> Steuer-Nr: 15/200/53247

> USt-IdNr: DE815580155

> 

> _______________________________________________

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

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

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

-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155
      by Frederik Kramer. - 03:26 - 2 Oct 2020