AcumatiCares
Recientemente recibí una nueva solicitud de un cliente que quería una funcionalidad de notificación adicional en la pantalla de pedidos de venta. Fabrican artículos para sus clientes por encargo. En el proceso de fabricación, cada artículo debe enviarse a un único proveedor para el paso de acabado. Por lo tanto, es importante para ellos asegurarse de que el proveedor conoce todos los pedidos de ventas entrantes y las fechas prometidas para que puedan planificar en consecuencia. Querían una acción que enviara un informe abreviado de la orden de venta a ese proveedor. Voy a compartir con ustedes cómo lo hice.
En los primeros días de trabajo con el framework de Acumatica, habría montado algo que ejecutara un informe, obtuviera un pdf como matriz de bytes y luego lo adjuntara a una plantilla de notificación (véase 'Ejecutar un informe' y 'Llamar a una plantilla de notificación' ). Sin embargo, ahora una de mis filosofías centrales de diseño es buscar por todas partes en la aplicación para utilizar la funcionalidad existente que hace lo que yo quiero.
Para empezar, veamos cómo Acumatica gestiona acciones similares (el usuario hace clic en una acción, se ejecuta un informe y se llama a una plantilla de notificación), como "Enviar pedido de ventas por correo electrónico" o "Enviar presupuesto por correo electrónico".
GIST: https://gist.github.com/lekker-solutions/10db36e695f0944886fb56daf91a1c3e
Si se observa el código del gráfico SalesOrderEntry, todas las notificaciones se generan a partir de una única acción denominada "Notificación". El ID de la fuente de notificación se pasa al método de acción para llamar a las diferentes notificaciones definidas. Lo que hace que esto sea un poco complicado es el hecho de que el cuerpo del método está protegido, por lo que no es tan simple como llamar a este método. Por suerte, el framework xRP permite llamar a estos métodos desde una extensión del grafo.
GIST: https://gist.github.com/lekker-solutions/9218985815bc406eba0441e262fce21f
Observa el hecho de que la extensión del grafo está marcada como abstracta, y los atributos PXProtectedAccess están etiquetados tanto en la extensión del grafo como en el método abstracto. El método abstracto coincide exactamente con la firma del miembro protegido en el grafo base. Esto permitirá a esta extensión del grafo llamar al método 'Notification' de la misma forma que lo hacen las acciones "Email Sales Order" y "Email Quote" en el grafo base.
A continuación, publicamos este código y configuramos el front-end para añadir la fuente de notificación. He creado un informe FuturePO(SOGP6410) que es esencialmente el informe de pedidos de venta con los precios eliminados. Además, he creado una plantilla de notificación que debe ser llamada. La fuente de notificación "FUTUREPO" (basada en mi cadena const protegida 'NotificationID' en mi extensión gráfica) se añade tanto a Preferencias de Pedido de Venta como a mis clases de cliente.
Después de completar la configuración del front-end, cuando se pulsa el botón de acción, el informe se ejecuta y el correo electrónico se genera como se esperaba.
Las notificaciones personalizadas parecen ser una de las mayores peticiones de personalización que recibo de mis clientes. Las notificaciones de este tipo son un tipo de integración de "baja tecnología", en la que los datos no se transmiten de un lado a otro a través de API, sino que se transmiten de persona a persona. Tardan relativamente poco en configurarse y pueden suponer una gran diferencia en la visibilidad de los distintos procesos empresariales.
Espero que este ejemplo le haya ayudado quizás a resolver un reto para usted como usuario de Acumatica o para su cliente. Tal vez descubras que esta es una gran manera de hacer una personalización sencilla aprovechando al máximo el código de la plataforma base.
En cualquier caso, espero que te haya resultado útil y, como siempre, ¡feliz programación!
