Wednesday, December 10, 2025
19 changes · saas-18.3
Enhancements to existing features
This update enables users to send multiple attachments when sending invoices through the Peppol network. These attachments are now embedded within the invoice XML file using a standard ‘AdditionalDocumentReference’ tag, streamlining the process for exchanging documents with Peppol partners. This improves efficiency and compliance for international transactions.
Original PR description
[IMP] account: multiple embed files peppol This commit allows user to send multiple attachments through peppol. The attachments will be embedded into the xml under the `AdditionalDocumentReference` tags task-5103539 Forward-Port-Of: odoo/odoo#238662 Forward-Port-Of: odoo/odoo#234339
This update introduces a new process to automatically upload attachment files to cloud storage. It's triggered by a manual cron job, ensuring attachments larger than a specified size and meeting certain criteria are securely stored in the cloud. This improves storage efficiency and backup capabilities.
Original PR description
This commit provides a cron job to migrate attachment binary to the cloud storage. The cron job is designed to be manually triggered from by the "Run Manually" button of the Scheduled Action's form…
This commit provides a cron job to migrate attachment binary to the
cloud storage. The cron job is designed to be manually triggered from
by the "Run Manually" button of the Scheduled Action's form view.
The cron job will try to upload some attachments once
1. size is greater than the minimum upload file size defined by
(ir.config_parameter: cloud_storage_min_file_size)
2. id is greater than the number defined by
(ir.config_parameter: cloud_storage_migration_min_attachment_id)
3. res_model is in a white list
(ir.config_parameter: cloud_storage_migration_message_models)
(ir.config_parameter: cloud_storage_migration_all_models)
4. not used by documents.document
optional configurations to avoid timeout issues
- cloud_storage_migration_max_file_size:
max bytes for each migrated attachment
- cloud_storage_migration_max_batch_file_size:
max total bytes for migrated attachments in one cron job execution
The cloud_storage_migration_min_attachment_id which can be accessed
from the list view can be treated as the progress of the cron job.
Manually setting it to 0 and retriggering the cron job will retry the
upload process for previously failed or ignored attachments.
taskid: 5387110
Steps
1. install a cloud storage module (cloud_storage_google, cloud_storage_azure)
2. install the cloud storage migration module (cloud_storage_migration)
3. Go to Settings for Cloud Storage Settings <img width="505" height="206" alt="image" src="https://github.com/user-attachments/assets/d72d7b52-5ce7-4209-8645-4a8ac35dd049" />
4. [Configure the cloud storage settings](https://www.odoo.com/documentation/19.0/applications/general/integrations/cloud_storage.html)
5. Setting the Minimum File Size. Attachments smaller than the size won't be uploaded to the cloud storage <img width="457" height="96" alt="image" src="https://github.com/user-attachments/assets/8dc4e6fe-9c84-44f5-a83a-28c7b2fad30a" />
6. After 4, configure settings for the cloud storage migration
a. <img width="464" height="209" alt="image" src="https://github.com/user-attachments/assets/37352453-ff0e-4e03-a4d5-7fdb8168dee1" />
b. Cron Job:
i. the link to the cloud storage migration cron job
ii. the cron job is designed to be a job only triggered by clicking "Run Manually".
iii. It will re-trigger itself until all relevant attachments are migrated.
c. Parameters:
<img width="882" height="571" alt="image" src="https://github.com/user-attachments/assets/9926ed9f-81ac-4917-b759-872ed2584217" />
d. Progress Bar:
i.progress of the migration job
ii. calculated by `cloud_storage_migration_min_attachment_id / cloud_storage_migration_max_attachment_id`
e. Attachment Report:
i. <img width="1907" height="298" alt="image" src="https://github.com/user-attachments/assets/33a77835-c6b6-4bc4-b20a-4ec68acba783" />
ii. a view to help administrator analyze which model's attachments should be migrated
iii. help to configure step 6.c.i.4 and step 6.c.i.5
f. Message Attachments
i. help to configure step 6.c.i.4
g.All attachments
i. help to configure step 6.c.i.5
7. Click Cron Job and then Click Run Manually
<img width="409" height="123" alt="image" src="https://github.com/user-attachments/assets/f60cdfcf-e6a6-4503-87fc-0be7f14ceede" />
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238928
Forward-Port-Of: odoo/odoo#235745This update enhances user privacy by permanently providing access to the Cookie Policy page and allowing users to update their consent choices at any time. Previously, users could only access the policy through a popup, and changes weren't consistently reflected, now cookie preferences are reliably tracked and updated.
Original PR description
This improvement enhances user control over cookie preferences by making the Cookie Policy page (/cookie-policy) more accessible and allowing users to modify their consent at any time. **Issue:** -…
This improvement enhances user control over cookie preferences by making the Cookie Policy page (/cookie-policy) more accessible and allowing users to modify their consent at any time. **Issue:** - Previously, the only way to access the Cookie Policy page was through the link in the cookie consent popup. However, once users accepted cookies, the popup was no longer displayed, making it impossible to navigate to the policy page later. - Additionally, the Cookie Policy page had a button to reopen the cookie consent popup, but it was only visible if cookies were not accepted. Once cookies were accepted, the button was hidden, preventing users from changing their preferences. **Improvements:** - Added a permanent link to the Cookie Policy page in the copyright footer, ensuring it remains accessible at all times. - The cookie consent toggle button now remains visible even after a user has accepted cookies, allowing them to update their preferences at any time. task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416) Forward-Port-Of: odoo/odoo#238772 Forward-Port-Of: odoo/odoo#203409
Resolved issues and error corrections
This update resolves a bug where invoice totals weren't correctly updating after changing the unit price or product. The fix reorders the calculation logic to ensure the product's price is used accurately, leading to correct total calculations. This improves invoice accuracy and reliability.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice with an invoice line - Save the invoice - Change the unit price => The totals should change - Change the product => The unit price and…
**Steps to reproduce:** - Install Accounting - Create an invoice with an invoice line - Save the invoice - Change the unit price => The totals should change - Change the product => The unit price and the totals should change - Change the unit price again **Issue:** After this point, the totals don't change anymore, even if the unit price is changed several times. Only saving the form will adapt the totals correctly. **Cause:** When changing the unit price the first time, a "price_unit "key is added in the onchange values. When changing the product, a "product_id" key is added after the price key. Changing the product triggers an onchange of the price with the price of the new product. However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after. This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals". **Solution:** If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first. opw-5012125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239110 Forward-Port-Of: odoo/odoo#232684
This update fixes an error that occurred when calculating shipping rates for partners without complete address information (country, state, and city). The change ensures the system handles missing location data gracefully, preventing errors and allowing users to accurately obtain shipping quotes. This improves the reliability of the Envia Shipping module.
Original PR description
Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city). **Steps to Reproduce:** 1. Install and…
Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city). **Steps to Reproduce:** 1. Install and configure the **Envia Shipping** module. 2. Create a partner without an address (only name + phone). 3. Create quotation for that partner with a deliverable product (e.g; Conference Chair). 4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**". **Error:** `TypeError - quote_from_bytes() expected bytes` **Cause:** At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised. **Fix:** This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2] [1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593 [2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624 sentry-7063870478 Forward-Port-Of: odoo/enterprise#100734
This update resolves an issue in the Hong Kong payroll module by changing the default account used for NET salary payments. The change ensures accurate payslip generation and avoids payment problems. A new 'Salaries & Wages Payable' account has been implemented for broader compatibility.
Original PR description
Fixes the default account for NET salary rules in the Hong Kong payroll, which is using the wrong account type and causes issues when trying to pay payslips. It is replaced by a new Salaries & Wages Payable account, and we also set it for the structures other than 'Monthly Pay' task-5042786 Forward-Port-Of: odoo/enterprise#100835
This update corrects a bug in the loyalty program's reward system. Previously, rewards weren't triggered when using 'not ilike' product domains, due to a double negation issue. This change ensures that rewards are correctly applied based on product exclusions, improving the functionality of the loyalty program.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a loyalty program; 2. Create a reward; 3. Add a Product domain to the reward containing the `not ilike` operator; 4. Load the POS; 5. Try to trigger…
Versions
--------
- 18.0+
Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied
Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.
Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.
Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])`
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.
For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)
Solution
--------
1. Perform the initial search with `ilike` for both operators
opw-5182818
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235656This update fixes issues related to generating and resending snailmail reports, specifically for follow-up letters. It extracts key functions to ensure consistent PDF formatting and allows for targeted adjustments to the resending process, improving report accuracy and reliability.
Original PR description
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's…
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's margins are fixed and a cover page is added to it after the function is called in `_fetch_attachment`. The new function is extended in the related enterprise commit to generate the followup report inside `_fetch_attachment` (when sent via snailmail). This way it will respect the cover page option and page layout / size requirements. (See the related enterprise PR for more details.) #### [FIX] snailmail: extract letter resending function We extract a function `_resend_letters` from the `update_resend_action`. It handles the regeneration of letters after the cover option has been updated. This way the resending logic can easily extended to adjust the logic depending on attributes of the letter. The new function is extended in the related enterprise commit to disable the resending for followup report letters. This is necessary because the followup report requires special options to be generated that are not available at the point of the regeneration. #### references opw-5160121 opw-5209504 opw-5226366 Forward-Port-Of: odoo/odoo#238905 Forward-Port-Of: odoo/odoo#235699
This update resolves issues with generating snailmail follow-up reports, specifically addressing address validation problems, cover page functionality, and PDF layout inconsistencies. The fix ensures the report is correctly formatted for Pingen, provides feedback if addresses are invalid, and allows users to easily resend reports with or without a cover page.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366
Forward-Port-Of: odoo/enterprise#101596
Forward-Port-Of: odoo/enterprise#99491This update addresses a change in Facebook's data reporting, specifically the deprecation of the audience trend metric. We've temporarily adjusted the calculation to rely on total page follows, ensuring continued reporting accuracy. This change prioritizes immediate reporting functionality while a more comprehensive solution is developed.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend,…
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend, because we needed a fix rapidly, and we wasn't sure about unfollow. And indeed, `page_daily_follows` only count for positive value, unlike the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent of `page_fan_removes`... Example of data for a month: ``` page_follows 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 page_follows 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ``` So we now use `page_follows`, so the total value at a given time, and we look for the newest and oldest value (note that if we could do the same for `page_post_engagements`, then we could just make 2 APIs calls for the year stat). Task-5353390 Forward-Port-Of: odoo/enterprise#101625 Forward-Port-Of: odoo/enterprise#100275
This update resolves an issue where the Czech VAT control statement incorrectly calculated amounts for invoices in foreign currencies (specifically EUR). The fix ensures accurate reporting by correctly handling currency conversions and using the absolute value of the signed total when foreign currency amounts are involved.
Original PR description
With l10n_cz_reports: - Create a currency exchange between CZK and EUR where the EUR is valued at least at twice the amount of CZK. - Create an invoice in EUR, with a line with price_unit 5000 and a tax. - In the CZ Tax Report, in the VAT control statement, the converted amount is found in section B.3, which contains received taxable supplies and provided payments up to CZK 10,000. However, the converted amount of the invoice in CZK is higher than 10,000. In `_report_custom_engine_control_statement`, the amount used to check whether the move should be included in this section uses `amount_total`, which in the case of foreign currency gives the wrong result. If the move is in a foreign currency the total is not in CZK so we have to use the absolute value of the signed total. opw-5080339 Forward-Port-Of: odoo/enterprise#100456
This update fixes an issue where the debit note button was missing on credit notes and refunds. The button was recently moved to the invoice header, but this change only applied to invoices and bills. This ensures the button is visible for refunds, which is crucial for processing transactions in countries like Latin America.
Original PR description
The button for debit note is not visible on credit notes and refunds. Since f29c106b57dd6e8ca19ccc2d2479542f202d1c77 the button for debit note has been moved from action menu to the header of the invoice form, but the commit makes it only visible for invoices and bills, while it was also visible for credit notes and refunds before. The button needs to be also visible for CN/refunds as it is necessary for many countries, like latam countries opw-5385273 Forward-Port-Of: odoo/odoo#239019
This update fixes a calculation error in the MRR evolution dashboard that was incorrectly double-counting 'Contraction'. The fix ensures the 'Net new' figure accurately reflects subscription changes by removing the redundant inclusion of contraction data already present in the 'Up/Downgrade' calculation. This improves the dashboard's accuracy and reliability for tracking revenue.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#101227 Forward-Port-Of: odoo/enterprise#96878
This update fixes an issue where the barcode scanning functionality for batches wasn't working correctly when scanning partial pickings. The change ensures that moves are grouped by picking, allowing for accurate tracking of batch inventory. This improves the reliability of the barcode system for managing stock batches.
Original PR description
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of…
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of both pickings - Go back to the barcode main screen - Open the batch again > Both pickings have their demand = partially delivered quantity Cause ----- When leaving the page, we trigger https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68 in which we end up merging the moves together https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51 This has been added by 9753c24 (ade0bef in 17.0) The problem is that `_merge_moves` merges all of the moves into the first of `merge_into` https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088 This, however, doesn't make much sense for batches because the moves can be from different pickings. ----- Ticket: opw-5163740 Forward-Port-Of: odoo/enterprise#101630 Forward-Port-Of: odoo/enterprise#100940
This update enhances the accuracy of tax calculations within the bank reconciliation widget. It prevents accidental tax line deletions, automatically creates tax lines when default taxes are added, and ensures correct tax recomputation across various scenarios. This improves the reliability of financial reporting.
Original PR description
This commit will do multiple things: - Prevent users from deleting a tax line - Adding default taxes on an account will create a tax line for it - Removing a taxes from a line will recompute the taxes correctly - Removing and adding new taxes will recompute the taxes correctly - Removing a base line that has a tax linked to it will recompute the taxes correctly - Add a simple way for users to delete the tax directly from the ui without going to the edit line button task: 5081786
This update ensures invoices with downpayments use the correct downpayment account, regardless of product category or missing category information. Previously, invoices defaulted to the standard income account, causing inconsistencies with tax calculations and downpayment processing. This change aligns with expected downpayment behavior and improves financial accuracy.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This issue can also happen in the case where products have no category set. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** If there's no product category set, fall back to the company's default downpayment account. opw-5171067
This update ensures that downpayment taxes are calculated correctly when using external tax calculation tools like Avatax. Previously, invoices always used the default income account, even with a specified downpayment account. Now, the system uses the designated downpayment account from the product category or the company's default if no category is set, aligning with standard downpayment behavior.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** Check if there's a company default for downpayment account on product category and use this account for the downpayment line instead of the income account. opw-5171067 Forward-Port-Of: odoo/enterprise#101524
This update resolves an issue where by-products weren't correctly registered during multi-step manufacturing processes using the barcode app. The fix ensures that by-products are accurately added to production lines, streamlining the creation of finished goods with intermediate components. This issue is now resolved in version 18.3.
Original PR description
### Steps to reproduce: - In the settings enable By-Products an Multi-step routes - Put your warehouse in manufacturing in 3 steps - Create two storable products: - Final Product (FP) with an empty…
### Steps to reproduce:
- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
- Final Product (FP) with an empty bom
- By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination
### Cause of the issue:
Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.
### Note:
The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f
opw-5350222
Forward-Port-Of: odoo/enterprise#101455
Forward-Port-Of: odoo/enterprise#101087This update resolves an issue where the OCR process incorrectly assigned foreign currencies (like Convertible Marks) to expense items linked to products with standard prices. Now, users can correct the total amount after the OCR, ensuring accurate currency conversions and enabling timely reimbursements. This improves the reliability of expense reporting.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236 Forward-Port-Of: odoo/enterprise#101749 Forward-Port-Of: odoo/enterprise#89093