The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Germany and Switzerland both use the DIN5008 paper layout and encoutered some issues while printing an invoice's pdf.
In Germany, the display of pdf invoices changed with v16.0. The header and footer would always display borders, which would mess up the rest of the display.
Adding the 'table-borderless' class solved this problem.
In l10n_ch, this issue was also encountered, and the general display of the qr bill page was set off. This is problematic since this display is highly rigid.
Those changes seem to be linked to wkhtmltopdf unability to process some of the Bootstrap5 changes.
While waiting for a more long term solution regarding wkhtmltopdf and BS5 compatibility, calling directly the adequate external_layout allows us to get back a correct QR Bill.
task-3037921
closesodoo/odoo#105464
X-original-commit: 627b0f581801705f8e2d2f2bead5176e9af884f8
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Modules:
- hr_maintenance;
- maintenance;
- l10n_ch;
- l10n_generic_coa
- l10n_il.
The plural of "equipment" is "equipment" and not "equipments"
changes in the enterprise version: odoo/enterprise#31498
Remark:
Runbot test log:
Two fields (equipment_count, equipment_ids) of maintenance.equipment.category() have the same label: Equipment. [Modules: maintenance and maintenance]
Two fields (equipment_count, equipment_ids) of hr.employee() have the same label: Equipment. [Modules: hr_maintenance and hr_maintenance]
Using "Equipment Count" to differentiate them
opw-2981186
closesodoo/odoo#100558
Signed-off-by: Adrien Widart <awt@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Following reportalypse, reorder the menu items in order to bring
some consistency to the report menu.
Also clean the menu items by removing all the menu items no longer
used since most reports are now selectable by going on the generic
reports and then switching to localized ones.
Task id #2965755closesodoo/odoo#99210
Related: odoo/enterprise#30854
Related: odoo/upgrade#3831
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Creditor Reference is one of the 3 allowed references type in swiss QR-Bills (with None and QR-Reference)
It is used with normal IBAN (QR-Reference must be used only with special QR-IBAN)
Fixes#71578Closes#81269closesodoo/odoo#95518
X-original-commit: 8e1d86dcb10aebc1be1a318126492573a4b74331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Just fixing a typo in _render_qweb_pdf_prepare_streams().
closesodoo/odoo#97182
X-original-commit: 9cf1061b9a463e67e46468b5bf83a0e2059ded77
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
The only option to print a QR Invoice was to go on the invoice page and to click on the Print QR Button.
This PR allows for a user to print multiple QR codes, selected from the Invoices view.
The download occurs normally if all invoices are valid and QR-printable.
A wizard opens when the whole invoice selection isn't valid. It allows to download the invoices as a single pdf or to see a list of the ones that could not be printed in the QR format.
The wizard's text depends on the number of QR-valid, ISR-valid and classic (non QR, non ISR) invoices that the user tried to print.
All invoices for which a print is asked will be printed with a QR bill if it is possible. If not, this will check if printing in the ISR format is possible. Lastly, if none is possible, the classic invoice will be printed.
The behaviour allowed for the removal of the QR PRINT and ISR PRINT buttons on the single invoice view, for a behaviour closer to the original guidelines.
Bills can't be QR printed.
Corrected QR-Bill CSS.
task-2726507
closesodoo/odoo#82341
Signed-off-by: Laurent Smet <las@odoo.com>
To reproduce
============
- Create a company with a complete Swiss address (street, city, zip and country).
- Install the l10n_ch modules and install the Swiss plan comptable in the Settings of the Accounting app.
- Go to Accounting > Configuration > Settings > Activate the "QR codes" > Save
- Go to Accounting > Configuration > Journals > Choose the journal for the invoices > In "Advanced settings" verify that the communication type is "Based on invoice" and the communication standard is "Switzerland"
- Go to Accounting > Configuration > Journals > Select your bank journal(s) > Verify that you have set up your bank account number and the name of the bank
- Go to the Contact app > Configuration > Bank Accounts > Choose the one you use for the QR-bills > Edit > In "ISR Client Identification Number" refer a client number and make sure account type is 'IBAN' > Save.
- Verify that you have a complete address on the contact form of the customer (street, city, zip and country).
- create multiple invoices for this client
- try to print QR-bill for these invoices at once -> and assert error is raised
Purpose
=======
the `assert len(outlines_pages) == len(res_ids)` fails because the generated pdf
contains only a single invoice.
this issue is caused by the line `<script>document.body.className += " l10n_ch_qr";</script>` in `swissqr_report.xml`,
when `wkhtmltopdf` generates the pdf from html, it doesn't wait for all javascript to finish before rendering the page,
which lead to not execute the script `<script>document.body.className += " l10n_ch_qr";</script>` for some pages then the final pdf
is missing some pages.
Specification
=============
To solve the issue we removed the javascript block `<script>document.body.className += " l10n_ch_qr";</script>` from the template
and move it to python, by setting the body style when generating the html.
opw-2772396
closesodoo/odoo#89835
X-original-commit: a669b4c5f78aa18b87f5adcfc5acca3ce0a76040
Signed-off-by: abla001 <abla@odoo.com>
Canceled and draft entries are the same color as posted entries. They should be in a different color (grey/blue) in order to be distinguished from other invoices/bills.
Amount Due, a.k.a. amount_residual(_signed), is not 0 for draft and canceled entries. It should be 0 since they haven't been posted yet.
A few tests have to be adapted to reflect this change in spec.
Task=2801521
closesodoo/odoo#88295
X-original-commit: 498a4a52b5fbc5466d8d0652db10563ccba55032
Related: odoo/upgrade#3435
Signed-off-by: Laurent Smet <las@odoo.com>
When setting acc_holder_name on the bank account receiving the payment of a QR-bill, acc_holder_name was used instead of the company's name inside the QR-code, but not on the summary text displayed next to it. This fix replaces the company name there as well. The behavior is unchanged when acc_holder_name isn't set.
closesodoo/odoo#88804
X-original-commit: e37d43d52d56e55291f9deb0eb76b5cd3863739e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Localisation modules are converted to English and published in a
separated project on Transifex
https://www.transifex.com/odoo/odoo-15-l10n
Every localisation module will progressively be converted to have the
source in English and translated via Transifex.
This will allow developers to improve the localisations without having
to work with translators directly.
closesodoo/odoo#88439
X-original-commit: e5dfe8613723ba522e20334568c5637188ff2252
Related: odoo/enterprise#26091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Every tax should have a tax repartition line even 0% tax
closesodoo/odoo#85990
X-original-commit: 17e3bd58e519bd40fdc0c7fd431cd1a8f90cf33e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Issue:
Padding impacting all reports since css file imported in common
report assets.
Solution:
part revert of commit: https://github.com/odoo/odoo/commit/69a1289eca79272efe7e53f8b3ad70de6df3d96a
use .swissqr_title and .swissqr_content selectors for most of the CSS
instead of body.l10n_ch_qr that will not work for installation of l10n_ch
that happened with fix 69a1289eca (8 september 2021 up to this fix).
opw-2686597
closesodoo/odoo#83283
X-original-commit: 71ae792d63b57627cc15eadc1e63a7b7a7dfbe70
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Users with Swiss localization have a possibility to create QR_Bills from their invoices, however, PoS currently does not send information about partner_bank_id to the generated invoice, so users can not create
QR_Bill from the invoice that was created by PoS. After this commit, function _get_partner_bank_id will get partner_bank_id in case customer didn't pay for the order fully, and this information will be added to
the invoice, thus, giving user an ability to create a QR-Bill from said invoice.
In case user will try to create a QR-Bill from the invoice that has been fully paid, they will get an error saying that QR-Bill can not be generated on paid invoices. If the user tries to generate QR-Bill from
the invoice that has empty partner_bank_id, they will also get an error notifying them that they should check Recipient Bank field on the invoice.
OPW-2695969
closesodoo/odoo#83456
X-original-commit: 634f90a728cba9ff45c17e471f2b160e939bbd3d
Signed-off-by: Masereel Pierre <pim@odoo.com>
The title's (S)CSS selector was failing to pick up the invoice title,
because it was inside the .swiss_container_v2 while it should be out of that.
opw-2584899
closesodoo/odoo#80873
Signed-off-by: William André (wan) <wan@odoo.com>
Reworked the structure of the HTML and the SCSS
to adhere to the official specs:
- 5mm padding inside the two main sections
- Correct font sizes
- Bold headers
- Increased the Swiss Cross inside the logo (7mm x 7mm)
- Scissors pictogram on the outline
- Dashed borders
Sizes now take the wkhtmltopdf (1/1.25 factor) shrinking
into consideration.
closesodoo/odoo#80544
X-original-commit: f02622684c6a220a425044d8d4a5fd474efdb519
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
When trying to print a Suisse QR bill, if multiple images are presents
in document and they have a url as src, some pictures will not be
displayed.
(Same issue may occur with simple QR code)
Cause:
It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b
Also, adding css class to body by js break wkhtmltopdf.
Solution:
Replace link by base64 image value (use a function to retrieve base64
image instead of image_url).
Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
to this report).
Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
(since generic) to account module.
Move specific logic like `_get_qr_vals` and
`_get_qr_code_generation_params` to specific module (ex: l10n_ch).
extra: Alter some css for better rendering + update unitest.
opw-2620082
closesodoo/odoo#77643
X-original-commit: 699b6eeac993e3a8d97ae7949170f7e18ca05831
Signed-off-by: Olivier Colson <oco@odoo.com>
DIN 5008 is not specific to Germany.
It also applies to Switzerland, Austria (& Lichtenstein).
The goal is to make DIN independent from l10n_de,
for Switzerland and Austria.
closesodoo/odoo#76227
Task: 2613993
Related: odoo/upgrade#2932
Signed-off-by: William André (wan) <wan@odoo.com>
"account_tax_group.xml" and "account_data.xml" data files
have been renamed to "account_tax_group_data.xml"
when containing only tax groups, for compliance with the standard.
AE, AR, AT, BE, BO, BR, CA, CN, CR, CZ,
DE SKR03, DE SKR04, DO, ES, FI, FR, GR,
GT, HN, IL, IN, LT, MA, MX, NL, NO, PA,
PL, PT, RO, SG, SY, TH, TR, UA, UY, VE,
VN.
Part-of: odoo/odoo#77295
Many changes involved several localizations.
Tax groups data files that were missing the country_id:
AR, AU, EC, ET, HR, HU, IT, JP, LU, MN, NZ, SI, UK, ZA
Account_data.xml files being renamed or split to account_tax_group.xml
AT, CH, CL, PE, SK
Tax templates that were missing tax group information:
CH
Tax groups missing that were added:
EC
Part-of: odoo/odoo#77295
The partner created in TestOnchangePostal and the product created in
TestSwissQR were taken from demo data, which might not be installed
in the test environment, so the create_invoice() method could
raise a traceback.
Part-of: odoo/odoo#77295
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit implements improvements in the layout designer, such as addition of a new custom background, adds custom report footer and company details.
task-2355704
closesodoo/odoo#66860
Related: odoo/upgrade#2275
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
In order to not show unnecessary tax groups when configuring a tax,
we'll now filter them to only shows the tax groups that are either
linked to no country, or that are linked to the same country as the tax.
Task id #2206280
Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field
Problem:
The specific fields to a Swiss company appear.
Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.
opw-2504699
closesodoo/odoo#70011
X-original-commit: 326dc3f7001f605d7ebb929740ed8478fce20e7e
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
- records in XML files are now in English language instead of French
- translation for the same will be loaded through *.po files for French, German and Italian
- improved translation for French, German and Italian languages
closes odoo/odoo#67512
Task: 2391988
Related: #67512
Related: odoo/enterprise#16944
Enterprise: https://github.com/odoo/enterprise/pull/16944
Signed-off-by: Josse Colpaert <jco@openerp.com>
Adding this field to the bank journal's form view had been done to ease encoding; yet more fields were left to be set on the related res.partner.bank object (l10n_ch_qr_iban, chf and eur subrscription numbers. In the end, to be consistent, we would have needed to do related fields for all of them as well on the journal. This would have put too many advanced features in a single screen. Instead, we just consider the whole setup needs to be done directly on the res.partner.bank.
Task 2412391
This module had been introduced in stable to add a field to store the QR-IBAN in case it differed from the regular account number. We now merge it into the original module and make it so that the only way to define a QR-IBAN is to populate this field (no more magic with account number).
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
