AcumatiCares
L'une des grandes caractéristiques de la plateforme Acumatica XRP est qu'elle élimine la nécessité d'un codage personnalisé par le biais des attributs. Par exemple, l'écran Articles en stock fournit des attributs en fonction de la classe de l'article ; l'écran Vendeur fournit des attributs en fonction de la classe du fournisseur ; et la liste est encore longue. Ce qui rend cette fonctionnalité si incroyable, c'est que l'administrateur du système peut établir une liste d'attributs à gérer en fonction de la classification de l'article, du fournisseur, etc. Ces attributs peuvent être des valeurs qui n'ont pas encore de place dans le système, mais ils peuvent aussi varier d'une classe à l'autre.
La plateforme Acumatica XRP contient de nombreux exemples d'écrans et de codes qui peuvent être copiés pour ajouter des attributs à des écrans personnalisés. Mais qu'en est-il si l'objectif est d'afficher les attributs d'un AUTRE écran... à partir d'un objet connexe ? Ne craignez rien. Le processus est assez simple pour un développeur et peut être décomposé en 3 étapes faciles comme je l'illustre ci-dessous.
Pour préparer le terrain, une exigence commerciale a été reçue pour afficher divers onglets de données liées à un article à partir de l'écran Articles en stock, de sorte que l'onglet d'attributs sur l'écran personnalisé se tournera vers InventoryItem pour les attributs. Étant donné que cet écran est destiné à être défini pour la visibilité plutôt que pour la maintenance, veillez à verrouiller l'accès à la maintenance de l'onglet des attributs par le biais de permissions ou d'un code. (Avertissement : ce code 2021 R1 n'a pas été testé pour la maintenance des attributs associés).
Étape 1 - Créer une version personnalisée de CRAttributeList
GIST : https://gist.github.com/BrianMRO/6e442e41e0dcaa748f6efceb8c67aeed
Ce code peut sembler compliqué pour les nouveaux développeurs, mais il ne l'est pas vraiment. La majeure partie du code important consiste à redéfinir SelectDelegate de manière à récupérer l'objet associé et ses attributs. La majeure partie de cette section est due au fait que nous devons copier le constructeur et toutes les méthodes et variables internes et privées de CRAttributeList pour les rendre accessibles, car leur niveau de protection les rend inaccessibles par le biais de l'héritage. Rappelez-vous que, techniquement, l'héritage leur permet d'être hérités, mais cela ne signifie pas qu'ils vous sont accessibles dans votre nouvelle classe.
Si l'on examine de plus près SelectDelegate, l'enregistrement MyDAC en cours est extrait du cache, puis l'enregistrement InventoryItem correspondant, référencé dans MyDAC, est extrait. Le fait de transmettre l'objet InventoryItem (item) à SelectInternal permet au reste de l'attribut de fonctionner normalement, mais en se basant sur l'InventoryItem associé plutôt que sur l'enregistrement MyDAC de l'écran personnalisé.
Étape 2 - Définir la vue Réponses pour l'onglet Attributs
GIST: https://gist.github.com/BrianMRO/4e78a158f7dce459395c6b5710d95a06
Cela reflète l'utilisation de CRAttributeList pour des raisons évidentes. L'attribut personnalisé est basé sur CRAttributeList, et le nom est la seule chose qui change ici par rapport à n'importe quel autre écran.
Étape 3 - Ajouter l'onglet Attributs
GIST : https://gist.github.com/BrianMRO/ae4e7bb280477faa80a54c7b3bce6e46
Ce code .aspx peut être copié à partir de presque n'importe quel écran contenant un onglet d'attributs. Il se réfère simplement à la vue Answers pourremplir la grille standard.
Après avoir compilé, mis à jour le projet de personnalisation avec la nouvelle DLL et publié le projet, le nouvel onglet Attributs devrait afficher les attributs de l'objet associé à partir de l'écran personnalisé.
Bon codage !
