Northwind 2.0 Developer Edition : Bons de commande

Cette édition Dev de l’exemple d’application Commandes achetés Northwind a le seul module Bons de commandes. Dans Starter Edition, les produits ne sont jamais à court et n’ont jamais besoin d’être achetés. Cette édition Dev développe le schéma de base de données (tables utilisées) dans Northwind 2.0 Starter Edition et utilise des fonctionnalités plus avancées. Il est toujours destiné à vous présenter les principales fonctionnalités de Microsoft Access, et non à exécuter une entreprise spécifique.

• La liste des bons de commande est disponible à partir du ruban. Il comporte des liens hypertexte pour ouvrir chaque bon de commande.

• La liste des bons de commande et le ruban ont tous deux un bouton Nouveau bon de commande pour ouvrir un nouveau bon de commande vide. Vous pouvez également créer des bons de commande à partir du formulaire Produits >bouton Réorganiser le produit .

• Les boutons de l’en-tête avancent les bons de commande dans le flux de travail via Envoyer, Approuver, Recevoir et Fermer. Les champs de suivi correspondants sur le formulaire sont verrouillés, car ils doivent uniquement être définis par programme en cliquant sur les boutons d’action.

• L’approbation d’un bon de commande nécessite le privilège d’approbation d’achat. Vous pouvez vous connecter en tant qu’Andrew Cencini, qui dispose du privilège, ou vous le donner dans Le système Administration > Privilèges. Notez que votre capacité à le faire est l’une des nombreuses raisons pour lesquelles Northwind n’est pas une application de qualité de production. Dans le monde réel, les utilisateurs ne pourront pas élever leurs propres autorisations.

• Les éléments de ligne d’un bon de commande sont validés par rapport à leur quantité. Il doit s’agir au moins de la quantité minimale de réapprovisionnement et, dans l’idéal, il doit récupérer l’inventaire au moins jusqu’au niveau cible, comme défini pour chaque produit.

• Lorsqu’un bon de commande est reçu, un traitement spécial est appelé pour distribuer ces produits aux articles de ligne de commande qui se trouvent dans aucun stock status et les définir sur Alloué. Toute quantité restante est envoyée à l’inventaire. Un enregistrement est ajouté à la table StockTake .

Cette section traite des détails d’implémentation notables du formulaire Bon de commande, frmPurchaseOrderDetails :

1. Le formulaire Bon de commande obtient ses données à partir d’une requête simple, qryPurchaseOrder (voir propriété RecordSource ). Il est recommandé de baser un formulaire de saisie de données sur une requête simple. Notez qu’il n’est pas nécessaire d’inclure la table PurchaseOrderDetails dans cette requête. Les détails sont gérés par le sous-formulaire. Toutefois, la requête se joint à d’autres tables pour récupérer les champs StatusName, SubmittedBy et ApprovedBy en lecture seule.

2. Le formulaire PurchaseOrderList peut ouvrir plusieurs instances du formulaire Bon de commande. Cela est pratique, car le service de bon de commande traite de nombreuses interruptions et peut avoir besoin d’ouvrir un autre bon de commande tout en travaillant sur le premier , ou de le comparer à un troisième bon de commande. La technique est documentée ici.

3. VendorID obtient sa valeur à partir d’une zone de liste modifiable à deux colonnes : une colonne d’ID masquée et une colonne Description visible. Ces zones de liste modifiable sont liées à des requêtes simples à deux colonnes : consultez la propriété RowSource .

4. Lors de l’enregistrement d’un enregistrement, les champs obligatoires doivent au moins être renseignés. Dans l’édition Starter, nous laissons le comportement par défaut d’Access se produire . dans cette édition Dev, une technique plus conviviale est implémentée, comme décrit en détail ci-dessous.

5. Lorsque l’état du bon de commande passe à Reçu, un traitement spécial est appelé (procédure AllocateToInventory) pour distribuer le nouvel inventaire sur les commandes en attente de ces produits.

VALIDATION

Le code de validation implémenté dans l’édition Northwind Dev ne nécessite que trois lignes de code :

• Dans Form_BeforeUpdate : Cancel = ValidateForm(Me)

• In Form_AfterUpdate:  ValidateForm_RemoveHighlights Me

• In Form_Current: ValidateForm_RemoveHighlights Me

Il s’agit d’un bon modèle à suivre : rendre votre code très autonome facilite l’implémentation partout. Les développeurs professionnels peuvent aller encore plus loin, par exemple en utilisant la sous-classification de formulaires. (Cela dépasse les objectifs de Northwind Dev.)

Le code de validation autonome accepte un objet de formulaire à valider.  Il vérifie ensuite la collection de formulaires de RecordsetClone sous-jacente pour déterminer quels contrôles sont liés aux champs obligatoires et vérifie s’ils ont une valeur. Si ce n’est pas le cas, ils sont mis en surbrillance. 

• Northwind 2.0 Developer Edition : ce que vous devez savoir.

• Northwind 2.0 Developer Edition : Toutes les rubriques