- Aug 31, 2023
-
-
roen-odoo authored
Current behavior: When a discount is applied to a product, the receipt shows the price with the discount applied as the base price. Steps to reproduce: - Open PoS - Add a product to the order - Apply a discount to the product with the numpad - Validate the order - Check the receipt, the base price of the product is the price with the discount applied. (https://github.com/odoo/odoo/assets/32939472/eb0998a7-70a1-432a-8909-868d9307c999 ) The price in red should be 70$ (the price without the 5% discount) opw-3463745 closes odoo/odoo#133377 Signed-off-by:
Joseph Caburnay (jcb) <jcb@odoo.com>
-
hmai authored
This commit fixes the issue of animations that got trigger by backspacing, pressing enter and other causes The cause of the issue was a custom historyRevert event that was only used to trigger a widgets_start_request event which ended up restarting the options, which lead to the animation option replaying the animation. We were not able to pinpoint the use of this particular trigger_up as it does not seem to serve any purpose anymore. Since its presence does create a bug, we decided that the best course of action was to remove it. If this commit creates a regression and the original bug comes back, we will reassess the situation. Task-2752421 closes odoo/odoo#131026 Signed-off-by:
David Monjoie (dmo) <dmo@odoo.com>
-
Pedram (PEBR) authored
This commit introduces improvements to the order synchronization mechanism. The changes ensure better error handling and provide a more reliable and informative synchronization process. Key Changes: 1. Enhance `_flush_orders` Method - The `_flush_orders` method now has additional error handling to detect RPC errors during synchronization of multiple orders. If an RPC error is detected and multiple orders are being synced, the method will attempt to send each order to the server individually. 2. Introduce `_flush_orders_retry` Method - This method sends orders to the server one by one and keeps track of the synchronization status (successful, RPC error, or other errors). - It sets the synchronization status to `'connected'`, `'error'`, or `'disconnected'` based on the outcome of individual order synchronization attempts. 3. Improve Error Handling - Enhanced error handling mechanisms to differentiate between various types of errors. - Synchronization status reflects the type of error encountered. opw-3389388 closes odoo/odoo#126662 Signed-off-by:
Joseph Caburnay (jcb) <jcb@odoo.com>
-
Saurabh Mishra authored
During 'l10n_eg_eta' server connection when the 'request_response' is not in proper json format then while decoding 'request_response', the user will face the 'JSONDecodeError Expecting value: line 1 column 1 (char 0)'. We are keeping the 'blocking_level' as 'error' because the occurence of this error will prevent the succession of ongoing operation. Applying the changes will resolve the issue. sentry-4220714667 closes odoo/odoo#123637 Signed-off-by:
Josse Colpaert <jco@odoo.com>
-
Julien Van Roy authored
In Saudi Arabia, the InvoiceLine/ID should not be greater than 6 digits. Using the move.line_id, this limit can be exceeded. Simply count the invoice line ids starting from 1 instead. In master, add a parameter `line_id` to `_get_invoice_line_vals`. closes odoo/odoo#133640 X-original-commit: 94aac2ed Signed-off-by:
Josse Colpaert <jco@odoo.com> Signed-off-by:
Julien Van Roy (juvr) <juvr@odoo.com>
-
- Aug 30, 2023
-
-
Louis Wicket (wil) authored
For some reason, “New” has been translated as “Nieuw” in Bulgarian, but this is not Bulgarian, this is Dutch. This commit replaces all occurrences of “Nieuw” with “Нов”, which is the correct translation for “New” in Bulgarian. closes odoo/odoo#133621 X-original-commit: 73512e95 Related: odoo/enterprise#46568 Signed-off-by:
Louis Wicket (wil) <wil@odoo.com>
-
Benjamin Vray authored
Steps to reproduce the bug. - In website edit mode, add a form snippet to a page. - Add a "number" field within this form. - Modify the label of this field in the options and name it "Field 1". - Add a "text" field to the form. - In the options of the "Text" field, select "Visible only if" for the "visibility" option. - Then, choose "Field 1" and "Is greater than" in the two dropdowns that follow. - Enter "10" in the input below. - Save the page. - Enter "2" in the "Field 1" input. - Bug: The text field is displayed, even though it should only be visible if "Field 1" is greater than 10. This bug exists since the "conditionally show form fields" feature was added to Website (in this commit [1]). The bug happened because we were comparing strings instead of numbers. [1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce opw-3449900 closes odoo/odoo#133579 Signed-off-by:
Quentin Smetz (qsm) <qsm@odoo.com>
-
Louis (loco) authored
This reverts [this commit]. Indeed, [this commit] was too restrictive on the visibility dependencies and blocked the creation of some conditions. Example: - Add a form on the website. - Add two fields and rename them (by "test" for example). - Change the visibility of the first one and set it to "Visible only if Your Name is equal to Boule" - Change the visibility of the second one and set it to "Visible only if Your Name is equal to Bill" -> The field "test" will be visible if "Your name" is "Boule" or "Bill". [this commit]: https://github.com/odoo/odoo/commit/acb4a2764ca31a856d452e788afe4cb99d7d54af closes odoo/odoo#133011 Signed-off-by:
Arthur Detroux (ard) <ard@odoo.com>
-
Adrien Widart (awt) authored
When posting again an account move related to an expense, the sheet's state and the expense's state won't be updated To reproduce the issue: 1. Create an expense - Paid By: Company 2. Create the related report 3. Submit to manager, Approve, Post Journal Entries 4. Open the related journal entry 5. Reset & Post Error: States of both expense and sheet are incorrect (sheet: "Posted" instead of "Done", expense: "Approved" instead of "Paid") The state of the expense depends on the one of the sheet: https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L141-L153 The state of the sheet is manually written, each time the user does an action. For instance, when posting the journal entries from the sheet, we update the state of the sheet (which will change the state of the expense, as shown in the above `compute`) https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L642-L643 https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L1164-L1165 Same thing will happen when resetting the AM to draft: https://github.com/odoo/odoo/blob/f6a13938f904f275b0360507b7ec987ef3bc2ddc/addons/hr_expense/models/account_move.py#L16-L20 But here is the issue: nothing updates the expense/sheet states when posting again the AM OPW-3322836 closes odoo/odoo#131060 Signed-off-by:
Josse Colpaert <jco@odoo.com>
-
odoo authored
Description of the issue/feature this PR addresses: In project module, if milestone name is long then name is overflowing. Current behavior before PR: milestone name is overflowing when name is too long. Desired behavior after PR is merged: when milestone name is long it would show with '...' format. Fix: add some bootstrap class so that long name should be formatted in '...' . task-3217427 closes odoo/odoo#116811 Signed-off-by:
Xavier Bol (xbo) <xbo@odoo.com>
-
odoo authored
Description of the issue/feature this PR addresses: when logged in user name is too long then it take whole header to display it name. Current behavior before PR: whole header is occupied when username is long. Desired behavior after PR is merged: when username is long it would show with '...' format. Fix: some property is added in oe_topbar_name class to display the username in short and '...' format task-3217427 Part-of: odoo/odoo#116811
-
Romain Derie authored
There were 2 errors fixed by this commit: 1. The form registry fields added in [1] and [2] in Odoo 13 had a `string` attribute translated with `_t()` while now it should be translated with `_lt()`. It was surely working in Odoo 13 but not anymore. It's not worth investigating to be sure. 2. The IMP done at [3] added a lot of fields but all of those forgot the `_t()`/`_lt()` translation. Note that: 1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done as it was not targetting the correct version... and only fixed one of many occurences. [1]: https://github.com/odoo/odoo/pull/32565 [2]: https://github.com/odoo/enterprise/pull/4063 [3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee [4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687 opw-3471873 closes odoo/odoo#132975 Related: odoo/enterprise#46206 Signed-off-by:
Quentin Smetz (qsm) <qsm@odoo.com>
-
Romain Derie authored
Somehow, there is not .pot file for this module while there is a translated term. A proper investigation wasn't made, but here is the history: - The "Project" translatable term was added in JS with commit [1] in April 2019 as an IMP in master so there was no addition in the `.pot` file, as expected. - The `.pot` file was added by a `[I18N] export saas-12.4 terms` commit at [2] in Augustus 2019. - The `.pot` file was removed by a `[I18N] export 15.0 source` commit at [3] in September 2021. This was probably an error as the "Project" term from this module was never removed and always existed since it was added in 2019. [1]: https://github.com/odoo/odoo/commit/6df3ba8b22ff16e9fd8ad6d87ea55e7eaf13e67b#diff-529f47293f2a178209115a2bc74ce79c5a880e58497a5e9d86ad4d7fd29676baR17 [2]: https://github.com/odoo/odoo/commit/8be6470a826fc6e467a3bef1696d236249ca29f9#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2R1 [3]: https://github.com/odoo/odoo/commit/63e6807437295519a0f4705fb88644d6d557ca3a#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2L1 Part-of: odoo/odoo#132975
-
Victor Piryns (pivi) authored
Issue: In the project's portal view, if the user is previewing his tasks of a project with a specific order that is not date or name, and then goes back to the project list view via the breadcrumb, he is met with an error 500. Steps to reproduce: - Install Project - With the portal user, go to Project - Click on a project and sort the task by 'project' - Go back to the project view via the breadcrumbs. - Error 500 Cause: Due to the definition of the url of the breadcrumbs which is set with `keep_query` which keeps the arguments of the url. The issue with that is that for the project list view, some of the sort arguments are not defined, as they are only present in the task view. So if we sort based on 'project' there is a `KeyError` in the controller of the project portal view. Fix: If the `sortby` is not one of the valid keys, we fallback on 'date' sorting, which is the behaviour in case when there is no `sortby` argument in the url. This will keep the `sortby` in the arguments of the URL, but just ignoring it. This is better UX than having a hard redirection, because if the user decides to click on a project, the tasks will be sorted with his previous order specified, which is usually the wanted behaviour. Affected versions: 15.0 -> 16.0 opw-3425342 closes odoo/odoo#129016 Signed-off-by:
Xavier Bol (xbo) <xbo@odoo.com>
-
Ricardo Gomes Rodrigues (rigr) authored
A new text has been introduced in 863eba62 but not added in the .pot file, this commit fixes this. closes odoo/odoo#133571 Signed-off-by:
Florian Gilbert (flg) <flg@odoo.com>
-
MerlinGuillaume authored
The inherited field of a custom field cannot be deleted Steps to reproduce: 1. Install Contacts and Studio 2. Go to Contacts and open any contact 3. Toggle Studio 4. Add a field of any type in the view, remove it and close Studio 5. Go to Settings > Technical > Database Structure > Fields and search for `x_studio` Solution: Mark the inherited field as manual if its parent field is manual and allow the deletion of inherited custom field if we also delete its dependency Problem: The inherited field was not marked as custom so it was impossible to delete it opw-3093581 closes odoo/odoo#130420 Signed-off-by:
Raphael Collet <rco@odoo.com>
-
- Aug 29, 2023
-
-
Ricardo Gomes Rodrigues (rigr) authored
The condition to create is wrongly evaluated and does not take into account the country code and the picking type code. This commit fixes this by reordering the conditions. closes odoo/odoo#133161 X-original-commit: 30b00e5c Signed-off-by:
Josse Colpaert <jco@odoo.com> Signed-off-by:
Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
-
Benjamin Hanquin (beha) authored
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| closes odoo/odoo#129363 Signed-off-by:
William Henrotin (whe) <whe@odoo.com>
-
roen-odoo authored
Current behavior: If you set a specific sale_order_item for an employee on a project, and create a timesheet line from the "My Timesheets" menu, the sale_order_item will not be the one you selected for this employee. This happens because when you create a timesheet line from the "My Timesheets" menu, the employee is not set on the timesheet line. To fix this we fallback on the user's employee when creating a timesheet line from the "My Timesheets" menu. Steps to reproduce: - Make sure you'r logged in as Mitchel Admin - Create a service product that create project and tasks - Create a sale order with this product - Go to the project and set a sale order item for Mitchel Admin in the invoicing tab - Go to the "My Timesheets" menu and click "Add Line" - Select the project you created - The sale order item will not be autofilled with the one set on the invoicing tab of the project. opw-3463849 closes odoo/odoo#133478 Signed-off-by:
Xavier Bol (xbo) <xbo@odoo.com>
-
Nicolas Lempereur authored
After eb3dcd60cb88f190d6398d7cadfb7852eecf909c is_html_empty was accepted in document layout and would no longer cause an error when using "Configure Document Layout" wizard. If l10n_de is installed, this caused an error itself in "Configure Document Layout" because of the content of the external_layout_din5008 that itself use the "company" variable if available (and in the given case, this is a NewId base.document.layout record). To fix this issue, this commit backports the 16.0 forward-port of the referenced commit (5f1ad0c1). opw-3433583 closes odoo/odoo#133447 Signed-off-by:
Nicolas Lempereur (nle) <nle@odoo.com>
-
Christophe Simonis authored
Don't do it only at install. closes odoo/odoo#133364 X-original-commit: 5add840b Signed-off-by:
Nicolas Seinlet (nse) <nse@odoo.com> Signed-off-by:
Christophe Simonis (chs) <chs@odoo.com>
-
Guillaume (gdi) authored
Since [this commit], it's now possible to edit a media when it's in a parent that is not editable thanks to `o_editable_media` class. Unfortunately, these changes make the new class bypass the potential `data-exclude` defined in the XML option declaration. So if the target looks like that: ```html <img class="o_editable_media odoo"/> ``` and the XML option declaration has a `data-exclude=".odoo"`, the option will still be displayed. This commit corrects the way the `o_editable_media` class works, so that it only bypasses the `.o_not_editable` but not the entire exclude. [this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904 task-3476644 closes odoo/odoo#132849 Signed-off-by:
Quentin Smetz (qsm) <qsm@odoo.com>
-
Benjamin Vray authored
After this commit, we prevent the slideshow from appearing when clicking on an "Images Wall" snippet image that has been set as a link. Steps to reproduce the bug: - Drag and drop an "Images Wall" snippet onto the page. - Add some images in the snippet. - Click on an image within the snippet. - In the editor text toolbar, click on the "Link" button. - Set the URL of the link to "/contactus". - Click on the "Save" button in the modal. - Save the page. - Click on the image with the link. - Bug: The slideshow briefly appears before redirecting to the "contact us" page. task-3425624 closes odoo/odoo#133325 X-original-commit: 8b29eabb Signed-off-by:
Colin Louis (loco) <loco@odoo.com>
-
dinolew authored
closes odoo/odoo#133036 X-original-commit: 854923b8 Signed-off-by:
Quentin De Paoli <qdp@odoo.com> Signed-off-by:
Josse Colpaert <jco@odoo.com>
-
Theo VINCENT (thvi) authored
The closing session popup input for bank payment methods throws an error when no cash payment method is configured. Steps to reproduce: - Configure a shop without any cash payment method and with at least one bank payment method - Open a session for that shop - Click on the button to display the closing session popup - In the popup, change the amount of the bank payment method An error is thrown. The fix simply consists in correctly checking if there is a cash payment method. closes odoo/odoo#132473 Task-id: 3468828 Signed-off-by:
Joseph Caburnay (jcb) <jcb@odoo.com>
-
- Aug 28, 2023
-
-
Merel Geens (mege) authored
A check was added to prevent importing records with prefixes of existing modules: https://github.com/odoo/odoo/pull/130825 . This queries the known modules, but non-admin users don't have access to that by default, causing the import to fail for them. Allow the module query regardless of access rights. closes odoo/odoo#133326 X-original-commit: e1dcf886 Signed-off-by:
Raphael Collet <rco@odoo.com> Signed-off-by:
Merel Geens <mege@odoo.com>
-
Walid authored
steps to reproduce it: 1. Create a storable product, add a Purchase vendor with start date = 20/6/2022 and delay = 56 2. Create another storable product, add the same Purchase vendor with start date = 11/01/2023 and delay = 21 3. For both products, add Routes "MTO". 4. Create a SO with those 2 products, and confirm it 5. As you can see, the price of the first product is correctly set but not the second product BUG: This is due of "Order Deadline" (date_order) being set to an old date, which is before the second product date_order. FIX: set max PO date as today opw-3167094 closes odoo/odoo#132892 X-original-commit: 72a17baf Related: odoo/enterprise#46177 Signed-off-by:
William Henrotin (whe) <whe@odoo.com> Signed-off-by:
Walid Hanniche (waha) <waha@odoo.com>
-
Romain Derie authored
This commit introduces a test in Odoo 15 about a broken behavior in Odoo 16 which was not covered by a test. A fix will be shipped alongside this commit forward-port in Odoo 16. The behavior involved here is about: - Having a multi-url defined route - One of those URL not having a model converter - One of those URL having a model converter - Creating a 308 redirect for the URL without model converter Something like this route (real example from the code): ```py @http.route([ '''/shop''', '''/shop/page/<int:page>''', '''/shop/category/<model("product.public.category"):category>''', '''/shop/category/<model("product.public.category"):category>/page/<int:page>''' ], type='http', auth="public", website=True, sitemap=sitemap_shop) ``` And this redirect (real usual example from clients): ```py self.env['website.rewrite'].create({ 'name': 'Test Multi URL 308', 'redirect_type': '308', 'url_from': '/shop', 'url_to': '/magasin', }) ``` In Odoo 15, everything will work as expected: 1. Accessing /shop will redirect to /magasin 2. Accessing /shop/category/categ-1 will not redirect and user will be on /shop/category/categ-1 still But in Odoo 16: In the case described above, acessing the URL with model converter from the route will fail and redirect to a non slugified URL in the form of `/some-url?param=test.model%287%2C%29` which is basically the stringified encoded version of the record `test.model(7,)`. Note: - It doesn't matter if the route is contained in the other, the error will still occur even if `'''/shop'''` was `'''/abc'''`. - Even if all URL from the route have their own 308 redirect, the error will still occur. - It won't have any issue if there is a 308 on the route with model converter: both the one without model converter and other url with model converter will work and won't be impacted. This might be because of a concept of "merging URL" from httpocalypse, see https://github.com/odoo/odoo/commit/347a3ccf763cc6958d5dc1df3168c9c65245736c opw-3450054 opw-3466498 closes odoo/odoo#133183 Signed-off-by:
Romain Derie (rde) <rde@odoo.com>
-
Mahdi Cheikh Rouhou (macr) authored
Issue : When you try to import a big file it will display a blank error. Steps to reproduce the error : 1-install inventory and e-commerce 2-go to products and import records 3-upload the file attached the ticket Reason : Before, there was a type included in the `reason` but now it seems that the error has no type neither a message. Fix: I tried to just output a general error. opw-3410954 closes odoo/odoo#128272 Signed-off-by:
Xavier Morel (xmo) <xmo@odoo.com>
-
Ivan Rasputin authored
Crop widget is implemented as div block that is supposed to be displayed on top of other elements. However, it's not the case for dialogs, because they want to be on top as well (z-index of dialog is 1050 bootstrap [1]) STEPS: * Go to Sales Order * SO * Schedule an activity * Use '/' command * select image * click image * crop image BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up Fix it by increasing z-index for the crop widget [1]: https://github.com/odoo/odoo/blob/9102df15cce455205a19fb7b9a0c36186cc51e3a/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L5524 opw-3391583 closes odoo/odoo#128830 Signed-off-by:
David Monjoie (dmo) <dmo@odoo.com>
-
Maximilien (malb) authored
There was inconsistency in the translation for the words "price unit", with this commit all the "price unit" are translated the same. closes odoo/odoo#132890 Task-id: 3262408 Signed-off-by:
Brice Bartoletti (bib) <bib@odoo.com> Signed-off-by:
Maximilien La Barre (malb) <malb@odoo.com>
-
Maximilien (malb) authored
This PR solve two things: - Preview: due to the hardcoded width the preview didn't take all the page and was push on the left. - PDF: Weird stuff happened with the header, he was hiding information below the header. Task-id: 3262408 Part-of: odoo/odoo#132890
-
Maximilien (malb) authored
Before this PR, when there is no shipping address, the pdf show an empty "Shipping Address" header. By changing the colspan dynamically we can manage to keep the layout like it was and remove the useless section. Task-id: 3262408 Part-of: odoo/odoo#132890
-
Archana Vaghasiya authored
When the user tries to import the invoice file with space on both sides of the date value the error will be generated. Steps to reproduce: 1. Install the `account_edi_ubl_cii` module. 2. Generate one `factur-x.xml` file or import this file https://drive.google.com/file/d/1RCqLT37j2g6LPkauf75LpOzZt64XHd_L/view?usp=drive_link 3. Go to the invoice app and click the `upload` button. 4. Select the `factur-x.xml` file and an error will be generated at the backend and nothing to be imported. This commit fixes the issue by removing the extra spaces in the date value, if user gives the spaces in the invoice file. see- https://github.com/odoo/odoo/blob/a0ea6302a574624604cad7d0903711b30a4802a6/addons/account_edi_ubl_cii/models/account_edi_xml_cii_facturx.py#L315 sentry-4331059603 closes odoo/odoo#132611 X-original-commit: 1f32b5ec Signed-off-by:
Laurent Smet (las) <las@odoo.com>
-
- Aug 27, 2023
-
-
Odoo Translation Bot authored
-
- Aug 25, 2023
-
-
Ricardo Gomes Rodrigues (rigr) authored
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to go from a credit note/refund to an invoice/bill. This is now the case. This is a partial backport of https://github.com/odoo/odoo/pull/103427 task-id 3102251 closes odoo/odoo#132969 Related: odoo/enterprise#46200 Signed-off-by:
Florian Gilbert (flg) <flg@odoo.com>
-
Thomas Lefebvre (thle) authored
Steps to reproduce: ------------------- - create a job position without specifying the company; - being in the first company, create an application for this job position; - being in the second company, create an other application; - go to the job position kanban view; Issue: ------ Despite the selected company, the count for this job application is still two. Solution: --------- Include the allowed companies in the query to count the number of applicants. opw-3453348 closes odoo/odoo#133033 Signed-off-by:
Sofie Gvaladze (sgv) <sgv@odoo.com>
-
Merel Geens (mege) authored
It's possible to specify an existing module as the xml id prefix when importing records from a file. This will result in `ir_module_data` records being created with `noupdate` set to False. When the module is upgraded, these records will be deleted. This can lead to undesired side effects like journal items for accounts imported this way being deleted. This change prevents creating new records linked to existing modules when importing from a file. Instead, the user should either use no prefix or the name of a non-existent module, like `__import__`. opw-3231987 closes odoo/odoo#133053 X-original-commit: 56a53e90 Signed-off-by:
Merel Geens <mege@odoo.com>
-
Brice bib Bartoletti authored
The aim of this commit is to allow any tax tag to be set on a journal item and to allow the user to put tax tag from foreign countries in which they have a VAT number on any tax. The end goal is to allow the user to impact tax reports from several country with the same journal item, avoiding the creation of a whole journal entry and setting the path for some more automation. Context: Our user has a company based in Belgium but has a warehouse in Netherland. Thus, when the company sells anything from that warehouse, it needs to fill the Dutch tax report directly. Moreover, the company needs to fill a grid on the Belgian VAT tax report. That means that the user would need to gather some journal items on both the Belgian tax report and the Dutch tax report. Before this commit: The user can't set tax tag from another country on its tax nor in the same move. After this commit: The user can set tax tags from any country for which its company has a foreign vat number on any tax and in a move Task-id: 3196547 opw-2810712 backport of https://github.com/odoo/odoo/commit/c45a164b136f3f12eb3b203646463dfa0bddd50b closes odoo/odoo#131088 Related: odoo/enterprise#45385 Signed-off-by:
John Laterre (jol) <jol@odoo.com>
-