販売管理ソフトにおける残高リアルタイム更新の設計

Question

皆さん、こんちは。
大変マニアックな質問で恐縮ですが、ご教授いただければ幸いです。
社内の売上売掛管理システムを設計・プログラミングすることになったのですが（言語はAccess or VB　未定）、設計要望として、日次・月次更新のないリアルタイムなシステムを要求されました。
大方の概要設計は完了したのですが、唯一売掛残高の残高更新をどのように設計すれば良いのか、途方にくれています。これまで発想ですと月次更新を使って、売掛残高の繰越処理をしていたのですが、今回リアルタイム更新を要求されているので、売上・入金入力と同時にどのように売掛残高も塗り替えていけば良いのか発想が浮かびません。
よく会計パッケージなんか見ると、元帳残高などが月度の切れ目なくリアルタイムで塗り変わっているのを見るとどのように設計しているのかな、と思います。もし、売上・入金明細に残高項目を持たせてしまうと、データ量が増えるにつれ塗り替えに時間がかかってしまいます。
大変マニアックな質問ですが、このあたりの設計・プログラミングについてご経験のございます方のアドバイスを期待しております。
宜しくご教授の程お願い申し上げます。

imogasi · Accepted Answer

>大変マニアックな質問で恐縮ですが
表現だけ（言葉のあや）のことと思いますが、決してマニアックでもなく、事務系の業務ソフトのＳＥの最大の（永遠の）課題だと思います。その点をはっきり認識し、対処しないと、周りも誤解します。
○言わんとするムードはわかりますが、テーマがあちこち
移り、答えにくいものとなっています。それぞれ大テーマですから、ＯＫＷＥＢでの事実上限られた回答文字数のことを勘案すると、絞るべきとおもいます。
（１）「売上売掛管理システムを設計」の売掛金に重点があるのか
（２）「日次・月次更新のないリアルタイムなシステムを要」のリアルタイム性に質問重点があるのか
（３）「売上・入金入力と同時にどのように売掛残高も塗り替えていけば良いのか」その技術的方法についての質問か
（４）「リアルタイムで塗り変わっているのを見るとどのように設計しているのかな、と思います。」この技術的方法か。「塗り変わり」と言わず、ＳＥは「更新」という慣わしのはず。
（５）「売上・入金明細に残高項目を持たせてしまうと、データ量が増えるにつれ塗り替えに時間がかかってしまいます。」売掛金から売上・入金に話題が飛んでいますが。
－－－－－
以上はさておき、明細と残高について、思いを述べさせて
もらいます。
Ａ．トランザクションの最小単位だけを持つ。注文の品名
ごとの明細まで分解して持つなど。
まとめはリクエスト（端末からの要求）の都度検索し計算して出すことになります。今社員は何人？に対し、照会の都度全社員のレコード舐めて、勘定するような式です。
Ｂ．まとめを持つ。例．社員数合計をもつ。
Ｃ．両者の混合
使っていて、Ａを持たないと明細が出ないので、仕事をする人側からは必須のように見え要望が強い。ある部署では明細が出ると多すぎて鬱陶しく、全貌が却って掴み難いとか、検索や処理に時間がかかり、イライラするとかもある。
Ａを持つと、データ量が膨大になることがある。
照会対象取引日時を制限するとかのことになりますが、使う側からは不便・不満がでる場合があります。
旧いもの、特殊なものは別ファイルにして優先分と非優先分を分けるとか。去年の３月の社員数となると、退職者レコードも残す必要がある。
取引先よりの照会・訂正・クレーム処理・税務調査対応などでは重宝することがあるが、悩ましい。
Ｂのまとめを持つ点について。
毎取引ことに加除（減）が必要になる。まとめを持つ項目やレベルは社内コンセンサスが得にくいので決め難いものもあります。部署で頻用するデータが違っていたり、中身が微妙に違っていたりする。ある部署はパートを含む人員数を使いたい、休職者は除くとか、部外者には同じと見える言葉の定義も、中に入ると色々である。でもポピュラーな項目はまとめざるを得ないでしょう。何々別残高の何々と言うのが問題です。銀行などでは、預金者別のほかに、ＡＴＭ別、科目別、支店別、ブロック別、時間帯（締め後）別もリアルタイムに欲しいとかになります。
統計・経営管理・業務管理に使うデータと日常の取引先との交渉や担当者が使うなどに使うデータは分けて考えざるを得ないでしょう。これらの点に充分苦労されて設計されるようにと思います。ただ最近は大容量固定ディスクが安くなっているので、記録媒体であれこれ選択はしないで良いので楽です。あとは出きればアクセスを超える本格的なデータベースソフトに任すよりほかないでしょう。自作ではとても追いつかないレベルなので、検索等はそれらにお任せで、ＳＱＬ（ＲＤＢ）などの利用が一般的のようです。
○リアルタイムについて、特別にお考えのようですが
磁気ディスクを読み書きするパソコンの利用形態はリアルタイムが多く、特別ではなくなっています。昔はデータを磁気テープに記録していたのでオフラインバッチ処理が多かったですが。今も即座に使えないファイルを作ったり
検索結果が１分以上もかかる設計とか、印刷が多い場合だとバッチ処理もありえますが。
むしろＬＡＮ・ＷＡＮ環境の問題が最近は必須で加わっています。
○貴社での売掛金計上基準はどうなっていますか。
受注（注文）基準・蔵出し発送・納品書発送・検収・指定支払い期限・月末や翌月末・それらの一定日後とか。納入先によりばらばらとか。それらの２要素以上の情報をレコード上で、合成・結合して売掛状態であることが判るようにする。そして支払い済みを捉えて、その状態を消していけばよい。実際は別部署での発生データ・日時経過などあり複雑化する要因がありますが。消しこみ管理に付いては大テーマですので取りあえずは、今やっている方法をコンピュタ化する、他社の例を業者ＳＥに聞いてみるとか、市販既製品ソフトを研究するとか。
なにか１つでもヒントになることを祈ります。

ngsvx · Answer

会計ソフトは、見た感じでは期首残高だけを持っていて、
あとは表示時に計算しているように見えます。

これと同じやりかたでいいかどうかは、
様々な前提条件（データ量、目標レスポンス時間、利用者の数・・・）
によって変わってくるので、なんとも言えません。

ただ、ＲＤＢを使ってるなら、データ量がものすごく多いのでなければ、
表示に集計するのでも大丈夫な気はします。
（ただの抽出＆集計処理だろうから）


処理時間が問題になりそうなら、
一定の間隔（日次、月次等）で残高を保持し、
その時点から集計するしかないのでは？

最終残高は、入力時に更新します。
（前回残高とそれ以降の増減から集計する）
日付にインデックスが張ってあれば、全部を集計するよりも
速く出来ると思います。

その場合、最後の基準時点よりも以前の日付での入力を
許すと、それ以降の全ての残高を更新しなければならず、
処理時間がかかってしまいます。
基準時点を締め日として、入力させない等をする必要があります。
もっとも、「基準時点以前の入力は時間がかかるが、入力はできる」
という仕様にしてしまうのも１つの手かもしれませんが・・・。

と、こんな感じでどうでしょうか？
少しでも参考になれば。

販売管理ソフトにおける残高リアルタイム更新の設計

>大変マニアックな質問で恐縮ですが

会計ソフトは、見た感じでは期首残高だけを持っていて、

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング