基幹システムの電子記録債権への対応 Part6 テーブル設計

テーブル設計

前回でも書いていますが、要件がきちんと定まっていない中での開発なので、内部設計が重要な意味を持ってきます。

ある程度の仕様変更に耐えられるように、柔軟な受け皿を用意しないといけません。
さて、どうしたものか．．．

履歴管理

基本的なデータの持ち方は、こんな感じですかね。


期日が10/10で、電子記録債権を受け取ったのが1/5。
決済を向かえた後で、10/14に不渡になった事が判明した電子記録債権のデータの持ち方です。

肝になるのが、右端の2項目の開始日と終了日です。
データ上に状態（発生、決済、不渡）を表す区分を用意して、それらが有効な期間を開始日と終了日で表現します。
終了日は、基本的には次の履歴データの開始日の前日になるようにして、最終レコードの終了日は、設定できる最大日を設定します。

帳票などで、特定の時期の状態を出力しなければならない時は、この開始日と終了日から対象となるデータを抽出するって方針です。

例えば、基準日が2013/9/30時点での電債の状態を確認するのであれば、こんな感じでしょうか。

-- 基準日が2013/9/30の場合
select * from ***
where
開始日　<=　基準日　and
終了日　>=　基準日　and
期日　>　基準日

条件には、期日が到来している電子記録債権は弾くように考慮します。
．．．基本的には、これで行けると思うのだが。

ちなみに、PrimaryKeyは、管理番号と履歴として、自動採番してやります。

分割した時は？

これが手形であれば、上記の手法だけで問題ないと思うのですが、電子記録債権の場合は分割っていう事が出来てしまうので、その時の方法も考えないと行けませんね。

それを考慮して、こういう持ち方にします。


5/5に1,000円の電債を700円と300円に分割した時のデータの持ち方です。

元になった管理№1の終了日を、分割を実施した前日の5/4としてやります。
そして、分割した700円と300円の２件分のレコードを、開始日5/5として作成してやります。

この時に、元になった電子記録債権が分るように、元管理№という項目に、分割元の親の管理№を設定してやります（元が無い場合は、0とする）。

先ほどの抽出条件を考慮すると、基準日が5/4までは元の電債が、5/5以降は、分割した後の電債のみが抽出対象になります。

譲渡を伴わない分割？

上では、単純に電債を分割した想定ですが、でんさいネットの場合は、譲渡を伴わない分割は許されないはずです。
ただ、他に３つ存在する記録機関はどうなのか分らないし、電子記録債権法には、分割だけをしちゃダメって書いてないようなので、譲渡を伴わない分割も出来るように考えました。

では、譲渡を伴う場合はどうするかっていうと。


300円の電債を譲渡した場合のデータです。
このような場合には、履歴を作らずに、状態を上書き更新します。

譲渡だけに限らないのですが、履歴の保持方法が日の単位なので、１日の間に複数回の状態変更が発生する場合には、履歴を作らずに上書更新しようかと。

ただ、ここはもう少し慎重に考えても良いかもですね。
さっきは、終了日は次の履歴の開始日の前日って書き方をしましたけど、状態が変更される場合には同一日でもｏｋにするとか。でないと、制約の多いシステムになってしまいそうです。

あとは、うーん。開始時間と終了時間を持たせるって手もありますかね。

フラグによる使用制御

このデータをベースとして、売掛、買掛、経理などの各サブシステムと連携させていくので、連携用のフラグを準備してやります。

決済フラグ、債権フラグ、仕訳フラグってかんじでフラグを用意。
各フラグの値は、未処理、処理済み、対象外って３つの状態で管理して、連携用のプログラムでは、フラグの値が未処理であるデータを対象として処理を行ってやります。

後書き

いろいろ考えたんですけど、１件の電子記録債権を１レコードとして考えるって方式では無理があると判断しました。

“今この瞬間だけを考えれば良い”っていう要件であれば、それでも良かったんですけど、“過去の特定の時点の状態”も見たいとなると、これが正解の一つではないかと思います。

．．．もっと良い手段もあるとは思いますけど、私の能力ではここまでですね。

前回：基幹システムの電子記録債権への対応　Part5　開発方法
次回：基幹システムの電子記録債権への対応　Part7　仕訳ってどうなるん？
投稿記事の一覧：目次

--- blog end ---