Northwind Developer Edition での注文の管理については、以下のトピックを選択してください。
Northwind Orders サンプル アプリケーションのこの Developer Edition は、Starter Edition よりも高度です。 データベース スキーマ (使用されているテーブル) が拡張され、追加の高度な機能が提供されるようになりました。 ここでの目的は、特定のビジネスを実行するのではなく、Microsoft Access の機能を紹介するためです。
-
注文一覧はリボンから入手できます。 いくつかのフィルター オプションと、各注文を開くハイパーリンクがあります。
-
注文一覧とリボンの両方に、[注文の追加] ボタンが表示され、新しい空白の注文が開きます。
-
[新しい注文] フォームで、ドロップダウンから既存の顧客を選択します。 その時点で 、従業員 名と 新しい 状態が選択されます。 注文日も既に入力されています。 税率は SystemSettings テーブルから読み取られ、税ステータスの既定値は Customer レコードから取得されます。
-
リボンの MRU (最近使用した) リストに新しい注文と発注書が追加されます。 詳細については、この記事の「MRU リスト」セクションを参照してください。
-
現時点では、[ 出荷日 ] と [ 支払日] は空白のままにします。
-
新規顧客の注文を追加するには、会社名とタブアウトを入力します。 [会社の詳細] フォームが開き、新しい顧客レコードが完了します。 次に、それを閉じ、注文を続行します。 これで、新しい会社が [ 顧客 ] ドロップダウンに表示されます。
-
注文に品目を追加するには、この注文の 製品カテゴリ と 製品 を選択し、「数量」と入力します。 単価が入力され、Price は式によって計算されます。
-
注文の状態を進め、注文フォームの上部にあるボタンを使用して 、[新規] > [請求済み] > [出荷済み] > [クローズ] からワークフローを通じて注文を移動します。
-
請求は、その注文に対して製品が割り当てられている場合にのみ発生します。 明細が在庫なしまたは注文時の状態の場合は、検証エラーが発生します。 ユーザーは、その製品の発注書を作成して受け取ることができ、注文明細の状態が [割り当て済み] に調整されます。
-
注文を発送するには、 荷送人 と 配送料を 入力する必要があります。 忘れた場合は、検証エラーが発生します。 配送料が注文合計に追加されます。
-
[注文の削除] ボタンを使用して、未 承認の注文を削除できます。
-
注文が 新しい 状態を過ぎた後は、注文明細を変更できません。
-
Northwind Starter バージョンでは、注文プロセスは非常に単純です (たとえば、在庫は常に利用可能で、不足することはありません。購入する必要はありません)。 この Dev エディションでは、より現実的なプロセスで、少なくともそのような問題に対処しています。 実際のアプリケーションを実装するのではなく、Access の機能とベスト プラクティスを紹介しています。
-
ここでは実際のアプリケーションを実装していないという証拠には、日付が検証されていないという事実が含まれます。 そのため、注文日より 前 の出荷日などの非論理的な日付を入力できます。
このセクションでは、注文フォーム frmOrderDetails の注目すべき実装の詳細について説明します。
注文フォームは、単純なクエリ qryOrder からデータを取得します ( RecordSource プロパティを参照してください)。 単純な 1 テーブル クエリにデータ入力フォームを基にすることをお勧めします。 このクエリに OrderDetails テーブルを 含める必要はありません。 注文の詳細は、サブフォームによって処理されます。
OrderList フォームでは、Order フォームの複数のインスタンスを開くことができます。 これは、営業担当者が多くの中断を処理し、最初の注文の作業中に別の注文を開くか、3 番目の注文と比較する必要がある場合があるため、便利です。 この手法については、 こちらを参照してください。
さまざまな ID フィールドは、非表示の ID 列と表示される Description 列という 2 列のコンボボックスから値を取得します。 これらのコンボボックスは、単純な 2 列クエリにバインドされています。 RowSource プロパティを参照してください。
ワークフロー ボタンには、ビジネス ロジックが関連付けられているため、ユーザーは注文を 1 から 4 に進める必要があります。 Northwind 開発チームは、一部の企業が異なるルールを使用する可能性があることを認識しています。 これにより、ボタンクリックイベントに対して異なる実装が発生し、注文が確定するタイミングと注文を削除できるタイミングを再検討します。
サブフォーム sfrmOrderDetails は、より複雑なクエリにバインドされます。 その理由については、後述の「カスケード コンボボックス」セクションで説明します。 行が保存されたときにForm_AfterUpdate イベントのインベントリをチェックし、より強力なデータベース クエリを実行できます。
ProductCategory と Product はカスケード 型のコンボボックスです。最初の (ProductCategory) から選択すると、次のコンボ ボックスが一致する子 Product レコードに絞り込まれます。 ここで使用する手法については、以下で詳しく説明します。
レコードを保存するときは、必要なフィールドを入力する必要があります。 Starter エディションでは、Access の既定の動作が発生します。この Dev エディションでは、より使いやすい手法が実装されています。 ここで使用する手法については、以下で詳しく説明します。
注文明細ごとに、利用可能な在庫がチェックされ、それに応じてステータスが設定されます。 この機能の基本的な考え方については、 こちらを参照してください。
カスケードコンボボックス
製品カテゴリと製品ドロップダウンをカスケード コンボボックスとして実装するのは難しいです。Access はこの機能をすぐにサポートしていないためです。 この手法では、次の 4 つの手順が必要です。
フォームは連続フォーム モードである必要があります (データシートではありません)。 テキストボックスは各コンボボックスのテキスト部分と重なり、ドロップダウン矢印のみが表示されます。
フォームのレコード ソース クエリ qryOrderLineItems は、通常どおり OrderDetails テーブルを使用しますが、Products テーブルと ProductCategories テーブルと結合して ProductName と ProductCategoryName を取得します。 重複する 2 つのテキスト ボックスは、これらのフィールドにバインドされます。
Products コンボボックスの RowSource は cboProductCategories を振り返り、そのコンボボックスで選択されたカテゴリの製品のみを返します。 構文 "[Form]!抽出条件式の [cboProductCategories]" は、明示的な Forms よりも柔軟です 。FormName!名前 で 1 つのフォームを参照する ControlName 構文。
バインドされていない ProductCategories コンボボックスで製品カテゴリを選択すると、 AfterUpdate イベントによって Products コンボボックスがリスト内の最初の値に設定されます。 これにより、フォームの RecordSource に新しい行が作成され、 CategoryName が設定され、重なり合うテキスト ボックスで表示できるようになります。
検証
Northwind Dev Edition で実装されている検証コードを使用する場合、3 行のコードのみが必要です。
-
Form_BeforeUpdate:
Cancel = ValidateForm(Me) -
Form_AfterUpdateとForm_Current:
ValidateForm_RemoveHighlights Me
コードを非常に自己完結型にすることは、どこにでも簡単に実装できるため、従うのに適したパターンです。 プロの開発者は、フォームサブクラス化を使用するなどして、これをさらに進めることができます。 (これは Northwind Dev の目標を超えています)。
フォーム オブジェクトは、自己完結型の検証コードに渡されて検証されます。 次に、基になる RecordsetClone Fields コレクションをチェックして、必要なフィールドにバインドされているコントロールを調べ、値があるかどうかを確認します。 表示されない場合は、強調表示されます。
