はじめに
これは設計時の見落とし Advent Calendar 2018の15日目の記事となります。
業務アプリケーションの設計をするときに、見落としがちなところに焦点をあてて紹介します。
下流工程からの手戻りを少なくして 双方の負担を減らしましょう。
過去に請求処理機能を作成した際に指摘された3点を挙げてみました。
複数締日の設定
取引条件は顧客によって異なります。
月末締めの企業が多いと思いますが、5日、10日、15日、20日など別の日を締日としている会社も存在します。
また、締日は通常は1取引先で締日は1つですが、取引先によっては「15日締翌月末現金払い、月末締め翌々月10日払い」などというように1ヶ月に複数回締日のあるところもあります。
10日締め、20日締め、月末締めというように3回締日のある企業も存在することも考慮して、取引先マスタメンテナンスでは締日項目を3つ用意してあります。
画面レイアウト上でも、3つの数値入力を用意し、末日は31と設定して1～31の範囲チェックといずれか1つは必須入力とするようなチェック処理が仕様として記述されており、プログラムも仕様通り作成されました。
その後、設定した締日を使って処理する請求処理系の機能を製造するにあたりプログラマー側から問題提起がありました。
問題提起
3番目のみ入力されているとか、1番目と3番目で入力されているとか、10、5、15など昇順に並んでいないとかがあると処理が面倒になる。
3つの項目が順番通りに入っていることを保証してほしい。
対応
確かに締日に3つの項目の並びには特定の意味は無いわけですから、取引先マスタメンテナンス上にて空きのチェックや昇順にセットするようにチェック仕様を追加し、修正することとなりました。
締日に限らず複数項目がある場合、並びや空き入力なども考慮をしてチェックしなくても問題ないのかまで意識して仕様書を作成しましょう。
範囲指定と個別指定
請求書を発行する機能があり、その設計書には締日と請求先コードの範囲指定として開始コードと終了コードの入力項目がありました。
その設計書の画面レイアウトを見た営業兼SEの方が仰りました。
「お客さんによっては他のところより早めに請求書を要求してしてくるところがある、特に大きい会社など。範囲指定ではなく請求先一覧を表示し、チェックオンした請求先の請求書を発行するようにしたい。」 ということで、設計書の見直しが行われました。
このようなことがあるので請求書の発行機能に限らず、安易に範囲指定で済ませていいのかどうか、ユーザーとの検討が必要ではないでしょうか。
履歴持ちマスタの参照
社員マスタなど過去の情報も保持しておくために改定日をキーに含め履歴を持つようにしてあります。
例 社員00001が結婚して9/16から姓が変更した場合
| 社員ID | 改定日FROM | 改定日TO | 名前 |
|---|---|---|---|
| 00001 | 20050401 | 20080915 | 鈴木 花子 |
| 00001 | 20080916 | 99999999 | 佐藤 花子 |
※最終履歴の場合は、改定日TOの項目に99999999をセット
請求年月を参照してデータ出力する項目には社員コードがあり、社員マスタを参照して社員名をセットするようになっておりました。
問い合わせ
稼動から数ヶ月経って、ユーザーからエラーでデータ出力が出来ないとの問い合わせがありました。
データチェックの中に社員名が未セットならエラーとなるように仕組んでいたのですが、どうやらそのエラーにひっかかり出力できていなかったのです。
原因
原因を調査すると、データ上の社員が途中入社で改定日が2018/08/04で登録されている場合に発生することが分かりました。
実は、仕様書に「請求年月+1」としてから、社員マスタのデータを抽出するようになっており、請求年月が2018/08の場合、2018/08/01が条件となります。(日付は数値型として年月日の8桁で登録されている)
請求年月+1 BETWEEN 改定日FROM AND 改定日TO
20081801 BETWEEN 20081804 AND 99999999
「請求年月+1」としていた為に、途中入社の場合に抽出条件から外れてしまっていたのです。他の途中入社の方が今まで引っかからなかったのは、単純に過去入社だったからです。
対応
修正対応としては、履歴の先頭の改定日FROMを強制的に1日になるような社員マスタのビューを作成して、そのビューを参照させるようにしました。
雑感
社員名が空になるのさえ防げればいいとのことで直近の日にして抽出するようにとの指示でそうしたけれど、だったら年月だけで比較した方が簡単だったかも･･･
そもそも「請求年月+1」としている仕様の時点で整合性としてよく無かったですね。