AcumatiCares
J'ai récemment reçu une nouvelle demande de la part d'un client qui souhaitait une fonctionnalité de notification supplémentaire sur l'écran de commande client. L'entreprise fabrique des articles sur commande pour ses clients. Dans le processus de fabrication, chaque article doit être envoyé à un seul fournisseur pour l'étape de finition. Il est donc important pour eux de s'assurer que le fournisseur est au courant de toutes les commandes clients entrantes et des dates promises afin qu'il puisse planifier en conséquence. Ils voulaient une action qui enverrait un rapport de commande client abrégé à ce fournisseur. Je vais vous expliquer comment j'ai procédé.
Dans les premiers jours de travail avec le framework Acumatica, j'aurais créé quelque chose qui exécute un rapport, récupère un pdf sous forme de tableau d'octets, puis l'attache à un modèle de notification (voir "Exécuter un rapport" et "Appeler un modèle de notification" ). Cependant, l'une de mes principales philosophies en matière de conception consiste désormais à chercher partout dans l'application pour utiliser des fonctionnalités existantes qui font ce que je veux.
Pour commencer, regardons 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 "Email Sales Order" ou "Email Quote".
GIST : https://gist.github.com/lekker-solutions/10db36e695f0944886fb56daf91a1c3e
Si l'on examine le code du graphique SalesOrderEntry, toutes les notifications sont pilotées par une action unique appelée "Notification". L'identifiant de la source de la notification est transmis à la méthode d'action pour appeler les différentes notifications définies. La difficulté réside dans le fait que le corps de la méthode est protégé et qu'il ne suffit donc pas d'appeler cette méthode. Heureusement, le cadre xRP permet d'appeler ces méthodes à partir d'une extension de graphe.
GIST: https://gist.github.com/lekker-solutions/9218985815bc406eba0441e262fce21f
Notez que l'extension du graphe est marquée comme abstraite, et que les attributs PXProtectedAccess sont marqués à la fois sur l'extension du graphe et sur la méthode abstraite. La méthode abstraite correspond exactement à la signature du membre protégé dans le graphe de base. Cela permettra à cette extension de graphe d'appeler la méthode "Notification" de la même manière que les actions "Email Sales Order" et "Email Quote" dans le graphe 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 la tarification supprimée. En outre, j'ai créé un modèle de notification qui doit être appelé. La source de notification "FUTUREPO" (basée sur ma chaîne constante 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 l'on appuie sur le bouton d'action, le rapport est exécuté et le courrier électronique 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. Les notifications de ce type sont une sorte d'intégration "low tech", où les données ne sont pas transmises dans les deux sens par des API, mais plutôt rationalisées d'humain à humain. Leur mise en place est relativement rapide et peut faire une énorme différence dans la visibilité des différents processus d'entreprise.
J'espère que cet exemple vous a aidé à résoudre un problème pour vous-même en tant qu'utilisateur d'Acumatica ou pour votre client. Vous constaterez peut-être qu'il s'agit d'une excellente façon de procéder à une personnalisation simple tout en tirant le meilleur parti possible du code de la plate-forme de base.
Quoi qu'il en soit, j'espère que vous avez trouvé cela utile et, comme toujours, bon codage !
