AcumatiCares
Révision : Nov, 2023
J’ai récemment reçu une nouvelle demande d’un client qui voulait une fonctionnalité de notification supplémentaire sur l’écran de commande client . Ils fabriquent des articles pour leurs clients sur une base faite sur commande. Dans le processus de fabrication, chaque article doit être envoyé à un seul fournisseur pour l’étape de finition. Par conséquent, il est important pour eux de s’assurer que le fournisseur connaît toutes les commandes client entrantes et promettent des dates afin qu’ils puissent planifier en conséquence. Ils voulaient une action qui enverrait un rapport de commande client abrégé à ce fournisseur. Je vais vous dire comment je l’ai fait.
Dans les premiers jours de travail avec le framework Acumatica, j’aurais mis en place quelque chose qui exécute un rapport, obtient un pdf en tant que tableau d’octets, puis le joindre à un modèle de notification (voir « Exécution d’un rapport » et « Appel d’un modèle de notification »). Cependant, maintenant, l’une de mes philosophies de conception centrales est de rechercher haut et bas dans l’application pour utiliser les fonctionnalités existantes qui font ce que je veux.
Pour commencer, examinons comment Acumatica gère des actions similaires (l’utilisateur clique sur une action, un rapport est exécuté et un modèle de notification est appelé), telles que « Commande client par e-mail » ou « Devis par e-mail ».
GIST : https://gist.github.com/lekker-solutions/10db36e695f0944886fb56daf91a1c3e
En regardant le code dans le graphique SalesOrderEntry , toutes les notifications sont pilotées à partir d’une seule action nommée « Notification ». L’ID source de notification est transmis à la méthode d’action pour appeler différentes notifications définies. Ce qui rend cela légèrement délicat, c’est le fait que le corps de la méthode est protégé, il n’est donc pas aussi simple que d’appeler cette méthode. Heureusement, le cadre xRP permet d’appeler ces méthodes à partir d’une extension de graphique.
GIST: https://gist.github.com/lekker-solutions/9218985815bc406eba0441e262fce21f
Notez le fait que l’extension de graphique est marquée comme abstraite et que les attributs PXProtectedAccess sont marqués à la fois sur l’extension de graphique et sur la méthode abstraite. La méthode abstraite correspond exactement à la signature du membre protégé dans le graphique de base. Cela permettra à cette extension de graphique d’appeler la méthode « Notification » de la même manière que les actions « Email Sales Order » et « Email Quote » dans le graphique de base l’appellent.
Ensuite, nous publions ce code et configurons le front-end pour ajouter la source de notification. J’ai créé un rapport FuturePO (SOGP6410) qui est essentiellement le rapport de commande client avec le prix supprimé. De plus, j’ai créé un modèle de notification qui devrait être appelé. La source de notification « FUTUREPO » (basée sur ma chaîne const protégée « NotificationID » dans mon extension graphique) est ajoutée à la fois aux préférences de commande client et à mes classes de clients.
Une fois la configuration frontale terminée, lorsque vous appuyez sur le bouton d’action, le rapport est exécuté et l’e-mail est généré comme prévu.
Les notifications personnalisées semblent être l’une des plus grandes demandes de personnalisation que je reçois de mes clients. De telles notifications sont une sorte d’intégration « low tech », où les données ne sont pas transmises d’avant en arrière via des API, mais plutôt rationalisées d’humain à humain. Ils ne prennent que relativement peu de temps à mettre en place et peuvent faire une énorme différence dans la visibilité des différents processus métier.
J’espère que cet exemple vous a peut-être aidé à résoudre un défi pour vous-même en tant qu’utilisateur d’Acumatica ou pour votre client. Peut-être trouverez-vous que c’est un excellent moyen de faire une personnalisation simple tout en tirant parti du code de la plate-forme de base autant que possible.
En tout cas, j’espère que vous avez trouvé ce codage utile et, comme toujours, heureux!
