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

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

October was the month we started moving the Japanese localization modules to Odoo 20.0, announced in September. On Odoo 19.0, the kana reading modules for products and employees were merged, following the one for contacts. Alongside that, we made proposals and improvements in summary invoices, inventory, AI integration, and mail and administration.

What we worked on in October 2026

Moving to Odoo 20.0

We started moving the modules of OCA's Japanese localization (l10n-japan) to Odoo 20.0, announced at Odoo Experience in September, in October. Within the month we proposed 20.0 ports of eleven l10n-japan modules, and of account_billing, the foundation of the summary invoice.

l10n_jp_address_layout, which puts the address fields on the contact form in the Japanese order, and account_payment_term_cutoff_day, which adds a cutoff day to payment terms and computes the due date from it, were merged during October. l10n_jp_kana, which normalizes kana readings, was merged in early November, and the reading modules for contacts, products and employees follow it.

l10n_jp_summary_invoice and l10n_jp_summary_invoice_carryover for the summary invoice, report_alternative_layout, which adds a document layout with the partner address on the left, l10n_jp_partner_title_qweb, which prints the partner's honorific in the addressee, and l10n_jp_country_state, which shows prefecture names in the user's language, are under review. Standard Odoo dropped its contact title in 19.0, so on 20.0 too l10n_jp_partner_title_qweb carries the honorific for each partner.

Reference:

https://www.quartile.co/blog/odoo-bits-pieces-1/odoo-v20-release-highlights-2269
https://github.com/OCA/l10n-japan/pull/148
https://github.com/OCA/l10n-japan/pull/150
https://github.com/OCA/l10n-japan/pull/156

Kana readings and postcodes

l10n_jp_kana_product_name, which gives products a kana reading, and l10n_jp_kana_hr_employee_name, which gives employees one, were merged for Odoo 19.0 in early October. They follow the contacts module from September, so on 19.0 contacts, products and employees can all be found by their reading, whichever kana form is typed. Products can be picked by their reading in fields such as order lines. The employee reading is also shown on the public employee profile, so users without HR access can find colleagues by it.

An improvement to l10n_jp_kana with interfaces to other systems in mind was merged. ヵ and ヶ, which are read カ as in 3ヶ月, now become カ in every format. In the half-width format, kana with no half-width form, such as ヮ, ヰ and ヱ, fold to the nearest half-width kana. A new option restricts the characters a reading may hold, so a reading with a character the receiving side cannot take is refused on save, naming that character.

For addresses, we newly proposed l10n_jp_partner_zip for Odoo 19.0, which stores the postcodes of contacts in the 810-0041 format. It evens out input with or without the hyphen, in full-width digits or with the 〒 mark, and applies to imports and API calls as well as the form. We also proposed the 19.0 port of l10n_jp_partner_zip_address, which fills in the address from the postcode.

Reference:

https://github.com/OCA/l10n-japan/pull/138
https://github.com/OCA/l10n-japan/pull/139
https://github.com/OCA/l10n-japan/pull/158
https://github.com/OCA/l10n-japan/pull/160

Summary invoices and accounting

We proposed the Odoo 19.0 port of account_billing_from_cutoff, which creates summary invoices for all partners at once from a cutoff date. It picks the invoices by the cutoff date that account_payment_term_cutoff_day computes from the payment term. Following the 19.0 ports of the summary invoice merged in September, it completes the cutoff-based billing flow on 19.0.

We are also proposing to account_billing a way to send summary invoices to partners by email. A validated summary invoice can be sent with its PDF attached, and several can be sent at once in the background from the list. The email template can be set per company. It carries an improvement we are proposing for Odoo 18.0 forward to 19.0.

For the 19.0 version of l10n_jp_summary_invoice, we proposed a fix for line quantities handled with two decimal places, because the name of the quantity precision changed in 19.0.

purchase_deposit_company_amount, which we proposed in September to book a foreign-currency purchase deposit at the company currency amount actually paid, was merged in October. It is for Odoo 16.0. The deposit account closes out to zero at the amount paid, and the difference against the rate is treated as part of the acquisition cost and reflected in the stock valuation of the received goods. purchase_company_invoice_address, also proposed in September, which lets a purchase order choose the company's own invoice address, was reviewed through October and merged in early November.

Reference:

https://github.com/OCA/l10n-japan/pull/159
https://github.com/OCA/account-invoicing/pull/2504
https://github.com/OCA/l10n-japan/pull/162
https://github.com/OCA/purchase-workflow/pull/3161

Inventory and approval

stock_move_actual_date, which records the real date of stock transfers and scraps, is being renamed stock_date_done and reworked for its Odoo 19.0 port. Odoo 19.0 lets you edit the effective date of a done transfer out of the box, so instead of a separate Actual Date field, the module now makes the standard effective date itself auditable. The date and time a record is first done is kept as the Original Effective Date, and only members of a dedicated group can edit the effective date of a done record. It can never be moved before the accounting hard lock date, and the module extends that check, which core applies to transfers only, to scraps.

We proposed stock_inventory_tier_validation for Odoo 16.0, which adds an approval step to inventory adjustments. It applies base_tier_validation, OCA's approval framework, to adjustments, so counted quantities reach stock only when an approved adjustment is done. While approvals are configured, quantities cannot be applied directly from the on-hand stock screen.

For secondary units, we proposed an improvement to stock_secondary_unit for Odoo 18.0 that sets the product's secondary unit for inventory as the default on a move line added by hand. The improvement to sale_order_secondary_unit that carries the sales order's secondary unit over to invoice lines was merged, so combining it with account_move_secondary_unit no longer needs a glue module.

Reference:

https://github.com/OCA/stock-logistics-workflow/pull/2346
https://github.com/OCA/stock-logistics-warehouse/pull/2681
https://github.com/OCA/stock-logistics-warehouse/pull/2660
https://github.com/OCA/sale-workflow/pull/4114

AI integration

ai_tool_read, which lets an AI agent read data in Odoo, was merged for Odoo 16.0. It provides three tools, listing the available models, describing a model's fields, and searching and reading records, and all of them run with the calling user's own access rights. AI reading can be forbidden per field, and the values of sensitive fields such as personal data are kept out of the results, together with the related and computed fields that expose them. Filtering or sorting on such a field is not prevented, though, and the module says so as a known issue.

In ai_oca_mcp, which lets external AI clients call Odoo's AI tools, a fix letting regular internal users use their own MCP keys was merged. Other users' keys stay hidden. We have also opened ai_oca_mcp_oauth as a draft, which connects MCP clients such as Claude through an OAuth sign-in instead of a key entered by hand. We proposed the Odoo 18.0 ports of ai_oca_mcp and ai_tool_read as well.

Reference:

https://github.com/OCA/ai/pull/122
https://github.com/OCA/ai/pull/93
https://github.com/OCA/ai/pull/133
https://github.com/OCA/ai/pull/134

Mail and administration

We proposed mail_max_email_size for Odoo 16.0, which sends the attachments of a large email as download links instead. It backports a standard feature of Odoo 18.0 to 16.0. Notifications are sent once per follower, so an email with a few MB of attachments, posted on a document with several followers, multiplies the data sent. We saw such emails stay in the outgoing queue for hours, reach the same recipients several times, and hold up the mails behind them. The maximum size can be set per outgoing mail server.

We are also proposing mail_message_history for 16.0, which lists chatter messages across documents so they can be searched and filtered. Messages posted by users and messages logged by the system can be viewed apart, and the document name, which core leaves empty on system-logged messages, is filled in. In mail_post_defer, which defers sending emails, an improvement that honors a request for immediate sending from standard features was merged for Odoo 15.0. Also for 15.0, we are continuing our proposal of mail_last_message_date, which gives every model with a chatter a field holding the date of its latest message, for use in conditions such as those of automated actions.

On the administration side, a fix to auditlog, which records change history, was merged for Odoo 19.0, and we proposed it for 16.0 as well. Reverting an audit rule left the replaced method behind, which could stop the overrides of modules loaded later from taking effect. We are also proposing a fix to base_export_manager, where Export All could be used on models without export access, and endpoint_log, which logs the requests to and responses from endpoints in the database.

Reference:

https://github.com/OCA/mail/pull/313
https://github.com/OCA/mail/pull/247
https://github.com/OCA/server-tools/pull/3787
https://github.com/OCA/server-ux/pull/1378

A note from the team

Within a month of Odoo 20.0's announcement, we had proposed the ports of eleven l10n-japan modules. We have been using AI to improve how we work, and the move from 19.0 to 20.0 is going much more smoothly than past migrations did. Being able to use the modules for Japan early on a new version is, we believe, one of the conditions that matter to anyone considering Odoo or an upgrade.

I took on the 19.0 port of account_billing_from_cutoff, which groups invoices into summary invoices by cutoff date. The summary invoice modules are coming together on 19.0, and I would like to get 20.0 to the same point soon.

We will keep working with the community on reviews and migrations, so that modules fitting Japanese business practice can be used with solid quality on both 19.0 and 20.0.