[September 2026] Odoo community activity and Quartile's contributions

In September 2026 Quartile again continued proposing, improving and porting work at OCA.

September was the month the Odoo 19.0 ports of the summary invoice feature for Japan were merged, one after another. The module giving contacts a kana reading was merged too, and two members of our team joined the PSC of OCA's Japanese localization. Alongside that, we made new proposals in inventory and manufacturing, maintenance, and purchasing.

What we worked on in September 2026

Summary invoices on Odoo 19.0

The Odoo 19.0 port of account_billing, which groups several invoices into a single billing document, was merged in September. We proposed it in May and it had been waiting on the upstream merge since, so the foundation for the Japanese summary invoice feature on 19.0 is now in place.

The Odoo 19.0 ports of l10n_jp_summary_invoice, which prints the summary invoice as a Japanese qualified tax invoice, and l10n_jp_summary_invoice_carryover, which carries the balance from the previous billing onto it, were merged after it. The 19.0 port of l10n_jp_summary_invoice also brings in the partner-level default for excluding invoices from summary billing.

We kept fixing the Odoo 18.0 side as well. In l10n_jp_summary_invoice, the labels in the totals of the printed document were frozen in the language of the user who ran the computation, and they are now printed in the partner's language. In l10n_jp_summary_invoice_carryover we reworked the carryover computation, and carried the fix that computes the carryover per remit-to bank account forward to Odoo 19.0.

Reference:

https://github.com/OCA/account-invoicing/pull/2349
https://github.com/OCA/l10n-japan/pull/124
https://github.com/OCA/l10n-japan/pull/133
https://github.com/OCA/l10n-japan/pull/142

Normalized kana readings

The modules giving contacts a kana reading were merged for Odoo 19.0. We proposed them in August as l10n_jp_name_kana, and during review split it in two: l10n_jp_kana, which carries the normalization, and l10n_jp_kana_partner_name, which adds the field to contacts.

The reading is both the sort key and the lookup key for a name written in kanji. Once full-width katakana, half-width katakana and hiragana are mixed, both sorting and searching become unreliable. The module normalizes readings to the configured format on write, and normalizes search terms the same way before matching. The same contact is found whichever kana form is typed.

At the end of September we proposed an improvement to l10n_jp_kana so that a model delegating a field to another one, such as a product variant, normalizes it in the format of the model it delegates to. It was merged in early October. l10n_jp_kana_product_name for products and l10n_jp_kana_hr_employee_name for employees are still under review.

Reference:

https://github.com/OCA/l10n-japan/pull/137
https://github.com/OCA/l10n-japan/pull/145

Stock valuation and manufacturing

We are proposing stock_valuation_layer_removal_date for Odoo 18.0, which puts a removal date on stock valuation layers. In standard Odoo, a valuation layer keeps no trace of the removal date once the goods have moved. Companies handling perishable goods can then filter and group the valuation report to see how much of their stock value is close to expiry.

The Odoo 18.0 port of mrp_stock_analytic, which assigns an analytic distribution to a manufacturing order, was merged. The distribution carries over to the component moves, so cost analysis by project or department needs no re-entry move by move. Alongside the migration, the distribution now also reaches work-in-progress (WIP) accounting.

We are also working on secondary units, the units the warehouse counts in alongside the stock keeping unit, such as cases or bags. We proposed an improvement to stock_secondary_unit that sets the secondary unit on move lines when lot or serial numbers are generated or imported, and a new module, mrp_secondary_unit, that brings secondary units to manufacturing, both for Odoo 18.0. With mrp_secondary_unit, a recipe written as a number of bags or boxes can be entered on the bill of materials in that unit.

Reference:

https://github.com/OCA/stock-logistics-workflow/pull/2443
https://github.com/OCA/account-analytic/pull/878
https://github.com/OCA/stock-logistics-warehouse/pull/2496
https://github.com/OCA/manufacture/pull/1855

Review and approval built into the flow

For maintenance, we are proposing two new modules for Odoo 18.0. maintenance_equipment_tier_validation applies base_tier_validation, OCA's approval framework, to equipment, so that several reviewers confirm a piece of equipment before it is activated. maintenance_request_done_readonly makes completed maintenance requests read-only, so that a record of an inspection or a repair stands as evidence.

For timesheets, we proposed an improvement to hr_timesheet_sheet for Odoo 18.0. Until now everyone in the groups granted by the review policy could review the sheets of every employee. Naming the approvers per employee fits the common arrangement where a manager approves the sheets of their own reports.

For stock moves, we are proposing an improvement to stock_move_location for Odoo 19.0. It is a per-company setting that turns off immediate transfers in the Move from location wizard, so that every transfer is checked before it is validated.

Reference:

https://github.com/OCA/maintenance/pull/574
https://github.com/OCA/maintenance/pull/578
https://github.com/OCA/timesheet/pull/945
https://github.com/OCA/stock-logistics-warehouse/pull/2653

Purchasing

We proposed purchase_deposit_company_amount for Odoo 16.0, which books a foreign-currency purchase deposit at the company currency amount actually paid. Standard Odoo books it at the rate of the day, so the deposit account never closes out against what was paid and the difference stays behind. The module allocates that difference to the product lines, as part of the acquisition cost rather than as an exchange gain or loss.

We are also proposing purchase_company_invoice_address for Odoo 16.0, which lets a company with several locations choose its own invoice address on a purchase order. Odoo links a company to a single address, so a purchase order could not tell the vendor which location should receive the invoice. The chosen address is printed on the purchase order and the request for quotation.

Reference:

https://github.com/OCA/purchase-workflow/pull/3161
https://github.com/OCA/purchase-workflow/pull/3177

Migrations and more

The Odoo 19.0 port of report_positioned_image, which places images at chosen positions on PDF reports, was merged. We have followed it with a proposal to print an image only on the records matching a condition. A company seal can then appear only on the documents for some customers, for example.

As a foundation for importing files that arrive on a schedule with nobody at the screen, we proposed data_import_log and data_import_log_fs for Odoo 19.0. Each imported file is logged, and the rows are processed separately, so that only the rejected rows are cut out and returned to the sender.

We are porting base_view_action_visibility, which restricts the Duplicate and Delete actions per model, to Odoo 16.0, and website_sale_product_publish_date, which controls a product's visibility in the shop with a publish and an unpublish date, to Odoo 18.0.

Reference:

https://github.com/OCA/reporting-engine/pull/1193
https://github.com/OCA/server-tools/pull/3744
https://github.com/OCA/server-ux/pull/1330
https://github.com/OCA/e-commerce/pull/1111

Our role in the community

Lin and Kanda from our team joined the PSC of OCA's Japanese localization (l10n-japan). A PSC (Project Steering Committee) is responsible for a project's direction and quality, and decides which pull requests are merged. They were selected on their review and merge activity since January 2024, and the l10n-japan PSC now has three members.

In September, Nobu from our team attended OCA Days and Odoo Experience in Belgium, and shared what came out of them at the Odoo Open Talk at the end of the month. How the two events differ is the subject of a separate article.

Reference:

https://github.com/OCA/repo-maintainer-conf/pull/191
https://www.quartile.co/blog/odoo-bits-pieces-1/odoo-two-communities-oca-days-odoo-experience-2026-2262

A note from the team

It has turned much cooler here in Fukuoka too, and autumn is in the air.

The 19.0 port of account_billing, which the August report mentioned, was finally merged in September. l10n_jp_summary_invoice and the carryover module followed, so the summary invoice for Japan can now be installed on Odoo 19.0 from the OCA branches.

In the same month, Lin and I joined the l10n-japan PSC. We can now move reviews and merges along ourselves more than before, and deciding what gets merged also means answering for its quality.

We will keep working with the community so that modules fitting Japanese business practice reach users sooner and with solid quality.