コンテンツにスキップ

iDempiere オークションセラーの使い方|販売管理 操作マニュアル・技術仕様

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

オークションセラーは、オークションに 売り手として参加するユーザー を登録するウィンドウです。ユーザー 1 人につき 1 件のセラー情報を持ち、参加資格の有効期限(有効終了日)や社内参加者かどうか(内部フラグ)を管理します。配下のタブでは、そのユーザーに紐づく基金と提示済みオファーを参照できます。

⚠️ 注意: この画面は iDempiere 13 標準では無効化されています(旧バージョンからの互換用)。標準メニューにも登録されていません。オークション関連テーブル(B_*)にはビジネスロジッククラスが存在せず、新規の業務設計での利用は推奨されません。

📌 ポイント: B_Seller テーブルには専用の ID カラム(B_Seller_ID)が 存在しません。主キーは AD_User_ID で、システムユーザーと 1 対 1 に対応する拡張情報テーブルという構造になっています。同じユーザーに複数のセラー登録を持たせることはできません。

オークションセラーでできること

Section titled “オークションセラーでできること”
  • オークションに売り手として参加するユーザーの登録
  • 参加資格の有効終了日(ValidTo)の設定
  • 社内参加者(内部)かどうかの区別
  • セラー名・説明の登録
  • そのユーザーに紐づく基金(委託金額・非委託金額)の参照
  • そのユーザーが提示したオファーの一覧参照
  • 参加資格の無効化(アクティブ解除)

オークションセラーは 2 階層・3 タブ構成です。

タブ名テーブル階層項目数役割
売り手B_Seller08項目セラー本体(ユーザー単位)
基金B_BuyerFunds18項目紐づく基金の参照
オファーB_Offer19項目提示済みオファーの参照
graph TD
    subgraph "オークションセラー(Window ID: 309・標準では無効)"
        T1["👤 売り手<br/>B_Seller<br/>8項目"]
        T2["&nbsp;&nbsp;└ 基金<br/>&nbsp;&nbsp;&nbsp;&nbsp;B_BuyerFunds<br/>&nbsp;&nbsp;&nbsp;&nbsp;8項目"]
        T3["&nbsp;&nbsp;└ オファー<br/>&nbsp;&nbsp;&nbsp;&nbsp;B_Offer<br/>&nbsp;&nbsp;&nbsp;&nbsp;9項目"]
    end
    T1 --> T2
    T1 --> T3

オークションセラー(Window ID: 309・標準では無効) 売り手 B_Seller 8項目   └ 基金     B_BuyerFunds     8項目   └ オファー     B_Offer     9項目

⚠️ 注意: 「基金」タブに割り当てられているテーブルは B_BuyerFunds(買い手基金) です。タブの説明文は「Seller Funds from Offers on Topics(オファーによる売り手基金)」となっており、標準の AD 定義上、タブ名・説明とテーブルが食い違っています。売り手基金は本来 B_SellerFunds テーブルであり、この画面から参照できるのは買い手基金である点に注意してください。

graph TD
    A["⚙️ 前提: 参加者のユーザーを<br/>AD_User に登録済み"] --> B["➕ 売り手を新規作成"]
    B --> C["👤 ユーザーを選択<br/>(主キーになる)"]
    C --> D["✏️ 名称を入力"]
    D --> E["📅 有効終了日を設定"]
    E --> F{"社内参加者?"}
    F -->|はい| G["🏢 内部にチェック"]
    F -->|いいえ| H["💾 保存"]
    G --> H
    H --> I["👀 基金・オファータブで<br/>参加状況を確認"]

前提: 参加者のユーザーを AD_User に登録済み 売り手を新規作成 ユーザーを選択 (主キーになる) 名称を入力 有効終了日を設定 社内参加者? 内部にチェック 保存 基金・オファータブで 参加状況を確認 はい いいえ

アクセス方法(メニューパス)

Section titled “アクセス方法(メニューパス)”

標準メニューには登録されていません(*(標準メニュー未登録 / 間接使用)*)。参照する場合はシステム管理者権限で「ウィンドウ・タブ・フィールド」から AD_Window_ID: 309 を有効化する必要があります。

  1. 新規」ボタンをクリック
  2. 必須項目を入力:
    • ユーザー: セラーとして登録するシステムユーザー(このテーブルの主キー)
    • 名称: セラー名(最大 60 文字)
    • 有効終了日: 参加資格の最終日
    • 内部: 自社内の参加者である場合にチェック
  3. 任意項目(説明)を入力
  4. 保存」をクリック

⚠️ 注意: 有効終了日(ValidTo)は必須項目ですが、これを過ぎたセラーの参加を自動的に止めるロジックはコアに存在しません。期限切れの判定・締め出しはカスタム実装または運用でのチェックが必要です。

  • 基金 タブ: 委託金額(法的にコミット済みの金額)、非委託金額(未コミット金額)、紐づく 入金支払伝票発注伝票
  • オファー タブ: 対象 トピック売手基金、オファー名、希望委託 フラグ、テキスト、プライベートメモ

💡 ヒント: これらのタブは参照が主目的です。金額の増減は入出金処理と連動しないため、手入力での更新になります。

項目名カラム必須説明
クライアントAD_Client_ID必須選択テナント(自動セット)
組織AD_Org_ID必須選択組織(自動セット)
ユーザーAD_User_ID必須選択セラーとなるユーザー(主キー)
名称Name必須文字列(60)セラー名(識別子)
説明Description-文字列(255)補足説明
有効IsActive必須チェック無効化する場合はチェックを外す
有効終了日ValidTo必須日付参加資格の最終日(当日を含む)
内部IsInternal必須チェック自社内の参加者かどうか
項目名カラム必須説明
ユーザーAD_User_ID必須選択資金保有ユーザー(識別子)
委託金額CommittedAmt必須金額コミット済み金額(識別子)
非委託金額NonCommittedAmt必須金額未コミット金額(識別子)
入金支払伝票C_Payment_ID-選択紐づく入出金伝票
発注伝票C_Order_ID-選択紐づく受発注伝票
項目名カラム必須説明
トピックB_Topic_ID必須選択対象の入札トピック
ユーザーAD_User_ID必須選択オファー提示者
売手基金B_SellerFunds_ID必須選択紐づく売り手基金
名称Name必須文字列(60)オファー名(識別子)
希望委託IsWillingToCommit必須チェックコミット意思
テキストTextMsg-テキスト(2000)メッセージ
プライベートメモPrivateNote-テキスト(2000)他参加者に非公開のメモ

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

graph TD
    A["ユーザー<br/>AD_User"] --> B["売り手<br/>B_Seller<br/>(PK = AD_User_ID)"]
    B --> C["オファー<br/>B_Offer"]
    C --> D["入札トピック<br/>B_Topic"]
    C --> E["売り手基金<br/>B_SellerFunds"]
    A --> F["買い手基金<br/>B_BuyerFunds<br/>(この画面の基金タブ)"]
    F --> G["入出金伝票 / 受発注伝票"]

ユーザー AD_User 売り手 B_Seller (PK = AD_User_ID) オファー B_Offer 入札トピック B_Topic 売り手基金 B_SellerFunds 買い手基金 B_BuyerFunds (この画面の基金タブ) 入出金伝票 / 受発注伝票

Q. メニューにこの画面が見当たりません。

Section titled “Q. メニューにこの画面が見当たりません。”

iDempiere 13 標準ではこのウィンドウは無効化されており、メニューにも登録されていません。オークション機能全体が旧バージョンからの互換用として残されているためです。

Q. 同じユーザーを 2 回セラー登録できますか?

Section titled “Q. 同じユーザーを 2 回セラー登録できますか?”

できません。B_Seller の主キーは AD_User_ID であり、専用の B_Seller_ID カラムを持たないため、1 ユーザーにつき 1 レコードのみです。ユーザーと 1 対 1 の拡張テーブルという構造になっています。

Q. 有効終了日を過ぎるとどうなりますか?

Section titled “Q. 有効終了日を過ぎるとどうなりますか?”

コア側では何も起きません。ValidTo を参照して参加を制限するロジックは実装されていないため、期限切れセラーの締め出しが必要な場合はスケジューラで IsActive を落とすカスタムプロセスなどを用意してください。

Q. 「内部(IsInternal)」は何のためのフラグですか?

Section titled “Q. 「内部(IsInternal)」は何のためのフラグですか?”

自社組織内の参加者であることを示すフラグです(カラム説明は「Internal Organization」)。これを使った分岐処理はコアに実装されていないため、社内出品と外部出品を区別したい場合のカスタム条件として利用します。

Q. 基金タブの金額はどこから更新されますか?

Section titled “Q. 基金タブの金額はどこから更新されますか?”

手入力です。B_BuyerFundsCommittedAmt / NonCommittedAmt を入出金伝票(C_Payment)から自動更新する仕組みはコアにありません。C_Payment_ID / C_Order_ID は参照カラムとして持っているだけです。

Q. 買い手(Buyer)側の画面はありますか?

Section titled “Q. 買い手(Buyer)側の画面はありますか?”

B_Bid(入札)と B_BuyerFunds(買い手基金)は入札トピック画面のタブとして参照できます。セラーに相当する「バイヤーマスタ」テーブルは標準に存在しません。

🛠 技術仕様(開発者向け)

オークションセラーはマスタデータ型のウィンドウ(AD_Window_ID: 309)で、ヘッダーが B_Seller、子タブが B_BuyerFundsB_Offer です。3 テーブルとも AccessLevel=3(クライアント+組織レベル)/IsDeleteable=Y / IsHighVolume=N

M クラス(ビジネスロジッククラス)は存在しません。 提供されるのは自動生成クラス X_B_Seller / X_B_BuyerFunds / X_B_Offer とインターフェース I_B_* のみで、beforeSave() / afterSave() によるコア側の検証・派生処理はありません。

B_Seller は専用 ID を持たず AD_User_ID を主キーとする点が特徴で、AD_User に対する 1 対 1 の拡張テーブルとして設計されています。

classDiagram
    class X_B_Seller {
        <<generated>>
        +setAD_User_ID(int) void
        +setValidTo(Timestamp) void
        +setIsInternal(boolean) void
    }
    class X_B_BuyerFunds {
        <<generated>>
        +setCommittedAmt(BigDecimal) void
        +setNonCommittedAmt(BigDecimal) void
    }
    class X_B_Offer {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    class I_B_Seller {
        <<interface>>
    }
    X_B_Seller --|> PO
    X_B_BuyerFunds --|> PO
    X_B_Offer --|> PO
    X_B_Seller ..|> I_B_Seller
    X_B_Seller --> X_AD_User : PK is AD_User_ID
    X_B_Offer --> X_B_SellerFunds : funded by
    X_B_Offer --> X_B_Topic : offers on

<> +setAD_User_ID(int) void +setValidTo(Timestamp) void +setIsInternal(boolean) void <> +setCommittedAmt(BigDecimal) void +setNonCommittedAmt(BigDecimal) void <> <> <> > PO X_B_BuyerFunds -- > PO X_B_Seller ..

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/X_B_Seller.java ほか X_B_BuyerFunds.java / X_B_Offer.java

カラム名必須説明備考
AD_User_IDTable DirectPKユーザー主キー(IsParent=Y。専用 ID カラムなし)
B_Seller_UUUUIDNUUID
AD_Client_IDTable DirectYクライアントdefault @#AD_Client_ID@
AD_Org_IDTable DirectY組織default @#AD_Org_ID@
NameString(60)Y名称識別子(IsIdentifier=Y)
DescriptionString(255)N説明
IsActiveYes-NoY有効default Y
ValidToDateY有効終了日当日を含む最終日
IsInternalYes-NoY内部自社組織の参加者フラグ
カラム名必須説明備考
B_BuyerFunds_IDIDPK基金ID主キー
AD_User_IDTable DirectYユーザー識別子
CommittedAmtAmountY委託金額識別子
NonCommittedAmtAmountY非委託金額識別子
C_Payment_IDSearchN入金支払伝票参照のみ
C_Order_IDSearchN受発注伝票参照のみ
カラム名必須説明
B_Offer_IDIDPKオファーID
B_Topic_IDSearchYトピックFK
AD_User_IDTable DirectY提示ユーザー
B_SellerFunds_IDSearchY売り手基金FK
NameString(60)Y名称(識別子)
IsWillingToCommitYes-NoY希望委託
TextMsgText(2000)Nメッセージ
PrivateNoteText(2000)Nプライベートメモ
erDiagram
    AD_User ||--o| B_Seller : "seller profile (1:1)"
    AD_User ||--o{ B_BuyerFunds : "buyer funds"
    AD_User ||--o{ B_SellerFunds : "seller funds"
    AD_User ||--o{ B_Offer : "offers"
    B_Offer }o--|| B_Topic : "offer on topic"
    B_Offer }o--|| B_SellerFunds : "funded by"
    B_BuyerFunds }o--o| C_Payment : "payment"
    B_BuyerFunds }o--o| C_Order : "order"

seller profile (1:1) buyer funds seller funds offer on topic funded by

コア実装にビジネスロジックはありません。確認できる制約は次のとおりです。

  • 主キー制約: B_Seller の主キーは AD_User_ID。同一ユーザーの重複登録は DB レベルで不可
  • 必須制約: Name / ValidTo / IsInternal / IsActive が NOT NULL
  • 既定値: IsActive='Y'Created / UpdatedSYSDATE、クライアント/組織にコンテキスト変数(@#AD_Client_ID@ / @#AD_Org_ID@
  • 有効期限の判定なし: ValidTo を評価する処理はコアに存在しない
  • 基金の自動更新なし: CommittedAmt / NonCommittedAmt は入出金処理と連動しない

⚠️ 注意: 「基金」タブのテーブルが B_BuyerFunds(買い手基金)である一方、タブの説明は売り手基金となっており、標準 AD の定義に不整合があります。売り手の資金(B_SellerFunds)を扱いたい場合は、この画面からは参照できないため、タブのテーブル定義を変更するか別ウィンドウを用意する必要があります。

拡張ポイント(カスタマイズ箇所)

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

有効終了日の妥当性チェックを追加する例です。

public class CustomSellerValidator implements ModelValidator {
@Override
public int modelChange(PO po, int type) throws Exception {
if (MTable.getTableName(po.getCtx(), po.get_Table_ID()).equals("B_Seller")) {
if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
Timestamp validTo = (Timestamp) po.get_Value("ValidTo");
if (validTo != null && validTo.before(new Timestamp(System.currentTimeMillis()))) {
throw new AdempiereException("有効終了日は本日以降にしてください");
}
}
}
return null;
}
@Override
public String docValidate(PO po, int timing) {
return null; // B_Seller は Document 型ではないため不要
}
}

ValidTo を経過したセラーの IsActive を落とす処理は、SvrProcess を実装して AD_Scheduler に日次登録するのが定石です。コアに同等のプロセスは存在しません。

B_Seller / B_BuyerFunds / B_Offer の各カラムには Callout が設定されていません(gw_column.tsv の callout 列がすべて空)。ユーザー選択時にセラー名を自動補完するといった連動は IColumnCallout で実装します。

このウィンドウに紐づく標準プロセスはありません。Processing / DocAction カラムを持たない参照・登録専用のマスタです。


オークションセラーのようにユーザーと 1 対 1 で紐づく拡張テーブルは、会員制サービスや外部パートナーの参加資格管理にも応用できる構造です。既存テーブルを流用すべきか新設すべきかの判断からご相談いただけます。

As-Link株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。

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