売上・請求の業務処理
売上・請求の業務処理とは、出荷実績からの売上計上、会計システムへの連携、顧客への請求と入金照合までを一連の流れとして設計する業務処理である。大量のデータを限られた時間と資源の中で処理することと、業務データの整合性を保つことを両立させることが、システムアーキテクトによる設計の要点となる。
業務の流れとデータの受け渡し
売上・請求の処理は、前段の業務で得た情報を後段の処理が使える形に整えて渡す流れで成り立っている。仕入れと納品の仕組みを変更する場面でも、後続の買掛金システムに渡すデータに属性を二つ追加する変更が行われており、前段で持つ情報を後段へ欠けなく届けることが設計上の要求になる。
出荷実績ファイルから売上ファイルへ売上を計上する処理では、システムが自動で計上できるデータと、自動では計上できないデータを区別して扱う必要がある。計上の可否を業務ルールに基づいて分けておくことで、確認が必要なデータが会計へそのまま流れ込むことを防げる。
売上ファイルは会計システムへ連携され、自動仕訳を経た後に会計システムの一般会計処理へ引き継がれる。したがって、売上データは会計側で仕訳と勘定への集計を経て財務上の記録になる流れを前提に設計しなければならない。
バッチ処理の課題と処理方式の選択
大量データを一定のリソースで効率的に処理するために、業務処理ではバッチ処理が選ばれることがある。しかし、処理するデータが多いほど処理時間は長くなり、締め処理に間に合わなくなるおそれがある。さらに、オンライン処理と並行して実行すると、同じデータを異なる処理が同時に更新しようとして競合が生じる。
これらの課題を解決する基本は、業務の特性と制約に基づいて設計を工夫することである。例えば、インメモリデータ処理やオフラインバッチ処理などの処理方式を選択すると、単位時間あたりの処理量を示すスループットを上げられる。その結果、後続の締め処理に間に合う時間内に処理を終えられるようになる。
件数上限と優先度による判断
ピークの日には、リソースの範囲で全ての取引を処理しきれない可能性がある。このような場合には、1日の処理件数に上限を設けたうえで、業務上優先度の高い取引から順に処理する。上限を超えた取引は翌日の処理に持ち越すことで、締め処理に必要な重要な取引を先に確実に終えられる。
この節の続き
- 返品と照合の実際の場面
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む