![[2026年8月] Odooコミュニティ活動とコタエルの取り組みのご報告](/web/image/blog.post/2257/author_avatar/%5B2026%E5%B9%B48%E6%9C%88%5D%20Odoo%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E6%B4%BB%E5%8B%95%E3%81%A8%E3%82%B3%E3%82%BF%E3%82%A8%E3%83%AB%E3%81%AE%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF%E3%81%AE%E3%81%94%E5%A0%B1%E5%91%8A?unique=80ee65d)
2026年8月も、コタエルではOCAへの提案・改善・移行対応を継続しました。
8月は、日本語環境での使い勝手を整える取り組みが中心になりました。日本のローカライゼーションに関する修正がOdoo本体にマージされ、連絡先や商品、従業員にカナの読みを持たせるモジュールの提案も始まっています。あわせて、合計請求書まわりの実務対応と、在庫評価の根拠を残すための提案を進めました。
2026年8月の取り組み
日本のローカライゼーション
Odoo本体の日本のローカライゼーション l10n_jp では、会計ポジションの日本語名に誤りがありました。国内取引先向けの名称が「海外取引先」となっており、日本語環境では2つの会計ポジションが同じ名前で並んでいました。どちらを選ぶべきか判別できず、消費税の扱いを取り違える原因になります。
この修正はOdoo 19.0向けに提案し、8月中にマージされました。以降のバージョンへも展開されています。あわせて、海外取引先向けの英語名の綴りを直し、仕入先にも設定する項目であることに合わせて名称から「Customer」を外しました。
日本語環境のもうひとつの提案が、カナの読みへの対応です。連絡先にカナの読みを追加する l10n_jp_name_kana を、同じ仕組みを他のモデルでも使えるようにする抽象モデルとあわせて、Odoo 19.0向けに提案しました。この抽象モデルを使って、商品向けの l10n_jp_product_name_kana と従業員向けの l10n_jp_hr_employee_name_kana も提案しています。商品では、テンプレートと品目のどちらもカナで検索できます。
参考リンク:
https://github.com/odoo/odoo/pull/284608
https://github.com/OCA/l10n-japan/pull/137
合計請求書と請求業務
締日から合計請求書を一括で作成する account_billing_from_cutoff は、Odoo 18.0対応がマージされました。月に一度まとめて請求し、まとめて回収する商習慣に合わせるための機能です。
適格請求書としての合計請求書を扱う l10n_jp_summary_invoice には、合計請求の対象外とする設定を取引先の単位でも持てるようにする改善が、Odoo 16.0向けにマージされました。
account_billing_from_cutoff には、受取銀行口座が設定されていない請求書の扱いを直す修正も提案しています。請求書は取引先・通貨・受取銀行口座の組み合わせでまとめられるため、口座のない請求書だけが単独のグループになり、同じ取引先の下書きに合流できませんでした。
合計請求書の明細行の並び順を整える account_billing の改善は、Odoo 16.0への展開を提案しています。Odoo 18.0向けに提供している改善です。
参考リンク:
https://github.com/OCA/l10n-japan/pull/110
https://github.com/OCA/l10n-japan/pull/108
在庫の可視化と評価
在庫の「レポーティング」メニューを在庫管理者以外にも開けるようにする stock_reporting_access は、Odoo 18.0向けがマージされ、続いて16.0対応もマージされました。実績を確認したいだけの担当者に、在庫管理者の権限をまとめて渡さずに済みます。
FIFO評価でロット管理している商品について、在庫評価レイヤの金額をロットごとにどう配分したかを記録する stock_valuation_fifo_lot_allocation を、Odoo 16.0向けに提案しています。
既存の stock_valuation_fifo_lot はロットごとの現在の残高を示しますが、ランデッドコストや仕入請求時の価格差、評価替えの経緯はロット単位では残りません。監査でロットごとの金額の根拠を問われたときに説明できるよう、評価レイヤが作られた時点で配分を記録し、ロット単位の台帳として参照できるようにします。
参考リンク:
https://github.com/OCA/stock-logistics-workflow/pull/2293
APIエンドポイントの改善
設定画面からAPIのエンドポイントを追加できる endpoint と、その基盤になる endpoint_route_handler について、Odoo 19.0向けの改善が2件マージされました。
ひとつは、認証方式にbearerを追加する改善です。Odooが標準で持つAPIキーの仕組みをそのまま使えるようになり、認証のための追加モジュールが要りません。
もうひとつは、応答をJSONに変換する際の不具合の修正です。日付や日時、バイナリなど標準のJSONが扱えない値が応答に含まれるとエラーになっていました。Odoo本体が使っている変換処理を適用して解決しています。
参考リンク:
管理者による制御
エクスポートの権限を扱う base_export_manager に、Odoo 18.0向けの改善を2件提案しました。ひとつは、新しく作られるアクセス権のエクスポート許可を、既定で不許可にできる設定です。もうひとつは、ピボットビューのxlsxダウンロードのボタンにも同じ制御を効かせる改善です。これまでは一覧のエクスポートを隠しても、ピボットからは書き出せる状態でした。
文字数の上限をコードではなく設定データとして持たせる base_field_length_constraint を、Odoo 19.0向けに提案しています。モデルと項目の組み合わせごとに上限を決め、文字数か、指定した文字コードでのバイト数で数えます。会社や対象レコードの条件で適用範囲を絞ることもでき、超過したときに保存を拒否するか警告にとどめるかを選べます。
添付ファイルの形式を制限する attachment_mimetype_restriction には、Odoo 15.0向けの修正を提案しました。商品や取引先の画像、会社のロゴやファビコンは、Odooが内部的に添付として保存します。これらも制限の対象になっていたため、許可リストの内容によっては通常のレコード保存が失敗していました。
参考リンク:
https://github.com/OCA/server-ux/pull/1326
https://github.com/OCA/server-ux/pull/1327
移行対応
PDFレポートの任意の位置に画像を挿入できる report_positioned_image のOdoo 19.0対応を進めています。請求書や納品書に社印を載せる要件に応えるモジュールで、Odoo 18.0向けに提供しています。
一覧からのエクスポートで、HTMLフィールドをプレーンテキストとして書き出す web_export_html_as_text は、Odoo 18.0と19.0への対応を並行して進めています。Odoo 16.0向けに提供しているモジュールです。
複数の請求書を1件の合計請求書にまとめる account_billing は、Odoo 19.0対応を進めています。顧客側と仕入先側で別々だった一覧ビューを、この対応で共通化しました。
参考リンク:
https://github.com/OCA/reporting-engine/pull/1193
https://github.com/OCA/web/pull/3312
そのほかの改善
連絡先の電話番号の書式を選べる phone_format_option を、Odoo 18.0向けに提案しています。Odoo標準では必ず国番号付きの国際表記に変換されるため、国内の取引先しか登録しない運用では見慣れない表記になります。
チャターのメッセージを専用のメニューで一覧できる mail_message_view を、Odoo 16.0向けに提案しました。利用者が書いたメッセージとシステムが記録したメッセージが混在する履歴を、検索や絞り込み、グループ化で追えるようにします。項目の変更履歴も本文の要約として読めます。
製造オーダのオペレーションタイプをルートから決める mrp_production_picking_type_from_route には、Odoo 18.0向けの修正を提案しました。フォーム以外から作られた製造オーダで、オペレーションタイプと採番が実際の流れと食い違う問題を解消します。
ポータルの受注一覧を、利用者がアクセスしているウェブサイトのものに限る portal_sale_order_website_filter が、Odoo 15.0向けにマージされました。複数のウェブサイトを運用する環境で、他サイトの受注が見えないようにします。
参考リンク:
https://github.com/OCA/partner-contact/pull/2422
https://github.com/OCA/mail/pull/247
担当者よりひとこと
Odoo 20.0のリリースが近づくなか、日本向けの合計請求書機能の19.0対応を思うように進められておらず、少しやきもきしています。
つかえているのは、上流の account_billing の19.0対応PRです。5月にいったん承認をもらいましたが、その後は数か月待っている状態です。その間も本体の変更に追随してコードの更新は重ねてきました。移行作業そのものは手元でほぼ終わっているものの、OCAのブランチから誰でも入れられる形にはなっていません。届けられるはずの価値が届いていないのは、やはりもったいないと感じます。
コミュニティでの活動には、自分の裁量だけでは進められない部分があります。PRをマージできるのはメンテナーやPSC（Project Steering Committee）で、品質を担保するうえで適切な仕組みではあるものの、スピードが落ちる場面もあります。
できることとしては、コタエルのメンバーがPSCの役割をもっと引き受けていくこと、そして account_billing への依存をなくし、機能を l10n-japan 側に取り込むことが考えられます。
合計請求書は日本でのOdoo導入で求められることの多い機能です。コミュニティで相談しながら、早めに手を打ちたいと考えています。
[2026年8月] Odooコミュニティ活動とコタエルの取り組みのご報告