Wednesday, September 11, 2024
16 changes
4 changes
Resolved issues and error corrections
Credit notes for vendor bills linked to a project are now treated as negative costs in the project profitability view. This prevents reversed bills from incorrectly increasing project costs and gives users a more accurate profitability picture.
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Enable analytic accounting; 2. create a project with a new analytic account; 3. create a purchase order with a line linked to the analytic account; 4. confirm order; 5. create bill, add bill date, confirm bill; 6. click the "Credit Note" button; 7. confirm the credit note to reverse the bill; 8. go to project profitability panel. Issue ----- Instead of reversing the project's costs, the credit note doubled them. Cause ----- Commit 9c14dfdf2302 changed the retrieval of profitability costs from purchase orders to vendor bills. In doing so, it assumed each move line's listed amount to be a cost. Solution -------- If the line has `is_refund` set, multiply the cost by -1. opw-4100220
Kitchen receipts in Point of Sale now handle very long product names without text overlapping other lines. This keeps order preparation tickets readable for restaurant staff and reduces confusion in the kitchen.
Original PR description
When printing order changes that contains a product with a really long name, the product name would overlap on the kitchen receipt. Steps to reproduce: ------------------- * Modify the name of a product so that it is really long * Setup a kitchen printer on a PoS restaurant * Add some product on an order and send the order in preparation > Observation: The kitchen receipt has overlapping lines Why the fix: ------------ We make sure to hide the overflowing text so that it is not overlapping on other lines. opw-4136775 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from getting stuck repeatedly switching between list and form screens after a network or session error. Instead of looping endlessly, the system now shows the error clearly when there is no previous screen to return to, improving stability and reducing user confusion.
Original PR description
Go to a kanban view (directly from a menu, s.t. it's the first item in the breadcrumb), open a record. Simulate a global network error (connection loss, server down, outdated session...). For…
Go to a kanban view (directly from a menu, s.t. it's the first item in the breadcrumb), open a record. Simulate a global network error (connection loss, server down, outdated session...). For instance, remove the session_id cookie. Click on the breadcrumb to go back to kanban. Before this commit, this caused an infinite loop of reloading the kanban and the form views. When the first rpc error occurs, we land into the onError handler in the action service. We detect that we are trying to restore a controller from the stack, which crashes. At that point, we would like to restore the controller which appears before the faulty one in the stack. In our case, there's no such controller (we are the first one). So we reach the other part of the error handling, which concerns controllers that are not yet in the stack. For that case, we try to restore the last controller of the stack (the form view). This one fails as well, so we land again in the onError handler, for a controller that is already in the stack, but not the first one this time. So we try to restore the one before it (the kanban), which fails, and so on. The issue has been introduced in [1], where we simply forgot to handle the case where the faulty controller is the first one of the stack, and that's exactly what we do in this commit. In that case, there's nothing to do but display the error (there's no controller to restore). [1] ad35b3069e2efc69b97a283476da4154d49dda8b 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
Manual purchase orders for products received through two-step warehouse routes now record the final stock destination correctly. This prevents incoming purchased goods from being ignored in forecasts and avoids unnecessary extra supplier requests.
Original PR description
Problem --- Using the default 2 steps receipt routes (input -> stock), when we manually create and confirm a purchase order for a storable product, the incoming products are not being taken into…
Problem --- Using the default 2 steps receipt routes (input -> stock), when we manually create and confirm a purchase order for a storable product, the incoming products are not being taken into account for the stock forecast Steps --- * install purchase, mrp, sales_management * In the setting enable multi-step routes, and configure the main warehouse to use the 2 step route. * create a product P: * storable * has a supplier line * route = buy * create a corresponding 0,0 auto buy reordering rule. * create a purchase order for 10 P, confirm it. * => the forecast for the reordering rule is still 0 * create a SO for 10 P and confirm it * => a new RFQ is wrongly generated Cause --- Previously, when using multi step routes, creating a purchase order would create a move for every step of the route, and the destination of the last move of the chain was the main stock. But as of 11e69870db1c49d9a6af79ffd263e4e162b34b6b, we create moves one step at a time, and use `location_final_id` to keep track of the eventual destination. However, in purchase when creating the moves for a manual PO, we do not set this location. So the forecast doesn't take the move into account, as its destination is not the stock but the input. opw-4033857
6 changes
Resolved issues and error corrections
The Appointments schedule menu is now hidden from users who do not have permission to access it. This prevents confusing access error messages when staff try to open resource or staff booking schedules they are not allowed to view.
Original PR description
**Steps to reproduce:** Log in as Demo. Go to Appointments > Schedule > Resource bookings / Staff bookings. Both menus result in an Access Rights Error. After commit https://github.com/odoo/enterprise/commit/f406f3b7ed34ac53bacdaa44ca359a2dbbd152ba, the schedule menu is also visible for those users who don't have access to it. **After this PR:** Hide the schedule menu for those users who don't have access to it. Task-4172809
6 changes
Resolved issues and error corrections
This fix resolves an issue where expense invoicing would fail when trying to bill against a locked subscription order. The system now intelligently checks for renewed subscription orders that are still active and uses those instead of the original locked order, allowing expenses to be properly invoiced without errors.
Subscriptions that were previously churned can now be reopened automatically when a related invoice is paid on time. This helps avoid customers remaining incorrectly closed after completing payment, especially when using payment links.
Original PR description
Before this commit, when a subscription received a payment in Churned stage, it would stay closed after the invoice payment confirmation. After this commit, when this payment scenario happens, we re-open the churned subscriptions linked to the invoice if the payment date is less than or equal the next invoicing date. task-4106927
A spelling mistake was corrected in the UrbanPiper restaurant integration information. This is a minor cleanup that improves presentation and avoids confusion in module details.
The guided timesheet walkthrough no longer gets stuck when users click a timesheet cell to enter hours. This keeps onboarding and training flows smooth by ensuring the tour recognizes the click even when an overlay appears on hover.
Original PR description
Steps to reproduce: - start timesheets tour - when reaching step "Click on the cell to set the number of hours you spent on this project.", and clicking on the cell, tour stay at the same step. Source: - when hovering the cell, a new html element came to superpose above the trigger. so the click is done on the new element and not the trigger. Fix: - The fix was done in task 4147246, this commit just adapted the trigger with an additional alternative trigger task-4141027
New tables added in Studio report editing now follow the report's existing external layout styling. This keeps reports visually consistent and avoids manual formatting corrections after inserting tables.
Original PR description
Before this commit, when inserting a new table in the report, its style was off because of the specific styles set by the external layout After this commit, the styles fit the external layout's task-4166611
Automatic bank reconciliation now prefers an active customer or vendor when matching a bank statement line by account number. This helps avoid assigning inactive contacts during reconciliation while still allowing reconciliation when there is only one possible match.
Original PR description
…sible Context: When doing automatic reconciliation, statement lines without partner but with account_number set are using the method `_retrieve_partner` to find a partner which would have a bank account with the same account_number. Problem: The res.partner.bank could be active and the partner inactive, which would result in selecting an inactive partner for the reconciliation. This commit improve on that behavior by trying to assign an active partner if we happen to have one with the same bank account and if it is not possible, we still leave the inactive partner but we disable the "auto reconcile" part of the reconciliation. Task: 3975338
Original PR description
**Current behavior:** After creating a subscription for a recurring product which creates a project/task, invoicing the original order and posting it, then creating the renewal order, if you create a…
**Current behavior:**
After creating a subscription for a recurring product which
creates a project/task, invoicing the original order and posting
it, then creating the renewal order, if you create a purchase
order for some expensable service product that has an
`expense_policy == 'sales_price'` and attempt to create the
vendor bill for the purchase order, you will get a UserError
about the original sale order being locked.
**Expected behavior:**
Because there is a renewed order which is not locked, the
expense should use that instead of the original subscription
order.
**Steps to reproduce:**
1. Create a recurring service product which is set to create a
project and task that has an associated analytic account
2. Create a subscription for the product and confirm it, create
the invoice and post it (locking the order)
3. Renew the subscription, confirm it, create the invoice but do
not post it
4. Create a service product which can be expensed and uses the
expense policy of sales price
5. Create a purchase order for the expensable service and set
analytic distribution on the order line to use the same one
from the subscription
6. Confirm the purchase order and create an invoice, then try to
post it -> UserError
**Cause of the issue:**
The original subscription order is found via the shared analytic
account and generates the error because it is now in a locked
state.
**Fix:**
Check if a found order is in the renewed subscription state and
then search for the lowest id order in DB with the originally
found subscription as its origin order- if one exists, use this
record instead of the original order in the
`_sale_determine_order()` mapping.
opw-4061484This fix resolves an issue where subscription payments were not being properly tokenized (saved for future use) even when customers had sufficient funds. The problem occurred due to minor rounding differences in currency calculations. The update now correctly compares payment amounts using the order's currency rounding rules, ensuring payments are tokenized as intended.
Original PR description
Since 4dfb9259762de we tokenize subscription payment when amount is sufficient, in some case that test was not true because the sum of order's recurring line was greater by an epsilon. This commit compare the two amounts relative the order's currency (rounding). opw-4176380 opw-4162841 opw-4117553 opw-4152609
This fix corrects an issue where Mexican tax documents (CFDI) generated from point-of-sale invoices were incorrectly using the customer's individual name instead of the company name. This ensures that tax filings with Mexican authorities contain the correct buyer information as provided by the business.
Original PR description
Currently, when a user requests an invoice from a POS ticket under a Mexican company, the CFDI document attached to the invoice incorrectly uses the buyer's name instead of using the provided company name. ### Steps to reproduce * install `l10n_mx_edi_pos` * Switch to a Mexican company * the settings enable "Generate a code on ticket" * validate a POS order * follow the instructions on the ticket to generate an invoice. Make sure to provide a company name on the customer form. When checking the XML file that is forwarded to the Mexican tax authorities, you see that only the "individual name" is registered there as the buyer, when it should be the company name. opw-4103543 opw-4071503
This fix resolves two critical issues in the Mexican electronic shipping document (Cartaporte) generation that were introduced during a version upgrade. The system was incorrectly calculating customs regime data, causing PDF generation to fail, and was missing country names in tax residency information. These fixes ensure shipping documents are generated correctly for Mexican operations.
Original PR description
[This commit] is a fw-port from 15.0. However, during the adaptation between the versions, we had two issues: - the `regimenes_aduanero` for the PDF was incorrectly computed, causing a crash on generation - the country names for the Residencia Fiscal were not added anymore This commit fixes these issues. task-3990042 [This commit]: https://github.com/odoo/enterprise/commit/e76859d90cfca3a144f10860e8e4e6845850e4f8
This fix resolves an issue where invoices in foreign currency with withholding taxes (like 10% ILA) fail to render properly in the Chilean EDI system. The problem was caused by outdated code using a deprecated method that was removed in version 16. The fix updates the code to use the correct current method, ensuring invoices post successfully.
Original PR description
To reproduce: Create an invoice, in foreign currency. Use a withholding tax, like 10% ILA Post the invoice => The rendering of the dte fails It's still using a deprecated method, which has been removed after 16. no task
Fixed an issue where the Knowledge editor would automatically create empty "Untitled" articles when users reloaded the page with no existing articles. The system now only saves articles when there are actual changes made by the user, preventing unnecessary empty article creation.
Original PR description
When there is no article to load, the form view creates a virtual record and saves it when the user closes the page or reloads it. To avoid creating empty articles, we will trigger an urgent save only if the record is dirty. Steps to reproduce the issue: 1. Delete all articles from the database 2. Open the Knowledge editor (you should see the no-content helper) 3. Reload the page (F5) => The system creates a new "Untitled" article (see the list view). TO BE: The system should not create any article when reloading the view. task-4167335