導入
Odooでは“モデル”がデータの設計図です。受注や請求書、仕訳など、業務で扱うすべての情報はモデルという枠組みでデータベースに整理されます。
モデルの理解は開発者だけでなく業務担当者にも不可欠です。モデルがフィールド、関連、そして業務ロジックを定め、Odooのデータ構造の土台となるからです。
本稿は会計モジュールで重要な役割を担う account.move.line に焦点を当てます。カスタム帳票、外部連携、照合フローの設定など、会計周りの作業はこのモデルに触れることが多いです。
account.move.line モデルとは何か
account.move.line は仕訳の“行”を表します。各行は借方か貸方のどちらか一方の金額を持ち、仕訳全体では借方合計と貸方合計が一致することが求められます。
この行モデルは account.move（仕訳本体／請求書・請求書受領・銀行明細などを含む）の子に当たります。1件の仕訳に対して複数の行が紐づき、会計処理の最小単位になります。
model の定義は account モジュールにあり、他モジュールは継承で必要な拡張を加えます。販売は請求行を、購買は仕入行を、アナリティクスは配賦情報を追加するといった具合で、コアを壊さずに機能を付与します。
モデルの主要フィールド
ここからは account.move.line で頻繁に使う主要フィールドを示します。これらを押さえると仕訳操作や帳票作成がスムーズになります。
1. name（摘要）
型: Char。行のラベルや摘要を保持します。帳票や仕訳一覧で表示される重要な説明欄で、請求書由来なら商品名や任意の説明が入ります。
2. move_id（仕訳参照）
型: Many2one (account.move)。この行が所属する親仕訳を指します。すべての行は必ず1つの move に紐づき、仕訳と行の主要な関連です。
3. account_id（勘定科目）
型: Many2one (account.account)。この行が記入される科目。必須で、集計やレポート、表示のためにビュー用でない科目が選ばれます。
4. debit（借方）
型: Float。借方金額。デフォルト0.0。通常、各行は借方か貸方のいずれか一方のみを持ち、借方は資産・費用の増加を示します。
5. credit（貸方）
型: Float。貸方金額。デフォルト0.0。貸方は負債・資本・収益の増加を示し、仕訳全体の借貸一致が求められます。
6. balance（残高）
型: Float。計算項目で、debit - credit を返します。行の正味影響を表し、レポートや照合で利用されます。
7. partner_id（取引先）
型: Many2one (res.partner)。顧客や仕入先などの取引先情報。売掛・買掛の管理、エイジングや照合で重要になります。
8. date（日付）
型: Date。行の有効日。通常は親仕訳から継承され、締め処理や期間集計、年月別レポートに使います。
9. date_maturity（支払期日）
型: Date。入金・支払の期日。エイジングや支払スケジュールに利用されます。
10. currency_id（通貨）
型: Many2one (res.currency)。行の通貨。会社通貨と異なる通貨で仕訳を作る際に使用します。
11. amount_currency（通貨金額）
型: Float。行の通貨での金額。currency_id と組み合わせて多通貨会計を扱います。
12. quantity（数量）
型: Float。任意の数量。請求書や購買に由来する行で単位あたりの計算や数量集計に使います。
13. product_id（商品）
型: Many2one (product.product)。販売・購買や請求から来た行に紐づく商品。商品別分析や在庫連携に役立ちます。
14. product_uom_id（単位）
型: Many2one (uom.uom)。数量の単位。商品と併用して表示や換算を正しく行います。
15. price_unit（単価）
型: Float。単価。数量と掛け合わせて請求金額を算出する際に使われます。
16. tax_ids（税）
型: Many2many (account.tax)。行に適用される税。仕訳投稿時に税額用の追加行が生成され、VATなどの計算に用います。
17. tax_line_id（税行参照）
型: Many2one (account.tax)。税額行が生成された場合、その元となる税を参照します。税行と通常行の区別に使います。
18. analytic_account_id（分析勘定）
型: Many2one (account.analytic.account)。プロジェクトや部門別の収支を追うための分析勘定。分析会計が有効な場合に使用されます。
19. analytic_distribution（分析配賦）
型: Json または Text。複数の分析勘定へ配賦する情報を格納します。新しい分析プランでは analytic_account_id に替わる形で使われることがあります。
20. ref（参照）
型: Char。親仕訳から引き継ぐ外部参照やメモ。帳票表示や照合のキーとして使われます。
21. narration（備考）
型: Text。内部メモ。通常は顧客向け文書には出力されませんが、内部管理には便利です。
22. journal_id（仕訳帳）
型: Many2one (account.journal)。親仕訳の属する仕訳帳。帳簿別の絞り込みや集計に使います。
23. company_id（会社）
型: Many2one (res.company)。マルチカンパニー環境では各行が所属する会社を示し、表示権限や連結処理に影響します。
24. reconciled（照合済み）
型: Boolean。行が完全に照合済みかを示します。未照合項目のフィルタリングなどに利用します。
25. full_reconcile_id（完全照合グループ）
型: Many2one (account.full.reconcile)。複数行を一括で照合したグループを紐づけ、照合履歴の追跡を可能にします。
26. payment_id（支払参照）
型: Many2one (account.payment)。支払処理由来の行がある場合、その支払レコードを参照します。請求との照合で重要です。
27. statement_id（銀行明細）
型: Many2one (account.bank.statement)。銀行明細に由来する行はここに紐づき、銀行照合で使われます。
28. statement_line_id（明細行参照）
型: Many2one (account.bank.statement.line)。銀行取引の個別行とマッチングさせるためのリンクです。
29. display_type（表示タイプ）
型: Selection。'line_section' や 'line_note' を取り、セクション見出しや注記行として表示用に使います。これらの行は借貸金額を持ちません。
30. create_date（作成日時）
型: Datetime。レコード作成日時。Odooが自動管理し、監査ログとして有用です。
31. write_date（更新日時）
型: Datetime。最終更新日時。変更の追跡や履歴確認に使います。
業務フローでの利用例
1. 売上請求（顧客向け請求）
請求書を確定すると account.move.line が生成されます。収益は収入科目へ、売掛金は得意先の売掛科目へ、税は税額行として別途立てられます。partner_id によってエイジングや照合が可能になります。
2. 仕入請求（買掛）
仕入伝票は費用や仕入税、買掛金の行を作成します。構造は売上請求と似ていますが、用いられる科目種別が異なります。
3. 銀行照合
銀行明細行は statement_line_id を通じて仕訳行とマッチングします。照合処理により full_reconcile_id が設定され、reconciled フラグが True になります。
4. 手動仕訳入力
ユーザーは複数行を持つ手動仕訳を作成します。各行は科目と借貸のいずれかを持ち、Odoo は仕訳を投稿する際に借貸が一致しているかを検証します。
5. 分析会計・コスト集計
分析会計が有効な場合、行は analytic_account_id や analytic_distribution を持ちます。レポートは分析勘定別に集計でき、プロジェクトや部門別の損益把握に使われます。
開発者はどう拡張するか
開発者は Odoo の継承パターンを使って account.move.line を拡張します。基本はモデル継承によるカスタマイズです。
モデル継承の基本
モデルを拡張する際は _inherit = 'account.move.line' を使います。フィールド追加、メソッド上書き、制約追加などを行い、変更は別モジュールにまとめておけば将来のアップグレード管理がしやすくなります。
フィールド追加の注意点
継承モデルで新しいフィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selection など適切な型を選び、マルチカンパニー環境では company_dependent を検討してください。計算フィールドは依存関係を正しく設定することが重要です。
Python側の拡張
create、write、unlink をオーバーライドして独自処理を挟めますが、super() を必ず呼び、借貸不一致など会計の不整合を生まないよう注意します。これらのメソッドは外部連携でも呼ばれる点を意識してください。
Odoo Studio の活用
Odoo Studio でコードなしにフィールド追加できます。短期間のニーズや簡単なラベル追加には便利ですが、複雑なロジックや照合ルールはカスタムモジュールで実装する方が保守性に優れます。
実務上のベストプラクティス
- 行を直接編集せず、必ず親の move を経由して操作してください。move 経由の API（例: line_ids）を使うことで整合性チェックや自動処理が正しく実行されます。
- 帳票や集計を作る際は move_id.state = 'posted' を条件に含めて、下書きや取り消し済みの仕訳を除外してください。
- エイジングや照合に使う科目は account_id の科目種別（売掛、買掛等）を正しく設定してください。
- API 経由で連携する場合はまず move を作成し、続けて行を追加するフローにしてください。投稿時に借貸が一致していることを確認する必要があります。
- カスタムフィールドは x_ プレフィックスやモジュール名プレフィックスを付けて、将来の Odoo 変更と衝突しないようにしてください。
よくあるミス
- 同じ行で debit と credit を同時に設定すること。各行は借方か貸方のどちらか一方だけ持つべきです。
- 仕訳を不均衡なまま作成すること。投稿時に借方合計と貸方合計が一致しないとエラーになります。
- 既に投稿した行を直接編集して修正すること。仕訳の訂正は逆仕訳や調整仕訳で行い、直接編集は避けます。
- 売掛・買掛の行で partner_id を設定し忘れること。これによりエイジングや照合が正しく動作しなくなります。
- core メソッドをオーバーライドして super() を呼ばないこと。照合やロック、他モジュール連携が壊れる原因になります。
まとめ
account.move.line は Odoo 会計の中心です。仕訳、請求書、伝票のすべての借方・貸方がここに蓄積されます。フィールドと拡張方法を理解すると設定やカスタマイズ、連携が格段に楽になります。
業務設計側でワークフローを落とし込む担当者も、開発者も、account.move.line の仕組みを押さえておくことで手戻りを減らしミスを防げます。
Odoo 導入で支援が必要ですか？
Dasolo は Odoo の導入・カスタマイズ・最適化を支援します。API連携や開発の実績が豊富で、account.move.line のようなデータ構造に精通したチームが対応します。
導入支援、カスタム開発、連携が必要ならお気軽にご相談ください。 デモのご予約 でプロジェクトをお話ししましょう。