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

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

POS支払は、店頭販売（POS）の受注伝票1件に対して受け取った支払を、支払手段ごとに1レコードずつ記録する画面です。現金・クレジットカード・小切手・口座振替などを組み合わせた分割支払（複数手段での支払）に対応します。

📌 ポイント: POS支払は処理済みの受注伝票に対して新規追加できません（MPOSPayment.beforeSave() が新規レコードで親受注が処理済みの場合に ParentComplete エラーを返します）。支払の追加や修正が必要な場合は、受注伝票を再開（Re-activate）してから行ってください。

POS支払でできること

• 受注伝票1件に対する複数支払手段の登録（分割支払）
• 支払手段の指定（POS支払方法タイプ／提出タイプ）
• 現金・クレジットカード・小切手・口座振替それぞれの必要情報の記録
• クレジットカード情報（種別・番号・ボイス認証コード）の記録
• 小切手情報（金融機関コード・小切手番号・口座番号・MICR）の記録
• 国際送金情報（IBAN・Swiftコード）の記録
• 先日付小切手（Post Dated）と納品予定日の管理
• 入金伝票（C_Payment）とのひも付け

画面構成

POS支払は単一タブ構成です。

タブ名	テーブル	項目数	役割
POS Payment	C_POSPayment	約23項目	受注伝票に対する支払1件分の明細

💡 ヒント: 支払手段そのもののマスタは POS支払方法タイプ で定義します。POS支払を登録する前に、店舗で受け付ける支払手段を一通り登録しておいてください。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>販売管理 > 見積受注管理 > POS Payment"] --> B["➕ 新規で支払を登録"]
    B --> C["📄 受注伝票を選択<br/>（未処理の伝票のみ）"]
    C --> D["💳 POS提出タイプを選択<br/>→ 提出タイプが自動セット"]
    D --> E{支払手段}
    E -->|現金| F["💴 御支払金額を入力"]
    E -->|クレジットカード| G["💳 カード種別・番号<br/>名義人・認証コードを入力"]
    E -->|小切手| H["🧾 金融機関コード・小切手番号<br/>口座番号を入力"]
    E -->|口座振替/送金| I["🏦 口座番号・IBAN<br/>Swiftコードを入力"]
    F --> J["💾 保存"]
    G --> J
    H --> J
    I --> J
    J --> K["🔁 残額があれば<br/>別の支払手段で追加登録"]

メニューから開く 販売管理 > 見積受注管理 > POS Payment 新規で支払を登録 受注伝票を選択 （未処理の伝票のみ） POS提出タイプを選択 → 提出タイプが自動セット 御支払金額を入力 カード種別・番号 名義人・認証コードを入力 金融機関コード・小切手番号 口座番号を入力 口座番号・IBAN Swiftコードを入力 保存 残額があれば 別の支払手段で追加登録 支払手段 現金 クレジットカード 小切手 口座振替/送金

アクセス方法

メニューから「販売管理 > 見積受注管理 > POS Payment」を開きます。

新規登録

1. ツールバーの「新規」ボタンをクリック
2. 必須項目を入力:
   • 受注伝票: 支払の対象となる受注伝票（処理済みの伝票は選択不可）
   • POS提出タイプ: 支払方法タイプ（選択すると「提出タイプ」が自動セットされます）
   • 御支払金額: 受け取った金額
3. 支払手段に応じた情報を入力:

支払手段	入力する項目
現金	御支払金額のみ
クレジットカード	クレジットカード（種別）、クレジットカード番号、名義人、ボイス認証コード
小切手	金融機関コード、小切手番号、口座番号、Micr、Check Status
口座振替・送金	口座番号、金融機関コード、IBAN、Swiftコード

4. 先日付小切手の場合は「転記日時」（Post Dated）にチェックし、「納品予定日」に取立予定日を入力
5. 必要に応じて「Deposit Group」（入金グループ）や「コメント」を入力
6. 「保存」をクリック

⚠️ 注意: クレジットカード番号は CreditCardNumber（20文字）にそのまま保存されます。カード情報の保持は PCI DSS 等の規制対象となるため、実運用では決済代行サービス側にカード情報を残し、iDempiere には取引識別子のみを記録する設計を推奨します。

支払状況の確認

このウィンドウは受注伝票ごとの支払明細を一覧・検索する用途にも使えます。伝票番号や取引先で絞り込み、支払手段別の内訳を確認できます。処理が完了した支払は「処理済み」（Processed）が立ちます。

項目リファレンス

項目名	必須	型	説明
受注伝票	必須	検索	支払対象の受注伝票。更新不可
入金支払伝票	-	検索	ひも付く入金伝票（C_Payment）
POS提出タイプ	必須	選択	支払方法タイプ。Callout で提出タイプを自動セット
提出タイプ	-	リスト	支払手段の分類（現金・小切手・カード等）
御支払金額	必須	金額	受け取った金額
名義人	-	文字列(60)	カード名義人・口座名義
金融機関コード	-	文字列(20)	銀行のルーティング番号
小切手番号	-	文字列(20)	小切手の番号
口座番号	-	文字列(20)	口座番号
Micr	-	文字列(20)	金融機関コード・口座・小切手番号の組合せ
IBAN	-	文字列(40)	国際銀行口座番号
Swiftコード	-	文字列(20)	Swift/BIC コード
クレジットカード	-	リスト	カード種別（Visa/MC/AmEx 等）
クレジットカード番号	-	文字列(20)	カード番号
ボイス認証コード	-	文字列(20)	カード会社からの音声認証コード
Check Status	-	リスト	小切手の状態
転記日時	必須	チェック	先日付（Post Dated）か。既定値 N
納品予定日	-	日付	先日付小切手の取立予定日
Deposit Group	-	文字列(20)	入金グループ
コメント	-	テキスト	補足メモ
処理済み	必須	チェック	処理済みフラグ

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

よくある質問（FAQ）

Q. 「ParentComplete」というエラーで保存できません

親の受注伝票が既に処理済み（Processed=Y）の状態で、新規の POS支払を追加しようとしています。MPOSPayment.beforeSave() が新規レコードかつ親受注が処理済みの場合にこのエラーを返す仕様です。受注伝票を再開（Re-activate）してから支払を追加してください。

Q. 1件の受注に複数の支払手段を登録できますか？

できます。POS支払は受注伝票に対する1対多の明細として設計されており、現金＋クレジットカードのような分割支払を、支払手段ごとに1レコードずつ登録します。

Q. 「POS提出タイプ」と「提出タイプ」の違いは？

「POS提出タイプ」（C_POSTenderType_ID）は店舗で定義する支払方法マスタへの参照、「提出タイプ」（TenderType）は iDempiere 標準の支払手段区分（現金・小切手・カード等）です。POS提出タイプを選ぶと Callout（CalloutOrder.SalesOrderTenderType）が対応する提出タイプを自動セットします。

Q. 提出タイプにはどんな区分がありますか？

標準では次の6区分です。A（口座振込 Direct Deposit）、C（クレジットカード）、D（口座引落 Direct Debit）、K（小切手 Check）、T（掛売 Account）、X（現金 Cash）。

Q. Check Status（小切手の状態）の選択肢は？

標準では C（Charged／取立済）、D（Delayed／遅延）、P（Replaced／差替）、R（Received／受領）、T（Returned／返却）の5種類です。

Q. 受注伝票を後から変更できますか？

「受注伝票」（C_Order_ID）は IsUpdateable=N として定義されており、保存後に変更できません。誤った伝票に登録した場合はレコードを削除して登録し直してください。

関連機能

• POS支払方法タイプの使い方
• 受注伝票（Sales Order）の使い方
• 入出金伝票（Payment）の使い方
• 得意先(顧客)の使い方
• 画面リファレンス: POS支払

🛠 技術仕様（開発者向け）

概要

POS支払は C_POSPayment（アクセスレベル 3 = Client+Org、削除可、高ボリュームテーブル IsHighVolume=Y）に格納されます。モデルクラスは MPOSPayment（90行）で、beforeSave() のみをオーバーライドした軽量クラスです。Document 型ではなく、DocStatus / DocAction は持ちません（Processed フラグのみ）。

IsHighVolume=Y のため、検索ダイアログでは自動的な全件リストではなく検索条件の入力が求められます。POS のトランザクション量を想定した設定です。

アーキテクチャ概要

classDiagram
    class MPOSPayment {
        +beforeSave(boolean) boolean
        -s_log : CLogger
    }
    class X_C_POSPayment {
        <<generated>>
        +CHECKSTATUS_* : String
        +TENDERTYPE_* : String
    }
    class PO {
        <<abstract>>
    }
    class MOrder {
        +isProcessed() boolean
    }
    class X_C_POSTenderType {
        <<generated>>
    }
    MPOSPayment --|> X_C_POSPayment
    X_C_POSPayment --|> PO
    MPOSPayment --> MOrder : validates parent
    MPOSPayment --> X_C_POSTenderType : tender type

+beforeSave(boolean) boolean -s_log : CLogger <> +CHECKSTATUS_* : String +TENDERTYPE_* : String <> +isProcessed() boolean <> > X_C_POSPayment X_C_POSPayment --

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/MPOSPayment.java（90行）/ X_C_POSPayment.java Callout: org.compiere.model.CalloutOrder.SalesOrderTenderType（C_POSTenderType_ID 列）

関連DBテーブル

C_POSPayment（POS支払）

カラム名	型	必須	説明	備考
C_POSPayment_ID	ID	PK	POS支払ID	主キー
C_POSPayment_UU	UUID(36)	N	UUID
AD_Client_ID	TableDirect	Y	クライアント	既定値 @#AD_Client_ID@
AD_Org_ID	TableDirect	Y	組織	既定値 @#AD_Org_ID@
C_Order_ID	Search	Y	受注伝票	更新不可（IsUpdateable=N）
C_Payment_ID	Search	N	入金支払伝票
C_POSTenderType_ID	TableDirect	Y	POS提出タイプ	Callout: CalloutOrder.SalesOrderTenderType
TenderType	List(1)	N	提出タイプ	A/C/D/K/T/X
PayAmt	Amount	Y	御支払金額
A_Name	String(60)	N	名義人
RoutingNo	String(20)	N	金融機関コード
CheckNo	String(20)	N	小切手番号
AccountNo	String(20)	N	口座番号
Micr	String(20)	N	MICR
IBAN	String(40)	N	IBAN
SwiftCode	String(20)	N	Swiftコード
CheckStatus	List(1)	N	小切手状態	C/D/P/R/T
CreditCardType	List(1)	N	クレジットカード種別
CreditCardNumber	String(20)	N	カード番号
VoiceAuthCode	String(20)	N	ボイス認証コード
IsPostDated	YesNo	Y	先日付	既定値 N
DatePromised	Date	N	納品予定日	先日付小切手の取立日
DepositGroup	String(20)	N	入金グループ
Help	Text(2000)	N	コメント
Processed	YesNo	Y	処理済み

提出タイプ（TenderType）の定数

コード	定数	意味
A	TENDERTYPE_DirectDeposit	口座振込
C	TENDERTYPE_CreditCard	クレジットカード
D	TENDERTYPE_DirectDebit	口座引落
K	TENDERTYPE_Check	小切手
T	TENDERTYPE_Account	掛売（Account）
X	TENDERTYPE_Cash	現金

小切手状態（CheckStatus）の定数

コード	定数	意味
C	CHECKSTATUS_Charged	取立済
D	CHECKSTATUS_Delayed	遅延
P	CHECKSTATUS_Replaced	差替
R	CHECKSTATUS_Received	受領
T	CHECKSTATUS_Returned	返却

ER図

erDiagram
    C_Order ||--o{ C_POSPayment : "payments"
    C_POSPayment }o--|| C_POSTenderType : "tender type"
    C_POSPayment }o--o| C_Payment : "payment document"
    C_Order }o--|| C_BPartner : "customer"

tender type payment document

ビジネスロジック

MPOSPayment.beforeSave()

MPOSPayment が持つ唯一のカスタムロジックです。

protected boolean beforeSave (boolean newRecord)
{
    MOrder parent = new MOrder(getCtx(), getC_Order_ID(), get_TrxName());
    if (newRecord && parent.isProcessed()) {
        log.saveError("ParentComplete", Msg.translate(getCtx(), "C_Order_ID"));
        return false;
    }
    return true;
}

処理内容は次のとおりです。

1. C_Order_ID から親の受注伝票（MOrder）をロード
2. 新規レコードかつ親受注が処理済み（isProcessed()）の場合、ParentComplete エラーを記録して false を返し保存を中止
3. それ以外は true を返す

⚠️ 注意: 既存レコードの更新（newRecord=false）は、親受注が処理済みでもこの検証を通過します。処理済み伝票の支払金額を意図せず変更してしまわないよう、運用ルールまたは Model Validator での追加制御を検討してください。

Callout

C_POSTenderType_ID 列には org.compiere.model.CalloutOrder.SalesOrderTenderType が設定されており、選択した POS支払方法タイプに対応する TenderType を自動セットします。

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

OSGi Model Validator（推奨）

public class CustomPOSPaymentValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MPOSPayment) {
            MPOSPayment pay = (MPOSPayment) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: 金額は正数のみ
                if (pay.getPayAmt() == null || pay.getPayAmt().signum() <= 0) {
                    throw new AdempiereException("御支払金額は正の値を入力してください");
                }
                // 例: 更新時も処理済み受注は変更禁止にする
                if (type == TYPE_BEFORE_CHANGE) {
                    MOrder order = new MOrder(pay.getCtx(), pay.getC_Order_ID(), pay.get_TrxName());
                    if (order.isProcessed()) {
                        throw new AdempiereException("処理済み受注のPOS支払は変更できません");
                    }
                }
            }
        }
        return null;
    }
}

決済代行サービスとの連携

クレジットカード決済をオンラインで処理する場合は、カード番号をそのまま CreditCardNumber に保存せず、決済代行の取引 ID を保持する設計が安全です。OSGi サービスとして決済アダプタを実装し、TYPE_AFTER_NEW で外部 API を呼び出す構成にすると、コアを変更せずに連携できます。

Callout の追加

C_POSTenderType_ID 以外の列に Callout は設定されていません。支払手段に応じて必須項目を切り替えるといった UI 制御を追加したい場合は、AD_Column の Callout 欄に独自 Callout を登録します（既存の記述はセミコロン区切りで維持してください）。

関連プロセス

POS支払ウィンドウには標準の関連プロセス（ボタン起動のプロセス）は定義されていません。Processed フラグは業務処理側で更新されます。

関連ドキュメント

• 画面リファレンス: POS支払
• POS支払方法タイプの技術仕様
• 受注伝票の技術仕様

---

iDempiereカスタマイズのご相談

POS の支払手段や決済代行連携は、店舗運営の実態に合わせた作り込みが必要になる領域です。Model Validator と OSGi サービスで、コア改変なしに決済フローを拡張できます。

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

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