[2026年10月] Odooコミュニティ活動とコタエルの取り組みのご報告

2026年10月も、コタエルではOCAへの提案・改善・移行対応を継続しました。

10月は、9月に発表されたOdoo 20.0に向けて、日本のローカライゼーションのモジュールの移行を始めた月になりました。Odoo 19.0では、連絡先に続いてプロダクトと従業員の読み仮名のモジュールがマージされています。あわせて、合計請求書、在庫、AIとの連携、メールと管理の各領域で提案と改善を進めました。

2026年10月の取り組み

Odoo 20.0への移行

9月のOdoo Experienceで発表されたOdoo 20.0に向けて、OCAの日本のローカライゼーション（l10n-japan）のモジュールの移行を10月に始めました。月内に、l10n-japan の11モジュールと、合計請求書の土台になる account_billing のOdoo 20.0対応を提案しています。

連絡先フォームの住所欄を日本式の並びにする l10n_jp_address_layout と、支払条件に締日を設定して支払期日を計算する account_payment_term_cutoff_day は、10月中にマージされました。読み仮名を正規化する l10n_jp_kana も11月初めにマージされ、連絡先、プロダクト、従業員の読み仮名のモジュールがこれに続きます。

合計請求書の l10n_jp_summary_invoice と l10n_jp_summary_invoice_carryover、取引先の住所を左に置く帳票のレイアウトを追加する report_alternative_layout、取引先の敬称を宛名に印字する l10n_jp_partner_title_qweb、都道府県名をユーザの言語に応じて表示する l10n_jp_country_state は、レビュー中です。Odoo標準の敬称は19.0で廃止されたため、20.0でも l10n_jp_partner_title_qweb が取引先ごとの敬称を受け持ちます。

参考リンク:

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

読み仮名と郵便番号

Odoo 19.0向けに提案していた、プロダクトに読み仮名を持たせる l10n_jp_kana_product_name と、従業員に読み仮名を持たせる l10n_jp_kana_hr_employee_name が、10月初めにマージされました。9月の連絡先に続くもので、19.0では連絡先、プロダクト、従業員のいずれも、入力したカナの種類を問わず読み仮名で探せます。プロダクトはオーダ明細などの入力欄で読み仮名から選べます。従業員の読み仮名は公開従業員プロファイルにも表示されるため、人事の権限を持たないユーザも同僚を読みで探せます。

l10n_jp_kana には、他のシステムへの連携を見据えた改善がマージされました。「3ヶ月」の「ヶ」のように「カ」と読む「ヵ」「ヶ」は、どの形式でも「カ」にそろえます。半角カナの形式では、半角の文字がない「ヮ」「ヰ」「ヱ」なども近い半角カナに変換します。読み仮名に使える文字を制限するオプションも加わり、受け側で使えない文字を含む読み仮名は、保存の時点でどの文字かを示して受け付けません。

住所では、連絡先の郵便番号を「810-0041」の形式にそろえて保存する l10n_jp_partner_zip を、Odoo 19.0向けに新しく提案しました。ハイフンの有無や全角数字、「〒」の付いた入力をそろえ、画面での入力だけでなく、インポートやAPI経由の登録にも適用します。郵便番号から住所を補完する l10n_jp_partner_zip_address の19.0対応も提案しています。

参考リンク:

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

合計請求書と会計

締日を指定して取引先ごとの合計請求書を一括で作成する account_billing_from_cutoff について、Odoo 19.0対応を提案しました。対象の請求書は、支払条件の締日から account_payment_term_cutoff_day が計算した締日で選びます。9月にマージされた合計請求書の19.0対応に続き、締日を基準にした請求の流れを19.0でそろえるものです。

合計請求書を取引先にメールで送る機能も、account_billing に提案しています。確定した合計請求書を帳票のPDFを添付して送信でき、一覧から複数件をまとめてバックグラウンドで送ることもできます。メールのテンプレートは会社ごとに設定できます。Odoo 18.0向けに提案中の改善を、19.0にも展開したものです。

l10n_jp_summary_invoice の19.0版では、数量の小数精度の名前が19.0で変わったために、明細の数量が小数点以下2桁で扱われていた問題の修正を提案しました。

9月に提案した、外貨建ての購買前払金を実際に支払った自国通貨の金額で計上する purchase_deposit_company_amount は、10月にマージされました。Odoo 16.0向けです。前払金の勘定が支払額どおりにゼロで消し込まれ、レートとの差額は取得原価の一部として、入荷した商品の在庫評価にも反映されます。同じく9月に提案した、発注書で自社の請求先住所を選べる purchase_company_invoice_address も、10月のレビューを経て11月初めにマージされました。

参考リンク:

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

在庫と承認

入出庫や廃棄に実際の日付を記録する stock_move_actual_date は、Odoo 19.0対応にあわせて stock_date_done に名前を変え、作り直しを進めています。19.0では完了済みの入出庫の有効日を標準で変更できるため、独自の「実績日」の項目をやめ、標準の有効日そのものを監査できる形にしました。最初に完了した日時を「元の有効日」として残し、完了済みの有効日を変更できるのは専用の権限グループのユーザに限ります。会計のハードロック日より前の日付には変更できず、標準では入出庫だけが対象のこのチェックを、廃棄にも広げています。

棚卸の調整に承認の手順を加える stock_inventory_tier_validation を、Odoo 16.0向けに提案しました。OCAの承認基盤 base_tier_validation を在庫調整に適用し、数えた数量は、承認された調整を完了したときにだけ在庫に反映されます。承認の設定があるあいだは、手持在庫の画面から数量を直接適用することはできません。

副単位では、移動明細を手で追加したときに、プロダクトの在庫用の副単位を初期値として設定する stock_secondary_unit の改善を、Odoo 18.0向けに提案しました。販売オーダの副単位を請求書の明細に引き継ぐ sale_order_secondary_unit の改善はマージされ、account_move_secondary_unit と組み合わせるための連携モジュールが不要になりました。

参考リンク:

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との連携

AIエージェントにOdooのデータを読ませるための ai_tool_read が、Odoo 16.0向けにマージされました。利用できるモデルの一覧、モデルの項目の説明、レコードの検索と読み取りの3つのツールを提供し、いずれも呼び出したユーザ自身の権限で動きます。項目ごとにAIの読み取りを禁止でき、個人情報など機微な項目の値は、その項目を参照する関連項目や計算項目も含めて結果に返しません。ただし、その項目での絞り込みや並べ替えまでは防げないため、既知の課題として明記しています。

OdooのAIツールを外部のAIクライアントから呼び出せるようにする ai_oca_mcp では、一般の社内ユーザが自分のMCPキーを使えるようにする修正がマージされました。他のユーザのキーは、引き続き見えません。あわせて、ClaudeなどのMCPクライアントを、手で入力するキーではなくOAuthのサインインで接続する ai_oca_mcp_oauth をドラフトとして公開しています。ai_oca_mcp と ai_tool_read のOdoo 18.0対応も提案しました。

参考リンク:

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_max_email_size を、Odoo 16.0向けに提案しました。Odoo 18.0の標準機能を16.0に移植したものです。通知はフォロワーごとに送られるため、数MBの添付があるメールを複数のフォロワーがいる伝票に投稿すると、送るデータが何倍にもなります。実際に、こうしたメールが何時間も送信キューに残り、同じ相手に何度も届いたうえ、後ろのメールまで止まる事例がありました。上限のサイズは送信メールサーバごとに設定できます。

チャタのメッセージを伝票をまたいで一覧で検索、絞り込みできる mail_message_history も、16.0向けに提案しています。ユーザが投稿したメッセージとシステムが記録したメッセージを分けて見られ、標準では空になるシステムのメッセージの伝票名も補います。メールの送信を遅らせる mail_post_defer では、標準の機能が即時送信を求めた場合にはそれに従う改善が、Odoo 15.0向けにマージされました。同じ15.0向けには、チャタの最新メッセージの日時を、チャタを持つすべてのモデルで項目として参照できる mail_last_message_date の提案も続けており、自動アクションの条件などに使えます。

管理の面では、変更履歴を記録する auditlog の修正がOdoo 19.0でマージされ、16.0への展開も提案しています。監査ルールを解除しても置き換えたメソッドが残り、後から読み込まれたモジュールの処理が効かなくなることがありました。ほかに、エクスポートの権限がないモデルで「すべてエクスポート」が使えてしまう base_export_manager の問題の修正や、エンドポイントへのリクエストとレスポンスをデータベースに記録する endpoint_log の提案を進めています。

参考リンク:

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

担当者よりひとこと

Odoo 20.0の発表から1か月で、l10n-japan の11モジュールの移行を提案できました。AIでオペレーションを改善しているところもあり、19.0から20.0への移行も、以前に比べるとずいぶんスムーズに進められています。新しいバージョンで日本向けのモジュールを早く使えることは、導入や移行を検討する方にとって大事な条件の一つだと考えています。

私自身は、締日で合計請求書をまとめる account_billing_from_cutoff の19.0対応を担当しました。19.0では合計請求書の一連のモジュールがそろいつつあり、20.0でも同じ状態を早く整えたいところです。

19.0と20.0のどちらでも、日本の商習慣に合ったモジュールを確かな品質で使えるよう、コミュニティの皆さんと一緒にレビューと移行を進めていきます。