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

iDempiere POS支払方法タイプの使い方｜販売管理 操作マニュアル・技術仕様

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

POS支払方法タイプは、店頭で受け付ける支払手段（現金・クレジットカード・商品券・電子マネー等）を店舗の運用名称で定義するマスタです。ここで登録した支払方法タイプを POS支払 で選択すると、対応する標準の提出タイプ（TenderType）が自動セットされます。

📌 ポイント: 「支払方法タイプ」は自由に名前を付けられる店舗側の呼び名、「提出タイプ」は iDempiere 標準の6区分（現金・小切手・カード等）です。同じ提出タイプに対して複数の支払方法タイプを作れるため、「Visa」「JCB」のようにブランド別に分けて集計する運用が可能です。

POS支払方法タイプでできること

Section titled “POS支払方法タイプでできること”
  • 店舗で受け付ける支払手段の登録（検索キー・名称）
  • 標準の提出タイプ（現金・小切手・カード・口座振替・掛売）への対応付け
  • 先日付（Post Dated）を前提とする支払手段の指定
  • 保証（Guarantee）付き支払手段の指定
  • 支払手段ごとの操作ヘルプ・注意事項の記載（コメント欄）
  • 使わなくなった支払手段の無効化

画面構成

Section titled “画面構成”

POS支払方法タイプは単一タブ構成のシンプルなマスタです。

タブ名テーブル項目数役割
POS Tender TypeC_POSTenderType約10項目支払手段の定義

基本操作手順

Section titled “基本操作手順”
graph TD
    A["🚀 メニューから開く<br/>販売管理 > 販売管理設定 > POS Tender Type"] --> B["➕ 新規で支払方法タイプを登録<br/>（検索キー・名称）"]
    B --> C["💳 提出タイプを選択<br/>（現金/カード/小切手など）"]
    C --> D{支払手段の性質}
    D -->|先日付を扱う| E["転記日時 = ON"]
    D -->|保証付き| F["Guarantee = ON"]
    D -->|即時現金など| G["両方 OFF"]
    E --> H["💾 保存"]
    F --> H
    G --> H
    H --> I["🔗 POS支払で選択可能に<br/>→ 提出タイプが自動セット"]

メニューから開く 販売管理 > 販売管理設定 > POS Tender Type 新規で支払方法タイプを登録 （検索キー・名称） 提出タイプを選択 （現金/カード/小切手など） 転記日時 = ON Guarantee = ON 両方 OFF 保存 POS支払で選択可能に → 提出タイプが自動セット 支払手段の性質 先日付を扱う 保証付き 即時現金など

アクセス方法

Section titled “アクセス方法”

メニューから「販売管理 > 販売管理設定 > POS Tender Type」を開きます。

新規登録

Section titled “新規登録”
  1. ツールバーの「新規」ボタンをクリック
  2. 必須項目を入力:
    • 検索キー: 支払方法の一意コード（40文字まで。例: CASH、VISA）
    • 名称: 店舗での呼び名（60文字まで。例: 現金、Visaカード）
  3. 分類・性質を設定:
    • 提出タイプ: 標準の支払手段区分（現金・小切手・クレジットカード等）
    • 転記日時（Post Dated）: 先日付小切手など、受領日と入金日が異なる支払手段の場合にチェック（既定値 N）
    • Guarantee: 与信に対する保証がある支払手段の場合にチェック（既定値 N）
  4. 必要に応じて 説明 と コメント（操作ヘルプ）を入力
  5. 「保存」をクリック

登録例

Section titled “登録例”
検索キー名称提出タイプ転記日時Guarantee
CASH現金X（現金）--
VISAVisaカードC（クレジットカード）-✔
JCBJCBカードC（クレジットカード）-✔
CHECK小切手K（小切手）--
CHECK-PD先日付小切手K（小切手）✔-
TRANSFER銀行振込A（口座振込）--
ACCOUNT掛売T（掛売）--

💡 ヒント: 提出タイプが同じでも支払方法タイプを分けておくと、POS支払の集計をブランド別・手段別に取れます。逆に細かく分けすぎるとレジ担当の選択ミスが増えるため、集計上必要な粒度で設計してください。

項目リファレンス

Section titled “項目リファレンス”
項目名必須型説明
クライアント必須選択テナント（既定値は現在のクライアント）
組織必須選択組織（既定値は現在の組織）
検索キー必須文字列(40)支払方法の一意コード
名称必須文字列(60)支払方法の名称
説明-文字列(255)補足説明
コメント-テキスト(2000)操作ヘルプ・注意事項
提出タイプ-リスト標準の支払手段区分（A/C/D/K/T/X）
Guarantee必須チェック与信に対する保証があるか。既定値 N
転記日時必須チェック先日付（Post Dated）を扱うか。既定値 N
有効必須チェックレコードが有効か。既定値 Y

全項目は 画面リファレンス: POS支払方法タイプ を参照してください。

よくある質問（FAQ）

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

Q. 「提出タイプ」にはどんな選択肢がありますか？

Section titled “Q. 「提出タイプ」にはどんな選択肢がありますか？”

標準では6区分です。A（口座振込 Direct Deposit）、C（クレジットカード）、D（口座引落 Direct Debit）、K（小切手 Check）、T（掛売 Account）、X（現金 Cash）。この区分は C_POSTenderType.TenderType のリスト参照として定義されています。

Q. 提出タイプを空欄のまま登録できますか？

Section titled “Q. 提出タイプを空欄のまま登録できますか？”

テーブル定義上、提出タイプ（TenderType）は必須ではありません。ただし空欄のまま POS支払で選択すると、Callout（CalloutOrder.SalesOrderTenderType）が転記する値がなく、支払手段の区分が特定できません。運用上は必ず設定してください。

Q. 「Guarantee」は何に使いますか？

Section titled “Q. 「Guarantee」は何に使いますか？”

IsGuarantee は「与信に対する保証があるか」を示すフラグです（標準の説明は “Guarantee for a Credit”）。クレジットカードのように決済が保証される手段と、小切手のように不渡りリスクがある手段を区別する目的で使います。

Q. 「転記日時」（Post Dated）とは？

Section titled “Q. 「転記日時」（Post Dated）とは？”

受領日と実際の入金日が異なる支払手段であることを示すフラグです。先日付小切手が典型例で、POS支払 側では「納品予定日」に取立予定日を入力して管理します。

Q. 使わなくなった支払方法を削除できますか？

Section titled “Q. 使わなくなった支払方法を削除できますか？”

C_POSTenderType は削除可能なテーブルですが、POS支払から参照されているレコードは参照整合性により削除できません。「有効」チェックを外して無効化してください。無効化すると新規の POS支払で選択できなくなり、既存データは保持されます。

Q. 支払方法タイプごとに勘定科目を分けられますか？

Section titled “Q. 支払方法タイプごとに勘定科目を分けられますか？”

C_POSTenderType 自体には会計設定の項目がありません。会計処理は受注・請求・入金の各伝票側で決まります。支払手段別に仕訳を分けたい場合は、対応する入金伝票（C_Payment）の銀行口座や現金出納帳の設計で対応するのが標準的な考え方です。

関連機能

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

概要

Section titled “概要”

POS支払方法タイプは C_POSTenderType（アクセスレベル 3 = Client+Org、削除可、高ボリュームではない）に格納されるマスタです。専用のビジネスロジッククラス（MPOSTenderType）は存在せず、自動生成クラス X_C_POSTenderType（310行）のみが提供されます。保存時の追加検証やカスタムロジックはコア側に実装されていません。

アーキテクチャ概要

Section titled “アーキテクチャ概要”
classDiagram
    class X_C_POSTenderType {
        <<generated>>
        +setValue(String)
        +setName(String)
        +setTenderType(String)
        +setIsGuarantee(boolean)
        +setIsPostDated(boolean)
        +getKeyNamePair() KeyNamePair
        +TENDERTYPE_Cash : String
        +TENDERTYPE_CreditCard : String
        +TENDERTYPE_Check : String
    }
    class PO {
        <<abstract>>
    }
    class MPOSPayment {
        +beforeSave(boolean) boolean
    }
    X_C_POSTenderType --|> PO
    MPOSPayment --> X_C_POSTenderType : references

<> +setValue(String) +setName(String) +setTenderType(String) +setIsGuarantee(boolean) +setIsPostDated(boolean) +getKeyNamePair() KeyNamePair +TENDERTYPE_Cash : String +TENDERTYPE_CreditCard : String +TENDERTYPE_Check : String <> +beforeSave(boolean) boolean

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/X_C_POSTenderType.java（310行、生成クラス）

関連DBテーブル

Section titled “関連DBテーブル”

C_POSTenderType（POS支払方法タイプ）

Section titled “C_POSTenderType（POS支払方法タイプ）”
カラム名型必須説明備考
C_POSTenderType_IDIDPK支払方法タイプID主キー
C_POSTenderType_UUUUID(36)NUUID
AD_Client_IDTableDirectYクライアント既定値 @#AD_Client_ID@
AD_Org_IDTableDirectY組織既定値 @#AD_Org_ID@
ValueString(40)Y検索キー
NameString(60)Y名称
DescriptionString(255)N説明
HelpText(2000)Nコメント操作ヘルプ
TenderTypeList(1)N提出タイプA/C/D/K/T/X
IsGuaranteeYesNoY保証既定値 N
IsPostDatedYesNoY先日付既定値 N
IsActiveYesNoY有効既定値 Y

提出タイプ（TenderType）の定数

Section titled “提出タイプ（TenderType）の定数”

X_C_POSTenderType に定義されている定数は次のとおりです。

コード定数意味
ATENDERTYPE_DirectDeposit口座振込
CTENDERTYPE_CreditCardクレジットカード
DTENDERTYPE_DirectDebit口座引落
KTENDERTYPE_Check小切手
TTENDERTYPE_Account掛売
XTENDERTYPE_Cash現金

ER図

Section titled “ER図”
erDiagram
    C_POSTenderType ||--o{ C_POSPayment : "tender type of"
    C_POSPayment }o--|| C_Order : "payment for"
    C_POSPayment }o--o| C_Payment : "payment document"

tender type of payment for payment document

ビジネスロジック

Section titled “ビジネスロジック”
  • モデルクラスのカスタムロジックなし: C_POSTenderType には M クラスが存在せず、X_C_POSTenderType が PO を直接継承します。beforeSave / afterSave は実装されていません。
  • 利用側の Callout: C_POSPayment.C_POSTenderType_ID 列に org.compiere.model.CalloutOrder.SalesOrderTenderType が設定されており、支払方法タイプの選択時に対応する TenderType を POS支払へ転記します。ロジックは支払方法タイプ側ではなく、利用側の列に置かれている点に注意してください。
  • 検索キーの一意制約: Value はマスタの検索キーですが、テーブル定義上のユニーク制約はカラム属性からは確認できません（要確認）。運用上は一意になるようコード体系を定めてください。

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

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

OSGi Model Validator（推奨）

Section titled “OSGi Model Validator（推奨）”
public class CustomPOSTenderTypeValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof X_C_POSTenderType) {
            X_C_POSTenderType tt = (X_C_POSTenderType) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: 提出タイプの入力を必須にする
                if (Util.isEmpty(tt.getTenderType())) {
                    throw new AdempiereException("提出タイプを選択してください");
                }
                // 例: 先日付は小切手のみ許可
                if (tt.isPostDated()
                    && !X_C_POSTenderType.TENDERTYPE_Check.equals(tt.getTenderType())) {
                    throw new AdempiereException("先日付は小切手の支払手段でのみ設定できます");
                }
            }
        }
        return null;
    }
}

支払手段の追加区分

Section titled “支払手段の追加区分”

提出タイプ（TenderType）のリスト値は AD のリスト参照で管理されています。電子マネーや QR コード決済のような新しい区分を増やす場合、リスト値の追加はアップグレードで影響を受けるコアデータの変更にあたります。区分自体は標準の6種類に寄せ、支払方法タイプ（C_POSTenderType）のレコードで細分化する運用を推奨します。

Callout

Section titled “Callout”

C_POSTenderType の列に標準の Callout は設定されていません。支払方法タイプ選択時の追加制御が必要な場合は、利用側（C_POSPayment）の列に Callout を追記します。

関連プロセス

Section titled “関連プロセス”

このウィンドウには標準の関連プロセス（ボタン起動のプロセス）は定義されていません。

関連ドキュメント

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

iDempiereカスタマイズのご相談

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

店舗ごとの支払手段体系や決済ブランド別の集計要件は、マスタ設計と Model Validator の組み合わせで無理なく実現できます。

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

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