Northwind 2.0 Developer Edition : Commandes

Cette édition développeur de l’exemple d’application Northwind Orders est plus avancée que celle de l’édition Starter. Il développe le schéma de base de données (les tables utilisées) et fournit désormais des fonctionnalités avancées supplémentaires. L’intention des présentes est de vous présenter les fonctionnalités de Microsoft Access, et non de gérer une entreprise spécifique.

• La liste des commandes est disponible à partir du ruban. Il dispose de quelques options de filtre et de liens hypertexte pour ouvrir chaque commande.

• La liste des commandes et le ruban ont tous deux un bouton Ajouter une commande pour ouvrir une nouvelle commande vide.

• Dans un formulaire Nouvelle commande, sélectionnez un client existant dans la liste déroulante. À ce stade, votre nom d’employé et le nouveau status sont sélectionnés. La date de commande est déjà renseignée. Le taux d’imposition est lu à partir de la table SystemSettings et l’état de la taxe par défaut à partir de l’enregistrement Client.

• Les nouvelles commandes et bons de commande sont ajoutés à la liste MRU (Most Recently Used) dans le ruban. Pour en savoir plus, consultez la section Liste mru de cet article. 

• Laissez les champs Date d’expédition et Date de paiement vides pour l’instant.

• Pour ajouter des commandes pour de nouveaux clients, entrez le nom de l’entreprise et appuyez sur la touche Tab out. Le formulaire Détails de la société s’ouvre pour terminer le nouvel enregistrement client. Ensuite, fermez-la et poursuivez avec la commande. La nouvelle entreprise se trouve désormais dans la liste déroulante Client .

• Pour ajouter des éléments à une commande, sélectionnez une catégorie de produit et un produit pour cette commande, puis entrez Quantité. Unit Price est renseigné et Price est calculé par une expression.

• Avancez l’état de la commande et déplacez la commande dans le flux de travail à partir de Nouveau > Facturé > Expédié > Fermé à l’aide des boutons en haut du formulaire de commande.

• La facturation ne peut se produire que si le produit est alloué à cette commande. Si un élément de ligne est en status Aucun stock ou Sur commande, une erreur de validation se produit. L’utilisateur peut créer un bon de commande pour ce produit et le recevoir, et l’élément de commande status sera ajusté sur Alloué.

• Pour expédier une commande, les frais d’expédition et d’expédition doivent être entrés. Si vous oubliez de le faire, une erreur de validation se produit. Les frais d’expédition sont ajoutés au total de la commande.

• Les commandes non commandées peuvent être supprimées à l’aide du bouton Supprimer la commande.

• Les éléments de ligne de commande ne peuvent pas être modifiés une fois la commande passée la nouvelle status.

• Dans la version Northwind Starter, le processus de commande est incroyablement simple (par exemple, l’inventaire est toujours disponible, n’est jamais à court et n’a jamais à être acheté). Maintenant, dans cette édition Dev, un processus plus réaliste traite au moins certains de ces problèmes. N’oubliez pas que nous présentons les fonctionnalités d’Access et les meilleures pratiques, et non l’implémentation d’une application réelle. 

• La preuve que nous n’implémentons pas d’application réelle ici inclut le fait que les dates ne sont pas validées. Par conséquent, il est possible d’entrer des dates illogiques telles qu’une date d’expédition antérieure à la date de commande. 

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

Le formulaire de commande obtient ses données à partir d’une requête simple qryOrder (voir propriété RecordSource ). Il est recommandé de baser un formulaire de saisie de données sur une simple requête d’une table. Notez qu’il n’est pas nécessaire d’inclure la table OrderDetails dans cette requête. Les détails de la commande sont gérés par le sous-formulaire.

Le formulaire OrderList peut ouvrir plusieurs instances du formulaire Order. Cela est pratique, car les commerciaux font face à de nombreuses interruptions et peuvent avoir besoin d’ouvrir une autre commande tout en travaillant sur la première, ou de la comparer à une troisième commande. La technique est documentée ici.

Les différents champs ID obtiennent leurs valeurs à partir de zones de liste modifiable à deux colonnes : une colonne 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 .

La logique métier des boutons de flux de travail est associée, ce qui force l’utilisateur à passer la commande de 1 à 4. L’équipe de développement Northwind est consciente que certaines entreprises peuvent utiliser des règles différentes. Cela entraînerait une implémentation différente pour les événements de clic de bouton, ainsi que la réexécriture du moment où une commande est définie et quand une commande peut toujours être supprimée.

Le sous-formulaire sfrmOrderDetails est lié à une requête plus complexe. Les raisons de cela sont décrites dans la section Cascading Comboboxes ci-dessous. Nous case activée pour l’inventaire dans l’événement Form_AfterUpdate lorsque la ligne est enregistrée et nous pouvons exécuter des requêtes de base de données plus puissantes.

ProductCategory et Product sont des zones de liste déroulante en cascade : la sélection dans la première (ProductCategory) réduit la suivante aux enregistrements de produit enfants correspondants. La technique utilisée ici est décrite en détail ci-dessous.

Lors de l’enregistrement d’un enregistrement, les champs obligatoires doivent ê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. La technique utilisée ici est décrite en détail ci-dessous.

Pour chaque article de ligne de commande, l’inventaire disponible est vérifié et le status est défini en conséquence. L’idée de base de cette fonctionnalité est décrite ici.
 

COMBOBOXES EN CASCADE

L’implémentation des listes déroulantes Catégorie de produit et Produit en tant que zones de liste déroulante en cascade est délicate, car Access ne prend pas en charge cette fonctionnalité prête à l’emploi. Quatre étapes sont nécessaires dans cette technique :

Le formulaire doit être en mode Formulaires continus (et non feuille de données). Les zones de texte chevauchent la partie texte de chaque zone de liste modifiable, laissant uniquement leurs flèches déroulantes visibles. 

La requête source d’enregistrement du formulaire, qryOrderLineItems, utilise la table OrderDetails par habitude, mais se joint également aux tables Products et ProductCategories pour récupérer ProductName et ProductCategoryName. Les deux zones de texte qui se chevauchent sont liées à ces champs.

La valeur RowSource de la zone de liste modifiable Products examine cboProductCategories pour renvoyer uniquement les produits de la catégorie sélectionnée dans cette zone de liste déroulante. Notez la syntaxe « [Formulaire] ! [cboProductCategories] » dans l’expression critère, qui est plus flexible que les forms explicites! FormName! Syntaxe ControlName , qui fait référence à un formulaire par nom.

Après avoir sélectionné une catégorie de produit dans la zone de liste déroulante ProductCategories non lié, son événement AfterUpdate définit la zone de liste déroulante Products sur la première valeur de sa liste. Cette opération crée une ligne dans l’objet RecordSource du formulaire, qui remplit le CategoryName afin qu’il puisse être affiché par sa zone de texte qui se chevauche.
 

VALIDATION

L’utilisation du code de validation implémenté dans l’édition Northwind Dev ne prend que 3 lignes de code :

• Dans Form_BeforeUpdate :
     Cancel = ValidateForm(Me)

• In Form_AfterUpdate and Form_Current:
      ValidateForm_RemoveHighlights Me

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

L’objet de formulaire est passé au code de validation autonome à valider. Il vérifie ensuite la collection RecordsetClone Fields 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