Tuesday, September 8, 2026
10 changes · master
New functionality added to Odoo
Turkish companies can now respond to received e-Dispatches directly from Odoo instead of manually using the Nilvera portal. The new workflow records received, rejected, missing, or excess quantities and follows up automatically to retrieve finalized documents from GIB.
Original PR description
A Turkish company receiving an e-Irsaliye has to tell GİB what it got: how much arrived, how much was rejected and why, and whether anything was short or in excess. Odoo could import a received…
A Turkish company receiving an e-Irsaliye has to tell GİB what it got: how much arrived, how much was rejected and why, and whether anything was short or in excess. Odoo could import a received e-Dispatch but not answer one, so the reply had to be filed by hand on the Nilvera portal. This module bridges l10n_tr_nilvera_edispatch and quality_control with a Unit Count control point, restricted to receipts of Turkish companies and to one point per operation type, since a dispatch is answered once. Its check carries one line per stock move, holding the received, rejected, missing and excess quantities and a rejection reason. Passing or failing it writes the counted quantities back onto the moves. The answer goes to Nilvera as an AcceptAll when every line arrived complete, and as DespatchAnswerLines otherwise. Its GİB document number is built from the Quality Control Point sequence prefix, the receipt's year and the check's number, and kept on the receipt so a retry re-uses the number Nilvera may already hold. An unknown serie is registered and the send retried once. Two hourly crons follow the answer up, on the receipts the company answers and the deliveries its customers answer, and pull the signed XML and PDF once GİB settles it. task-5419976
Odoo now supports issuing Egyptian Tax Authority e-receipts directly from Point of Sale orders. This helps Egyptian retailers validate, submit, track, and reprint compliant electronic receipts as part of the normal checkout flow.
Original PR description
Introduce a new localization module integrating the Point of Sale with the Egyptian Tax Authority (ETA) e-invoicing service so that PoS orders can be issued as e-receipts: signing, submission, status tracking and the customer-facing QR/receipt printout are handled at validation time and replayed from the ticket screen when needed. The shared serialization helpers used to build the ETA document are extracted from `l10n_eg_edi_eta` into a reusable `tools/eta_serialize.py` so both invoice- and PoS-based flows produce the same canonical payload, and product templates expose the activity-code fields required by the e-receipt schema. task-3925833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds a new My Subscription area that lets on-premise customers manage databases, subscriptions, IAP services, and related account actions from one place. It brings subscription-management features closer to the SaaS experience and makes common actions like upgrades, support, pricing, and database renaming easier to access.
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
Enhancements to existing features
The stock traceability report now shows both where products came from and where they went, including finished products and customers, within the same report. Expanding report lines is faster and clearer, with better visual hierarchy and highlights for locations that still hold stock.
Original PR description
Expand towards end products and customers: Instead of moving downstream moving from one report to the next, we're adding a way to find all the 'children' lines of the select stock move line(s). This way we can stay in the same report and have a global view upstream and downstream from any point in the chain. Moreover, we're modifying the Unfold/Fold button to fetch all records in python before sending the final result at once to the JS. This limits the number of calls between JS and python to one. If we enter the report from the middle of a chain, there will be at least two lines show, one going upstream (parent line, existing behavior) and one going downstream (child line, new behavior). The most recent lines are shown at the top of the report. task 5265405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Social media managers can now set different scheduled times for each social channel within one post, making multi-channel campaigns easier to coordinate. The update also refreshes social calendar and card views, separates likes, comments, and shares for clearer reporting, and adds controls to cancel posts that are still being published.
Original PR description
Purpose ======= Allow specifying a schedule date per media, like we did for the message, images, first comment, etc. In the calendar view, we show the post from the smallest date to the latest date. When moving card in the calendar view, we try to keep the same hour of the day of all scheduled date share the same day (most of the time, we will schedule different hour of the day for different media, and changing the day from the calendar view is convenient). Now the CRON is triggered when adding the post in the queue instead of for every scheduled dates update. We cannot schedule a post not in draft state. Improve the kanban cart of the social.media Improve the kanban view of the `social.live.post` to make it look like the `social.stream.post`. Like we have for `social.stream.post`, use the number of likes, the numbers of comments and the number of shares instead of aggregating everything into "engagement". Task-6323897
The barcode app now uses a more consistent scanning and manual entry experience across its screens, reducing confusion for warehouse users. Barcode Lookup product creation is also available from every scanner view, with added support for expiry-date handling when relevant.
Original PR description
Before the barcode app had inconsistent barcode scanning flows, sometimes a dialog was opened, sometimes you had to click on the 'gear' icon to input the code manually. Now it has been unified to follow the same flow. Moreover, capability to create a new product with Barcode Lookup is added to all barcode scanners to provide consistency. task-4170451
This update makes it easier for businesses with multiple companies or branches to move, buy, sell, and value goods across company boundaries. It improves warehouse resupply routes, sales and purchase delivery options, stock valuation for intercompany transfers, and reporting visibility for intercompany deliveries.
Original PR description
[WIP] --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Bangladesh localization updates its taxes and chart of accounts to align with Finance Act 2026 requirements. Businesses get clearer statutory tax categories, better account rollups for reporting, and updated company accounting defaults while obsolete tax reporting setup is removed.
Original PR description
This commit replaces the percentage-based tax structure and the flat chart of accounts with the ones required by the Finance Act 2026, and removes the outdated tax report. Before: the 16 tax…
This commit replaces the percentage-based tax structure and the flat chart of accounts with the ones required by the Finance Act 2026, and removes the outdated tax report. Before: the 16 tax templates were grouped by rate alone (`VAT at 2%`, `VAT at 4.5%`, ...), which says nothing about the law a tax is levied under. The chart had no hierarchy beyond `active=False` range accounts (`100100-100199`), so nothing rolled up and a section-wise Trial Balance was impossible. `tr_form` no longer matched the NBR reporting format. Now: taxes sit on the three statutory pillars, Value Added Tax (VAT and Supplementary Duty Act, 2012), Tax Deducted at Source (Withholding Tax Rules, 2026) and VAT Deducted at Source (VAT and Supplementary Duty Rules, 2016), with VDS and TDS flagged as withholding so they are held back until payment rather than deducted on the invoice. The chart is a real `parent_id` hierarchy, `1 Assets` -> `11 Current Assets` -> `111 Cash & Cash Equivalents` -> `111400 Bank Suspense Account`, so accounts roll up by section. `bank_account_code_prefix` moves to `1111` and `_get_account_parent_xmlid` nests the auto-created journal accounts under `111` instead of leaving them outside the tree. The company defaults follow the new chart: VAT 15% on sales and purchases, fiscal year ending 30 June, and the inventory, exchange difference, bank and deferred accounts. The obsolete tax report is dropped along with its fiscal positions, which mapped nothing once the rate-based taxes were gone. task-6219535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll now treats employee versions as concurrent when their worker code and DIMONA category match, so payslips automatically include the right related versions. Payruns now select employees and create payslips for each relevant employee-version combination, reducing manual selection issues and duplicate warnings.
Original PR description
For Belgian payroll, employee versions are now considered concurrent if their DIMONA category and worker code match, instead of only contract dates. So that change the logic in the payslip for where…
For Belgian payroll, employee versions are now considered concurrent if their DIMONA category and worker code match, instead of only contract dates. So that change the logic in the payslip for where if you select specefic version, the payslip will also include the concurrent versions with the same worker code and DIMONA category. And if all the versions are concurrent in the payslip period, you will not have an option to select specific version and the payslip will automatically include all the concurrent versions. For Payrun: now selects employees instead of versions A payslip is generated for every employee-version combination within the payrun period If an employee has multiple versions in the payrun period, a payslip is created for each version The previous tests did not account for the newly added concurrency. In some tests, so that calculate all the concurrent versions in the same payslip and merging two versions into a single payslip hit the contract's wage limit. Since the total payment was capped regardless of the combined payslip amounts, those tests nothing now . To resolve this, I changed the version dates to ensure each version is tested separately. Additionally, I removed test_bik_first_payslip_unpaid. That specific scenario no longer exists now that the versions run concurrently. Task Id: 6126845
Restaurants can now create a one-time QR code when seating guests, print it on a ticket, and let customers use it to access the self-ordering menu for that visit. The code is invalidated after payment, reducing reuse risk and supporting more controlled table-based self-ordering workflows.
Original PR description
To support common self-ordering workflows, restaurants require dynamic, single-use QR codes generated per visit rather than static QR codes per table. Specification: - Allow staff to generate a dynamic QR code when seating a customer in the POS. - Extend POS receipt functionality to print the dynamic QR code on a physical ticket. - Enable customers to scan the ticket to access the self-ordering menu for their session. - Add validation to ensure the QR code is immediately invalidated and cannot be reused once the payment is validated. task-4934385