ビジネスロジックとは、アプリケーション固有のルールでデータアクセスやプレゼンテーション以外の部分、平たく言うと、どんな状況をエラー/警告とみなすか、エラー/警告とみなした時はどうするのか等の決め事である。
販売管理パッケージソフトのビジネスロジックは導入顧客の要望に柔軟に対応できるようにしておかなくてはいけない。
例えば、Ａ社は在庫切れは商取引上命取りになるなら在庫割れチェックでエラーとしなければならないが、Ｂ社は受注生産で受注してから引き当てたらよいケースは在庫割れの警告メッセージまたは在庫割れチェック無しでよい。
また売上伝票は都度入力するが、仕入は後からまとめて入力等の運用している場合は、売上入力で在庫割れチェックでエラーとすると業務が前に進まない。
その都度、個別顧客の要望に合わせて販売管理パッケージソフトの修正で対応していたら、コストや時間がかかるしソフトの管理も煩雑になる。
そこで、よくあるビジネスロジックは、運用設定マスターで一元管理し、途中変更になってもエンドユーザで設定変更できるようにするのが望ましい。
販売管理パッケージソフトの「ふくろう販売」では、このように運用設定マスタで主要なビジネスロジックを制御できるようになっている。
1.原価割れチェック
通常、売上金額は売上原価以上で販売する。 売上原価は最終仕入法・移動平均法や標準原価法で計算される。
売上単価の入力間違いや原価を無視した大幅安値の防止等、売上伝票入力時にエラーチェックをかけておかなければいけない。
原価割れチェックの画面サンプルは、このようになる。
2.在庫チェック
在庫切れで販売チャンスを逃さないように、最低在庫・適正在庫割れしないように発注しなければいけない。
また、過大在庫持たないように最大在庫オーバチェックも必要である。
在庫チェックの画面サンプルは、このようになる。
3.与信限度チェック
各得意先毎の売掛債権が、設定した与信限度額を超えるような見積/受注/売上入力時にチェックをかけなければいけない。
事前に察知することで、貸倒損失のリスクを考慮した販売方法等を検討することが可能となる。
与信限度チェックの画面サンプルは、このようになる。
4.請求済伝票チェック
請求書発行済の得意先の締切前の売上日で伝票追加したり修正や削除すると請求書の再発行しなければいけない。
再発行せずに翌月締切で請求書発行すると請求残高が転がらない。
また、誤操作防止のため締切後の伝票修正等はできないようにロックする事も必要である。
請求済チェックの画面サンプルは、このようになる。
5.転記済伝票チェック
会計連動している会社で、転記済の伝票を修正や削除すると会計データも修正や削除しなければいけない。
「ふくろう販売」では修正前赤伝と修正後黒伝が自動転記されるが、警告メッセージを表示して更新可否をきいてくる。
転記済警告の画面サンプルは、このようになる。
また、むやみに許可すると総勘定元帳が赤黒で見にくくなるため、伝票修正等はできないようにロックする事もできる。
転記済エラーの画面サンプルは、このようになる。
6.伝票日付チェック
前月締切処理をしたにも拘わらず遡及入力で伝票追加/修正/削除をすると前月末の管理資料が信用できなくなる。
日付の入力ミスで翌年(月)の伝票として登録する場合も起こりうる。
伝票日付範囲チェックの画面サンプルは、このようになる。
7.棚卸日チェック
期末に棚卸する会社も多いが、正確な月次決算のため毎月棚卸する会社も少なくない。
通常は月次締切、すなわち末日決算なら毎月末、20日決算なら毎月20日に棚卸日を設定する。
上記と異なる日で棚卸しても間違いではないが、警告メッセージを表示して注意を促している。
棚卸日チェックの画面サンプルは、このようになる。
以上の他にも、たくさんのビジネスロジックがアプリケーション・システムに組み込まれている。
セキュリティ・システムと同様に何もしないと信頼性なくなるが、ガチガチにすると使い勝手が悪い。
どちらにウェイトを置くか、バランスよく運用設定を登録しておくのが望ましい。