AcumatiCares
L’une des grandes caractéristiques de la plate-forme Acumatica XRP est qu’elle élimine le besoin de beaucoup de codage personnalisé via des attributs. Par exemple, l’écran Articles stock fournit des attributs en fonction de la classe d’article de l’article; l’écran Fournisseur fournit des attributs basés sur la classe de fournisseur ; et la liste s’allonge encore et encore. Ce qui rend cette fonctionnalité si incroyable, c’est que l’administrateur système peut configurer une liste d’attributs à maintenir en fonction de la classification de l’article, du fournisseur, etc. Bien que ces attributs puissent être des valeurs qui n’ont pas encore d’espace réservé dans le système, ils peuvent également varier d’une classe à l’autre.
La plate-forme Acumatica XRP contient de nombreux exemples d’écrans et de codes qui peuvent être copiés pour ajouter des attributs aux écrans personnalisés. Cependant, que se passe-t-il si l’objectif est d’afficher les attributs d’UN AUTRE écran... d’un objet connexe? N’ayez pas peur. Le processus est assez facile 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és à un élément à partir de l’écran Article stock , de sorte que l’onglet d’attribut sur l’écran personnalisé se tournera vers InventoryItem pour les attributs. Étant donné que cela est destiné à être défini pour la visibilité plutôt que pour la maintenance, veillez à verrouiller l’accès pour maintenir l’onglet attributs via des autorisations ou du code. (Avertissement: Ce code R1 2021 n’a pas été testé pour maintenir les attributs associés!)
Étape 1 – Créez une version personnalisée de CRAttributeList
GIST : https://gist.github.com/BrianMRO/6e442e41e0dcaa748f6efceb8c67aeed
Ce code peut sembler compliqué pour les nouveaux développeurs, mais ce n’est vraiment pas le cas. La plupart du code important consiste à redéfinir SelectDelegate afin que nous récupérions l’objet associé et récupérions ses attributs. La majeure partie de cette section est parce que nous devons copier le constructeur et toutes les méthodes et variables internes et privées de CRAttributeList pour les rendre accessibles puisque leur niveau de protection les rend inaccessibles par héritage. N’oubliez pas 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.
En examinant de plus près SelectDelegate, l’enregistrement MyDAC actuel est récupéré à partir du cache, puis l’enregistrement InventoryItem référencé dans MyDAC est récupéré. La transmission de l’objet InventoryItem (item) dans SelectInternal permettra au reste de l’attribut de fonctionner normalement, mais en fonction de l’InventoryItem associé plutôt que de l’enregistrement MyDAC de l’écran personnalisé.
Étape 2 - Définissez 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 essentiellement la seule chose qui change ici à partir de n’importe quel autre écran.
Étape 3 - Ajoutez 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 attributs . Il regarde simplement la vue Réponses to remplir la grille standard.
Après la compilation, la mise à jour du projet de personnalisation avec la nouvelle DLL et la publication du projet, le nouvel onglet Attributs doit afficher les attributs de l’objet associé à partir de l’écran personnalisé.
Bon codage!
