Skip to content

[6817][ADD] product_rental_fee_link - #6

Open
yostashiro wants to merge 1 commit into
19.0from
6817-add-product_rental_fee_link
Open

[6817][ADD] product_rental_fee_link#6
yostashiro wants to merge 1 commit into
19.0from
6817-add-product_rental_fee_link

Conversation

@yostashiro

Copy link
Copy Markdown
Member

QT6817

背景

レンタル費用は機器そのものとは別の品目として管理する方針(OCJ-063・#6934/#6817)ですが、標準のデータモデルには両者を結びつける項目がありません。機種プロダクトに「レンタル費用品目」の many2one を追加します。

IF-01(機種)の商品CDは、この項目でたどったレンタル費用品目のバリアント(単価区分別)の default_code から導出する想定です。

optional_product_ids を使わなかった理由

06ocj2 では既に optional_product_ids で機器→レンタル費用を紐づけた例が1件ありましたが、正本の関係としては採用しませんでした。

  • 機能は見積の商品コンフィギュレータでのクロスセル提案のみsale/controllers/product_configurator.py)。ナビフロー→Odoo API で記帳する本プロジェクトの課金フローでは起動しないため、実質「何も強制しないデータ規約」になる
  • many2many なので 1件である保証がなく、品目種別の制約もない
  • 本来のクロスセル(機器に推奨消耗品など)を設定した時点で用途が衝突し区別できなくなる

is_storable を条件に含めていない理由

当初案は domain=[("type", "=", "service"), ("is_storable", "=", False)] でしたが、is_storable は外しました。

  • 検証DB(06ocj2)には ir_defaultproduct.template.is_storable = true(全社)が設定されており、type="service" で作成したプロダクトも is_storable=True になる。この条件では候補が常に空になり、制約が正当なサービス品目を弾く(実測でテスト3件がエラー)
  • core の compute_is_storabletype != 'consu' のとき is_storable を False に戻すだけで、サービス品目の is_storable は意味を持たない

したがって判別子は type のみとし、その理由をコードのコメントにも残しています。

内容

  • product.template.rental_fee_product_tmpl_id(domain: サービス品目のみ)
  • 制約: 自己参照の禁止/サービス品目以外の禁止
  • ビュー: プロダクトフォーム(品目カテゴリの後・サービス品目では非表示)、検索ビューに「レンタル費用品目 未設定」フィルタ
  • i18n/ja.po(レンタル費用品目 ほか)
  • テスト6件

複数の機種が同一のレンタル費用品目を参照することは制限していません(同じ費用が複数機種に適用される運用があるため)。

確認済み

  • 06ocj2 へインストールし テスト6件すべてパス
  • pre-commit run 全フック Pass

Rental fees are managed as products separate from the equipment itself
(one rental fee product per equipment model), and nothing in the standard
data model ties the two together. Add a dedicated Rental Fee Product
many2one on the product, restricted to services.

A dedicated field is used rather than optional_product_ids: the latter is
a many2many for cross-sell suggestions in the quotation configurator, so
it cannot express a single verifiable relationship, carries no type
restriction, and its meaning collides with genuine cross-sell entries.

is_storable is deliberately not part of the domain nor the constraint: it
only means "track inventory", can be turned on for a service by a user
default, and core clears it for non-goods on recompute - so the product
type is the only reliable discriminator.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant