Daily updates from Odoo
Friday, December 27, 2024
7 changes
1 change
Enhancements to existing features
The VoIP softphone now loads more recent calls and contacts as users scroll, instead of requiring all entries to appear at once. This makes browsing longer call histories and contact lists easier and keeps the interface more responsive.
Original PR description
Implement "infinite scrolling" in recent calls/contacts tabs. Task-3984680
3 changes
Enhancements to existing features
The Point of Sale +/- button now changes quantities and prices to negative values instead of resetting them to zero. This makes returns, refunds, and negative quantity adjustments more accurate and easier for cashiers to handle.
Original PR description
Before this commit: ------------------------- Previously, when adding a product and clicking the "+/-" button, the quantity would change to "0" instead of becoming negative. After this commit: ----------------------- After implementing this commit, pressing the +/- button now results in the quantity value changing to negative instead of changing it to 0. task- 4281516 Related PR: https://github.com/odoo/enterprise/pull/73653
Resolved issues and error corrections
Point of Sale global invoices now use the currency exchange rate from the original POS order instead of defaulting to 1. This helps Mexican localization documents show the correct TipoCambio value and improves acceptance of invoices created from foreign-currency POS orders.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: `pos.order.currency_rate` is the rate of the Currency at the time the order was created. It is the perfect value to use for `TipoCambio`. We must also adapt workflows that were designed with the absence of `rate` in `tax_base_line_values`. Test in Enterprise opw-4302180
This fixes Mexican Point of Sale global invoices created in a foreign currency so they use the correct exchange rate instead of defaulting to 1.000000. It helps ensure USD POS invoices are accepted and accurately reflect the required currency conversion information.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well. Fix in Community opw-4302180
3 changes
Resolved issues and error corrections
Odoo push notifications stopped working due to an update in Google's Firebase API. This change updates the necessary software components to align with the latest Firebase version, restoring the ability to send push notifications. This ensures continued functionality for features relying on push notifications.
Original PR description
Google recently updated the Firebase API and deprecated support for the version we are currently using (v6.3.4). As a result, Odoo push notifications are no longer functional. This PR updates the dependencies and API calls to align with the latest Firebase API, ensuring that push notifications can once again be sent from Odoo. see: https://firebase.google.com/docs/cloud-messaging/migrate-v1 task-4247811 Forward-Port-Of: odoo/enterprise#73390
This update prevents errors during batch delivery validation when using Sendcloud shipping. Previously, a validation error on one order would halt the entire process. Now, orders are processed correctly on the carrier side, even if individual validations fail, ensuring smoother delivery workflows.
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. community: https://github.com/odoo/odoo/pull/190320 opw-4357325 Forward-Port-Of: odoo/enterprise#75502
This update fixes an issue where debit notes created from invoices were defaulting to the wrong document type (33) when the EDI module was active. The change ensures the correct document type (56) is used, aligning with SII requirements and preventing errors in electronic invoicing. This ensures compliance and accurate data transmission.
Original PR description
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011