システム開発■ 困難
電子記録債権のデータは履歴で管理するように設計している（基幹システムの電子記録債権への対応 Part6 テーブル設計）のですが、これは支払についても同様です。
今でも発想は良いと思っているのですが、この仕様が、支払系のプログラムを実に難しくしてくれました。
■ 支払の取り消し（手形の場合）
前回（基幹システムの電子記録債権への対応 Part14 譲渡の実装）の記事で書いた通り、支払を間違えた場合の訂正について考えていました。
入力した支払を最終確定する処理があるのですが、この処理を実行すると、もう後戻り出来ません。手形を裏書する入力をしていた場合、支払確定処理を実行すると逃げ道がないのです。
ではどうするのかというと、まず、新たにマイナスの金額で支払を入力（横から支払データを無理やり登録する処理がある）して、支払金額を打ち消します。この処理では裏書した手形の状態まで戻らないので、手形の管理画面から直接状態を裏書から元に戻すようになっています。
これ、オペレーションを間違えたら支払と手形で整合性が取れなくなってしまうので、気に入りません。
■ 支払の取り消し（電子記録債権の場合）
そこで、電子記録債権についてはマイナス支払からの完全連動を行うようにしました。
マイナスの支払入力までは同じなのですが、そこから譲渡していた電子記録債権を関連付ける機能を実装します。その状態で支払確定処理が実行されたら、電子記録債権の状態を譲渡から元に戻すようにします。
ここまで聞くと、特に問題なく感じます。
■ 履歴管理
最初に書いた通り、電子記録債権は日の単位で履歴を作成します。電子記録債権を誤って譲渡した場合も、データ上は履歴が作成されます。
さて、2/20に受け取った電子記録債権を5/10に譲渡して、5/15に取り消した場合、履歴はこうなります。
1. 2/20 〜 5/9 債権 1,000
2. 5/10 〜 5/14 譲渡 1,000
3. 5/15 〜 債権 1,000
ここまでは良いのですが、ややこしいのは、取り消しを5/10に実行した場合です。履歴の管理単位は日なので、同一日に状態が変更された場合は、履歴を作成しません。
支払訂正の前の状態がこうなっています。
1. 2/20 〜 5/9 債権 1,000
2. 5/10 〜 譲渡 1,000
ここから、支払訂正を行った場合、ここまで戻さなければなりません。
1. 2/20 〜 債権 1,000
つまり、履歴どころか先に発生していたデータを削除した上に、発生元の債権の情報（履歴の終了日）も書き換える必要があるわけです。
・・・うーむ、面倒だなぁ。
■ 分割
面倒ですが、ここまでは許容範囲です。問題なのは、譲渡分割された電子記録債権を取り消す場合です。
2/20に受け取った電子記録債権を5/10に300円譲渡したとします。
1. 2/20 〜 5/9 債権 1,000
2. 5/10 〜 債権 700
3. 5/10 〜 譲渡 300
これを、5/15に取り消した場合、履歴はこうなります。
1. 2/20 〜 5/9 債権 1,000
2. 5/10 〜 5/14 債権 700
3. 5/10 〜 5/14 譲渡 300
4. 5/10 〜 債権 1,000
この場合、分割した結果も打ち消さないといけないので、分割譲渡した残りの債権データ（２件目）の終了日も更新が必要です。当然、取り消した元の譲渡データ（３件目）の終了日も更新します。
さらに、分割という事実自体を打ち消すための、新たに履歴を作成します（４行目）。ここで嫌らしいのは、債権金額が分割前の1,000円として履歴を生まなければならないということです。
この場合、横から差し込むマイナス金額は300円でしかありません。なので、関連付けられた電子記録債権（譲渡したやつ）から自身の発生元を探して元の債権金額を求めなければならない訳です。
これ、譲渡していたのが１件だけなら良いのですが、複数譲渡していた場合は悲惨です。1,000円の電子記録債権を、同じ日にA社に300円、B社に200円、C社に150円分割譲渡して、後日にB社の支払を打ち消すとしたら・・・
■ 後書き
最初に書いた通り。履歴管理の発想は良いと思っています。今回のように、電子記録債権の発生部分ではプログラムが複雑になりますが、入力後の管理系（決済、管理帳票など）については、単純なプログラムで過去の特定の時点をきちんと表示できます。
結局、どこで苦しむのかって話なんですよね。
前回：基幹システムの電子記録債権への対応 Part14 譲渡の実装
次回：基幹システムの電子記録債権への対応 Part16 実運用テスト
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end —
スポンサードリンク
0
0
