はじめに
Odooでは“モデル”がデータの設計図です。受注や請求書、仕訳といった業務データはすべてモデルに沿ってデータベースに保存され、表示・検索・連携はこの定義を起点に行われます。
モデルを理解することは、開発者だけでなく業務コンサルタントにとっても必須です。フィールド定義、他モデルとの関連、ビジネスロジックはすべてここに集約され、システム全体の挙動を決めます。
この記事では会計の中でも中核となるモデル、account.move に焦点を当てます。レポート作成、外部システム連携、請求フローの設定など、実務で頻繁に触れる部分です。
account.move モデルとは何か
account.move は Odoo における仕訳帳の単位です。以前は請求書や仕訳などが別モデルだったものを、Odoo13以降は一つに統合して扱います。つまり請求書も仕訳も同じ型のレコードとして管理されます。
このモデルは会計モジュールの中核で、明細行を持つ account.move.line の親です。請求書や仕訳は一つの account.move レコードで、その下に複数の行がぶら下がる構造になります。
account モジュールで定義され、販売や購買など他モジュールは継承で必要な機能を追加します。販売側は受注からの請求作成、購買側は発注からの請求書作成といった具合に、コア構造を重複せず拡張していきます。
モデルの主要フィールド
ここからは account.move の実務でよく使うフィールドを紹介します。各フィールドを押さえておくと、請求・支払・仕訳の自動化やレポート設計がスムーズになります。
1. name
型: Char。仕訳番号や請求番号を格納するフィールドです。通常はジャーナルのシーケンスから自動採番され、一覧や帳票に表示されます。
2. move_type
型: Selection。レコードの種別を示します（手動仕訳、売上請求書、売上クレジット、仕入請求書、仕入クレジットなど）。この値によって適用される画面や処理が切り替わります。
3. state
型: Selection。ワークフロー状態（下書き、仕訳済み、取り消しなど）。下書きは編集可能、仕訳済みは総勘定元帳へ反映されロックされます。
4. date
型: Date。ドキュメントの日付。帳票集計や与信計算、会計期間の判定に使われます。請求書では発行日として扱われることが多いです。
5. journal_id
型: Many2one (account.journal)。この仕訳が属する会計ジャーナル。売上、仕入、銀行、雑収支などジャーナルごとにシーケンスやデフォルト勘定が決まります。
6. company_id
型: Many2one (res.company)。マルチカンパニー環境でどの会社に属するかを示します。表示範囲や連結処理に影響します。
7. partner_id
型: Many2one (res.partner)。顧客または仕入先を指します。請求書・請求書の多くのレポートや照合処理は partner を基準に動きます。
8. currency_id
型: Many2one (res.currency)。仕訳の通貨。金額はこの通貨で保持され、複数通貨が絡む場合は会社通貨への換算が行われます。
9. amount_total
型: Monetary。仕訳全体の合計金額。請求書なら支払金額を示し、明細行から計算されます。
10. amount_residual
型: Monetary。未払い残高。支払が終わっていればゼロになります。債権債務管理や督促処理で参照されます。
11. payment_state
型: Selection。支払状況（未払い、支払中、支払済、部分支払など）。督促や入金通知のトリガーになります。
12. line_ids
型: One2many (account.move.line)。仕訳の各行。各行は勘定科目、借方、貸方を持ち、総借方合計が総貸方合計と一致する必要があります。
13. invoice_line_ids
型: One2many (account.move.line)。請求書や請求明細に対応する行。公開時に仕訳行を生成する元データとして使われます。
14. invoice_date
型: Date。請求書の日付。税期間や請求管理で重要な役割を持ち、場合によっては仕訳日と異なることがあります。
15. invoice_date_due
型: Date。支払期日。支払条件から算出されるか手動設定され、督促や年齢分析で使われます。
16. ref
型: Char。外部参照番号やベンダー請求書番号など。外部ドキュメントとの照合に便利です。
17. invoice_origin
型: Char。発生元ドキュメントの識別子。受注番号などをここに残すことでオーダーから請求までの追跡が可能になります。
18. create_date
型: Datetime。レコード作成日時。Odooが自動で管理するメタ情報です。
19. write_date
型: Datetime。最終更新日時。こちらも自動管理され、変更履歴把握に役立ちます。
20. narration
型: Text。内部メモや備考。印刷仕訳には表示されますが、顧客側の請求書には表示しない運用も多いです。
21. fiscal_position_id
型: Many2one (account.fiscal.position)。税ポジション。顧客・国に応じた税設定を適用するために使われます。
22. invoice_payment_term_id
型: Many2one (account.payment.term)。支払条件（例: ネット30日）。期日の算定や分割支払の計算に使います。
23. invoice_user_id
型: Many2one (res.users)。請求書の担当者や営業担当。レポートやコミッション計算で参照されます。
24. reversed_entry_id
型: Many2one (account.move)。取り消し仕訳がある場合、元の仕訳へのリンクを保持します。監査トレイルとして重要です。
25. to_check
型: Boolean。レビューが必要なフラグ。銀行照合や例外処理のワークフローで使われます。
26. active
型: Boolean。ソフトデリート用フラグ。False にするとアーカイブ状態となり、取消し済みの仕訳は通常アクティブを落とします。
27. sequence_number
型: Integer。ジャーナルのシーケンス番号。表示や並び替えに使われ、シーケンスミックスインで管理されます。
28. amount_untaxed
型: Monetary。税抜き小計。請求書では明細金額の合計（税抜）を示します。
29. amount_tax
型: Monetary。税額合計。明細の税計算や税設定に基づいて自動算出されます。
30. invoice_source_email
型: Char。メールから取り込んだ仕入請求書で元メールアドレスを保存するためのフィールド。自動取込のトラッキングに便利です。
業務フローでの使われ方
1. 顧客向け請求書の処理
出荷やサービス完了を起点に受注から out_invoice の account.move が生成されます。受注明細が invoice_line_ids に引き継がれ、仕訳を確定すると売掛金勘定に反映されます。
2. 仕入請求書の処理
発注から請求書が生成されるか、手入力で仕入の account.move を作成します。in_invoice タイプで記録され、確定時に買掛金が更新されます。
3. 入金照合の流れ
入金は amount_residual と payment_state を参照して請求書と突合されます。照合処理により支払仕訳と請求書仕訳が紐づき、残高が消し込まれます。
4. 手動仕訳の登録
経理担当者は調整や発生計上のために move_type=entry の仕訳を作成します。line_ids に勘定・借方・貸方を手動で追加し、仕訳は必ず整合している必要があります。
5. クレジットノート・返金処理
クレジットノートは out_refund / in_refund として記録され、元の請求書の影響を打ち消します。reversed_entry_id で元仕訳とリンクして監査性を確保します。
開発者がこのモデルを拡張する方法
開発者は Odoo の継承パターンを使って account.move を拡張します。フィールド追加、振る舞いの上書き、バリデーションの導入などが可能です。
モデル継承の使い方
_inherit = 'account.move' を使って既存モデルを拡張します。追加フィールドを定義したりメソッドを上書きして機能を差し込むことで、コアを直接触らずに変更を管理できます。
フィールドの追加
継承モデルに新しいフィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selection といった適切な型を選び、マルチカンパニーでは company-dependent を検討します。請求書専用の項目は move_type のドメインで制御すると良いです。
Python側の拡張
create、write、_post、button_draft などをオーバーライドして処理を差し込めます。super() を呼び出して既存処理を維持すること、計算フィールドの依存関係を正しく設定することに注意してください。@api.model や @api.depends といったデコレータで実行タイミングを管理します。
Odoo Studio の活用
Odoo Studio を使えばコードを書かずにフィールド追加が可能で、参照用フィールドなどの簡易カスタマイズには向いています。ただし複雑なバリデーションや自動化はカスタムモジュールで実装した方が保守性は高くなります。
補足: account.move は通常の永続モデルです。抽象モデル（テンプレート）や一時モデル（ウィザード）とは異なり、実際の会計データをDBに保存します。
ベストプラクティス
- レポートや連携を作る際は必ず move_type でフィルタをかけてください。タイプごとに必須フィールドや処理が異なります。
- 各仕訳は該当するジャーナルを正しく使うこと。ジャーナルを混同するとシーケンスや集計に影響します。
- APIで仕訳を作るときは、投稿前に line_ids がバランスしている（借方＝貸方）ことを確認してください。不均衡な仕訳は検証で弾かれます。
- 外部システムから請求を作る場合は、ドキュメント種別を正しく move_type にマッピングしてください。売上なら out_invoice、仕入なら in_invoice を使います。
- カスタムフィールドは x_ プレフィックスを付けることで将来の競合を避けやすくなります。
よくある誤り
- バランスしていない仕訳を投稿しようとすること。Odoo は投稿を拒否するため、事前に借貸の合計を確認してください。
- 投稿済みの仕訳を直接書き換えること。投稿後はロックされるため、修正は取り消し仕訳を作る等の手順で行ってください。
- 顧客・仕入先が必要な仕訳で partner_id を設定し忘れること。多くのレポートや照合作業がこれに依存します。
- 誤った move_type を使うこと。例えば返金を負の請求書で済ませるのではなく、正しく out_refund / in_refund を使ってください。
- コアメソッドを上書きして super() を呼ばないこと。他モジュールや将来のアップグレードとの互換性を壊す原因になります。
まとめ
account.move は Odoo 会計の中心です。請求書、仕入、仕訳を一元管理する構造を理解すれば、設定やカスタマイズ、連携がはるかに簡単になります。
業務設計を行うコンサルタントも、モジュールを作る開発者も、account.move を正しく把握しておけば手戻りやエラーを大幅に減らせます。
Odoo導入でお困りですか？
Dasolo は企業の Odoo 導入・カスタマイズ・最適化を支援します。API連携やモジュール開発に強みがあり、account.move のようなデータ構造に精通したチームが対応します。
実装、カスタムモジュール、連携について支援が必要ならご相談ください。 デモを予約する プロジェクトについて詳しくお話ししましょう。