fc2ブログ

(元)社内SEの徒然なる日記

基幹システムの電子記録債権への対応 Part2 基幹システム

基幹システム

電子記録債権への対応といっても、まず、基幹システムにどの程度の修正が必要か見積もる必要があります。
まず、現行の基幹システムが持っている役割を考えてみました。

この基幹システムってのが曲者で、フルスクラッチで開発しただけあって、様々な機能が実装されています。

基本機能として、販売システムの役割を持っており、在庫品の取扱もあるので、在庫システムでもあります。
販売システムから発生した仕入から、検収システムに繋がり、そこから支払システムに繋がります。
同様に、販売システムから発生した売上から。請求システム回収システム入金システムへと流れていきます。

支払システムと入金システムがあるってことは、手形管理システムが付随してきます。

これだけ連動してるってことは、当然債権システム債務システムがあり、債権システムに連動する形で、与信管理システムが存在します。
さらに、会計システムだけはパッケージを使っているので、そこに連動するための経理仕訳作成システムもあります。

大きな単位で考えると、こんなところでしょうかね。ざっと12システムですか。

影響範囲の考え方

前回(基幹システムの電子記録債権への対応 Part1 始まり)の記事で書いた通り、電子記録債権の実体は手形とは別物のようですが、基幹システムとの連動部分に限れば、似たような動作をすると考えられます。

それを踏まえて、現行の手形システムの影響範囲が、電子記録債権の対応に必要な範囲としました。

1.手形システム

当然、手形システムは影響しますね。
もっている機能は、手形の承認・取立・決済・割引・裏書・担保・不渡などの、手形特有の機能です。
他に、手形一覧などの管理帳票やデータ出力機能を持っています。

2.入金システム・支払システム

受取手形の発生は入金システムから、支払手形の発生は支払システムから行います。
正確には、入金・支払システムで入力して、手形システムで承認するんですね。

ということは、電子記録債権の入力を可能にしないといけませんね。

3.債権システム・債務システム・与信システム

未決済手形の情報を債権・債務や与信に連動させています。

受取手形の場合、未決済手形を加算して、手形が期日を迎えた(入金された)時点で減算します。
与信システムはこの未決済手形の金額も加味して、与信残高を管理しています。

このあたりへの対応が必要かは、実装方法次第ですね。

実は、ここが曲者だったりします。
入金や支払を入力する時、部署別・金種別に金額を入力するのですが、手形金額の案分まではしてないんですよね。

例えば、ある取引先に2部署から仕入を行い、その支払を手形を発行して行ったとします。

支払合計額:250万円
内訳
 部署A:100万円、部署B:150万円
 手形A:130万円、手形B: 50万円、手形C:70万円


手形の期日が3枚とも同じならば、問題もないのですが、手形の期日が別になった場合、その手形をどの部署の分とするのかが分らないんですね。
例えば手形Cを期日前に決済したとすると、70万円の債務を、部署Aと部署Bでどのように振り分けるかを判断させないと、債務システムに正しく連動できませんよね。

実は基幹システムには、この判断機能が実装されていないので、債務金額が正しく反映できなかったりします。
これは、入金についても同様です。

まぁ、年に数回しか発生しないんですけど、発生した時にはデータパッチで辻褄合わせをしてたりします。

4.経理仕訳作成システム

これも前回の記事で書いていますが、仕訳が手形とは異なるので対応が必要ですね。

5.その他

後は、実装次第ですね。

後書き

うーむ、思った以上に影響範囲が大きいです。

もっとも、依頼者がどの程度の対応を求めているかにもよりますけどね。
例えば、「電子手形として考える」というのであれば、手形テーブルに電子区分とか追加して、手形管理システムから変更できるようにしてやります。
後は、その区分によって経理仕訳作成システムで作成する仕訳を変更してやればすむでしょうね。

...まぁ、こんな手抜きをすると、後になって画面だの帳票だのに、電子記録債権の表示・入力を要求されるのは目に見えてますけどね。

とりあえず、いくつかプランを作ってプレゼンすることにします。
具体的な設計とかは、その後ですね。

前回:基幹システムの電子記録債権への対応 Part1 始まり
次回:基幹システムの電子記録債権への対応 Part3 計画立案
投稿記事の一覧:目次

--- blog end ---


スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する