Thursday, October 31, 2024
92 changes
10 changes
Miscellaneous changes
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185847 Forward-Port-Of: odoo/odoo#185817
Original PR description
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185847 Forward-Port-Of: odoo/odoo#185817
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: `abs(self.balance) / self.price_subtotal` However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked enterprise PR: https://github.com/odoo/enterprise/pull/73035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185230
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired b
Original PR description
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired behavior after PR is merged:** It is possible to create Factura B for a foreign customer. Task Adhoc side: 30008 Task latam side: 913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185160 Forward-Port-Of: odoo/odoo#176604
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: gram - Create a component “C1” - UoM: gram - Create a BoM for P1: - quantity: 1kg - Component: 1g of C1 - Create a Mo to produce 1kg of P1 - Confirm the MO - Create a landed cost: - Apply on manufacturing order - Select the created MO - Add a landed product with a unit price of 25 - Validate the landed cost - Go to the linked valuation layer Problem: A value of (25 * 1000) is
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: gram
- Create a component “C1”
- UoM: gram
- Create a BoM for P1:
- quantity: 1kg
- Component: 1g of C1
- Create a Mo to produce 1kg of P1
- Confirm the MO
- Create a landed cost:
- Apply on manufacturing order
- Select the created MO
- Add a landed product with a unit price of 25
- Validate the landed cost
- Go to the linked valuation layer
Problem:
A value of (25 * 1000) is added instead of only $25
opw-4252901
Forward-Port-Of: odoo/odoo#185725Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next con
Original PR description
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next contains a product 2) Run the Accrued Revenue Entry contextual action 3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry 4) Error appears, a move line is generated with no account --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183230
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdo
Original PR description
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT" ``` Looking at the documentation on [1], we realize we lack an additional VAT breakdown in the xml. [1] https://einvoice.belgium.be/en/article/business-expert-group-overview task-4283933 Forward-Port-Of: odoo/odoo#185138
Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#181462 Forward-Port-Of: odoo/odoo#181333
Original PR description
Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#181462 Forward-Port-Of: odoo/odoo#181333
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart ico
Original PR description
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart icon to ensure consistency between localisations while keeping things simple. opw-4198786 Forward-Port-Of: odoo/odoo#185936 Forward-Port-Of: odoo/odoo#185133
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there, which was already not the case for the frontend `session_info` when this was done. This commit simply makes the util not cache a value if there was actually no found value, and thus let the util falls back to making a RPC if needed. Note that in 18.0, the user service is actually not a service
Original PR description
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there,…
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there, which was already not the case for the frontend `session_info` when this was done. This commit simply makes the util not cache a value if there was actually no found value, and thus let the util falls back to making a RPC if needed. Note that in 18.0, the user service is actually not a service anymore (since commit [2]) and is the only truth of information about user data (since commit [3]), so this makes this even more important. We could consider adding the same group information in the frontend session_info in the future, but in general we want to avoid loading any useless information for visitors and would not mind the extra RPC for connected ones when it comes to the website. [1]: https://github.com/odoo/odoo/commit/da257e9d572047617cdfaac33fbe47983e8ab30d [2]: https://github.com/odoo/odoo/commit/3fb72654a898eb5c5b1c89279b0638dab8e3881d [3]: https://github.com/odoo/odoo/commit/182b0554882a2eeb5d86c9cb6fdaed6618b2615b Related to task-4290643 Forward-Port-Of: odoo/odoo#185479
15 changes
Enhancements to existing features
Article share and trash notifications now display more cleanly by removing an unnecessary blank line and background styling. This improves readability, especially for users viewing notifications in dark mode.
Original PR description
For the "share" and "send to trash" article notifications, remove the extra blank line and the white background which was preventing a good display in dark mode. Task-4273407
This update reorganizes how Odoo loads interface template assets by separating XML bundles from JavaScript bundles. The change supports cleaner asset management and should make future maintenance and performance work easier without changing day-to-day business workflows.
Original PR description
Related to https://github.com/odoo/odoo/pull/161254
Resolved issues and error corrections
Subscription pages no longer show an invoice amount field that was being used beyond its original purpose. This reduces confusion for users and helps ensure credit limit checks rely on clearer, more appropriate information.
Original PR description
When it was originally introduced on 'sale.order', the 'amount_to_invoice' field was only intended to be used to trigger the credit limit warnings on sale orders and invoices. With time, it came to be used for other unintended purposes, which created confusion regarding the computation method and ensuing fixes that did more harm than good. This is why it was decided to remove all unintended usaged of the field in the views, and rename it to further clarify its meaning. task-4213628
Code cleanup and technical improvements
The Point of Sale popup-related files were moved into a clearer shared folder structure across related modules. This is an internal cleanup that makes future maintenance easier without changing day-to-day user workflows.
Original PR description
Reorganization of all popup files of `point_of_sale` and submodules into a unique `popups` directory. task-id: 4290514
Miscellaneous changes
This commit fixes a position issue with the total row title which should be center aligned. task-4251407 Forward-Port-Of: odoo/enterprise#73121
Original PR description
This commit fixes a position issue with the total row title which should be center aligned. task-4251407 Forward-Port-Of: odoo/enterprise#73121
This PR fixes an issue about a `z-index` CSS property defined in Documents that is affecting the whole back-end and front-end environment as it is not scoped within a Documents related selector. While this CSS is actually needed if you have a dropdown with a `+ X` item at the end to prevent the button from being rendered under the view, it needs to be scoped to Documents only. We also take that opportunity to use the `SCSS` variable related to that `z-index` value. | 18.0 | This PR | |---
Original PR description
This PR fixes an issue about a `z-index` CSS property defined in Documents that is affecting the whole back-end and front-end environment as it is not scoped within a Documents related selector. While this CSS is actually needed if you have a dropdown with a `+ X` item at the end to prevent the button from being rendered under the view, it needs to be scoped to Documents only. We also take that opportunity to use the `SCSS` variable related to that `z-index` value. | 18.0 | This PR | |--------|--------| |  |  | task-4270185 Forward-Port-Of: odoo/enterprise#72379
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: abs(self.balance) / self.price_subtotal However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked community PR: https://github.com/odoo/odoo/pull/185230 Forward-Port-Of: odoo/enterprise#73120 Forward-Port-Of: odoo/enterprise#73035
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from
Original PR description
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by…
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match. It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further. This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view. By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard. [1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5 opw-3971513 Forward-Port-Of: odoo/enterprise#73027 Forward-Port-Of: odoo/enterprise#70517
After odoo/odoo@45b90b8b7ce252e1558728f4fc03e52459817565 `test: true` is not a valid tour key anymore Forward-Port-Of: odoo/enterprise#73116
Original PR description
After odoo/odoo@45b90b8b7ce252e1558728f4fc03e52459817565 `test: true` is not a valid tour key anymore Forward-Port-Of: odoo/enterprise#73116
The check for the sequence of the group_s was always true because the length was not compared. Now it is compared to the max length of the sequence. task-4203261 Forward-Port-Of: odoo/enterprise#72886
Original PR description
The check for the sequence of the group_s was always true because the length was not compared. Now it is compared to the max length of the sequence. task-4203261 Forward-Port-Of: odoo/enterprise#72886
On the employee, we should clarify the view to tell what is editable or not. On the contract, the index is monetary but shouldn't. Forward-Port-Of: odoo/enterprise#71794
Original PR description
On the employee, we should clarify the view to tell what is editable or not. On the contract, the index is monetary but shouldn't. Forward-Port-Of: odoo/enterprise#71794
### Description of the issue/feature this PR addresses: It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf ### Current behavior before PR: It is not possible to create Factura B for a foreign customer. ### Desired
Original PR description
### Description of the issue/feature this PR addresses: It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf ### Current behavior before PR: It is not possible to create Factura B for a foreign customer. ### Desired behavior after PR is merged: It is possible to create Factura B for a foreign customer. Task Adhoc side: 30008 Task latam side: 913 Forward-Port-Of: odoo/enterprise#72728 Forward-Port-Of: odoo/enterprise#71562
This command's purpose was to dispatch the event at each individual external step, but it was only used for embedded components, and `onExternalHistorySteps` resource (which handles every batch of collaborative steps) is enough for embedded components, and it is called less often. This commit therefore removes `ADD_EXTERNAL_STEP` command. task-4281356 Forward-Port-Of: odoo/enterprise#72681
Original PR description
This command's purpose was to dispatch the event at each individual external step, but it was only used for embedded components, and `onExternalHistorySteps` resource (which handles every batch of collaborative steps) is enough for embedded components, and it is called less often. This commit therefore removes `ADD_EXTERNAL_STEP` command. task-4281356 Forward-Port-Of: odoo/enterprise#72681
Steps: Create a ticket with no partner. Click on 'Plan Intervention'. The modal opens. Issue: See that a partner "@" has been created and set. Cause: Clicking on the button calls `action_generate_fsm_task`, which calls `_find_or_create_partner`, but the args, `self.partner_name` and `self.partner_email`, are empty. Solution: Not try to create a partner when the fields both empty. Also, if there was no partner on the ticket, it takes the value of the wizard's partner when savin
Original PR description
Steps: Create a ticket with no partner. Click on 'Plan Intervention'. The modal opens. Issue: See that a partner "@" has been created and set. Cause: Clicking on the button calls `action_generate_fsm_task`, which calls `_find_or_create_partner`, but the args, `self.partner_name` and `self.partner_email`, are empty. Solution: Not try to create a partner when the fields both empty. Also, if there was no partner on the ticket, it takes the value of the wizard's partner when saving the wizard (clicking on "Create (& View) Task". task-4265584 Forward-Port-Of: odoo/enterprise#72304
Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some workin
Original PR description
Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some working hours near the start/end of the period to be missed. opw-4163183 Forward-Port-Of: odoo/enterprise#73010 Forward-Port-Of: odoo/enterprise#72526