Explorando las funciones de procesamiento de pedidos de venta – Un análisis más profundo

Introducción

¿Ha querido personalizar la pantalla de procesamiento de pedidos SO? Observe que muchas acciones que se encuentran aquí se comparten en la pantalla de entrada de pedidos de venta. ¿Cómo se vinculan estas acciones entre las dos pantallas? Nuestro objetivo hoy es explorar la relación entre estas pantallas y cómo se invocan estas acciones desde la pantalla de procesamiento.

Procesamiento de Pedidos

En la pantalla Procesar Pedidos (SO501000), encontramos selecciones similares en el menú desplegable Acción, como las que se encuentran 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 impulsa la pantalla de entrada de pedidos de venta – SOOrderEntry.cs. Tras la inspección, observamos miembros como:

• ponerEnEspera
• cancelarPedido
• liberarDeRetenciónDeCrédito
• crearEnvío

Antes de continuar, existe una interesante historia 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 utilizando flujos de trabajo de automatización. Cada ciclo de vida se definía internamente con un archivo XML poco estético, que especificaba los estados de los documentos y campos, las acciones del menú, los informes y los 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 modificaciones a través de una pantalla separada (que aún existe). Esto ciertamente facilitó el trabajo, pero no fue de gran ayuda para comprender 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 observar por primera vez el gráfico SOCreateShipment.cs, notamos varios miembros de la clase

• Vista de datos de pedidos
• Filtro
• Evento RowSelected
• Evento RowUpdated

¿Pero notamos que no hay tipos con nombres naturales para nuestro menú desplegable de acciones? ¿Deberíamos esperar ver miembros con nombres 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 inferir, no es una buena práctica definir el contenido de cada acción, repetidamente, en ambas pantallas.

Así, al observar el código del gráfico, notamos la vista de datos Orders. Esta vista de datos es de tipo PXFilteredProcessing, que hereda de PXProcessingBase. La clase PXProcessing define la PXView para formar los criterios de selección de nuestros registros. Observe que en el constructor personalizado para la vista de datos Records se pasa el campo ID Filter.Owner, con el fin de añadir los criterios Where de OuterView de la vista de datos. Esto se utiliza para ayudar a seleccionar registros en los que el usuario actual es propietario del registro de Contacto.

Un patrón de diseño típico para las pantallas de procesamiento es definir el delegado de procesamiento en el constructor del gráfico. En nuestro caso, no vemos esto. Más adelante 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 Retención (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 de 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 configuradas en el cuerpo de este método que debemos observar

• screenId
• actionName

Tenemos una forma de saber cuál es el screenId y el actionName, el gráfico ProcessOrder, durante el evento RowSelected. Observe que el tipo de acción es S0301000$PrepareInvoice (en este caso, elegimos la acción Prepare Invoice en la pantalla de procesamiento).

Tras una investigación más profunda de 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 ID de pantalla y acción.

GIST: https://gist.github.com/tocohara/e74897a1c42ff9c630946f4eb9efb0e4

El código va mucho más allá de este método, pero finalmente, el vínculo entre la pantalla SO301000 y el gráfico SOOrderEntry se establece en el gráfico. Posteriormente, la acción se invoca en un lote.

Si tiene curiosidad sobre el almacenamiento de esta relación, consulte la tabla AUDefinitionDetail:

Resumen

En esta publicación, hemos explorado los gráficos para la pantalla de Procesar Pedidos. Investigamos el miembro Acciones. Utilizando una herramienta de reflector, descubrimos que el ID de la pantalla y el nombre de la Acción se interceptan en lo profundo de los miembros de la clase PXProcessBase, para invocar las acciones en la pantalla de entrada de pedidos de venta.

Espero que esto le haya sido útil y, como siempre, ¡Feliz codificación!