ERPNextの柔軟な拡張機能

ERPを導入する技術者にとって、最大の不安材料のひとつは 「カスタマイズを入れるとバージョンアップできなくなる」 ことです。
ERPNextは、この問題をHookとOverWrideの2つの仕組みで、設計レベルから解決しています。

1. バージョンアップに耐えられるERPNextの設計思想

ERPNextの「壊れないカスタマイズ」は、次の5つの仕組みによって支えられています。
どれも実際に導入支援をしていると「効いているな」と感じる部分です。

2. カスタマイズの４レイヤー

ここからは、具体的なカスタマイズ方法を解説します。
カスタマイズは、4段階に分けることができます。

1. カスタムフィールド

ERPNext では、管理画面からカスタムフィールドを簡単に追加できます。 マウス操作だけで、テキストの入力欄や表示形式、プルダウンリスト、チェックボックスなどを自由に設定できます。
データベースには tabCustom Field として自動で登録され、コアテーブルを直接改変しないため、アップデート時の衝突リスクを避けられる仕組みになっています。

操作も直感的で簡単です。

2. クライアントスクリプト

画面上のイベントは Custom Script でフック可能です。
例えば「受注フォームで商品を選択した際に、自動的に在庫数を表示する」といった動作を簡単に実現できます。

// client_script.js
frappe.ui.form.on("Sales Order Item", {
  item_code(frm, cdt, cdn) {
    frappe.call({
      method: "my_custom_app.api.get_stock_balance",
      args: { item_code: locals[cdt][cdn].item_code },
      callback: r => frappe.msgprint(`在庫数: ${r.message}`)
    });
  }
});

現場感覚で言えば、これは「ちょっとした自動化」をノーコードに近い形で素早く組み込めるレイヤーだと言えます。

３. カスタムフォーム・印刷フォーマット

フォームや印刷レイアウトは JSON 形式で保存されるため、開発環境から本番環境への エクスポート／インポート が容易です。 特に日本の業務では請求書・見積書のフォーマットが重要ですが、 ERPNext では自由に追加・編集が可能です。現場で「お客様指定の帳票フォーマットに合わせたい」といった要望にも柔軟に対応できます。

４. カスタムアプリ

さらに高度な拡張が必要な場合は、bench new-app my_custom_app で独立したアプリを作成します この方法では ERPNext 本体を一切変更せず、追加アプリ側で処理を「差し替える」ように動かせるため、バージョンアップ時の不具合をほぼ確実に回避できます。

例えば、受注から納品書を作成する標準メソッドを差し替える場合は、以下のように hooks.py にOverrideする宣言を記述し、overrides.make_delivery_noteにアドオン機能を記述します。

# hooks.py
override_whitelisted_methods = {
  "erpnext.selling.doctype.sales_order.sales_order.make_delivery_note":
    "my_custom_app.overrides.make_delivery_note"
}

# my_custom_app/overrides.py
import frappe
from erpnext.selling.doctype.sales_order.sales_order import make_delivery_note as erpnext_make_delivery_note
 
def make_delivery_note(source_name, target_doc=None):
    """
    カスタムメッセージをログに出力
    """
    # --- 標準の処理を呼び出し ---
    delivery_note = erpnext_make_delivery_note(source_name, target_doc)
 
    # --- カスタム処理を追加 ---
    # 独自フィールドに値をコピー
    sales_order = frappe.get_doc("Sales Order", source_name)
    if hasattr(delivery_note, "custom_sales_person"):
        delivery_note.custom_sales_person = sales_order.sales_person
 
    # カスタムメッセージをログに出力
    frappe.logger().info(f"Custom override: Delivery Note created from Sales Order {source_name}")
 
    return delivery_note

この仕組みを理解すると「本体は触らず、追加アプリで責務を分離する」という設計思想がしっかり腹落ちします。 結果として、システムはバージョンアップに強くなり、チーム開発でも役割分担が明確になります。

標準で提供される Hook ポイント

ERPNext（正確には Frappe Framework）は、拡張用に多くのフックを標準で用意しています。
代表的なものをカテゴリごとに整理すると、以下のようになります。

🔹 イベントフック

• doc_events
  DocType の作成・更新・削除時に処理を差し込む
  例：validate, before_save, on_submit

🔹 メソッドフック

• override_whitelisted_methods
  既存の API エンドポイントを自作関数で置き換える

🔹 UI / フロントエンド系

• fixtures
  Custom Field や Print Format を JSON 化して配布可能
• app_include_js / app_include_css
  独自の JS / CSS を読み込む

🔹 スケジュールジョブ

• scheduler_events
  定時実行処理を登録可能（毎時・毎日・Cron指定など）

3. カスタマイズ実例

• 業種別カスタマイズ
  現場ごとに必ず出てくる「ちょっとした追加項目」は、ERPNextでは Custom Field で解決できます。

  • 農業法人なら「収穫量」を入力する欄を加えるだけで、帳票や集計にすぐ反映可能。
  • 不動産業なら「契約更新日」をフィールド化すれば、更新管理の抜け漏れを防げます。
    どちらも数クリックで済むため、「システムを壊さずに現場にフィットさせる」好例です。

• 出力カスタマイズ
  日本企業では請求書や見積書のフォーマット要求が厳しいのは周知の事実です。
  ERPNextでは「消費税の明細」や「取引先コード」といった会社固有の要素を、印刷フォーマットに組み込むだけ。
  開発を伴わずに現場に納得感を出せるのは、導入を進める上で大きな武器になります。

• 独自ワークフロー
  承認ルートを追加したい場面は多々あります。例えば「100万円以上の発注は役員承認」といったルール。
  ERPNextでは Workflow と Server Script を組み合わせることで、現場の慣習を壊さずにシステムへ反映可能です。
  これは「業務プロセスにシステムを合わせる」ERPNextの真価が出る部分です。

• NG例
  導入現場でよく見かける失敗も共有しておきます。

  • コアの .py を直接編集 → これは一見手っ取り早いですが、アップデートで必ず消えます。
  • DocType の構造変更 → 短期的には便利でも、将来的に互換性を壊すリスクが高い。
  • Fixture 化を忘れる → 開発環境では動くのに、本番に反映されず「なぜ？」となる典型例です。
    どれも経験豊富な技術者なら「絶対に避けるべき」と口を揃える落とし穴です。

まとめ