Wednesday, October 9, 2024
31 changes · saas-17.4
Resolved issues and error corrections
This fix restores transparent table backgrounds on website pages after a Bootstrap upgrade changed their default appearance. It prevents checkout totals and similar table areas from incorrectly showing the page background color inside white cards, improving visual consistency for shoppers.
Original PR description
Since [1] when Bootstrap was upgraded to version 5.3, the `$table-bg` variable is obtained from `$body-bg` instead of being transparent as it was previously. Because of this, when a "Boxed", "Frame" or "Postcard" layout is used, and a background color is specified, that color is used as table background, even if they are nested within cards that have a white background. This commit restores the transparent table background. Steps to reproduce: - Install eCommerce - Set a "Postcard" layout - Specify a non-white background color - Add a product to the card - Proceed to the checkout page => The total area used the body background instead of the card background. [1]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935#diff-b037a8f5f304da130ba183549bf6abf5126d1bc118033211aa865ae74d3bca51R739 opw-4203976
The image editing toolbar no longer displays the translate button. This removes an irrelevant action from the image workflow, making the editor interface clearer for users.
Original PR description
Current behavior before PR: - The translate button was visible on the image toolbar. Desired behavior after PR is merged: - Now, translate button is no longer displayed on the image toolbar. task:4224550
This fix prevents an error dialog from appearing when website editors disable the Stretch option on shaped images. It makes the image editing controls update reliably, improving the page editing experience without changing visible website content.
Original PR description
Since [1] when the "Stretch" option was added on shape, upon changing that option the ImageTools XML is re-rendered to make sure the available widths in the "Format" option are up to date, but that operation is not awaited. Because of this, the widgets might not be available yet during `updateUI`, which leads to an error. This commit fixes this by awaiting the calls to `_onImageCropped`. No problem was identified for the second call, but the missing `await` is added by this commit anyway. Steps to reproduce: - Edit a website page - Drop a "Columns" block - Select first image - Apply shape on image (e.g. Tear) - Activate "Stretch" - Set "Animation" to "On hover" - Save - Edit - Disable "Stretch" => An error dialog was displayed [1]: https://github.com/odoo/odoo/commit/c66ae88eaa275d1b87693f329d3b2622c0534c33#diff-ffb61e86e6b8297ef8997f9c605de14de896b54161c032d88a80bbaeac4f89beR6657 opw-4192761
Fixes an issue where the dependencies popover could remain stuck on screen after saving page properties. This keeps the website editing experience clean and prevents users from seeing an unclosable popover after closing the dialog.
Original PR description
task-4219465
The link editor now respects the link a user selects from the dropdown using the keyboard. This prevents the wrong link from being saved and makes editing links in Odoo's web editor more reliable.
Original PR description
### Steps to reproduce: - Open the To-do app. - Enter /link and provide a label. - Type / (e.g., /web) in the link dialog to preload available links. - Use the arrow keys to select a link from the dropdown. - Press Enter. - Edit the link again and check the result. ### Description of the issue/feature this PR addresses: Selecting a link from the dropdown with `Enter` would directly apply the link in the dialog, ignoring the selected dropdown link. ### Desired behavior after PR is merged: Selecting a link from dropdown with `Enter` now correctly updates the link dialog with the selected link, and pressing `Enter` again applies the updated link. task-4169784
Creating a purchase order no longer crashes when a user clears the company field in a multi-company setup. This avoids an interruption during purchase order entry and keeps the workflow usable even when company information is temporarily blank.
Original PR description
Currently, a traceback occurs when the user removes the company while creating a PO with a multi-company environment. To reproduce this issue: 1) Install Purchase order 2) Switch to multi-company environment 3) Create a PO and remove the company value from other information Error:- ``` ValueError: Expected singleton: res.currency() ``` When the user removes the company, its value becomes False. This leads to an empty currency record set as the currency fetches from the company. https://github.com/odoo/odoo/blob/97de468e6943b1a13998503deb436eaa38cdaafe/addons/purchase/models/purchase_order.py#L226-L230 It leads to the above traceback sentry-5939949508
This fix prevents cash change from being reported as an additional positive payment on Ecuador POS invoices and electronic invoices. It ensures invoice payment details match the actual sale, reducing confusion and improving compliance reporting accuracy.
Original PR description
With an EC company setup Open POS Add a product Go to Payment screen Select Invoice and pay using a cash payment method with an excess amount Issue: On the invoice (and xml e-invoice) there will be 2 payments, both with a positive amount We should not report the change opw-4192615
Miscellaneous changes
### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons - **Validity**: Today's date for example - Conditional rule with a **Minimum Purchase** of 0.00 - Start a new POS session. Add a product and click **Payment**. - **Validate** the order. - In the receipt shown, notice how the text show **_'Valid until: no expiration'_** althoug
Original PR description
### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons…
### Steps to reproduce:
- Install **pos_loyalty** module
- Go to **Point of Sale** app > **Products** > **Discount & Loyalty**
- Create a **New** program with:
- **Program Type**: Next Order Coupons
- **Validity**: Today's date for example
- Conditional rule with a **Minimum Purchase** of 0.00
- Start a new POS session. Add a product and click **Payment**.
- **Validate** the order.
- In the receipt shown, notice how the text show **_'Valid until: no expiration'_** although a Validity date is defined!
### Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78
opw-3838427
Forward-Port-Of: odoo/odoo#182838
Forward-Port-Of: odoo/odoo#160633Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/o
Original PR description
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/odoo#182746
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries
Original PR description
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the…
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries to enter in edit mode, the `FacebookPageWidget` public widget is destroyed and the system tries to disconnect `this.resizeObserver`. As it is not defined, the system fails in the `destroy()` method. Steps to reproduce the second bug: - Add an "Image-Text" snippet on the website. - Add a "Text-Image" snippet under the "Image-Text" one. - Save and edit. - Drop a "Facebook" snippet on the "Image-Text" snippet. - Move the "Facebook" snippet on the "Text-Image" snippet. - Click on the undo button. -> Two iframes are on the Facebook snippet. The problem is that since [1], the editor observer is not deactivated when removing the iframe in the `destroy()` method of the `FacebookPageWidget` widget. Finally, this commit also adds back the `frameborder` and `allowTransparency` attributes on the iframe (removed due to [1]) and sets the width and height in the style attribute. Although the `frameborder` and `allowTransparency` attributes are deprecated, this commit adds them back in case a potential customization relies on it. [1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25 task-4220972 Forward-Port-Of: odoo/odoo#182810 Forward-Port-Of: odoo/odoo#182134
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
Original PR description
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767
Original PR description
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Original PR description
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182326 Forward-Port-Of: odoo/odoo#178909
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
Original PR description
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
Original PR description
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corre
Original PR description
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the…
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corresponding lines should be the inverse of those which are generated by this action when the product's on-hand quantity is positive. **Steps to reproduce:** 1. Enable automatic accounting, create a stored product whose category has `FIFO` costing and `real_time` valuation 2. Create an in move for the product so it gets some cost assigned to it 3. Create an out move for more of the product than is currently in stock (so it's on-hand qty becomes negative) 4. Change the product category's `cost_method` to average/AVCO 5. Observe the journal items created by this action in the accounting application -> see that the stock valuation account is credited in both of the created moves **Cause of the issue:** The replenishing move's debiting/crediting accounts are currently adjusted if the associated SVL's quantity is non-positive, but the preceding emptying move's accounts are not. This results in the mismatch. **Fix:** Similarly adjust the emptying move accounts as was done to the replenishing move in commit: f7e3ada opw-4127737 Forward-Port-Of: odoo/odoo#182304
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
Original PR description
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
When installing an industry from the database, the list of dependencies to install is displayed in the dialog box. This is not clear nor necessary for the user and is therefore removed. Also, a message better alerts the user about loading demo data on a database. task-4096849 Forward-Port-Of: odoo/odoo#182783 Forward-Port-Of: odoo/odoo#180035
Original PR description
When installing an industry from the database, the list of dependencies to install is displayed in the dialog box. This is not clear nor necessary for the user and is therefore removed. Also, a message better alerts the user about loading demo data on a database. task-4096849 Forward-Port-Of: odoo/odoo#182783 Forward-Port-Of: odoo/odoo#180035
- In any APP (We would use CRM for the example); - On a multi-record view (Kanban, List, or other); - Click the action menu; - Click on “Import records” dropdown; - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, an exception was raised, and the default multi-record view was loaded. This occurs because, the client action base import required a model (found in the context) that was lost when reloading. Now,
Original PR description
- In any APP (We would use CRM for the example); - On a multi-record view (Kanban, List, or other); - Click the action menu; - Click on “Import records” dropdown; - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, an exception was raised, and the default multi-record view was loaded. This occurs because, the client action base import required a model (found in the context) that was lost when reloading. Now, the model is put in the query string of the URL (as active_model), in that way, when reloading, the client action base import will have the needed model. Note that, this is also the behavior of the stock TraceabilityReport client action [1]. opw-3959254 [1] : https://github.com/odoo/odoo/commit/8b3deab679bfee844ccd84c7f4f6f831921365d3 Forward-Port-Of: odoo/odoo#182744
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *
Original PR description
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document **Issue:** The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes. opw-4034659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182730 Forward-Port-Of: odoo/odoo#179289
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
Original PR description
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71504 Forward-Port-Of: odoo/enterprise#71236
Original PR description
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71504 Forward-Port-Of: odoo/enterprise#71236
* test_whatsapp odoo/odoo#178173 Forward-Port-Of: odoo/enterprise#69056
Original PR description
* test_whatsapp odoo/odoo#178173 Forward-Port-Of: odoo/enterprise#69056
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **
Original PR description
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **[FIX] l10n_uy_edi: Create Uruware account help** Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly. **[FIX] l10n_uy_edi: Send and Print after Post** Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted. Forward-Port-Of: odoo/enterprise#70351
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occu
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 Forward-Port-Of: odoo/enterprise#69760
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
Original PR description
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](
Original PR description
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842) Forward-Port-Of: odoo/enterprise#71407 Forward-Port-Of: odoo/enterprise#71379
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning'
Original PR description
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales…
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning' in Settings > Planning - Go to Project > : Menu > 'Timesheet and planning analysis' - Under the Measures dropdown, add all columns You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet. opw-3918082 Forward-Port-Of: odoo/enterprise#71425
Previous behavior: - Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies. New behavior: - Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills. OPW: 4210068 Forward-Port-Of: odoo/enterprise#71418 Forward-Port-Of: odoo/enterprise#70225
Original PR description
Previous behavior: - Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies. New behavior: - Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills. OPW: 4210068 Forward-Port-Of: odoo/enterprise#71418 Forward-Port-Of: odoo/enterprise#70225
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of:
Original PR description
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of: odoo/enterprise#71399 Forward-Port-Of: odoo/enterprise#69581