システム開発■ 不安
とりあえず、現在の支払手形の作成処理を解析しながら似たような作りで設計を始めたのですが、どうも変な感じがする。見た目は綺麗に見えるのですが、ふと業務レベルで深く考えると、本当に運用できるのか心配になってきました。
・・・これ、良くないなぁ。
ここまでの解析結果と、試作品（Excelで書いた画面や帳票のレイアウト）を携えて、ちょっと方向性を確認することにしましょうかね。
■ 手戻り
結果、ほぼ作り直し。
・・・フザケルナヨ（小声）。
こちらは手形ベースで考えていたのですが、実際の電子記録債権の運用方法は、振込に近い扱いになっているようなんです。なので、振込をベースにして、そこに電子記録債権の特有の機能（ぶっちゃけると期日）を加味する方向で作って欲しいと。
・・・あぁぁぁぁ、これまでの作業が水の泡だよ〜〜〜〜〜〜！
そもそも、電子記録債権の基本設計が手形ベースだったし、受取側（入金）については問題なく機能していたので気にしていませんでしたが、話を聞いてから実際に発生している電子記録債権のデータを見てみると、確かに変な感じ。
具体的に言うと、債権金額がやたらと細かい。手形の場合、100万とかキリのいい数字になることが多いのですが、113,985円みたいな細かいデータがゴロゴロ転がっています。
■ でんさいネット
うーん、どうやら当初からの設計が良くなかった気がします。
このシステム、そもそも「でんさいネット」っていう全銀協のシステムを利用することが大前提なのですが、直接使用できるわけではなく、窓口となる銀行を経由して使用するものです。これがまた厄介さを増しています。
「でんさいネット」のホームページを見ると、「現在利用している窓口金融機関をそのまま利用できる」「金融機関の創意工夫によって、それぞれの利用者ニーズにあったサービスを提供できる」といった、さぞ良いことのように書いていますが、そんな訳がありません。
複数の銀行を窓口金融機関とする場合、各銀行が個別に提供しているサービスに合わせた機能がいるってことか？
直接的な影響としては、複数の銀行を支払元銀行とする場合、各銀行を窓口金融機関として別々に使用する必要がありそうな感じじゃないですか。
例えば、窓口銀行がA行だった場合、B行の口座を支払元とすることは出来ない。それをするためには、B行にも窓口銀行となって貰わないとならないってことですかね？
■ 方針
手形で支払う場合、必要な情報は支払元銀行、額面金額、期日、印紙税。このくらいでしょうか。それをベースに考えていたのですが、電子記録債権の場合、支払先の銀行や利用者番号（１法人に付与される一意の番号）なども必要になってきます。
お客様の口座情報はすでに取引先マスタに持っているのですが、それは振込用の口座情報。振込と電子記録債権で口座情報が変わることもあるらしいです。
さらに、電子記録債権を使用する場合、１件ごとに手数料が発生するのですが、最近では手数料を支払先に負担してもらうことが出てきているようです。この考え方、振込については振込手数料の負担先（取引先 or 自社）を設定する区分を取引先マスタに持っていましたが、手形についてはノーチェックです。
うーん、マスタ項目を見直す必要があるなぁ。これは結構手間取りそう。
■ 後書き
開発開始時点では結構真剣に設計して、これまでも大きな不備はなかったのですが、これは大掛かりな方向修正が必要みたいです。開発開始時点で、支払系の知見が私になかったことが響いていますね。
・・・・・・・・ま、なんとかなるさ！
前回：基幹システムの電子記録債権への対応 Part18 支払系の開発開始
次回：いつか
最新の記事：http://harikofu.blog.fc2.com/
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end —
スポンサードリンク
0
0
