Dear Team,

We have faced an issue in the currency revaluation calculation.
You can find the attache file which can show the current result and the expected result.
I would be thankful if any comment which can help to resolve this issue.

Kind Regards, Riken

Currency reevaluation calculation.xlsx

When we repeat revaluation with same revaluation date, it is create other journal entry.

Expected
The previous created entry is revised or deleted when we do repeat the revaluation, so avoid multiple exchange entry created.

Spotted on V11, not try yet on v12 of v13 yet

We have had a case of unbalanced bs/pl accounts due to the cutoff module.

I think it should apply rounding here.

Otherwise we end up with accounting entries with many decimal which cause issues down the line.

@alexis-via what do you think?

The odoo account module, in Payment methods, already inserts a record with id account_payment_method_manual_in:
https://github.com/odoo/odoo/blob/fe381f95b704085eb16b23ed74da7924ae0872e7/addons/account/data/account_data.xml#L85

You are trying to insert a record with the same id, conflicting with the former.

Playing in Runbot, we just got this traceback. I didn't investigate further (sorry, I don't have time for it). I just post it here.

To reproduce, click on a menuitem "Accrued Revenue" or "Accrued Expense" in the Runbut instance http://3337925-11-0-9b8e34.runbot1.odoo-community.org/. If the Runbot instance expires in the meanwhile, I'm afraid I cannot help you in creating the steps to reproduce in a fresh Runbot instance (sorry again).

Traceback (most recent call last):
  File "/.repo_requirements/odoo/odoo/http.py", line 650, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/.repo_requirements/odoo/odoo/http.py", line 310, in _handle_exception
    raise pycompat.reraise(type(exception), exception, sys.exc_info()[2])
  File "/.repo_requirements/odoo/odoo/tools/pycompat.py", line 87, in reraise
    raise value
  File "/.repo_requirements/odoo/odoo/http.py", line 692, in dispatch
    result = self._call_function(**self.params)
  File "/.repo_requirements/odoo/odoo/http.py", line 342, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/.repo_requirements/odoo/odoo/service/model.py", line 97, in wrapper
    return f(dbname, *args, **kwargs)
  File "/.repo_requirements/odoo/odoo/http.py", line 335, in checked_call
    result = self.endpoint(*a, **kw)
  File "/.repo_requirements/odoo/odoo/http.py", line 936, in __call__
    return self.method(*args, **kw)
  File "/.repo_requirements/odoo/odoo/http.py", line 515, in response_wrap
    response = f(*args, **kw)
  File "/home/odoo/OCB-11.0/addons/web/controllers/main.py", line 876, in search_read
    return self.do_search_read(model, fields, offset, limit, domain, sort)
  File "/home/odoo/OCB-11.0/addons/web/controllers/main.py", line 898, in do_search_read
    offset=offset or 0, limit=limit or False, order=sort or False)
  File "/.repo_requirements/odoo/odoo/models.py", line 4222, in search_read
    records = self.search(domain or [], offset=offset, limit=limit, order=order)
  File "/.repo_requirements/odoo/odoo/models.py", line 1480, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/.repo_requirements/odoo/odoo/models.py", line 3773, in _search
    query = self._where_calc(args)
  File "/.repo_requirements/odoo/odoo/models.py", line 3563, in _where_calc
    e = expression.expression(domain, self)
  File "/.repo_requirements/odoo/odoo/osv/expression.py", line 668, in __init__
    self.parse()
  File "/.repo_requirements/odoo/odoo/osv/expression.py", line 846, in parse
    raise ValueError("Invalid field %r in leaf %r" % (left, str(leaf)))
ValueError: Invalid field 'type' in leaf "<osv.ExtendedLeaf: ('type', '=', 'accrued_revenue') on account_cutoff (ctx: )>"

Hi, after installing, Multicurrency revaluation (v10) the chart of accounts template configured was removed from the corresponding field in the accounting settings, is this an expected result? Thanks

• Need to add the possibility to add an analytic account on the P&L account
  
• Open Invoice Report : 'Option 'Group by currency' has no effect anymore
• Report 'Print Currency Unrealized' has no template linked

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0

Modules to migrate

• account_cutoff_accrual_base - By @Cedric-Pigeon - #43
• account_cutoff_accrual_picking
• account_cutoff_base - By @adrienpeiffer - #41
• account_cutoff_prepaid - By @adrienpeiffer - #41
• account_fiscal_year_closing - By @jbeficent - #57
• account_invoice_accrual - By @Cedric-Pigeon - #45
• account_invoice_start_end_dates - By @adrienpeiffer - #41
• account_multicurrency_revaluation - By @grindtildeath - #47
• account_multicurrency_revaluation_report By @yvaucher - #48

This test won't work in the specific days it force creation of rate without checking they already exists.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

• account_cutoff_base - By @jimhoefnagels - #120
• account_cutoff_prepaid
• account_invoice_start_end_dates
• account_multicurrency_revaluation - By @ernestotejeda / @pedrobaeza - #124

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Have some currencies activated and used base currency IDR, other foreighn currency USD and JPY. Some accounts including payable and receivable accounts, and liquidity account (banks and cashes account are allowed for revaluation.
When the revaluation is done, all revaluation for banks and cashes, and payables are OK, but a receivable account is got incorrect entry.

Situation:

currency rate is entered one time of every month end revaluated with currency entered at the end of the month.

On the error revaluated account:
There are transaction (register payment to a customer invoice at USD --reconciled, using bank at USD currency) at the end of the month (31th March 2021)
The bank statements are entered at 6th of April 2021 with date in statment lines 31 March 2021, they are all reconciled
Entered a currency rate at 31 March 2021
Do currency revaluation with date = 31 March 2021

Result:
The revaluation entry on the USD Bank was correct
The revaluation entry at the account receivanle was not correct (It seem that the registered payment at 31 March 2021 not counted on the balance of the account receivable)

Try to read the code, i suspect that the transaction of 31 March 2021 is not included in the revaluation because "date < %" in the query to fetch the move lines.

Expected:
The registered payment on 31 March 2021 should deduct the balance of receivable and the unrealize exchange diff to be correct.

If you create a new cut-off type "accrued revenue" at a certain cut-off date in order to move the income and the taxes to prior period the field "tax_ids" from the origin move is empty. This will lead to wrong tax reports in the period of the cut-off.

Module

account_cutoff_start_end_dates

Describe the bug

The cut-off moves will be created but the tax_ids and therefore the tax_tag_ids on the lines will miss.

Affected versions:
at least 15.0

To Reproduce

Configure the accounts in the settings (check module configuration advises)
Steps to reproduce the behavior:
Create a invoice with the date "2023-02-10"
Enter a line with start date "2023-01-01" and end date "2023-01-31"
Enter also a sale tax on the line (with configured "tag_ids").
Go to Accounting > Accounting > Cut-Offs > Accrued Revenues
Click on "Create"
Enter the cut-off date "2023-01-31".
Click on re-generate lines.
Click on "Create Journal Entry"
Check the move lines with the income account (cut-off value) and the tax account.
The tax on the line of the deferred revenue account is missing (also tax grid).

Expected behavior
The tax should be on the lines of the cut off account move lines.

Additional context
Video:
https://drive.google.com/file/d/1tSjaz6J86ZtLiUL9dtJSCnOyvaHPjEXB/view

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0

Modules to migrate

• account_cutoff_accrual_picking
• account_cutoff_base
• account_invoice_start_end_dates

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Working on the migration of the cutoff modules for v13 these last days, I had some thoughts about structural changes that I propose to make when we'll migrate to odoo 14:

1. Integrate account_cutoff_accrual_base in account_cutoff_base

2. Merge account_cutoff_prepaid and account_cutoff_accrual_dates. The name I propose for the merged module would be account_cutoff_start_end_dates.

I think it will make things easier to understand for users.

Please tell me what you think. Feel free to share other ideas that you have for the future.

Read OCA/maintainer-tools#29 to know more about it

On branch 11 and 12 for account_multicurrency_revaluation fixing the report currency unrealized like #104

Module

account_cutoff_start_end_dates

Describe the bug

cutoff_days = fields.Integer(
    readonly=True,
    help="In regular mode, this is the number of days after the "
    "cut-off date. In forecast mode, this is the number of days "
    "between the start date and the end date.",
)  # Old name: prepaid_days

The above field needs to be migrated,

and the below field from https://github.com/OCA/account-closing/blob/11.0/account_cutoff_prepaid/models/account_cutoff.py#L179

is missing in the new module:

    move_line_id = fields.Many2one(
        'account.move.line', string='Account Move Line', readonly=True)

maybe this field should be migrated too?

To Reproduce

Affected versions: 14.0

Expected behavior
old data in prepaid_days must be migrated in cutoff_days and maybe move_line_id too

I'm giving a try to the account_fscal_year_closing in version 14.0.

I'm not sure if it's related to my data or something else I'm getting the following traceback while clicking on calculate button:

As far I understand given a quick analysis I'm not sure if we should add the date on the model account.fiscalyear.closing.unbalanced.move.line or remove it in the move_prepare ?

Erreur:
Odoo Server Error

Traceback (most recent call last):
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
    result = request.dispatch()
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 683, in dispatch
    result = self._call_function(**self.params)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 359, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/service/model.py", line 94, in wrapper
    return f(dbname, *args, **kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 347, in checked_call
    result = self.endpoint(*a, **kw)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 912, in __call__
    return self.method(*args, **kw)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 531, in response_wrap
    response = f(*args, **kw)
  File "/home/pverkest/clients/cgi/cgi-erp/addons-contrib/web/controllers/main.py", line 1393, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/addons-contrib/web/controllers/main.py", line 1381, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 396, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 383, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/home/pverkest/clients/cgi/cgi-erp/addons-contrib/account_fiscal_year_closing/models/account_fiscalyear_closing.py", line 328, in button_calculate
    res = self.calculate()
  File "/home/pverkest/clients/cgi/cgi-erp/addons-contrib/account_fiscal_year_closing/models/account_fiscalyear_closing.py", line 315, in calculate
    return self._show_unbalanced_move_wizard(data)
  File "/home/pverkest/clients/cgi/cgi-erp/addons-contrib/account_fiscal_year_closing/models/account_fiscalyear_closing.py", line 295, in _show_unbalanced_move_wizard
    wizard = self.env["account.fiscalyear.closing.unbalanced.move"].create(data)
  File "<decorator-gen-65>", line 2, in create
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 344, in _model_create_multi
    return create(self, [arg])
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/addons/base/models/ir_fields.py", line 533, in create
    recs = super().create(vals_list)
  File "<decorator-gen-13>", line 2, in create
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 345, in _model_create_multi
    return create(self, arg)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/models.py", line 3868, in create
    records = self._create(data_list)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/models.py", line 4028, in _create
    for other, data in zip(others, data_list)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/fields.py", line 3038, in create
    self.write_batch(record_values, True)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/fields.py", line 3064, in write_batch
    return self.write_real(records_commands_list, create)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/fields.py", line 3236, in write_real
    flush()
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/fields.py", line 3200, in flush
    comodel.create(to_create)
  File "<decorator-gen-65>", line 2, in create
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 345, in _model_create_multi
    return create(self, arg)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/addons/base/models/ir_fields.py", line 533, in create
    recs = super().create(vals_list)
  File "<decorator-gen-13>", line 2, in create
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/api.py", line 345, in _model_create_multi
    return create(self, arg)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/models.py", line 3825, in create
    raise ValueError("Invalid field %r on model %r" % (key, self._name))
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 639, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/home/pverkest/clients/cgi/cgi-erp/ocb/odoo/http.py", line 315, in _handle_exception
    raise exception.with_traceback(None) from new_cause
ValueError: Invalid field 'date' on model 'account.fiscalyear.closing.unbalanced.move.line'

We think the set-up of this module in the company settings is far too complex and can generate errors in reports.

It has been initially implemented this way in order to be able to automatise the provisioning entry that you must post in some country (ie: France) on top on the revaluation entry.

However, the second entry is not required in all countries and it is really basic (just 2 lines). The really complexity is the calculation of the revaluation er account and the report showing the details of this calculation.

So I suggest to get rid of the functionnality allowing you to post the provision entry so the user can only fill 2 default account instead of 6 in the company settings.

I propose the following changes:

• simplifing the view to this one :
  
• hide deprecated fields
  Since we cannot delete fields in v7 we will simply add a check box mecanism th hide the too complex settings but it will remain possible to unhide it thanks to a checkbox in the accounting settings
  note : the idea is to delete these fields + method linked whenever this module will be ported to v8.
• add few comments to help end-users

For bank account, partner_id is replaced by False, but amount is not sumed.
File account_multicurrency_revaluation\model\account.py , method def compute_revaluations , code line accounts[account_id][partner_id][currency_id] = line should be replaced by code below :

            #accounts[account_id][partner_id][currency_id] = line
            org_line = accounts[account_id][partner_id][currency_id]
            if not org_line:
                line['partner_id'] = partner_id
                accounts[account_id][partner_id][currency_id] = line
            else: 
                org_line['balance'] += line['balance']
                org_line['debit'] += line['debit']
                org_line['credit'] += line['credit']
                org_line['foreign_balance'] += line['foreign_balance']

I don't understand the logic of journal entries of currency Revaluation Module. As I understand, it should find the amounts held in different currency and make adjustment journal entry like: If my base currency is USD and I had 1000 EUR Cash and rate was 1EUR=1.3USD, and now rate went to 1.1 USD, when I use the option of revaluation in this module, it should credit the cash account by 200 and debit the Loss account(configured in company settings as needed) with 200. So that I will have a real picture on my ledger as before my balance was 1300, now it will be 1100 USD. Instead of this, this module makes the journal entry with total amounts, and closes my currency account. Is it revaluation or period closing of an account?

See comment here:

• #88 (comment)

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• account_cutoff_accrual_base - By @rven - #99
• account_cutoff_base - By @jeroen7s - #90
• account_cutoff_prepaid - By @jimhoefnagels - #93
• account_invoice_accrual - By @sbejaoui - #113
• account_invoice_start_end_dates - By @jeroen7s - #89
• account_multicurrency_revaluation - By @hbto - #88

ISSUE:

The module considers both in Prepaid Revenue and Prepaid Expense (o Accrued) lines of MISC entry in which are indicated start and end dates, duplicating cutoff entries.

HOW TO REPRODUCE:

If I create a MISC journal entry entering start and end date on a line

and then i create Prepaid Expense (in my example) adding Miscellaneus Journal as Source Journal, it correclty considers the MISC created before

but if i create also Prepaid Revenue adding also here Miscellaneus Journal as Source Journal, it considers again the previous MISC duplicating the jorunal entry of prepayments

There are many cases in which i can use Miscellaneus Journal to enter expenses or incomes referred to a start and end date without going through an invoice (vendor or customer).

any one can migrate account_fiscal_year_closing for 13 ?

Module

account_cut_off_start_end_date

Affected version 14 CE

Steps to reproduce the behavior:

1. open menu "Cut-off Account Mapping"
2. Click on any record of the Account Mapping
3. Appear an error " TypeError: Cannot read properties of undefined (reading '0') " as below

After running wizard for Revaluation on Receivable Account and adding new journal entries
the wizard does not compute properly the xrate difference.
In this video this can be observed.

https://youtu.be/FHpR4jO03-4

Regards.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-17.0

Modules to migrate

• account_cutoff_accrual_subscription
• account_cutoff_base - By @lethuthao2403 - #284
• account_cutoff_picking - By @lethuthao2403 - #285
• account_cutoff_start_end_dates - By @lethuthao2403 - #287
• account_invoice_start_end_dates - By @lethuthao2403 - #286

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Hello, when we have created a year-end closing and we have added the transaction configuration. When saving or calculating the year-end closing it gives the attached error. And it does not create the year-end closing.

Thank you.

@pedrobaeza This accounting closure is compatible with the OCA sys and MIS builder? Since it is understood that the OCA sys and MIS builder calculate the 129 in real time, and that if the closure is used the data in the OCA sys and MIS builder reports, the data of the 129 would be duplicated.

Currently all the agencies and consultancies request the printing of the annual accounting journals (they even request it because they say it is by law) including the opening and closing, so currently you have to be getting a sys as of 12/31 of the previous year by pasting in the excel as entry nº1, then renumber from entry nº2 and then the sys as of 12/31 of the closed year and paste in the excel as closing entry, I believe that this is not a very suitable procedure for an accounting closing.

It is right? Is closure going to be implemented from now on?

@fclementic2c @grindtildeath can you have a look?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0

Modules to migrate

• account_cutoff_base - By @dzungtran89 - #213
• account_cutoff_picking (ex account_cutoff_accrual_picking) - By @alexis-via - #230
• account_cutoff_accrual_subscription
• account_cutoff_base - By @dzungtran89 - #213
• account_cutoff_start_end_dates - By @dzungtran89 - #216
• account_invoice_start_end_dates - By @FrancoMaxime - #206
• account_multicurrency_revaluation

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Hello,
what are the Provision B.S accounts & Provision P&L accounts?
how can we use them?

Permissions for multicompany seem to be broken.

Module

account_fiscal_year_closing

Describe the bug

Even the admin user seems unable to create account.fiscalyear.closing.template records, for a specific company, if multiple companies are present (even if the currently selected company is the correct one).

If the company is omitted from the template, a similare error is shown when creating a ccount.fiscalyear.closing using the same template.

To Reproduce

Affected versions:

• 14.0

Steps to reproduce the behavior:

1. Install l10n_it and account_fiscal_year_closing
2. Enable "Show Full Accounting Features" for the user
3. Invoicing -> Configuration -> Closing Templates
4. Make sure that "IT Company" is the current company for the user
5. Create a new template specifying "IT Company" as company and save
6. This fails (see screenshot 1)
7. Remove the company and save the tamplate
8. Invoicing -> Accounting -> Fiscal year closing
9. Create a new closing, specifying the template created above
10. Make sure the company is "IT Company", then Save
11. This fails (see screenshot 2)

First error message is:

Due to security restrictions, you are not allowed to access 'Fiscal year closing template' (account.fiscalyear.closing.template) records.

Records: Chiusura (id=3)
User: Mitchell Admin (id=2)

This restriction is due to the following rules:

• Fiscal year closing template multi-company

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.

Second error message is:

Due to security restrictions, you are not allowed to create 'Fiscal year closing' (account.fiscalyear.closing) records.

Records: 2021-01-01-2021-12-31 (id=3)
User: Mitchell Admin (id=2)

This restriction is due to the following rules:

• Fiscal year closing multi-company

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.

Expected behavior
Multi-company issues should not occur.

Additional context
Fedora Linux 34, Python 3.9.13

screenshot 1

screenshot 2

Hello everyone,
we've noticed that most modules from v11 are not aligned to their v10 and v12 counterparts.
More accurately, it seems that updates that were introduced in v10 and then ported to v12 via #112 are totally missing from v11, where many modules seem untouched from the day they were migrated (not considering translations, I mean).

Is there a reason behind this? Or is it because v11 is quite unused, so noone took care to keep it updated and aligned to v10 and v12?

I'm asking because we'd need to use some modules that our customers already use (v12), but we'd need them to be installable on v11. So we installed them (v11 of course, not v12), but a few features seemed missing (for example, button "Re-Generate Lines" in account.cutoff form view), so we noticed that the reason behind it was the aforementioned unalignment.

So, before opening a PR to align the code on v11 from v12, I would like to know whether it was a deliberate choice, because (if it was) it wouldn't be worth the effort 😅

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

Modules to migrate

• account_cutoff_accrual_base
• account_cutoff_accrual_dates
• account_cutoff_accrual_picking
• account_cutoff_base
• account_cutoff_prepaid
• account_invoice_start_end_dates
• account_multicurrency_revaluation
• account_multicurrency_revaluation - By @phuctranfxvn - #150

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

it looks like a bug in the code (models/account_fiscalyear_closing.py line 555):

  @api.model
   def create(self, vals):
       if "dest_account_id" in vals:
           vals["dest_account_id"] = vals["dest_account_id"][0]
       res = super(AccountFiscalyearClosingMapping, self).create(vals)
       return res

   def write(self, vals):
       if "dest_account_id" in vals:
           vals["dest_account_id"] = vals["dest_account_id"][0]
       res = super(AccountFiscalyearClosingMapping, self).write(vals)
       return res

dest_account_id is a Many2one field, it doesn't return a list!!! This commit wasn't tested?

Module

account_fiscal_year_closing

To Reproduce

Affected versions: 14

Steps to reproduce the behavior:

1. create new closing
2. add/Edit "Destination account" in move config
3. save

Hi Team,

I was recently testing account_revaluation module for multi company having multi currency and found a bug.

The details are as follows:

• Account periods are always searched from user's company instead of selected journal.
  "company = user_obj.browse(cr, uid, uid).company_id"
  accounting to me this should be
  "company = form.journal_id.company_id or user_obj.browse(cr, uid, uid).company_id"

It should search period for company in journal rather than logged in user.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• account_cutoff_accrual_base - By @OleksandrPaziuk - #62
• account_cutoff_accrual_picking
• account_cutoff_base - By @OleksandrPaziuk - #61
• account_cutoff_prepaid - By @OleksandrPaziuk - #60
• account_fiscal_year_closing - By @jbeficent - #58 No need of making the "account FY closing"
• account_invoice_start_end_dates - By @OleksandrPaziuk - #63
• account_multicurrency_revaluation - By @OleksandrPaziuk - #64
• account_multicurrency_revaluation_report

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Modules to migrate

• account_cutoff_base #37 by @alexis-via
• account_cutoff_accrual_base - By @grindtildeath - #42
• account_cutoff_accrual_picking
• account_cutoff_prepaid #37 by @alexis-via
• account_invoice_accrual WIP by @adrienpeiffer
• account_multicurrency_revaluation_report
• account_multicurrency_revaluation - By @grindtildeath - #46

When I have a multicompany env if I create different chart for every company, the chart si load only for the firtst company.
I see the domain si not valid because chart_template_ids not exist and the right field is company_id to load only chat of the company you are logged

• [10.0 ]

• [12.0 ] #180

There is no title for the "must have date" parameter when another parameter is present

Module

account_invoice_start_end_dates

Describe the bug

When another module adds a parameter to the accounting tab,
the title of the boolean field "must have date" disappears

To Reproduce

Affected versions: 16.0

Steps to reproduce the behavior:

1. Install a module adding a parameter to the accounting tab
2. Go to the accounting tab of a product
3. Notice that the field title has disappeared

Expected behavior
See field title "must have date", possibly frame in a group