AcumatiCares
Introducción
¿Ha deseado personalizar la pantalla SO Procesar pedidos? Observe que muchas acciones que se encuentran aquí son compartidas en la pantalla de entrada de Pedidos de Ventas. ¿Cómo se relacionan estas acciones entre las dos pantallas? Nuestro objetivo hoy es explorar la relación entre estas pantallas, y cómo estas acciones son invocadas desde la pantalla de procesamiento.
Tramitación de pedidos
En la pantalla Procesar Pedidos(SO501000), encontramos selecciones similares en el desplegable Acción, a las encontradas en la pantalla de entrada de Pedidos de Venta(SO301000). Por ejemplo, las acciones Crear Envío y Cancelar Pedido se encuentran en ambas pantallas. Utilizando la herramienta de consulta de código, podemos abrir el archivo gráfico que alimenta la pantalla de entrada de pedidos de venta - SOOrderEntry.cs. Al inspeccionarlo, observamos miembros como:
- putOnHold
- cancelarPedido
- releaseFromCreditHold
- crearEnvío
Antes de continuar, hay una historia interesante de Acumatica anterior a la versión 2017. En esas versiones, los flujos de trabajo de los ciclos de vida de documentos estándar, como pedidos de venta, pedidos de compra, facturas, etc., se definían mediante flujos de trabajo de automatización. Cada ciclo de vida se definía internamente con un archivo XML feo, que definía estados de documentos y campos, acciones de menú, informes y valores. Acumatica permitía al desarrollador modificar el archivo XML para anular el flujo de trabajo predeterminado. Además, un menú de flujo de trabajo de automatización ayudaba al desarrollador a crear estas alteraciones a través de una pantalla independiente (que todavía existe). Ciertamente facilitó el trabajo, pero no fue de gran ayuda conocer el vínculo entre las acciones de la pantalla de procesamiento y la pantalla de entrada de documentos.
Con el navegador de código, es más fácil aprender cómo se comparten las acciones entre las pantallas.
Al echar un primer vistazo al gráfico SOCreateShipment.cs, observamos varios miembros de la clase
- Vista de datos de pedidos
- Filtro
- Evento RowSelected
- Evento RowUpdated
Pero, ¿te das cuenta de que no hay tipos naturales con nombre para nuestro desplegable de acciones? ¿Deberíamos esperar ver miembros con nombre para cada una de estas acciones en el gráfico?
Recordemos uno de los pilares de la programación orientada a objetos: la encapsulación. Como podemos deducir, no es una buena práctica definir el contenido de cada acción, repetidamente, en ambas pantallas.
Así que al mirar el código del gráfico, observe la vista de datos Órdenes. Esta vista de datos es de tipo PXFilteredProcessing, que hereda de PXProcessingBase. La clase PXProcessing define la PXView, para formar el criterio de selección de nuestros registros. Note que en el constructor personalizado para la vista de datos Records pasa el campo Filter.Owner ID, para agregar el criterio OuterView Where de la vista de datos. Esto se utiliza para ayudar a seleccionar los registros en los que el usuario actual tiene la propiedad del registro de Contacto.
Un patrón de diseño típico para pantallas de procesamiento es definir el delegado de procesamiento en el constructor del gráfico. En nuestro caso, no vemos esto. Más abajo en el código del gráfico, observe el evento RowSelected.
GIST: https://gist.github.com/tocohara/681c603dbe5f3aa059534373a5e66f14
Varias pantallas de procesamiento de Acumatica utilizan el evento Filter RowSelected para invocar un delegado de proceso de datos. Por ejemplo, vemos esto en la pantalla Liberar retenciones(AR510000).
GIST: https://gist.github.com/tocohara/9c879a1e6670adeb921c6296c7fd1bc6
En ese caso, el SetProcessDelegate es más obvio. Pero, ¿qué pasa con nuestra pantalla de procesamiento de pedidos de venta? Volvamos al evento SOProcessFilter RowSelected. SetProcessWorkflowAction es un miembro de PXProcessingBase. Usemos nuestra herramienta reflector para explorar este miembro.
GIST: https://gist.github.com/tocohara/3e92bb85c5cf5a62438b2bfaa19be5a5
Encontramos algunas declaraciones interesantes dentro de este método. En particular, hay algunas variables establecidas en el cuerpo de este método a notar
- screenId
- actionName
Tenemos una forma de saber cual es el Id de la pantalla y el nombre de la acción, el gráfico ProcessOrder, durante el evento RowSelected. Note que el tipo de acción es S0301000$PrepareInvoice (en este caso, elegimos la acción Preparar Factura en la pantalla de procesamiento).
Al investigar más a fondo los detalles del método SetProcessWorkflowAction, notamos una llamada a un método más profundo llamado _SetProcessTargetInternal. Lo que descubrimos es el código que crea variables de pantalla y menú dividiendo la variable Action junto con el carácter $. Esto es importante ya que se utilizan más adelante en el método, para invocar la automatización del flujo de trabajo, específicamente por pantalla y acción ID.
GIST: https://gist.github.com/tocohara/e74897a1c42ff9c630946f4eb9efb0e4
El código es bastante más profundo que este método, pero al final se establece el vínculo entre la pantalla SO301000 y el gráfico SOOrderEntry en el gráfico. Posteriormente se invoca la acción en un lote.
Si tiene curiosidad por conocer el almacenamiento de esta relación, consulte la tabla AUDefinitionDetail:
Resumen
En este post, hemos explorado los gráficos de la pantalla Procesar Pedidos. Investigamos el miembro Acciones. Mediante el uso de una herramienta de reflector, descubrimos el ID de la pantalla y el nombre de la Acción se intercepta profundamente en los miembros de la clase PXProcessBase, con el fin de invocar las acciones en la pantalla de entrada de pedidos de venta.
Espero que le haya resultado útil y, por supuesto, ¡feliz codificación!
