Maximo puede aplicar la lógica empresarial de muchas maneras. Cada enfoque tiene algunas ventajas y distintos niveles de habilidades técnicas que implementar. La exigencia de un campo en la pantalla se puede abordar de diferentes maneras.

El primer enfoque para crear campos obligatorios en Maximo es establecer un campo como «obligatorio» mediante Application Designer; esta es una forma sencilla de hacer que un campo específico sea obligatorio el 100% del tiempo en una sola aplicación. Esta es una opción excelente para los usuarios que solo interactúan con una aplicación en Maximo y para los que el campo siempre es obligatorio. El segundo enfoque es útil cuando un usuario quiere añadir lógica condicional al campo «obligatorio»; esto se puede hacer mediante el uso de restricciones de datos. Estas restricciones de datos se pueden implementar a nivel global o de grupo de seguridad. Me parece que las restricciones de datos globales funcionan bien la mayoría de las veces. Este enfoque es más complejo que el cambio del diseñador de aplicaciones porque hay que escribir una cláusula «where». Esta es una solución ideal en mi bolsa de herramientas, ya que son muy versátiles.

Ambos enfoques son excelentes porque pueden mostrar visiblemente un campo como «obligatorio» en la aplicación. Estos enfoques son eficientes en la aplicación y, al mismo tiempo, sencillos de implementar y respaldar. Una desventaja es que cuando se cambia el estado de una orden de trabajo, un campo que no era obligatorio en el estado anterior puede pasar a ser obligatorio en el estado recién actualizado. Por ejemplo, una orden de trabajo con el estado WAPPR pasa al estado APPR, y un campo que no era obligatorio en el estado WAPPR es obligatorio dentro del estado APPR; cuando el usuario vaya a cambiar el estado, recibirá un error genérico indicando que el campo es obligatorio. La otra desventaja es que la lógica condicional solo puede ser tan buena como las habilidades del implementador para escribir una cláusula «dónde».

Los scripts de automatización destacan por ofrecer una lógica compleja con mensajes claros. Agregar una lógica empresarial personalizada al cambio de estado de un registro es un excelente caso de uso para los scripts de automatización. He utilizado este enfoque para cambiar el estado de los activos, las órdenes de trabajo, las solicitudes de servicio, las órdenes de compra y los elementos de configuración. He descubierto que los scripts de automatización me permiten enviar mensajes segmentados con una lógica que puede ser tan compleja como sea necesario. Compartiré algunos ejemplos comunes.

Punto de lanzamiento

La utilización de un punto de inicio basado en atributos permitirá que la lógica se active cada vez que cambie el estado. En el siguiente ejemplo, estoy implementando una validación del estado de cambio de un activo. Si quieres ejecutar la validación con más frecuencia, puedes usar un punto de inicio para guardar objetos.

Mensaje de error

La combinación del script de automatización con un mensaje de Maximo permite enviar mensajes específicos y flexibles al usuario. Para cada script de automatización que implemento, me gusta tener un mensaje correspondiente con un parámetro al que pueda pasar un mensaje. Este mensaje se configura en Configuración de la base de datos, dentro del cuadro de diálogo de mensajes. El «{0}» será el parámetro que pasaremos con un mensaje personalizado.

Una vez que tenga un mensaje en el script de automatización, puede llamar a un error utilizando el mensaje. Tenga en cuenta que los dos primeros parámetros indican el mensaje que se va a utilizar. El tercer parámetro es una matriz que se pasa al mensaje. Cuando se invoca, el «{0}» del mensaje reemplazará a la primera cadena de la matriz. Si agregas un «{1}» a tu mensaje, se asignará al segundo valor de la matriz.

service.error («emx», «AssetStatusValidation», [«La dirección es necesaria para pasar al estado ACTIVO»])

Ejemplos:

Dirección requerida cuando el estado cambia a ACTIVO

si mbo.getString («STATUS») =="ACTIVE» y mbo.isNull («emxAddress»):

service.error («emx», «AssetStatusValidation», [«La dirección es necesaria para pasar al estado ACTIVO»])

Valor requerido para todas las especificaciones de activos cuando el estado cambia a OPERATIVO

si mbo.getString («STATUS») =="OPERANDO»:

mbosetAssetSpec= mbo.getMboSet («$EMXASSETSPECREQUIRED», "ASSETSPEC», "assetnum =:assetnum y siteid=:siteid»)

mboAssetSpec = mboSetAssetSpec.moveFirst ()

mientras que mboAssetSpec:

si mboAssetSpec.isNull («ALNVALUE») y mboAssetSpec.isNull («NUMVALUE») y mboAssetSpec.isNULL («TABLEVALUE»):

service.error («emx», "assetStatusValidation», ["Asset Spec" + mboAssetSpec.getString («ASSETATTRID») + "debe no ser nulo"])

mboAssetSpec = mboSetAssetSpec.moveNext ()

Todas las tareas de WO deben ser COMP para cambiar a COMP

si (mbo.getString («STATUS») == «COMP»):

mbosetTask = mbo.getMboSet («$EMXWOTASK», "WOACTIVITY», "historyflag=0 e istask=0 y status! ="COMP» y parent=:wonum y siteid=:siteid»)

si (no mboSettask.isEmpty ())

service.error («emx»,» woStatusValidation», [«Esta orden de trabajo tiene «+mbosetTask .count () + «órdenes de trabajo secundarias abiertas que deben estar completas para completar esta orden de trabajo»])