AcumatiCares
Introduction
Avez-vous souhaité personnaliser l'écran de traitement des commandes de l'OC ? Vous remarquerez que de nombreuses actions de cet écran sont communes à l'écran de saisie des commandes clients. Comment ces actions sont-elles liées entre les deux écrans ? Notre objectif aujourd'hui est d'explorer la relation entre ces écrans et la manière dont ces actions sont invoquées à partir de l'écran de traitement.
Traitement des commandes
Dans l'écran Traiter les commandes(SO501000), les sélections dans la liste déroulante Action sont similaires à celles de l'écran de saisie des commandes clients(SO301000). Par exemple, les actions Créer une expédition et Annuler la commande sont présentes dans les deux écrans. En utilisant l'outil de recherche de code, nous pouvons ouvrir le fichier graphique qui alimente l'écran de saisie de la commande client - SOOrderEntry.cs. Lors de l'inspection, nous remarquons des membres tels que :
- putOnHold
- annuler la commande
- libération de la retenue de crédit
- créerShipment
Avant de continuer, il y a un historique intéressant d'Acumatica avant la version 2017. Dans ces versions, les flux de travail des cycles de vie des documents standard tels que les commandes clients, les commandes d'achat, les factures, etc. étaient définis à l'aide de flux de travail d'automatisation. Chaque cycle de vie était défini en interne à l'aide d'un vilain fichier XML, qui définissait les états des documents et des champs, les actions du menu, les rapports et les valeurs. Acumatica a permis au développeur de modifier le fichier XML pour remplacer le flux de travail par défaut. En outre, un menu d'automatisation du flux de travail a aidé le développeur à créer ces modifications via un écran séparé (qui existe toujours). Cela a certainement facilité le travail, mais n'a pas été d'une grande aide pour apprendre le lien entre les actions de l'écran de traitement et l'écran de saisie des documents.
Avec le navigateur de code, il est plus facile d'apprendre comment les actions sont partagées entre les écrans.
En regardant le graphique SOCreateShipment.cs, nous remarquons plusieurs membres de la classe
- Vue des données des commandes
- Filtre
- Événement RowSelected
- Événement RowUpdated
Mais remarquez qu'il n'y a pas de types nommés naturels pour notre liste déroulante d'actions ? Devrions-nous nous attendre à voir des membres nommés pour chacune de ces actions dans le graphe ?
Rappelons l'un des piliers de la programmation orientée objet : l'encapsulation. Comme nous pouvons le déduire, il n'est pas judicieux de définir le contenu de chaque action, de manière répétée, sur les deux écrans.
Lorsque nous examinons le code du graphique, nous remarquons que la vue de données Orders est de type PXFilteredProcessing. Cette vue de données est de type PXFilteredProcessing, qui hérite de PXProcessingBase. La classe PXProcessing définit la PXView, qui constitue le critère de sélection de nos enregistrements. Remarquez que le constructeur personnalisé de la vue de données Records passe le champ Filter.Owner ID, afin d'ajouter les critères OuterView Where de la vue de données. Cela permet de sélectionner les enregistrements dans lesquels l'utilisateur actuel est propriétaire de l'enregistrement de contact.
Un modèle de conception typique pour les écrans de traitement consiste à définir le délégué de traitement dans le constructeur du graphe. Dans notre cas, ce n'est pas le cas. Plus loin dans le code du graphique, remarquez l'événement RowSelected.
GIST: https://gist.github.com/tocohara/681c603dbe5f3aa059534373a5e66f14
Plusieurs écrans de traitement Acumatica utilisent l'événement Filter RowSelected pour invoquer un délégué de traitement de données. C'est le cas, par exemple, dans l'écran Validation des retenues(AR510000).
GIST : https://gist.github.com/tocohara/9c879a1e6670adeb921c6296c7fd1bc6
Dans ce cas, l'utilisation de SetProcessDelegate est plus évidente. Mais qu'en est-il de notre écran de traitement des commandes clients ? Revenons à l'événement SOProcessFilter RowSelected. SetProcessWorkflowAction est un membre de PXProcessingBase. Utilisons notre outil de réflexion pour explorer ce membre.
GIST : https://gist.github.com/tocohara/3e92bb85c5cf5a62438b2bfaa19be5a5
Nous trouvons quelques déclarations intéressantes dans cette méthode. En particulier, certaines variables définies dans le corps de cette méthode sont à noter
- screenId
- nom de l'action
Nous disposons d'un moyen de connaître l'identifiant de l'écran et le nom de l'action, le graphique ProcessOrder, lors de l'événement RowSelected. Remarquez que le type d'action est S0301000$PrepareInvoice (dans ce cas, nous avons choisi l'action Prepare Invoice dans l'écran de traitement).
En examinant de plus près les détails de la méthode SetProcessWorkflowAction, on remarque un appel à une méthode plus profonde appelée _SetProcessTargetInternal. Nous découvrons le code qui crée les variables d'écran et de menu en divisant la variable Action avec le caractère $. Ceci est important car ces variables sont utilisées plus loin dans la méthode, pour invoquer l'automatisation du flux de travail, spécifiquement par écran et par ID d'action.
GIST : https://gist.github.com/tocohara/e74897a1c42ff9c630946f4eb9efb0e4
Le code va plus loin que cette méthode, mais finalement, le lien entre l'écran SO301000 et le graphique SOOrderEntry est établi dans le graphique. Plus tard, l'action est invoquée dans un lot.
Si vous souhaitez en savoir plus sur le stockage de cette relation, consultez le tableau AUDefinitionDetail:
Résumé
Dans ce billet, nous avons exploré les graphiques de l'écran Traiter les commandes. Nous avons étudié le membre Actions. En utilisant un outil de réflexion, nous avons découvert que l'ID de l'écran et le nom de l'action sont interceptés profondément dans les membres de la classe PXProcessBase, afin d'invoquer les actions dans l'écran de saisie des commandes clients.
J'espère que vous avez trouvé cela utile - et toujours - Happy Coding !
