iDempiere オークションセラーの使い方|販売管理 操作マニュアル・技術仕様
📖 販売管理の全体像: 販売管理の全体図 も合わせてご覧ください。
オークションセラーは、オークションに 売り手として参加するユーザー を登録するウィンドウです。ユーザー 1 人につき 1 件のセラー情報を持ち、参加資格の有効期限(有効終了日)や社内参加者かどうか(内部フラグ)を管理します。配下のタブでは、そのユーザーに紐づく基金と提示済みオファーを参照できます。
⚠️ 注意: この画面は iDempiere 13 標準では無効化されています(旧バージョンからの互換用)。標準メニューにも登録されていません。オークション関連テーブル(
B_*)にはビジネスロジッククラスが存在せず、新規の業務設計での利用は推奨されません。
📌 ポイント:
B_Sellerテーブルには専用の ID カラム(B_Seller_ID)が 存在しません。主キーはAD_User_IDで、システムユーザーと 1 対 1 に対応する拡張情報テーブルという構造になっています。同じユーザーに複数のセラー登録を持たせることはできません。
オークションセラーでできること
Section titled “オークションセラーでできること”- オークションに売り手として参加するユーザーの登録
- 参加資格の有効終了日(
ValidTo)の設定 - 社内参加者(内部)かどうかの区別
- セラー名・説明の登録
- そのユーザーに紐づく基金(委託金額・非委託金額)の参照
- そのユーザーが提示したオファーの一覧参照
- 参加資格の無効化(アクティブ解除)
オークションセラーは 2 階層・3 タブ構成です。
| タブ名 | テーブル | 階層 | 項目数 | 役割 |
|---|---|---|---|---|
| 売り手 | B_Seller | 0 | 8項目 | セラー本体(ユーザー単位) |
| 基金 | B_BuyerFunds | 1 | 8項目 | 紐づく基金の参照 |
| オファー | B_Offer | 1 | 9項目 | 提示済みオファーの参照 |
graph TD
subgraph "オークションセラー(Window ID: 309・標準では無効)"
T1["👤 売り手<br/>B_Seller<br/>8項目"]
T2[" └ 基金<br/> B_BuyerFunds<br/> 8項目"]
T3[" └ オファー<br/> B_Offer<br/> 9項目"]
end
T1 --> T2
T1 --> T3
⚠️ 注意: 「基金」タブに割り当てられているテーブルは
B_BuyerFunds(買い手基金) です。タブの説明文は「Seller Funds from Offers on Topics(オファーによる売り手基金)」となっており、標準の AD 定義上、タブ名・説明とテーブルが食い違っています。売り手基金は本来B_SellerFundsテーブルであり、この画面から参照できるのは買い手基金である点に注意してください。
基本操作手順
Section titled “基本操作手順”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/>参加状況を確認"]
アクセス方法(メニューパス)
Section titled “アクセス方法(メニューパス)”標準メニューには登録されていません(*(標準メニュー未登録 / 間接使用)*)。参照する場合はシステム管理者権限で「ウィンドウ・タブ・フィールド」から AD_Window_ID: 309 を有効化する必要があります。
新規登録(売り手)
Section titled “新規登録(売り手)”- 「新規」ボタンをクリック
- 必須項目を入力:
- ユーザー: セラーとして登録するシステムユーザー(このテーブルの主キー)
- 名称: セラー名(最大 60 文字)
- 有効終了日: 参加資格の最終日
- 内部: 自社内の参加者である場合にチェック
- 任意項目(説明)を入力
- 「保存」をクリック
⚠️ 注意: 有効終了日(
ValidTo)は必須項目ですが、これを過ぎたセラーの参加を自動的に止めるロジックはコアに存在しません。期限切れの判定・締め出しはカスタム実装または運用でのチェックが必要です。
基金・オファーの確認
Section titled “基金・オファーの確認”- 基金 タブ: 委託金額(法的にコミット済みの金額)、非委託金額(未コミット金額)、紐づく 入金支払伝票 と 発注伝票
- オファー タブ: 対象 トピック、売手基金、オファー名、希望委託 フラグ、テキスト、プライベートメモ
💡 ヒント: これらのタブは参照が主目的です。金額の増減は入出金処理と連動しないため、手入力での更新になります。
項目リファレンス
Section titled “項目リファレンス”| 項目名 | カラム | 必須 | 型 | 説明 |
|---|---|---|---|---|
| クライアント | 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 | - | 選択 | 紐づく受発注伝票 |
オファータブ
Section titled “オファータブ”| 項目名 | カラム | 必須 | 型 | 説明 |
|---|---|---|---|---|
| トピック | B_Topic_ID | 必須 | 選択 | 対象の入札トピック |
| ユーザー | AD_User_ID | 必須 | 選択 | オファー提示者 |
| 売手基金 | B_SellerFunds_ID | 必須 | 選択 | 紐づく売り手基金 |
| 名称 | Name | 必須 | 文字列(60) | オファー名(識別子) |
| 希望委託 | IsWillingToCommit | 必須 | チェック | コミット意思 |
| テキスト | TextMsg | - | テキスト(2000) | メッセージ |
| プライベートメモ | PrivateNote | - | テキスト(2000) | 他参加者に非公開のメモ |
セラーとオークションの関係
Section titled “セラーとオークションの関係”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["入出金伝票 / 受発注伝票"]
よくある質問(FAQ)
Section titled “よくある質問(FAQ)”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_BuyerFunds の CommittedAmt / 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_BuyerFunds と B_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 の拡張テーブルとして設計されています。
アーキテクチャ概要
Section titled “アーキテクチャ概要”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
パッケージ: org.compiere.model
ソースファイル: org.adempiere.base/src/org/compiere/model/X_B_Seller.java ほか X_B_BuyerFunds.java / X_B_Offer.java
関連DBテーブル
Section titled “関連DBテーブル”B_Seller(売り手)
Section titled “B_Seller(売り手)”| カラム名 | 型 | 必須 | 説明 | 備考 |
|---|---|---|---|---|
| AD_User_ID | Table Direct | PK | ユーザー | 主キー(IsParent=Y。専用 ID カラムなし) |
| B_Seller_UU | UUID | N | UUID | |
| AD_Client_ID | Table Direct | Y | クライアント | default @#AD_Client_ID@ |
| AD_Org_ID | Table Direct | Y | 組織 | default @#AD_Org_ID@ |
| Name | String(60) | Y | 名称 | 識別子(IsIdentifier=Y) |
| Description | String(255) | N | 説明 | |
| IsActive | Yes-No | Y | 有効 | default Y |
| ValidTo | Date | Y | 有効終了日 | 当日を含む最終日 |
| IsInternal | Yes-No | Y | 内部 | 自社組織の参加者フラグ |
B_BuyerFunds(基金タブ)
Section titled “B_BuyerFunds(基金タブ)”| カラム名 | 型 | 必須 | 説明 | 備考 |
|---|---|---|---|---|
| B_BuyerFunds_ID | ID | PK | 基金ID | 主キー |
| AD_User_ID | Table Direct | Y | ユーザー | 識別子 |
| CommittedAmt | Amount | Y | 委託金額 | 識別子 |
| NonCommittedAmt | Amount | Y | 非委託金額 | 識別子 |
| C_Payment_ID | Search | N | 入金支払伝票 | 参照のみ |
| C_Order_ID | Search | N | 受発注伝票 | 参照のみ |
B_Offer(オファータブ)
Section titled “B_Offer(オファータブ)”| カラム名 | 型 | 必須 | 説明 |
|---|---|---|---|
| B_Offer_ID | ID | PK | オファーID |
| B_Topic_ID | Search | Y | トピックFK |
| AD_User_ID | Table Direct | Y | 提示ユーザー |
| B_SellerFunds_ID | Search | Y | 売り手基金FK |
| Name | String(60) | Y | 名称(識別子) |
| IsWillingToCommit | Yes-No | Y | 希望委託 |
| TextMsg | Text(2000) | N | メッセージ |
| PrivateNote | Text(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"
ビジネスロジック
Section titled “ビジネスロジック”コア実装にビジネスロジックはありません。確認できる制約は次のとおりです。
- 主キー制約:
B_Sellerの主キーはAD_User_ID。同一ユーザーの重複登録は DB レベルで不可 - 必須制約:
Name/ValidTo/IsInternal/IsActiveが NOT NULL - 既定値:
IsActive='Y'、Created/UpdatedにSYSDATE、クライアント/組織にコンテキスト変数(@#AD_Client_ID@/@#AD_Org_ID@) - 有効期限の判定なし:
ValidToを評価する処理はコアに存在しない - 基金の自動更新なし:
CommittedAmt/NonCommittedAmtは入出金処理と連動しない
⚠️ 注意: 「基金」タブのテーブルが
B_BuyerFunds(買い手基金)である一方、タブの説明は売り手基金となっており、標準 AD の定義に不整合があります。売り手の資金(B_SellerFunds)を扱いたい場合は、この画面からは参照できないため、タブのテーブル定義を変更するか別ウィンドウを用意する必要があります。
拡張ポイント(カスタマイズ箇所)
Section titled “拡張ポイント(カスタマイズ箇所)”OSGi Model Validator(推奨)
Section titled “OSGi Model Validator(推奨)”有効終了日の妥当性チェックを追加する例です。
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 型ではないため不要 }}期限切れセラーの自動無効化
Section titled “期限切れセラーの自動無効化”ValidTo を経過したセラーの IsActive を落とす処理は、SvrProcess を実装して AD_Scheduler に日次登録するのが定石です。コアに同等のプロセスは存在しません。
Callout
Section titled “Callout”B_Seller / B_BuyerFunds / B_Offer の各カラムには Callout が設定されていません(gw_column.tsv の callout 列がすべて空)。ユーザー選択時にセラー名を自動補完するといった連動は IColumnCallout で実装します。
関連プロセス
Section titled “関連プロセス”このウィンドウに紐づく標準プロセスはありません。Processing / DocAction カラムを持たない参照・登録専用のマスタです。
関連ドキュメント
Section titled “関連ドキュメント”iDempiereカスタマイズのご相談
Section titled “iDempiereカスタマイズのご相談”オークションセラーのようにユーザーと 1 対 1 で紐づく拡張テーブルは、会員制サービスや外部パートナーの参加資格管理にも応用できる構造です。既存テーブルを流用すべきか新設すべきかの判断からご相談いただけます。
As-Link株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。