システム開発■ 譲渡
これまでは、債務への連動やマスタ関係、支払いの入力までの部分の修正をしていたのですが、いよいよ最難関の譲渡に手をつけることになりました。以前に書いたかもしれませんが、電子記録債権は、手形でいう裏書、割引、担保といったものを「譲渡」と呼ぶようです。もっとも、実運用で譲渡では分かりにくいので、そのまま裏書とか廻しとか呼んでると思いますけどね。
閑話休題。
さて、譲渡なのですが、電子記録債権を管理するテーブルについては、Part6（基幹システムの電子記録債権への対応 Part6 テーブル設計）で真剣に考えていたので受け皿の問題はありません。
なのですが、その時はあえて考えなかった支払と譲渡の特性を考慮する必要がありそうです。
■ 支払の特性
難しかったのは、譲渡するときに「一部を譲渡することができる」という電子記録債権の分割という機能です。そして、それの実装を困難にしたのは、支払で電子記録債権を譲渡する入力は予約であって、確定ではないということです。
手元にある電子記録債権を譲渡（裏書）する場合、対象の電子記録債権を選んで、譲渡したい金額を入力するのですが、入力した時点では「選択した電子記録債権から、***円を支払に廻す」という状態な訳です。
さて、この状態で元の電子記録債権に対してさらに譲渡しようとしたらどうするか。当然ですが、使えるのは先に支払に回した残額でなければなりません。
こうなると、以前考えていたテーブル設計だけだと、ちょっと無理がありますね。そもそも、あのテーブル設計は確定した電子記録債権を管理することを目的としていますし。
うーむ、入金系の場合は受け取るだけだったので良かったのですが、支払いの場合は手元にある電子記録債権を使うことがあるので、入金系よりもちょっと複雑ですね。かといって、電子記録債権を廻しに使うのであれば、入力＝確定にしてくれなんて言えないですし。割引、担保についてそれでも良いかも知れませんがね。
あと、間違えて入力された場合の取り消しも考慮しないといけないですよね。そうなると、ちょっと小手先の対応では無理が生じそうです。
■ 予約テーブル
色々と考えたのですが、新たにテーブルを作ることにしました。譲渡する電子記録債権に対して、どのような譲渡が予約されているのかを管理するテーブルです。
必要なのは、対象の電子記録債権と結合できるキー情報、譲渡入力の発生元のキー情報、譲渡の種別（裏書、割引、担保）、予約中か確定済みかの判定フラグ。ここまでを必須情報として、あとは要件に合わせて項目を追加すれば良いかな？
譲渡の入力時には、このテーブルと結合して、使用可能な金額を確認してやれば良いでしょう。
■ 後書き
電子記録債権の対応は、いくつかのフェイズに分けて実行する予定でした。最初は入金系からの受け口、次に、譲渡やデータ取り込みなどの補助機能、最後に支払い系。まぁ、実際には２番目の補助機能は放置して支払い系に手をつけているのが現状です。色々とやることが多すぎて補助機能まで手が回ってませんしね。
この電子記録債権のシリーズも、Part1からPart11までが入金系、Part12からは支払い系の話を書いているのですが、改めて支払い系の始まりのPart12（基幹システムの電子記録債権への対応 Part12 支払系の解析）を読むと、そのあたりの話がちゃんとかいてなくて、前後のつながりが無茶苦茶ですね。
・・・・・・・・まぁ、良いんです。整理して書くの、面倒だし。
前回：基幹システムの電子記録債権への対応 Part13 絶望のPG修正
次回：基幹システムの電子記録債権への対応 Part15 譲渡の取り消し
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end —
スポンサードリンク
0
0
