コンテンツにスキップ
As-Link Docs

iDempiere オークションバイヤーの使い方｜販売管理 操作マニュアル・技術仕様

📖 販売管理の全体像: 販売管理の全体図 も合わせてご覧ください。

オークションバイヤー（Auction Buyer）は、オークション機能で「買い手」として参加するユーザーを管理する画面です。バイヤー本体（ユーザーとの紐づけ）、入札の原資となる基金（Funds）、そしてトピックへの入札（Bid）の3階層で構成されます。

⚠️ 注意: このウィンドウ（AD_Window_ID: 310）は iDempiere 13 標準では無効化されており、標準メニューにも登録されていません（旧バージョンからの互換用）。オークション機能そのものがコアで積極的にメンテナンスされていないため、新規の業務設計での利用は推奨されません。

📌 ポイント: 基金は「委託金額（CommittedAmt）＝入札に拘束済み」と「非委託金額（NonCommittedAmt）＝未拘束の残高」に分かれ、入金伝票または受注伝票に紐づけて管理します。この振替を自動計算するロジックはコアに実装されていません。

オークションバイヤーでできること

Section titled “オークションバイヤーでできること”
  • オークションに参加する買い手（ユーザー）の登録
  • バイヤーの有効終了日（ValidTo）による参加期限の管理
  • 入金伝票・受注伝票に紐づけた基金（入札原資）の登録
  • 委託金額・非委託金額の記録
  • トピックに対する入札の記録
  • 「希望委託（IsWillingToCommit）」フラグによる資金拠出意思の記録
  • 入札に対するテキストメッセージ・プライベートメモの保持

画面構成

Section titled “画面構成”

オークションバイヤーは3タブ構成です。基金と入札はいずれもバイヤーの子タブです。

graph TD
    subgraph "オークションバイヤーウィンドウ（Window ID: 310）"
        T1["👤 バイヤー<br/>B_Buyer<br/>7項目"]
        T2["💰 基金<br/>B_BuyerFunds<br/>8項目"]
        T3["🔨 入札<br/>B_Bid<br/>10項目"]
    end
    T1 --> T2
    T1 --> T3

オークションバイヤーウィンドウ（Window ID: 310） バイヤー B_Buyer 7項目 基金 B_BuyerFunds 8項目 入札 B_Bid 10項目

タブ名テーブル階層項目数役割
バイヤーB_Buyer07項目買い手ユーザーの基本情報
基金B_BuyerFunds18項目入札の原資（委託額・非委託額）
入札B_Bid110項目トピックに対する入札レコード

基本操作手順

Section titled “基本操作手順”
graph TD
    A["🚀 ウィンドウを開く<br/>（標準メニュー未登録のため<br/>ロール設定でメニュー追加が必要）"] --> B["👤 バイヤーを登録<br/>ユーザー・名称・有効終了日"]
    B --> C["💰 基金タブで原資を登録<br/>入金伝票 or 受注伝票を紐づけ"]
    C --> D["💵 委託金額・非委託金額を入力"]
    D --> E["🔨 入札タブで入札を登録<br/>基金・トピック・名称"]
    E --> F{"資金拠出の意思あり?"}
    F -->|あり| G["☑️ 希望委託をチェック"]
    F -->|なし| H["そのまま"]
    G --> I["💾 保存"]
    H --> I

ウィンドウを開く （標準メニュー未登録のため ロール設定でメニュー追加が必要） バイヤーを登録 ユーザー・名称・有効終了日 基金タブで原資を登録 入金伝票 or 受注伝票を紐づけ 委託金額・非委託金額を入力 入札タブで入札を登録 基金・トピック・名称 資金拠出の意思あり? 希望委託をチェック そのまま 保存 あり なし

アクセス方法（メニューパス）

Section titled “アクセス方法（メニューパス）”

このウィンドウは iDempiere 13 標準ではメニューに登録されていません。利用する場合はシステム管理者がメニュー（AD_Menu）へウィンドウ ID 310 を追加し、ロールにアクセス権を付与する必要があります。

バイヤーの登録

Section titled “バイヤーの登録”
  1. 「新規」ボタンをクリック
  2. 基本情報を入力:
    • ユーザー（必須）: システム内のユーザーまたは取引先の担当者
    • 名称（必須）: バイヤー名
    • 有効終了日（必須）: 参加資格の終了日（当日を含む）
    • 説明: 補足説明
  3. 「保存」をクリック

⚠️ 注意: バイヤーはユーザー（AD_User）1件につき1レコードとして登録します。AD_User_ID は保存後に変更できません（IsUpdateable=N）。誤ったユーザーで登録した場合は削除して作り直してください。

基金（入札原資）の登録

Section titled “基金（入札原資）の登録”
  1. 「基金」タブに移動
  2. 「新規」ボタンをクリック
  3. 基金情報を入力:
    • ユーザー（必須）: 基金の保有者
    • 委託金額（必須）: すでに入札に拘束されている金額
    • 非委託金額（必須）: まだ拘束されていない金額
    • 入金支払伝票 または 受注伝票: 原資となった伝票を紐づけ
  4. 「保存」をクリック

入札の登録

Section titled “入札の登録”
  1. 「入札」タブに移動
  2. 「新規」ボタンをクリック
  3. 入札情報を入力:
    • ユーザー（必須）: 入札者
    • バイヤー基金（必須）: 原資となる基金
    • トピック（必須）: 入札対象のオークショントピック
    • 名称（必須）: 入札の名称
    • 希望委託: 資金拠出の意思がある場合にチェック
    • テキスト: 公開メッセージ
    • プライベートメモ: 相手方には表示されないメモ
  4. 「保存」をクリック

💡 ヒント: プライベートメモ（PrivateNote）は「他の当事者には見えないメモ」として定義された項目です。ただし iDempiere のロール／レコードアクセス設定によっては閲覧できてしまうため、機微情報の記録には使用しないでください。

項目リファレンス

Section titled “項目リファレンス”

バイヤータブ

Section titled “バイヤータブ”
項目名カラム必須型説明
クライアントAD_Client_ID必須選択テナント
組織AD_Org_ID必須選択組織
ユーザーAD_User_ID必須選択買い手となるユーザー（更新不可）
名称Name必須文字列(60)バイヤー名
説明Description-文字列(255)補足説明
有効終了日ValidTo必須日付参加資格の終了日（当日を含む）
有効IsActive必須チェックレコードが有効か（既定: Y）

基金タブ

Section titled “基金タブ”
項目名カラム必須型説明
ユーザーAD_User_ID必須選択基金の保有者
委託金額CommittedAmt必須金額入札に拘束済みの金額
非委託金額NonCommittedAmt必須金額未拘束の残高
入金支払伝票C_Payment_ID-検索原資となった入金（更新不可）
受注伝票C_Order_ID-検索原資となった受注（更新不可）
有効IsActive必須チェックレコードが有効か

入札タブ

Section titled “入札タブ”
項目名カラム必須型説明
ユーザーAD_User_ID必須選択入札者
バイヤー基金B_BuyerFunds_ID必須検索原資となる基金
トピックB_Topic_ID必須検索入札対象のトピック
名称Name必須文字列(60)入札の名称
希望委託IsWillingToCommit必須チェック資金拠出の意思
テキストTextMsg-テキスト(2000)公開メッセージ
プライベートメモPrivateNote-テキスト(2000)非公開メモ
有効IsActive必須チェックレコードが有効か

全項目一覧はリファレンス参照

よくある質問（FAQ）

Section titled “よくある質問（FAQ）”

Q. 落札処理や金額の自動振替はありますか？

Section titled “Q. 落札処理や金額の自動振替はありますか？”

ありません。B_Buyer / B_BuyerFunds / B_Bid のいずれにも M クラス（ビジネスロジック実装クラス）が存在せず、自動生成された X_ クラスのみが提供されています。委託金額と非委託金額の振替、落札判定、請求書の生成はすべてコア外の実装が必要です。

Q. バイヤーの検索キー（Value）はどこですか？

Section titled “Q. バイヤーの検索キー（Value）はどこですか？”

存在しません。B_Buyer は検索キーを持たず、ユーザー（AD_User_ID）が実質的なキーとして機能します。AD のカラム定義にも B_Buyer_ID は含まれておらず、生成クラスの新規コンストラクタは AD_User_ID を 0 で初期化します。

Q. 1人のユーザーが複数のバイヤーになれますか？

Section titled “Q. 1人のユーザーが複数のバイヤーになれますか？”

B_Buyer はユーザーを実質的なキーとする構造のため、1ユーザー＝1バイヤーが前提です。複数の基金・複数の入札は子タブ側でいくらでも登録できます。

Q. 「委託金額」と「非委託金額」の合計チェックはされますか？

Section titled “Q. 「委託金額」と「非委託金額」の合計チェックはされますか？”

されません。どちらも必須項目ですが、合計値の妥当性検証（例: 入金額との一致）はコアに実装されていません。整合性を担保したい場合は Model Validator で検証を追加してください。

Q. 有効終了日を過ぎたバイヤーは自動で無効化されますか？

Section titled “Q. 有効終了日を過ぎたバイヤーは自動で無効化されますか？”

されません。ValidTo は記録項目であり、期限切れを判定して IsActive を落とす処理はコアにありません。スケジューラで動く独自プロセスが必要です。

業務フロー上の位置づけ

Section titled “業務フロー上の位置づけ”
graph TD
    A["👥 ユーザー<br/>AD_User"] --> B["👤 バイヤー<br/>B_Buyer"]
    C["💰 入金伝票<br/>C_Payment"] --> D["💵 基金<br/>B_BuyerFunds"]
    E["📋 受注伝票<br/>C_Order"] --> D
    B --> D
    D --> F["🔨 入札<br/>B_Bid"]
    G["📢 トピック<br/>B_Topic"] --> F

ユーザー AD_User バイヤー B_Buyer 入金伝票 C_Payment 基金 B_BuyerFunds 受注伝票 C_Order 入札 B_Bid トピック B_Topic

関連機能

Section titled “関連機能”
🛠 技術仕様（開発者向け）

概要

Section titled “概要”

オークションバイヤーは B_Buyer（バイヤー）、B_BuyerFunds（基金）、B_Bid（入札）の3テーブルで構成されるウィンドウ（AD_Window_ID: 310）です。3テーブルとも専用の M クラスを持たず、AD から自動生成された X_B_Buyer（211行）、X_B_BuyerFunds（286行）、X_B_Bid（324行）のみが提供されています。生成クラスはアクセサと関連オブジェクト取得メソッドだけを持ち、独自のビジネスロジックは実装されていません。Document 型ではありません。

アーキテクチャ概要

Section titled “アーキテクチャ概要”
classDiagram
    class X_B_Buyer {
        <<generated>>
        +getAD_User() I_AD_User
        +setAD_User_ID(int)
        +setValidTo(Timestamp)
        +getValidTo() Timestamp
    }
    class X_B_BuyerFunds {
        <<generated>>
        +getCommittedAmt() BigDecimal
        +getNonCommittedAmt() BigDecimal
        +getC_Payment() I_C_Payment
        +getC_Order() I_C_Order
    }
    class X_B_Bid {
        <<generated>>
        +getB_BuyerFunds() I_B_BuyerFunds
        +getB_Topic() I_B_Topic
        +isWillingToCommit() boolean
        +getTextMsg() String
        +getPrivateNote() String
    }
    class PO {
        <<abstract>>
    }
    X_B_Buyer --|> PO
    X_B_BuyerFunds --|> PO
    X_B_Bid --|> PO
    X_B_Bid --> X_B_BuyerFunds : funded by

<> +getAD_User() I_AD_User +setAD_User_ID(int) +setValidTo(Timestamp) +getValidTo() Timestamp <> +getCommittedAmt() BigDecimal +getNonCommittedAmt() BigDecimal +getC_Payment() I_C_Payment +getC_Order() I_C_Order <> +getB_BuyerFunds() I_B_BuyerFunds +getB_Topic() I_B_Topic +isWillingToCommit() boolean +getTextMsg() String +getPrivateNote() String <> > PO X_B_BuyerFunds --

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/X_B_Buyer.java、X_B_BuyerFunds.java、X_B_Bid.java

関連DBテーブル

Section titled “関連DBテーブル”

B_Buyer（バイヤー）

Section titled “B_Buyer（バイヤー）”

テーブル属性: 削除可（IsDeleteable=Y）／大量データ扱いなし／アクセスレベル=クライアント＋組織／ビューではない。

カラム名型必須説明備考
AD_User_IDTable DirectYユーザー実質的なキー、更新不可
B_Buyer_UUUUID(36)NUUIDキー
AD_Client_IDTable DirectYクライアント既定 @#AD_Client_ID@
AD_Org_IDTable DirectY組織既定 @#AD_Org_ID@
NameString(60)Y名称識別子カラム
DescriptionString(255)N説明
ValidToDateY有効終了日当日を含む
IsActiveYes-NoY有効既定 Y

📌 ポイント: AD のカラム定義に B_Buyer_ID は含まれていません。生成クラス X_B_Buyer の新規コンストラクタは setAD_User_ID(0) のみを行い、ユーザー参照が識別の中心になっています。

B_BuyerFunds（バイヤー基金）

Section titled “B_BuyerFunds（バイヤー基金）”
カラム名型必須説明備考
B_BuyerFunds_IDIDPK基金ID主キー
B_BuyerFunds_UUUUID(36)NUUIDキー
AD_User_IDTable DirectYユーザー基金保有者
CommittedAmtAmountY委託金額入札に拘束済み
NonCommittedAmtAmountY非委託金額未拘束残高
C_Payment_IDSearchN入金支払伝票更新不可
C_Order_IDSearchN受注伝票更新不可
IsActiveYes-NoY有効既定 Y

B_Bid（入札）

Section titled “B_Bid（入札）”
カラム名型必須説明備考
B_Bid_IDIDPK入札ID主キー
B_Bid_UUUUID(36)NUUIDキー
AD_User_IDTable DirectYユーザー入札者
B_BuyerFunds_IDSearchYバイヤー基金FK
B_Topic_IDSearchYトピックFK入札対象
NameString(60)Y名称識別子カラム
IsWillingToCommitYes-NoY希望委託
TextMsgText(2000)Nテキストメッセージ
PrivateNoteText(2000)Nプライベートメモ
IsActiveYes-NoY有効既定 Y

ER図

Section titled “ER図”
erDiagram
    AD_User ||--o| B_Buyer : "is buyer"
    AD_User ||--o{ B_BuyerFunds : "owns funds"
    B_BuyerFunds ||--o{ B_Bid : "funds bid"
    B_Topic ||--o{ B_Bid : "receives bids"
    C_Payment ||--o{ B_BuyerFunds : "source payment"
    C_Order ||--o{ B_BuyerFunds : "source order"

is buyer owns funds funds bid receives bids source payment source order

ビジネスロジック

Section titled “ビジネスロジック”

M クラスが存在しないため、コアに固有のビジネスロジック（beforeSave / 落札判定 / 金額振替）はありません。保存時の挙動は PO の標準処理（必須チェック、外部キー整合性、アクセスレベル制御）に従います。

AD_User_ID（バイヤータブ）、C_Payment_ID / C_Order_ID（基金タブ）は IsUpdateable=N のため、保存後の付け替えができません。

拡張ポイント（カスタマイズ箇所）

Section titled “拡張ポイント（カスタマイズ箇所）”

OSGi Model Validator（推奨）

Section titled “OSGi Model Validator（推奨）”
public class CustomBuyerFundsValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof X_B_BuyerFunds
                && (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE)) {
            X_B_BuyerFunds funds = (X_B_BuyerFunds) po;
            // 例: 金額はマイナス不可
            if (funds.getCommittedAmt().signum() < 0
                    || funds.getNonCommittedAmt().signum() < 0) {
                throw new AdempiereException("委託金額・非委託金額にマイナスは指定できません");
            }
        }
        return null;
    }
}

入札時の資金振替処理

Section titled “入札時の資金振替処理”

入札登録時に「非委託金額から委託金額へ振り替える」といった処理はコアにないため、X_B_Bid の TYPE_AFTER_NEW で親の B_BuyerFunds を更新する Model Validator として実装するのが定石です。

Callout

Section titled “Callout”

B_Buyer / B_BuyerFunds / B_Bid のカラムには AD 上の callout 定義がありません。

関連プロセス

Section titled “関連プロセス”

このウィンドウには専用のプロセスボタンは定義されていません。

関連ドキュメント

Section titled “関連ドキュメント”

iDempiereカスタマイズのご相談

Section titled “iDempiereカスタマイズのご相談”

iDempiere のオークション機能は標準では画面とテーブルのみが残された状態で、落札判定や資金振替のロジックは実装されていません。 オークション・入札型の販売モデルを実運用するには、Model Validator と独自プロセスによる業務ロジックの追加が前提になります。

Ａｓ－Ｌｉｎｋ株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。

OSS ERP導入・カスタマイズサービスの詳細はこちら