Wednesday, September 18, 2024
10 changes
2 changes
Resolved issues and error corrections
Users can now remove a component from a confirmed manufacturing order without triggering an error when saving. This prevents an interruption in manufacturing order updates and lets teams correct component lists as expected.
Original PR description
Steps to reproduce: - Create an MO and confirm it. - Remove any component (`move_raw_ids`). - Save the form. Expected behavior: The component should be removed. Current behavior: A traceback appears. This is because the `write` of the `mrp_production` always tries to destructure the value of `move_raw_ids` into a `Command` tuple of three elements, which is not the case when deleting on of the components, where the tuple consists only of two elements: the `DELETE` constant and the id of the removed record (no values element). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures warehouse push rules can be applied when stock moves originate from a sub-location, not only the exact configured location. It helps inventory routes behave consistently and reduces manual intervention when goods are redirected within warehouse location hierarchies.
Original PR description
The changes made in #156437 had the purpose of adding more flexibility in the moves, being able the re-route them on the fly, without having to bother with the whole chain being already created. And while the search for pull rules properly look for parent location if no rule is found within the givin location, it wasn't the case yet for push rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This fix improves how restaurant orders are synchronized with preparation displays by focusing on pending orders and processing them through a queue. It helps reduce missed or incorrectly synced orders and fixes related point-of-sale errors that could disrupt kitchen workflows.
Original PR description
6 changes
Resolved issues and error corrections
This fix resolves an error that occurred when trying to generate invoices from POS transactions in Chile. The system was looking for customer information in the wrong location, causing the invoice process to fail. With this correction, customers can now successfully create invoices from their POS orders without encountering errors.
Original PR description
Problem was we try to get partner from `order.partner` instead of `order.partner_id` Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4180894
*: pos_restaurant, pos_online_payment Before order synchronization was using table to know which orders needs to be synchronized. Now we only refer to pending orders, and we use a queue to synchronize them.
Orders marked as Food Ready in Atlas now update both their order status and payment status in the Point of Sale. This prevents delivery orders from appearing unpaid after they have progressed through the external food delivery workflow.
Original PR description
Steps: - Install pos_urban_piper - Open Point of Sale. - Configure Food Delivery Connector for one of pos. - Place a test order. - Mark order as Food Ready from Atlas. Issue: - Order status change to Food Ready but not got paid. Fix: - Order status and payment status both is updated.
The Accounting dashboard's comparison formulas have been updated to correctly handle monthly and quarterly date filters, not just yearly comparisons. Previously, the dashboard only worked accurately when comparing full years, but now it properly calculates deltas across different time periods that users can select.
Original PR description
The `Accounting` dashboard was using very naive formulas to compute deltas between years. Namely, the formulas were based on the assumpution that we'd only compare values year by year but the filters allow to work with quarters or months as well. This revision updates the dashboard file to take the months/quarters into account. task-3957037
This fix resolves a system error that occurred when changing product types in companies set to Kenya. The system was trying to access an incorrect company attribute, causing the product type change to fail. The fix corrects the attribute reference so product type changes now work properly for Kenya-based companies.
Original PR description
Currently, an error occurs when the system tries to access the attribute name 'account_fiscal_id' through 'company_id' [1] but it is not available in 'res_company' model. Step to produce: - Install the 'l10n_ke_edi_oscu_stock' module. - Create a product, Set a company as Kenya, Change a 'Product Type' storable to service or consumable. - Again change a 'Product Type' to a storable product. ```AttributeError: 'res.company' object has no attribute 'account_fiscal_id'``` Link [1]: https://github.com/odoo/enterprise/blob/3f0113b0d95200466f51b9c1f75b58a3534fb34c/l10n_ke_edi_oscu_stock/models/product.py#L21-L22 To resolve this issue, Get a product country code from 'account_fiscal_country_id' instead of 'account_fiscal_id' Sentry-5862212825
This fix resolves an issue where text in the general ledger report would overlap and become unreadable when printing to PDF. The problem occurred when journal entries contained longer text descriptions (like partner names and transaction details). The fix improves the text formatting rules to prevent overlapping regardless of text length, ensuring reports are always clear and professional-looking.
Original PR description
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the…
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the 1st account, select 'Account Receivable' (e.g., 121000 Account Receivable). - Set the Partner field to "0h3n-abcdefg@yahoo.example.com" and the label field to "Online transfer reced agst INV-00171, Dt:01.08.2024". - For the 2nd account, set it to any other type, such as "101401 Bank". - Add a credit amount in the 'Account Receivable' and the same amount in the 2nd account. - Save and post the transaction. - Navigate to the general ledger. - Ensure you expand the list of this newly created account move under the 121000 Account Receivable to observe overlapping text. - Click on 'PDF' and print the report. - Notice the overlapping text.  Cause of the issue ================== The o_overflow_value class is only applied when the cell value length is longer than 65 chars Solution =======  Here are the differences, only the following lines are pushed down  opw-4130917
Users can now reorder projects in the Field Service Configuration menu. Previously, the reordering feature was unavailable because the sequence field wasn't properly configured in the project list view. This fix enables drag-and-drop reordering functionality, giving users more control over how their projects are organized.
Original PR description
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403 Close odoo/odoo#176961
Fixed a bug in the Chilean localization module where claim status updates from the tax authority (SII) would fail when multiple events were returned instead of a single event. This was causing repeated error messages and preventing proper status tracking. The fix now handles both single and multiple event responses correctly, and adds support for an additional response code (NCA) that was observed in customer data.
Original PR description
When parsing a claim status from the SII, the list of events in the response can either be a single event or a list of events. If a list was returned this would fail with a parsing error because the…
When parsing a claim status from the SII, the list of events in the response can either be a single event or a list of events. If a list was returned this would fail with a parsing error because the original implementation only expects a single event. That then led to the status getting repeatedly checked and logging "list indices must be integers or slices, not str" when done through a cron. This fix supports both the single and multiple event scenario. The l10n_cl_claim field is not displayed anywhere by default and is only used to check if the claim status still needs to be logged in the chatter or not. Since multiple response codes are possible, in theory it should be a list instead of a single value, but that would be more appropriate for a change in master. A boolean flag would also suffice if the response code doesn't need to be displayed separately. We currently just set the last code that was returned. The responses observed in the customer database include the code NCA, which isn't expected by Odoo. This code was added as a valid one. opw-3920273 Forward-Port-Of: odoo/enterprise#70167 Forward-Port-Of: odoo/enterprise#66498