Daily updates from Odoo
Friday, August 15, 2025
6 changes · 18.0
New functionality added to Odoo
Adds a new integration that lets restaurants and other appointment-based businesses offer bookings through Google Maps Reserve. Odoo can share availability with Google via IAP and receive, update, or cancel reservations, helping businesses reach customers directly from Google Maps.
Original PR description
The new appointment_google_reserve module allows to make your restaurant (or other booking based service) available to book via Google Maps Reserve. See: https://www.google.com/maps/reserve…
The new appointment_google_reserve module allows to make your restaurant (or other booking based service) available to book via Google Maps Reserve. See: https://www.google.com/maps/reserve https://developers.google.com/actions-center/verticals/reservations/e2e/overview The integration works alongside with the IAP server, that plays the middleman between the client server and the Google servers. It is split in three main concepts: 1. The Feed files uploads See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/export-feeds The Google Reserve Service is based on data coming from "feed files", which are manually uploaded once per day via a HTTP call to the IAP servers. IAP servers will take care of the Merchant and Service feed files based on the merchants that registered for this service. The merchant/service registration happens via a HTTP call to the IAP server when an appointment.type is configured accordingly. This is simply done on the appointment.type form by specifying the "merchant" (which is a physical address and some contact details). The same merchant could be re-used between several appointment.types, for example if a hotel allows booking rooms (1 appointment.type) and massages (with a second appointment.type): the merchant is the hotal (same physical location) and the services are both appointment.types. The availabilities for all these services are uploaded to the IAP server with a HTTP call when the IAP server requests them. (See IAP commit message / documentation for more details). 2. The Booking Server See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/implement-booking-server Once a end-user books something from Google Maps Reserve, they (Google) will hit a certain endpoint on the IAP server with the booking details. IAP then needs to relay this information to the merchant (client)'s, acting as a proxy. The information is then stored accordingly, for example as a new calendar.event record on the related appointment.type. The same principle is applied to other necessary concepts; modify bookings, cancel bookings, ... 3. Real-time API updates See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/real-time-api-updates This is in a way the same thing as the booking server, but the other way around. Whenever something happens that modifies availabilities for an appointment, including: - Creating a booking directly in the backend - Creating calendar leaves for the appointment resources - Modifying opening hours - ... We need to update the availabilities on Google's side. In that case, the communication is thus initiated by the client server, that contacts IAP. IAP acts as a proxy again by relaying this information to Google. =============================================================================== Limitations: - Only works for auto-assign mode appointment types - Payment and sales related flow are not implemented. Task-3083812
Resolved issues and error corrections
This update fixes several issues affecting e-invoicing validation, quality control stock handling, loyalty pricelist behavior, recruitment search, and accounting performance. Businesses should see more reliable invoice compliance, smoother operational workflows, and faster reconciliation in large accounting databases.
Original PR description
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
This fix makes point-of-sale loyalty tests more reliable by ensuring the test customer appears near the top of the customer list. It helps prevent random test failures that can block automated validation, without changing customer-facing functionality.
Original PR description
Tours in POS rely on clicking on partners. But the POS interface does not load ALL records, meaning that depending on the test environment, the tested partner "Test Partner 2" can be too far down the list and not loaded properly. This commit fixes this by adding "AAA" in front of the name to move it up un the list order. It's a temporary fix to unblock the runbot and will be investigated more in details. 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
This fixes an accounting issue where reconciling invoices and payments in the same foreign currency could create duplicate exchange adjustment entries that were not correctly linked. Businesses get cleaner reconciliation records and fewer incorrect small currency difference entries.
Original PR description
After https://github.com/odoo/odoo/pull/204746, in some situations we will default the amount of the partial on residual of debit aml even if this one is larger than the credit aml amount. This lead to multiple exchange moves creation that are not properly linked to the reconciliation chain. Steps to reproduce: 1/ Setup foreign currency with rate 0.648587 (ex 0.648587 USD = 1 AUD for AUD company) 2/ Create invoice with lines 36 USD (55.51 AUD) -7.2 USD (-11.1 AUD) => Receivable will be 28.8 USD (44.41 AUD) because it's computed from sum of above lines 3/ Register a payment of 28.8 USD (44.4 AUD) => Two exchange moves will be created with 0.01 in credit, none of them is in a partial with the invoice or payment line This PR makes sure that we take the smallest amount of residual if both credit and debit are considered as fully matched. opw-4835254 Forward-Port-Of: odoo/odoo#219237
This change reverses a recent accounting tax rounding adjustment. It helps restore the previous behavior for tax total calculations, reducing the risk of unexpected invoice or accounting totals.
Original PR description
As per https://github.com/odoo/odoo/pull/222759#issuecomment-3188749767 --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This update records that Luca Policastro has signed Odoo's Contributor License Agreement for Camptocamp. It supports contribution compliance and does not change product behavior or user-facing features.
Original PR description
This pull request adds my Contributor License Agreement (CLA) as required by the Odoo contribution guidelines for Camptocamp company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222429