Prior to this change, if a contenteditable=true element was a child of a
contenteditable=false element, it was always flagged as unremovable=true.
In fact what should happen is that this.editable should be unremovable, but one
of its subchildren can be contenteditable=true while having a parent
contenteditable=false and not be unremovable.
Task-id: 2794990
X-original-commit: 72e2fd7439a0d6e44b5082def35079019371a3b7
Part-of: odoo/odoo#88733
Since [1] when the blog layout was refactored between 12.0 and 13.0, a
negative word spacing was introduced in the blog post snippet with the
big pictures layout.
This commit removes this negative word spacing.
[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72
task-2822436
closesodoo/odoo#88729
X-original-commit: c0e86be9074a0d72e6119801c7992232e9e32068
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce:
• Create Record: Product Category
- Costing Method: Average
- Inventory Valuation: Automated
- Specify a price difference account (may create new account).
- Ensure Stock Interim (Received) account is reconcilable.
• Create Record: Product
- Product Type: Storable
- Cost Price: 1.01
- Product Category: New Product Category
• Create bill with this product, for a quantity of 10.5
-> The is price difference of 0.1
Issue comes from this commit 286ea6b681e9ba77357f91b546052449f6342f20
which doesn't round if there is a discount.
With this commit we isolate the latter case in order to keep the
price unit rounded if there is no discount.
closesodoo/odoo#88734
X-original-commit: 643d91ef5ebfb29fde142294ced82c470d42c136
Signed-off-by: Florian Gilbert <flg@odoo.com>
Steps to reproduce:
- Install eCommerce module
- Select company A and set only one pricelist with:
- company = company A
- website = website of company A
- Select company B and set multiple pricelist.
- Switch to company B
- Archive a pricelist
Issue:
Error: "With this action, "Website of company A" website would not
have any pricelist available".
Solution:
Use sudo() when searching websites to don't use multi-company
compliant ir.rule `product_pricelist_comp_rule` (in website_sale) when
getting pricelist_ids (and therefore allow checking all pricelists for
all websites in all companies).
opw-2759069
closesodoo/odoo#88703
X-original-commit: 4b3404087f4541cf52b84ef668da4055da5ad9e2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
When creating a global time off in one resource.calendar A , it will be
propagated on any new resource.calendar B.
However the reverse is not true, if I delete the global time off in
calendar A it will not be deleted in calendar B.
During the work entry generation this is not taken into account, a
contract using calendar A will generate leave work entries because of
the global time off in calendar B.
This is due to a change in PR odoo/enterprise#15091.
The domain is now correct and will only fetch the right leaves.
TaskId-2627378
closesodoo/odoo#88725
X-original-commit: 0bac1d33a25e37ebece69de030b9fd72caa43a02
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
A field order_id has been introduce on account.analytic.line
in https://github.com/odoo/odoo/commit/dc9ef81ab21cbbf232eca1771ab94dd5a54e9345
to allow to group by order
This field was introduce as related readonly=False.
It has the side effect of modifying the order_id on the sale.order.line
each time a timesheet is created and thus trigger computed field that
are based on that field.
Since the field is only declared for a group by it's pointless to
make it modifiable, it will save a lot a useless computation and avoid
some issue with computed field wrongly triggered
closesodoo/odoo#88714
X-original-commit: 6916e541d272fea64fbc49e451f065b9cd614134
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#88692
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit
At each iteration, the `loop_cycle_number` was reset to 0.
This caused the cycle condition to always be the same.
After this commit
The cycle condition will properly make the style cycle.
closesodoo/odoo#88686
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On mass_mailing, the button does not have a specifc width.
Defining a width to the button makes the styling more predictible.
Task-2781002
closesodoo/odoo#88679
X-original-commit: 5f5b806559e06aad7f67b66c8da96d15516fcd52
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The overflow: auto on the container in mass mailing generated a
scrollbar whenever the drag and drop of snippets because
of the drop zones.
Task-2781002
X-original-commit: 2af04ad4798e11bb2c08798dddb04ed32c42992e
Part-of: odoo/odoo#88679
Reduce the content of the title to make sure it fits in a single line.
Task-2781002
X-original-commit: 2b87e5617c4cb25c6593df03b752f0c90814a7ff
Part-of: odoo/odoo#88679
A mechanism is provided by the OdooEditor to circumvent certain problems while
editing links. More specifically, editable zones are patched when editing a
link. This avoids the cursor ending up outside the link whenever the link tag
is emptied.
However, the mechanism does not check if the link is also in the editable zone
before doing so. In translation mode, the editable zones correspond to the
individual translation strings. When translating link texts, this means the
anchor tag containing the translation string is outside the editable zone. The
patching mechanism still applies, resulting in the anchor tag becoming editable
as well.
This causes problems while translating links, for example oDeleteBackward
commands are being rolled back. Checking if the anchor tag is inside the
editable zone resolves the problem.
opw-2780312
closesodoo/odoo#88674
X-original-commit: 99050b26446bbbe949e1fa797210c2a8a68d94cd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
For now `hr_timesheet_graphview` doesn't work with dashboard because
`board` is still in legacy and `hr_timesheet_graphview` in owl.
So we have to create a legacy version of it to adapt it to dashboard.
Similar fix: https://github.com/odoo/odoo/pull/86571/files
opw-2793729
closesodoo/odoo#88673
X-original-commit: 0b298005bebdc4b0de35608749f244e4b96b4f93
Signed-off-by: Xavier <xbo@odoo.com>
Currently, the event sponsor ordering on the website is non-deterministic as it
uses a non-ordered dictionary to accumulate items, which then dictates the
order of display.
We fix that issue by using a OrderedDict that will correctly retain the order.
In addition, we force the sorting of sponsors based on their
event.sponsor.type's sequence first and then based on their own sequence.
The '_order' of event.sponsor is currently 'sequence, sponsor_type_id' which
seems wrong but has to stay that way in order to avoid backend issues.
Indeed, the backend and the "handle widget" do not have the capability to sort
on multiple levels as we would need here (sponsor type sequence, then sponsor
sequence).
To completely fix this issue, we would need to:
- Store the sponsor.type's sequence field on the sponsor (related stored)
- Modify the _order to be sponsor_type_sequence, sequence
- Only allow people to sort event.sponsors within a single category at a time
Those changes would not be doable on a stable branch, hence why we use a local
sorting when displaying sponsors on the website.
Task-2818538
closesodoo/odoo#88633
X-original-commit: c32583a2160a289748616d4b0e49cba2bd5778fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task-2812497 accidentaly removed some CSS rules, causing the dialog not to be
centered properly. This commit put the rules back.
closesodoo/odoo#88653
X-original-commit: 3f8fd3d57c77a7eef41685d007bbc0a20d3bb290
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to follow
- Go to Accounting > Accounting > Sales (account.move.line model)
- Remove any existing group by
- Group by Products
- Select multiples lines of the same product
- Try to modify the account of the select line
-> `this.localData[value] is undefined
Cause of the issue
When grouping by a field not in the view, `list.__data` contains the
groupedBy field value because we fetched the group through a web_read_group
Solution
Filter out absent fields before creating the group datapoint
opw-2784995
closesodoo/odoo#88634
X-original-commit: d65852352ee4163f7097c19ac3c4a479922f32b8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#88594
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since [1] when the fuzzy search was introduced, the candidate words used
for the fuzzy matching were split on non-'\w' (all non alphanumeric
characters + underscore).
This commit adds '-' (hyphen) to the list of characters that should be
considered part of the same word.
Steps to reproduce:
- Specify a product with name 'micro-vis'
- search for 'micro-vis' or 'microvis'
=> Was not returning any match
=> Now returns fuzzy match even for 'micro-vs'
opw-2801704
[1]: https://github.com/odoo/odoo/commit/c6ba756e4b4704089d02434871788a82d90cb195closesodoo/odoo#88591
X-original-commit: 10d54d3c6ba46afa86abac5275a02c4b5ec7d5a1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`
-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs
Cause:
The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.
If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"
Solution:
Use for the New Price the same rounding precision as we use for the Standard Price.
Example:
Product Price/unit
--------------------------
Water 0.14
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000
Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized
Product Price/unit
--------------------------
Water 0.45
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000
Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000
=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price
opw-2724975
closesodoo/odoo#88616
X-original-commit: 2d6f4213af7464c5fe737e2e9265454cf9711020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
This is a view concern and prevents from refactoring the composer model.
Part of task-2390637
closesodoo/odoo#88588
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the `grid` is asked in a window action used when
the user clicks on the stat button to see the timesheets related in
account move form view. When the user clicks on that button he has a
traceback because the grid only exists in the enterprise version and not
in community version.
This commit removes the 'grid' in the `view_mode` of that action since
in community version the grid view does not exist.
closes#88274closesodoo/odoo#88581
X-original-commit: 6613ac1d93dd5bea0cfee6be92082fc9afcee64d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
This owl update is significant: it introduces a change in the way
components are rendered: now, child components check if there is a
current rendering somewhere in their ancestors. If this is the case, the
rendering will be delayed. This prevents lots of issues where a
child components may be in some kind of corrupted state after some state
changes.
closesodoo/odoo#88572
X-original-commit: 93710d082bf860d0ea576fe99db9506af9bb42b0
Related: odoo/enterprise#26135
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
The problem is that we have a limited space in the filename for
differentiating one file from the other. Only the five characters at the
end of the filename are used, this looks like:
<CODICE_FISCALE>_NNNNN.xml (where N is a character a-zA-Z0-9)
The current version utilises the invoice id to get the unique filename.
This has a couple of problems:
- It doesn't utilise the (lowercase) a-z characters
- Draft invoices still have invoice ids
- In a multicompany environment, the invoice ids are not unique to the
company (i.e. another company creating an invoice will increment the
value of the invoice.id on your company)
These above problems mean that we're not currently utilising the hashing
space available to us by the characters of the filename.
The solution is to utilise an ir.sequence, that is used to determine
each filename. This has the benefit of being editable by the user, so if
they continue to get duplications, they can offset them by adjusting the
value of the sequence's next number.
A more descriptive error message and its translation term have also been
added for when a filename duplication occurs.
relates to
closesodoo/odoo#88324
Task-id: 2813957
Ticket-id: 2788927
X-original-commit: d0f8ca31bfc761b09cda3be1c75732a56f031f2c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Since bcf665a291, this helper has moved.
closesodoo/odoo#88559
X-original-commit: 2ac6357073d80fb07c7bd71cfd472d26ea1e5d83
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
On an heavy database searching for company leads or assigned leads can be
costly. Having an OR does not necessarily triggers index usage and query plan
uses an index scan.
It is less costly to do two searches: one for the base domain (based on
commercial entity) and one for the assign domain (based on partner assigned).
Task-2770994
closesodoo/odoo#88538
X-original-commit: 6957d7a57cb3bf25d552d3f8f2760db46ace5e3a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Fixesodoo/odoo#86216
When printing qweb report use the current company.
For example, the company logo printed was always from user company
default instead of the current company.
closesodoo/odoo#86356
X-original-commit: becdd7d54a5dd7dc50ca1458951f98f95b011d56
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, this bug was present in edit mode:
- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.
It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.
Another similar bug was present when clicking the style tab and then
clicking on the theme tab.
About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.
For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.
[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a
task-2794266
closesodoo/odoo#88537
X-original-commit: 52d32e26c34bef10823582ef5c1f840492b73d7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
before this commit:
===================
if there is multi tag on one tax line then condition is not working as expected
see below test code
```
tags
account.account.tag(33, 34)
>>> self.env['account.account.tag'].browse([33]) in tags
True
>>> self.env['account.account.tag'].browse([33, 34]) in tags
False
```
after this commit:
==================
if there is multi tag on one tax line then condition working as expected
see below test code
```tags
account.account.tag(33, 34)
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33]))
True
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33,34]))
True
```
introduced from here https://github.com/odoo/odoo/commit/aa43799ed9e03d473f48c34ee470330e027ae462closesodoo/odoo#88513
X-original-commit: 7cd2b25a7595cecd3b5c6a9d410f4ac31b76e8ac
Signed-off-by: Florian Gilbert <flg@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>
Previously, some lifecycle hooks were not called when using a
ComponentWrapper in an iframe, this is because to know whether we should
call mounted, we check whether the target/el is in the document, but
when using iframes, the document in question is not the top-level
document and so the check returns false.
This commit fixes that by checking if the elements are inside their
ownerDocument instead.
closesodoo/odoo#88435
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit:
In discuss, livechat website visitor info is displayed above thread view topbar.
After this commit:
Livechat website visitor info will be displayed below the thread view topbar.
Task-2668036
closesodoo/odoo#88532
X-original-commit: 5294def72da677c75f980ffcfb1bb50508ee0760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
- isEditable field doesn't makes sense as attachments can't be Edited
- There is a Dead code in attachment_card component
After this commit:
- refactored isEditable to isDeletable
- removed the Dead code
Task-2782079
closesodoo/odoo#87654
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1], when editing cover texts only and saving, the cover
properties values (background, size, etc) were lost. This is because
we prepare the values to save only when one of them is edited... and
editing the cover texts is marking the cover as dirty thus without
the prepared cover properties values.
After this commit, the cover properties in the database are only updated
if the cover is marked as dirty *and* the values to save have been
prepared.
[1]: https://github.com/odoo/odoo/commit/ad59cbd33e0eaf5c7c77f9e5c0b0435917e2c155
task-2792006
X-original-commit: dffe8d2f8809a3e8e841bea1f2164fa42b578906
Part-of: odoo/odoo#88482
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#88468
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Sales flow require a pricelist to work, but the field was
set non required by mistake.
Since this is a stable version, we can only reduce potential problems
through views & create modifications.
The field will be made required again in next version(s).
closesodoo/odoo#88387
X-original-commit: af9f60d6981fb8b010dc60e93561d7af88372f47
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This is a followup of #86567, where we change the computation of
display_name to match the values of name_get(). Forcing its value to
False instead of the empty string causes many regressions in frontend
applications like website_blog.
closesodoo/odoo#88438
X-original-commit: d467881f66b11021005005584854f30059971b6c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The address in a SO report with RTL languages are cutoff, they
overflow the layout of the PDF which makes the address unreadable.
To reproduce the issue:
1. On runbot v15 > make a SO with the recipient in Arabic/Persian/Hebrew language (any language that is RTL)
2. Specify a different delivery/invoicing address than the recipient
3. Print the PDF
Result: Part of the delivery address is cut off
Solution: As for now, two CSS stylesheets are used in the HTML before transforming it to a PDF: *bootstrap.css* & *web.report_assets_common.min.css* (where the latter is mapped in RTL style with RTLCSS). Note that the *web.report_assets_common.min.css* import in itself the bootstrap style BEFORE the RTL mapping. Thus, they both define the `offset-1` class which is used by our problematic component in the HTML/PDF (a `margin-left` for the *bootstrap.css* and a `margin-right` for the *web.report_assets_common.min.css*). Consequently, these 2 margins makes the bootstrap `row` overflow. There are two different margin because the `margin-left` from *bootstrap.css* was translated into `margin-right` in the other CSS when doing the RTL mapping. A quick fix would be to override this undesired `margin-left` and make it null into the sale_report specific CSS style. While it would work, it does not resolve the underlying issue. In normal circumstances, the *bootstrap.css* should not be used into the report. It is in fact included because there is an error into the manifest of the web module (see permalink here-under). The issue comes from a file that was moved during the migration to the OWL framework (see commit 29731b4).
In the end, both fix will be applied on all versions except master. We keep the quickfix in running versions to avoid requiring an update by the client but the quickfix will not be pushed to master.
https://github.com/odoo/odoo/blob/95bcc8472c3f3ddc8a4c7c1ab4a97ddbd471dba0/odoo/addons/base/models/assetsbundle.py#L166
opw-2767445
closesodoo/odoo#88437
X-original-commit: b99df11f5ac2d4ca6e44d0f4963a600d3aef5a55
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
By updating all the fields/keys retrieved by _compute_quantities_dict,
rather than just a group of hardcoded ones, it makes it possible to
efficiently extend the model to add extra fields to compute by it.
closesodoo/odoo#88049
Signed-off-by: Arnold Moyaux <arm@odoo.com>
It is now possible to render multiple popups and most of them
are draggable. However, when the popup is hidden, the Draggable
component fails at onMounted because the limitArea (derived from
the offsetParent) is null. To fix, we first check the limitArea
before proceeding to the rest of onMounted procedure.
This fixes the issue when the pos ui is suddenly disconnected
from the server, and the OfflineErrorPopup blocks the ui and
the user can't get rid of it.
closesodoo/odoo#88373
Signed-off-by: Masereel Pierre <pim@odoo.com>
Observed Behaviour
When loading limited number of products in POS, we have the "database search"
functionnality allowing use to search in non-loaded product. Anyway, using this
method will make all products found in the search available in POS, despite
having set it to "False" on the product page.
Desired Behaviour
This search method should only search on the already checked "available in POS"
products and shouldn't in any case write in the models.
Fix Description
A filter on "available_in_pos" property has been added to the search, and,
because we now only search on already availaible products, rewriting on this
fields isn't necessary. We then decided to add an optional parameters to the
_addProducts method, set to true by default, which allow us to set (or not)
the products as 'available in POS'.
Related Issues/PR
-opw-2766095
closesodoo/odoo#88386
X-original-commit: e19dca22c5740262449ca061d1681eb8555036f0
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
The account used in the Repartition for Credit Notes is wrong for taxes
`IVA(8%) COMPRAS`, `IVA(16%) COMPRAS`, `IVA(8%) VENTAS`, `RETENCION IVA
ARRENDAMIENTO 10.67%`, `RETENCION IVA HONORARIOS 10.67%` and `IVA(0%)
COMPRAS`
Steps to reproduce:
1. Install Accounting app and l10n_mx module
2. Go to Accounting > Configuration > Invoicing > Taxes
3. Open any one of the taxes mentioned above
4. The account in Repartition for Invoices should be the same as the
account in Repartition for Credit Notes
Solution:
Change the default account used in Repartion for Credit Notes
opw-2806228
closesodoo/odoo#88359
X-original-commit: e8dbd07f160dee59117b855ff54d6fb428bf9778
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
abd-msyukyu-odoo