Friday, March 8, 2024
9 changes · saas-17.1
New functionality added to Odoo
This update enables Odoo users in Brazil to accept payments via Pix, a popular instant payment system developed by the Central Bank. The addition of static Pix code support streamlines the payment process, leveraging existing bank apps and ensuring compatibility with major Brazilian banks. Portuguese translations and thorough testing have been completed, enhancing the user experience.
Original PR description
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix…
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix codes [2] are BR codes [3] which are based on EMV QR codes. This commit adds support for static Pix codes. These contain all the info needed to make a payment. Dynamic Pix codes are more complex and not supported. Two validators were used to verify correctness [4][5]. The resulting Pix codes were also tested with the Caixa, Nubank and Itau bank apps (thanks to INGO!). Portuguese translations provided thanks to MADI. This will be merged into l10n_br in master. [1] https://www.bcb.gov.br/en/financialstability/pixstatistics [2] https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf [3] https://www.bcb.gov.br/content/config/Documents/BR_Code_MANUAL_Version_2_May_2020.pdf [4] https://pix.nascent.com.br/ [5] https://openpix.com.br/qrcode/scanner/ task-3669412 Forward-Port-Of: odoo/odoo#156211
Resolved issues and error corrections
This update corrects an issue where Saudi invoices weren't being validated correctly due to timezone differences. The fix ensures that the invoice date is accurately compared, regardless of the user's location. This prevents invoices from being incorrectly flagged and ensures proper compliance with Saudi regulations.
Original PR description
Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * make sure user timezone is Asia/Riyadh * create and post an invoice between these time from 12:00 to 3:00 Cause ----- EDI Invoice could be validated closes odoo/odoo#155363 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#155895
This update resolves a discrepancy in invoice tax calculations, specifically when simulating EPD lines. The fix ensures that tax calculations are correctly applied by using the commercial partner instead of the partner ID during the simulation process, resulting in accurate tax totals.
Original PR description
Set 'Rounding Method' to 'Round globally' Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)' Create a Payment term with 1% discount if paid before 30 days Create a company partner with child contact Create an invoice: - Add as partner the company partner (parent contact) or no contact at all (makes no difference) - Add a line with product 420.99, tax 21% not included - Add the payment term Tax total will show 87.52 Add the child contact as partner (set again payment terms if needed) Issue: Tax total will show 87.53 This occurs because, when simulating the not yet stored epd vals, we create the line using the `partner_id` and not the commercial partner. Then, when tax amounts are aggregated and rounding errors are managed the partner is used as grouping key to retrieve vals, so we don't fix the rounding error correctly opw-3661210 Forward-Port-Of: odoo/odoo#154174
This update streamlines the order preparation process in the restaurant POS module. Previously, note changes would reset the order, and order stages weren't sorted by product category. Now, notes are updated directly, products are categorized, and the system only sends crossed-out lines to the next stage, improving efficiency and accuracy.
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 enterprise PR: https://github.com/odoo/enterprise/pull/57385 Forward-Port-Of: odoo/odoo#155246
This update fixes a limitation where only one automation rule could be triggered for incoming messages on Helpdesk tickets. The change ensures that multiple rules can now be active for the same trigger, providing greater flexibility in automating helpdesk workflows. This improves the efficiency of automated responses and ticket management.
Original PR description
Steps to reproduce: - Install base_automation_hr_contract and helpdesk - Setup two automation rules with model "Helpdesk Ticket" and "On incoming message" as trigger - Create a ticket in helpdesk Issues: Traceback is shown because `_message_post` doesn't have the origin attributes. This is due to the closure being wrong as explained here: https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L686-L691 Solution: Encapsulate the `_message_post` function definition, so that each times we patch message_post we patch it with a new function. This wasn't the case before since `_message_post` wasn't isolated. This solution is similar to the other method patched. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L711-L734 opw-3758851 Forward-Port-Of: odoo/odoo#155596
The product search feature in the Point of Sale system has been optimized to handle large product databases more efficiently. By increasing the delay before search queries are triggered, we've reduced performance issues and improved the overall responsiveness of the system when users are searching for products.
Original PR description
Before this commit, searching for a product in the product screen was problematic when dealing with large databases. The search function was triggered too frequently, leading to performance issues. With this commit, I have increased the debounce time for the product search. This reduces the frequency of search operations when user is typing. opw-3788796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156806
This update corrects a display issue where data from a secondary company (compB) was incorrectly shown on the accounting dashboard. The fix ensures that data is accurately reflected only for the user's designated main company (compB), resolving a potential confusion regarding company-specific financial information. This improves data clarity and accuracy for users managing multiple companies.
Original PR description
Setup 2 companies with a COA: compA & compB For compA, have a journal having some data Give you access to compA & compB but make sure compB is your main company => samples data are displayed on the accounting dashboard for the journal Setup 2 companies with a COA: compA & compB, compB being a branch of compA For compA, create a journal Add some data into this journal using compB Give you access to only compA => you should not be able to see the data from compA since the data belongs to compB Introduced by: https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf issue: 3722386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156737 Forward-Port-Of: odoo/odoo#153641
This update fixes a bug where German businesses using the SKR03 fiscal localization were incorrectly flagged as not requiring VAT. The change ensures that fiscal positions with a VAT ID are automatically marked as requiring VAT, aligning with German tax regulations. This prevents potential errors and ensures accurate accounting for our German customers.
Original PR description
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal…
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: - The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: - We update the data file of the fiscal localization to the expected value opw-3721912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156934 Forward-Port-Of: odoo/odoo#156444
This update fixes an issue where invoices imported through the l10n_it_edi module were consistently being added to the first company in a multi-company setup. Now, invoices are correctly imported into the company they belong to, ensuring accurate accounting records across all businesses.
Original PR description
When the Cron runs in a multi-company environment, all invoices imported only in first company. They should be imported in the company they belong to. Ticket link: https://www.odoo.com/web#model=project.task&id=3744537 opw-3744537 Forward-Port-Of: odoo/odoo#156462