メイン コンテンツへスキップ
サポート
Microsoft アカウントでサインイン
サインインまたはアカウントを作成してください。
こんにちは、
別のアカウントを選択してください。
複数のアカウントがあります
サインインに使用するアカウントを選択してください。

Northwind Developer Edition の発注書については、以下のトピックを選択してください。 

Northwind 発注書サンプル アプリケーションのこの Dev Edition には、唯一の発注書モジュールがあります。 Starter Edition では、製品が不足し、購入する必要はありません。 この Dev Edition は、Northwind 2.0 Starter Edition のデータベース スキーマ (使用されるテーブル) を拡張し、より高度な機能を使用します。 特定のビジネスを実行するのではなく、Microsoft Access の主な機能を紹介することを目的としています。

  • [発注書一覧] はリボンから入手できます。 各発注書を開くハイパーリンクがあります。

  • [発注書一覧] と [リボン] には、[新しい発注書] ボタンが表示され、新しい空の発注書が開きます。 [製品] フォーム>[ 製品の並べ替え ] ボタンから発注書を作成することもできます。

  • ヘッダーのボタンは、[送信]、[承認]、[受信]、および [閉じる] を通じて、ワークフローを通じて発注書を進めます。 フォームの対応する追跡フィールドは、アクション ボタンをクリックしてプログラムによってのみ設定する必要があるため、ロックされます。

  • PO を承認するには、購入承認特権が必要です。 権限を持つ Andrew Cencini としてログインすることも、System 管理 > Privileges で自分に付与することもできます。 これを行う機能は、Northwind が運用環境の品質アプリケーションではない多くの理由の 1 つです。 実際には、ユーザーは自分のアクセス許可を昇格できません。

  • 購買発注の明細は、数量に関して検証されます。 少なくとも最小注文数量である必要があります。理想的には、各製品に対して設定されているように、在庫を少なくともターゲット レベルに戻す必要があります。

  • 購買発注が 入庫されると、特別な処理が呼び出され、これらの製品が 在庫なし ステータスの注文明細に配布され、 割り当て済に設定されます。 残りの数量は在庫に送信されます。 StockTake テーブルにレコードが追加されます。

このセクションでは、発注書フォーム frmPurchaseOrderDetails の注目すべき実装の詳細について説明します。

  1. 発注書フォームは、単純なクエリ qryPurchaseOrder ( RecordSource プロパティを参照) からデータを取得します。 単純なクエリでデータ入力フォームを基にするのがベスト プラクティスです。 このクエリに PurchaseOrderDetails テーブルを含める必要はありません。 詳細はサブフォームによって処理されます。 ただし、クエリは他のテーブルと結合して、読み取り専用 の StatusNameSubmittedByApprovedBy フィールドを 選択します。

  2. PurchaseOrderList フォームでは、発注書フォームの複数のインスタンスを開くことができます。 これは、PO 部門が多くの中断を処理し、最初の PO の作業中に別の PO を開くか、3 つ目の PO と比較する必要がある場合があるため、便利です。 この手法については、 こちらを参照してください

  3. VendorID は、非表示の ID 列と表示される Description 列という 2 列のコンボボックスから値を取得します。 このようなコンボボックスは、単純な 2 列クエリにバインドされます。 RowSource プロパティを参照してください。

  4. レコードを保存する場合は、少なくとも 必要な フィールドを入力する必要があります。 スターター エディションでは、Access の既定の動作が発生します。この Dev エディションでは、以下で詳しく説明するように、より使いやすい手法が実装されています。

  5. PO ステータス[受信済み] に移動すると、特別な処理 (プロシージャ AllocateToInventory) が呼び出され、これらの製品を待機している注文に対して新しい在庫が分散されます。

検証

Northwind Dev エディションで実装されている検証コードには、次の 3 行のコードのみが必要です。

  • Form_BeforeUpdate: Cancel = ValidateForm(Me)

  • Form_AfterUpdate : ValidateForm_RemoveHighlights Me  

  • Form_Current: ValidateForm_RemoveHighlights Me

これは従うのに適したパターンです。コードを非常に自己完結型にすると、どこでも簡単に実装できます。 プロの開発者は、フォームのサブクラス化を使用するなど、これをさらに進める可能性があります。 (これは Northwind Dev の目標を超えています)。

自己完結型の検証コードは、検証するフォーム オブジェクトを受け入れます。  次に、基になる RecordsetClone のフォーム コレクションをチェックして、必要なフィールドにバインドされているコントロールを調べ、値があるかどうかを確認します。 表示されない場合は、強調表示されます。 

ヘルプを表示

その他のオプションが必要ですか?

サブスクリプションの特典の参照、トレーニング コースの閲覧、デバイスのセキュリティ保護方法などについて説明します。

コミュニティは、質問をしたり質問の答えを得たり、フィードバックを提供したり、豊富な知識を持つ専門家の意見を聞いたりするのに役立ちます。

この情報は役に立ちましたか?

言語の品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?
[送信] を押すと、Microsoft の製品とサービスの改善にフィードバックが使用されます。 IT 管理者はこのデータを収集できます。 プライバシーに関する声明。

フィードバックをいただき、ありがとうございます。

×