For existing users who had previously disabled the "Lots & Serial
Numbers" settings, by applying this fix: https://github.com/odoo/odoo/pull/138907/commits/376ee1289eba840f1d8b2b6149d933bdedd47518
They will get the user error each time they try to access the settings.
Therefore, we prefer to prevent this and trigger the error only when
necessary.
opw-3452946
closesodoo/odoo#141921
X-original-commit: 608439b09cb68409dec10427d5b927ce0a27d526
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a tracked product with BoM “P1”:
- component: add any storable product e.g “C1”
- byproduct: add any storable product e.g “B1”
- Update the stock of C1
- Update the stock of “P1” with two SN
- use the 2 SN of P1 as component in any MO and mark the MO as done
- Create a new MO to produce 2 units of P1
- Confirm the MO
- Click on “Mass produce”
- Generate two new SN
* First error : The byproduct quantity is not set
- Try to Mark as done the new MO
Problem:
A user error is raised: 'This serial number for product P1 has already
been produced'
When splitting the MO into two, a “stock.move.line” are created with
a qty_done = 1, leading to an error when verifying if the serial_number
of the move_finished has already been produced.
When clicking the "mark as done" button on the MO, the function
"_check_sn_uniqueness" is triggered and since the finished product is
tracked and there is a serial number set in the MO, the function
"_is_finished_sn_already_produced" is called:
https://github.com/odoo/odoo/blob/c84d80cc71ca0e7120dd293bfc56f9027bfdf9fc/addons/mrp/models/mrp_production.py#L2158-L2162
Within this function, we verify if the move lines of the finished move
have a lot and qty_done set. If this condition is met and we do not need
to exclude this move, an error is triggered.
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2063https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2086
Solution:
Set "qty_done" to 1 only within the move lines of the components.
Opw-3566259
closesodoo/odoo#141521
X-original-commit: e0e6aed35d0f75c3ad01fbc329d7189f9e8d82f4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a kit product
- Create a storable product without BoM “P1”
- Create a MO to produce one unit of “P1”
- Add the kit product as component
- confirm the MO
Problem:
The Manufacturing Order is cancelled. This is because the MO contains
a kit product, and we need to generate moves based on its Bill of
Materials. However, at the same time, we cancel and remove the move
associated with the original product, which is no longer relevant.
But We remove it before creating the moves generated from the phantom
product. Consequently, since we cancel the move, the 'compute_state'
of the MO is triggered, and as there is only one 'move_finished' status
in 'cancel,' the status of the MO is set to 'cancel:
https://github.com/odoo/odoo/blob/5c238bbb18c682ff2d25f740aad604feb7bb5bbc/addons/mrp/models/mrp_production.py#L462-L463
Opw-3548464
closesodoo/odoo#140016
X-original-commit: baa0924974fee0115a0bce117141a8096455b88d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In some undeterministic circumstances the tests in
`test_wysiwyg_collaboration.js` tried to load an image with a wrong
url (`/web/image?model=res.users&field=avatar_128&id=undefined`). It
is `undefined` because in the testing context, `this.getSession().uid`
is `undefined`.
It is not necessary to load these images in these tests so this commit
prevents the loading of these images.
runbot-24600
task-3566600
closesodoo/odoo#139958
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit, the warning to inform the user that a product has
become unavailable was the same, whether the user was on the cart or on
the product page. This commit makes sure that the message is adapted to
the context.
closesodoo/odoo#139332
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When adding items to the cart, the server returns warnings that are
never displayed to the customer. This commit makes use of the new
notification system of website_sale to display it.
task-3502911
Part-of: odoo/odoo#139332
Steps to reproduce:
- Install Accounting
- Create a Company located in Italy (e.g. Company A)
- Create another company located in Italy (e.g. Company B)
- Switch to Company A and set its fiscal localization to Italy in Accounting settings
- Switch to Company B and set its fiscal localization to Italy in Accounting settings
- Try to install "Italy - E-invoicing (Withholding)" module (10n_it_edi_withholding")
=> An User Error is raised:
"Incompatible companies on records:
- 'account.tax.repartition.line,688' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company.
- 'account.tax.repartition.line,690' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company.
- 'account.tax.repartition.line,692' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company.
- 'account.tax.repartition.line,694' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company.
- 'account.tax.repartition.line,696' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company."
Cause:
When installing "10n_it_edi_withholding" module, some tax data are updated
for each Italian company.
These data are "generic" (not linked to any company) data, but some treatment
is performed on them for the first Italian company, linking them to the account
ids of that company.
The following companies are then updated with data linked to the first company.
opw-3538921
closesodoo/odoo#141898
X-original-commit: 9939789fd7024d864c365fe8f3ce311b96ba652c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The demo data of point_of_sale module was failing to load when pos_iot
module was installed due to proxy_ip validation error. In fact, the iot
module overrides this field by creating a relationship to iot_ip.
When the demo data is created in the pos, the iot does not yet exist,
so proxy_ip is empty, so it trigger the validation error.
Error validation is triggered only when proxy_ip is empty and
printer_type is set to "iot". In the point_of_sale data demos, we set
printer_type to false, which fixes the problem.
closesodoo/odoo#140457
X-original-commit: 2f1af3a39b0d61dbf7c70e4fbc6421af906854d0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>
On live youtube videos, url are in reality like this:
`https://www.youtube.com/live/<video_id>` which was not properly
caught by the regex in its compute
Reported during OXP
closesodoo/odoo#141910
X-original-commit: fd348c6778138240d67aa778866cd9e4d49c5021
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Each failing of the test "activity menu widget: activity menu with 2 models"
was close to midnight. And that was actually the cause of the error.
Actually, when executing that test very close to midnight, the test activities
are set up for a day and the check happens the day after (actually a few second
after). As we check in this test "overdue", "planned" and "today" activities,
the tested value are not inline anymore with the test setup when switching from
a day to the next (passing midnight). For example, "today" activities become
"overdue" activities. To avoid that we patch the date to be far from midnight.
Task-3592798
closesodoo/odoo#141762
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The support for IAP sandbox platform will soon be dropped, so all
references to it need to be removed.
This reference wasn't necessary in the first place since, in test mode,
the service doesn't require credits to run.
closesodoo/odoo#141939
X-original-commit: 66fcf2bc1360d42baa346d7447caa87ac511d127
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
The cog menu in the control panel (displayed next to breadcrumbs)
has a shortcut, so it is available in the command palette. However,
as is has no text content and no title/tooltip, the command palette
displays "No description provided". This commit adds a tooltip on
the icon, which is thus also displayed in the command palette.
closesodoo/odoo#141913
X-original-commit: 991e2e75d20bbb56b080c97e6b5ca96b746de3f3
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, the templates of the embed live chat were
not translated. This is due to the live chat embed app being
mounted without giving any `translateFn`.
This commit fixes this issue.
opw-3509309
closesodoo/odoo#141869
X-original-commit: 27aa2cb0ad1d279f72838000932d94e91cb436f3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When selecting a purchase order on a vendor bill,
the payment_reference is replaced even it was
manually filled.
Steps:
- Create and confirm a PO
- Create a vendor bill, set the bill ref and
the payment reference (different than bill ref)
- Select PO as purchase_vendor_bill_id
-> payment_reference is replaced by bill ref value
With this commit, we keep the payment_reference
as it is if not empty.
opw-3549673
closesodoo/odoo#141853
X-original-commit: 77a0449938dafdd234ecd5bf469ef3800336ba27
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This commit removes an undesired background on collapsible categories
when they are displayed in the left filter sidebar
task-3593419
closesodoo/odoo#141826
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions:
---------
- 15.0+
Steps to reproduce:
-------------------
1. install project & hr_timesheet;
2. create a follower-only project with timesheets enabled;
3. assign a task to a non-follower with user-level access rights;
4. log in as user;
5. go to timesheets app;
6. add a line.
Issue:
------
The assigned task doesn't show in the search results.
Cause:
------
The task's `allow_timesheets` field is set to be `related` to its
project's `allow_timesheets` field. This field is inaccessible for
private projects the user doesn't follow, so it doesn't show up when
searching tasks assigned to user where `allow_timesheets=True`.
Solution:
---------
Add compute and search methods to have `sudo` access without having to
make to field storable.
opw-3450671
closesodoo/odoo#141760
X-original-commit: 06e67687cf944ea14d38d3bf0272aece15d44faf
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, for some synced users, a weird behavior was happening when an event was created in Microsoft: the event info was being sent to Odoo with a different organizer than 'self.env.user' even though it was the same user creating the event.
After this commit, a condition checking if the event was created in Microsoft is added for skipping the checking since only events created in Odoo can have different organizers during their creation.
Issue from: 3450045
closesodoo/odoo#141481
X-original-commit: 176ca9789b0c2e032773f3ba2c72ab7e2ed24d91
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.
This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.
I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.
Benchmark
|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3 | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80 | 80 | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|
closesodoo/odoo#141301
X-original-commit: 9ed2b69cc06b1da481dfdc376dab50738a0471dd
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit adds the missing neutralisation necessary for the `pos_paytm`
module introduced in [1]
The purpose of the standard neutralisation framework is to allow us to
create database copies that will not interract with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interractions, make sure that they are benign or wont result in actual changes),
or impact the customers of the operator of the production database.
This is mainly useful to allow safe support investigation on database
duplicates.
[1] https://github.com/odoo/odoo/pull/133334closesodoo/odoo#141839
X-original-commit: 8c511a7f95a7fa0a7c1c0610a353eacd0fcc3b83
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Facturae is auto_install and as such if you want to
do e.g. simplified invoices in the PoS, it will give
an error telling that you need a VAT number as it tries
to send it (generate the Facturae) from the PoS.
So, we deactivate Facturae when the invoice is simplified.
closesodoo/odoo#141832
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
In the pos one cannot make a payment that is larger than the
required amount if there is no cash payment option.
In order to check this there is a condition in the `payment_screen`.
The problem is that this condition fails to spot certain cases.
Steps to reproduce:
- open a pos that has only one payment method and this method is `bank`;
- buy an item for 10 $;
- try to pay 11 $;
- notice error popup; ( this is the expected behaviour )
- now try to create another payment line for any amount ( ex 9999 $ )
- as this is a different payment line the error popup will not appear;
--> this is wrong
In this commit we change the condition such that it detects this type of
error too.
closesodoo/odoo#141778
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Current behavior:
When importing a sale order with a product that is not groupable, the
line is not split and the whole quantity is added to one line.
Steps to reproduce:
- Create a new uom category that is not groupable
- Add a new uom to the category
- Create a new product with the uom
- Create a new sale order with the product
- Settle the order in the PoS
- All quantity is on one line
This is also an issue if the product is tracked by serial number. The
popup to fill the serial number will only have one field, even if the
quantity is greater than 1.
opw-3493378
closesodoo/odoo#141302
X-original-commit: 957942fe64391f9df7bee38d179cd1ce75fff787
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Succeeds #140464
Misunderstood `had_failure` and should not have reused it, its goal is
to avoid eagerly aborting some JS tests -- specifically the unit test
suites -- while still logging errors normally (useful when watching
interactively, or for the runbot's own reporting).
So the *checks* added on `had_failure` should in fact be checks on
`_result.exception()`, and as it turns out on `_result.done()`: if a
tour is already marked as successful we can't fail it either.
So we should not, we should log an error (to notify the caller /
runbot) and then bail. While #140464 did improve some things, we could
still lose legit errors and get pages of unhelpful `InvalidStateError`
if a tour would succeed *then* failures would occur, as the guard only
checked that the tour had already failed.
closesodoo/odoo#141815
X-original-commit: 87fcf66203dcbd281470285d648365d33d0e2fca
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Commit [1] implemented an approach for changing style of a list item to normal.
It no longer wrapped the content in a <p> to remove extra spacing to next list
item. Later commit [2] was introduced which did the same thing but in sanatize.
Hence the code added in commit [1] is no longer needed.
This commit removes the redundant code from `setTagName`.
[1]: 03a134c
[2]: 324e138
closesodoo/odoo#141812
X-original-commit: bd1e432dc29be0dec6e52b142d9fb712335209b6
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
-------------------
- Create user with default company A
- User may have related employees, but not in company A
- Go to attendance - click -> New
You will get a traceback related to the sql request of _compute_overtime_hours
Explanation:
------------
- The query needs a non-empty list of employees
Fix:
----
- Don't run the sql query if we haven't defined any employees yet on the attendance
closesodoo/odoo#141808
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Currently, an error occurs when the user tries to open an employees
who checks in but does not check out.
Steps to produce:
1. Install 'hr_attendance'
2. Open Attendence > Attendences > create new
3. Set check In date previous month and no add Check out
4. Open employees > try to open current user
Error: `'<=' not supported between instances of 'bool' and 'datetime.datetime'`
This is because https://github.com/odoo/odoo/pull/140629 added [1] in the
filter, but in certain cases, the `att.check_out` may not be present.
This commit fixes the above issue by filtering attendees who have
a check-out date.
[1]-https://github.com/odoo/odoo/blob/46f2a019bd141389233257f24f0ddae05b0fa008/addons/hr_attendance/models/hr_employee.py#L82
sentry-4616207347
closesodoo/odoo#141771
X-original-commit: b0cb1ad7b43a296b91377df80b30cbd3976553b4
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Installations from the current Debian Bookworm (12.0) on amd64 systems are experiencing problem that prevents
the kernel from being upgraded (e.g. when trying to upgrade to kernel linux-image-6.1.0-10-amd64)
closesodoo/odoo#141588
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit, if we have x2many fields which contain a virtual
record with the many2many_tags widget, a server error will occur during
a search because the "name_search" will be performed with a domain containing
a virtualId.
This commit will therefore filter the virtualId when generating the domain
used by the "name_search".
closesodoo/odoo#141269
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form view with an x2many in non-editable list mode,
creating a record by clicking on "Save&New" allows it to be edited inline
despite the list view not being editable. The purpose of this commit is
to prevent this from happening.
How to reproduce:
- Go to a form view with an x2many field in non-editable list mode
- Add a record
- Edit the new record
- Click on Save&New
- Edit the new record
Before this commit:
The new record is in edition in the list view
After this commit
The new record is not in edition in the list view
Part-of: odoo/odoo#141269
Before this commit, in an editable list view (or in x2many), you need
to click twice on a boolean field to change its value. The first to set
the record to edit and the second to toggle the value.
The purpose of this commit is to simplify this flow by only requiring one click.
How to reproduce:
- Go to a form view with an x2many in editable list mode that contains a boolean field.
- Click on the boolean field of the first record
Before this commit:
The record goes to edition and the value of the field has not changed.
After this commit;
The record goes to edition and the value of the field has changed.
closesodoo/odoo#141153
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, with the synchronization with Outlook active, it was not possible editing the organizer of an event to a different user than yourself or even creating a new event with a different organizer because Outlook didn't accept the change.
After this commit, it is possible creating a new event with this characteristic and changing the event's organizer to a different user too. Changing the organizer will delete the current event and create a new one, and creating a brand new event will create the event directly with the different organizer.
closesodoo/odoo#140820
Task-id: 3450045
X-original-commit: 81601d5
Related: odoo/enterprise#50080
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Main Changes:
Precise (copy) in the name of a duplicate of a delivery carrier
Before:
When we duplicate a delivery carrier, the name of the copy is
exactly the same as the name of the source
After:
When we duplicate a delivery carrier, we append ' (copy)' at the end
of the name for the copy
closesodoo/odoo#140540
Signed-off-by: Mathias Mathy (mama) <mama@odoo.com>
The recent use of owl AutoComplete component in the website builder
broke some things (see [1]). This commit handles this bug:
Steps to reproduce:
- Go to /web?debug=1
- Go to the website app
- Enter edit mode
- Drop the text-image snippet
=> Traceback
This was because the AutoCompleteWithPages extension of website was
inheriting the AutoComplete props whose "value" prop was not optional
but was not used for this case.
This commit goes the easy way: make the original prop optional with the
default value being the empty string.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#141751
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this PR online and offline cache getter where called when not needed.
This PR move the code inside the onWillRender hook to cache the results and
avoid useless computation of getters.
task-3572093
closesodoo/odoo#141750
X-original-commit: 57aa00893cc47456d5eb39f429c83c4069ab0d7e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prior to this commit, there was an unwanted margin before the "Go to
Website" button in `button_box` located in the modal window of the
course parameters.
This commit removes this margin to maintain consistency with the
`button_box` layout.
task-3580610
closesodoo/odoo#141671
X-original-commit: 5530c846bf4c4b79c5e79e943c6859843a53187b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When submitting invoices with a foreign partneer using the fiscal
device, the device will throw an error when the VAT number is not
formatted as per the Kenyan VAT number. In this case, we should only
send the vat number when it matches the format of a Kenyan VAT number.
opw-3557736
closesodoo/odoo#141628
X-original-commit: de77cefd3bbad7e9c56d60ba446156a05331ebf9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
When there are multiple broken XML files in an assets bundle. During the
bundle processing, a template containing the parsing error message is
returned for each XML file that is broken.
Before this commit, each of the returned templates had the same name,
raising another error ("Template already exists in module").
Now, all the returned templates has unique names.
closesodoo/odoo#141568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After the refactor of pos tours all classes in the tours are
removed. The problem is that some instances of `this` were still
kept. This is obviously wrong. In this commit we fix the issue.
closesodoo/odoo#141404
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Before this commit:
1) The `certification` field was visible when `scoring_type` was set to
'No scoring'.
2) The `description` field of the Badge in form view was not taking the full
width of the sheet.
After this commit:
1) The `certification` field will be invisible if `scoring_type` is set to
'No scoring'.
2) The `description` field of the Badge in form view will take the full width of
the sheet.
Task-3367524
closesodoo/odoo#141120
X-original-commit: 094b2c53e8065de383d35bd0725e247345289867
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The header call to action button template was extended by other ones
based on classes that can be changed using the Odoo editor. So if you
changed them, saved then toggle those other template options... you
broke your header.
closesodoo/odoo#141694
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Adds the SST-02 tax report to the Malaysian
localisation
Task id # 2868179
closesodoo/odoo#140030
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When building the windows package, the build process can be accelerated
by increasing the virtual machine memory.
closesodoo/odoo#141730
X-original-commit: 88f2f374897f12c950b9f398715e3da8245332f6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Administrators sometimes machine-translate Odoo into their own language.
In this respect, we should avoid ambiguous wording* that could be poorly
machine-translated.
\*: in this case, the onomatopoeia "Poof!" was misinterpreted by a
machine-translation as a British slur.
opw-3590503
closesodoo/odoo#141723
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The aim of this commit is to make the OSS feature instanciate the taxes
on the the root company .
Context: currently, when a company has a branch, the OSS feature tries
to instanciate the taxes on both the root company and the branch
company.
This was brought up by a constrains that prevents you from instanciating
2 tax with the same name on the same company.
Before the commit:
The feature tries to instanciate the OSS taxes on both the root and
branch company.
After the commit:
The taxes are only instanciated on the root company.
closesodoo/odoo#141347
Task-id: 3573252
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Djamel Touati