この特集のトップページへ
>
Chapter 6:ビジネスロジックの設計
6.4.2 伝票情報の編集
●伝票情報テーブルの更新ならびに取得
まずは,伝票情報テーブルの更新ならびに取得を考える。 ○伝票情報テーブルの更新
先に説明したように,伝票情報テーブルのレコードでユーザーが直接編集可能なフィールドは,顧客番号を保持するCUSTOMERIDフィールドと,単独で請求書を作るかどうかを設定するONEBILLFLAGフィールドの2つである。そこで,List 6-95に示すUpdate_CUSTOMERIDメソッドとList 6-96に示すUpdate_ONEBILLFLAGメソッドを,それぞれDataObj.Slipコンポーネントに実装する。どちらのメソッドも,第1引数には更新したい伝票の伝票番号を,第2引数には更新後の顧客番号または単独で請求書を作るかどうかのフラグをとる。List 6-95やList 6-96を参照するとわかるように,ここではDataObj.Historyコンポーネントを使い,履歴を残す処理も加えている。
顧客番号を変更するメソッドと,単独で請求書を作るかどうかを示すフラグを変更するメソッドを,1つにまとめず分離したのは,操作できるタイミングが異なるためである。伝票の流れについては「6.5 伝票の遷移」で説明するが,取引先の顧客番号を変更できるのは,伝票が承認される以前に限りたい。たとえば,製品を発送したあとで伝票の対象となる顧客を変更できるようにしてしまうと,その後の請求処理において,発送先とは異なる顧客に対して請求処理を実行してしまうおそれがある。一方,単独で請求書を作るかどうかのフラグは,経理処理を実行する時点までは変更を許可する。詳しくはあとから説明するが,伝票を編集するためのビジネスコンポーネントに実装するメソッドでは,その時点の伝票の状態を調べ,顧客番号は変更可能か,単独で請求書を作るかどうかを示すフラグは変更可能かを事前に調査する。ここで,もし2つの判断が1つのメソッドにまとめられていると,片方は許して片方は許さないというわけにはゆかなくなる。
○伝票情報テーブルの取得もちろん,登録した伝票の情報は参照可能な状態にしなければならない。そこで,伝票情報テーブル内のレコードを返すメソッドを実装する。
このメソッドを,顧客情報を返すDataObj.CustomerコンポーネントのGetRecordメソッド(List 6-16)や,製品情報を返すDataObj.ProductコンポーネントのGetRecordメソッド(List 6-56)と同様に実装するとなると,次のようになるだろう。
Sub GetSlip(ByVal ID As Long, _ ByRef CUSTOMERID As Long, _ ByRef MADEDATE As Date, _ ByRef SUBTOTAL As Currency, _ ByRef TAX As Currency, _ ByRef TOTAL As Currency, _ ByRef BILLID As Variant, _ ByRef BILLDATE As Variant, _ ByRef MADEBILLFLAG As Boolean, _ ByRef ONEBILLFLAG As Boolean, _ …以下略。Table 6-14に示した全フィールド分だけ続く…
しかし,これでは引数があまりにも多すぎて,使いやすいとはいえない。そこで,用途ごとに機能を分類し,次の7つのメソッドに分割して実装することにする。
- GetRecord_Slipメソッド
- 取引先の顧客を示す顧客番号,小計,消費税,合計,起票者のアカウント名,起票日,最終更新者名,最終更新日時など,基本的な情報を返すメソッドである。このメソッドは,List 6-97のように実装する。
- GetRecord_Billメソッド
- 伝票に結び付けられた請求書の請求書番号,請求書が作成された日時,単独で請求書を作るかどうかのフラグなど,請求書にかかわる情報を返すメソッドである。このメソッドは,List 6-98のように実装する。
- GetRecord_Requestメソッド
- 承認を依頼したユーザーのアカウント名,承認を依頼した日時,承認を依頼したときのコメントなど,承認依頼処理にかかわる情報を返すメソッドである。このメソッドは,List 6-99のように実装する。
- GetRecord_Consentedメソッド
- 承認したユーザーのアカウント名,承認した日時,承認時のコメントなど,承認にかかわる情報を返すメソッドである。このメソッドは,List 6-100のように実装する。
- GetRecord_Rejectedメソッド
- 却下したユーザーのアカウント名,却下した日時,却下時のコメントなど,承認の却下にかかわる情報を返すメソッドである。このメソッドは,List 6-101のように実装する。
- GetRecord_Sendメソッド
- 発送処理をしたユーザーのアカウント名,発送日時,発送時のコメントなど,発送処理にかかわる情報を返すメソッドである。このメソッドは,List 6-102のように実装する。
- GetRecord_Accountingメソッド
- 経理処理をしたユーザーのアカウント名,経理処理をした日時,経理処理時のコメントなど,経理処理にかかわる情報を返すメソッドである。このメソッドは,List 6-103のように実装する。
このように分割しておけば,多数の引数を指定することなく,必要な情報だけを取得できるようになる。
○伝票の状態の取得ところで,List 6-97〜List 6-103で示した以外にも,もう少しメソッドを追加しておきたい。1つは,伝票が存在するか削除されているかを調べるメソッド,もう1つは,その時点における伝票の状態を調べるメソッドである。
前者のメソッドは,伝票情報テーブルのDELETEDFLAGフィールドの値を調べることで,簡単に実現できる。List 6-104は,このメソッドをIsDeletedという名前でDataObj.Slipコンポーネントに実装したものである。この処理は,顧客情報管理におけるDataObj.CustomerコンポーネントのIsDeletedメソッド(List 6-23)や,製品情報管理におけるDataObj.ProductコンポーネントのIsDeletedメソッド(List 6-58)と同様なので,ここでの説明は割愛する。
問題は,後者のメソッド,つまりその時点における伝票の状態を返すメソッドである。「3.2.5 伝票の流れ」でも説明したように,伝票は営業部で起票され,製品管理部や経理部を経て,最終的に請求書が生成される。この様子を再度図示すると,Fig.6-76のようになる。
Fig.6-76 伝票の流れ
伝票の状態は,伝票情報テーブル(Table 6-14)の下記フィールドによって決定される。
- REQ_CONSENTFLAG
- CONSENTEDFLAG
- REJECTEDFLAG
- SENDFLAG
- ACCOUNTINGFLAG
- MADEBILLFLAG
Fig.6-76を参照するとわかるように,伝票には次の7つの状態がある。
- 伝票作成中
- 伝票を作成中の段階である。REQ_CONSENTFLAG,CONSENTEDFLAG,REJECTEDFLAG,SENDFLAG,ACCOUNTINGFLAG,MADEBILLFLAGという各フィールドの値がすべてFalseであるときが,この状態に相当する。
- 承認待ち
- 伝票を書き終え,上司の承認を待っている段階である。REQ_CONSENTFLAGフィールドの値がTrueであるときが,この状態に相当する。
- 承認ずみ(発送待ち)
- 上司に承認され,発送を待っている段階である。CONSENTFLAGフィールドの値がTrueであるときが,この状態に相当する。
- 却下されている
- 上司の確認において却下された段階である。REJECTEDFLAGフィールドの値がTrueであるときが,この状態に相当する。
- 発送ずみ(経理処理待ち)
- 発送が完了し,経理の処理を待っている段階である。SENDFLAGフィールドの値がTrueであるときが,この状態に相当する。
- 経理確認ずみ(請求書作成待ち)
- 経理の確認が完了し,請求書の作成を待っている段階である。ACCOUNTINGフィールドの値がTrueであるときが,この段階に相当する。
- 請求書作成ずみ(すべて完了)
- 請求書が作成された段階である。伝票の最終的な状態といえる。MADEBILLFLAGフィールドがTrueであるときが,この段階に相当する。
そこでまず,これらの状態を示す列挙型をDataObj.Slipコンポーネントに実装しておく。このサンプルでは,List 6-105に示すSlipStatusという列挙型を使って伝票の状態を管理することにする。
次に,指定された伝票番号に基づいて伝票の状態を調査するメソッドを実装する。このメソッドは,指定された伝票番号に相当する伝票がList 6-105で示したSlipStatus列挙型のうち,どの状態になっているかを返すものである。この処理を実現するには,伝票情報テーブルから,REQ_CONSENTFLAG,CONSENTEDFLAG,REJECTEDFLAG,SENDFLAG,ACCOUNTINGFLAG,MADEBILLFLAGという6つのフィールドの値を調べればよい。このメソッドをDataObj.SlipコンポーネントにGet_SlipStatusという名前で実装したものが,List 6-106である。
Chapter 6 56/92 |