Posibles motivos y soluciones:
1. En el código de activación, no hay ningun objeto llamado conjunto de cambios para activar un trigger impulsado por eventos después de un pedido necesario o cambio de ficha del cliente
Diagnóstico:
Analizamos la condición de filtro y disparo para la presencia de un código para acceder al historial de pedidos, que se realiza mediante el objeto conjunto de cambios [conjunto de cambios]. Puede parecer diferente, pero el código siempre contendrá la palabra conjunto de cambios, por ejemplo:
conjunto de cambios.hasChangedField("status") and conjunto de cambios.newValue("status").code == "did-not-get-through"O así:
conjunto de cambios | contains ( c =>c.fieldName == 'order_product.status' and c.newValue.code == 'rechazado' and c.oldValue.code == 'new')En ausencia de este código, resulta obvio que el trigger no tenía una condición específica después del cambio necesario y se activaba cada vez que se cambiaba el pedido o la tarjeta del cliente, respetando las condiciones especificadas en el código de trigger .
Es importante comprender la diferencia entre verificación:
conjunto de cambios.hasChangedField("delivery_type") and conjunto de cambios.newValue("delivery_type").code == "Seur"desde
order.deliveryType.сode == "seur"En el primer caso, el trigger se ejecutara solo cuando el tipo de envío se cambie a Seur. En el segundo caso, el trigger se activará en el momento en que el tipo de entrega se cambie a "Seur" y con cada cambio posterior del pedido hasta que se seleccione un tipo de entrega que no sea "Seur".
Decisión:
Genere y agregue un código para acceder al conjunto de cambios (conjunto de cambios)
comprobando cambios en el campo requerido.
2. La condición en la que se activa el trigger se cumple al cambiar el pedido o la tarjeta del cliente varias veces
Si, por alguna razón, en su proceso comercial, se permiten momentos de cambios de pedidos repetidos para aquellos cambios que son activados por el trigger, entonces es posible limitar deliberadamente el trigger usando funciones adicionales del lenguaje de expresión.
Diagnóstico:
Analizar el código de activación, sabiendo qué campo se activa para cambiar, esto se puede hacer analizando la expresión para acceder al conjunto de cambios, por ejemplo: conjunto de cambios.hasChangedField("status") and conjunto de cambios.newValue("status").code == "did-not-get-through" - este código se activa al cambiar el campo con el código de estado, que indica un cambio en el estado de pedido, esto La información se puede encontrar en la referencia del objeto buscando el código de campo encontrado.
Vayamos a la fecha de pedido, en la que el trigger se ejecuto dos veces y analicemos el historial de cambios de pedido para detectar la presencia de varios cambios de estado de pedido en el estado especificado en la condición del trigger.
Decisión:
Agregue la función last_run() a la condición de activación, que verifica la última ejecución de activación con los parámetros pasados a la función. El primer parámetro de la función puede pasar el intervalo de tiempo para el que se debe realizar la verificación en el formato: "1 day", "3 month", "5 years", etc. El segundo parámetro de la función se puede utilizar para transferir el código simbólico del trigger, que debe ser verificado, en el formato: "some-code". El tercer parámetro de la función se puede pasar a una de las dos entidades disponibles: pedido - pedido y cliente - cliente.
La función generada que debe agregarse al trigger se verá así: not last_run("5 days"), respectivamente, el código de activación final con la restricción de reactivación, si el estado del pedido al que responde el trigger dentro de los 5 días desde el momento del primer cambio de estado del pedido, no volvió a cambiar, :
conjunto de cambios.hasChangedField("status") and conjunto de cambios.newValue("status").code == "did-not-get-through" and not last_run("5 days")