Buscar..


Sintaxis

  • beforeSubmit (type) // Before Submit, 1.0
  • beforeSubmit (scriptContext) // Before Submit, 2.0
  • afterSubmit (type) // After Submit, 1.0
  • afterSubmit (scriptContext) // After Submit, 2.0

Parámetros

Parámetro Detalles
SuiteScript 2.0 -
scriptContext {Object}
scriptContext.newRecord {N/record.Record} Una referencia al registro que se está leyendo de la base de datos. Podemos utilizarlo para modificar los valores de campo en el registro.
scriptContext.oldRecord {N/record.Record} Una referencia de solo lectura al estado anterior del registro. Podemos usarlo para comparar con los nuevos valores.
scriptContext.type {UserEventType} Una enumeración del tipo de acción de escritura que se está realizando
SuiteScript 1.0 -
type {String} El tipo de acción de escritura que se está realizando.

Observaciones

beforeSubmit y después afterSubmit

Estos dos eventos son activados por cualquier operación de escritura de base de datos en un registro. Cada vez que un usuario, una secuencia de comandos, una importación CSV o una solicitud de servicio web intentan escribir un registro en la base de datos, se activan los eventos Enviar.

Registrar acciones que desencadenan ambos eventos Enviar:

  • Crear
  • Editar
  • Borrar
  • XEdit (edición en línea)
  • Aprobar
  • Rechazar
  • Cancelar
  • Paquete
  • Enviar

Registre las acciones que se activan antes de beforeSubmit solo:

  • Marca completa
  • Reasignar (casos de soporte)
  • Editar pronóstico

Registrar acciones que desencadenan después de afterSubmit solo:

  • Dropship
  • Orden especial
  • Encargar artículos
  • Pagar facturas

Casos de uso típicos de beforeSubmit

  • Validar registro antes de que se confirma a la base de datos
  • Controles de permisos y restricciones.
  • Cambios de última hora antes de confirmar la base de datos
  • Obtenga actualizaciones de sistemas externos

Casos de uso típicos para afterSubmit

  • Notificación por correo electrónico de los cambios de registro
  • Redirección del navegador
  • Crear / actualizar registros dependientes
  • Impulsar cambios a sistemas externos.

Eventos de usuario no encadenan

El código escrito en Eventos del usuario no activará ningún evento del Usuario en otros registros. Por ejemplo, la modificación del registro de Cliente asociado de la beforeSubmit de un registro de Orden de venta no activará los eventos de envío del registro de Cliente.

NetSuite hace esto para evitar que los eventos de usuario se activen entre sí en un bucle infinito. Si necesita eventos de usuario para disparar en una secuencia encadenada, tendrán que ser inyectado en los eventos entre otros tipos de script (por ejemplo, RESTlets Suitelets, scripts programados).

Los manejadores de eventos devuelven el void

El tipo de retorno de los controladores de eventos Enviar es void . Cualquier dato devuelto por nuestro controlador de eventos no tiene ningún efecto en el sistema. No necesitamos devolver nada de nuestra función de manejador, ya que no podemos hacer nada con su valor devuelto.

!! PRECAUCIÓN !!

Tenga mucho cuidado al comparar valores entre registros antiguos y nuevos. Los campos vacíos desde el antiguo registro se devuelven como null , mientras que los campos vacíos desde el nuevo registro se devuelven como una cadena vacía. Esto significa que no puede simplemente comparar lo antiguo con lo nuevo, o obtendrá falsos positivos. Cualquier lógica que escriba debe manejar el caso donde uno es null y el otro es una cadena vacía de manera apropiada.

Mínimo: registrar un mensaje

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};

myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(type) {
        nlapiLogExecution("DEBUG", "Before Submit", "action=" + type);
    }

    function afterSubmit(type) {
        nlapiLogExecution("DEBUG", "After Submit", "action=" + type);
    }

    exports.beforeSubmit = beforeSubmit;
    exports.afterSubmit = afterSubmit;
    return exports;
})();

// 2.0
define(["N/log"], function (log) {

    /**
     * User Event 2.0 example showing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(scriptContext) {
        log.debug({
            "title": "Before Submit",
            "details": "action=" + scriptContext.type
        });
    }

    function afterSubmit(scriptContext) {
        log.debug({
            "title": "After Submit",
            "details": "action=" + scriptContext.type
        });
    }

    exports.beforeSubmit = beforeSubmit;
    exports.afterSubmit = afterSubmit;
    return exports;
});

Antes del envío: Valide el registro antes de que se confirme en la base de datos

Para este ejemplo, queremos asegurarnos de que cualquier Empleado que esté marcado como un Recurso de Proyecto también tenga un Costo Laboral adecuado definido.

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};
myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(type) {
        if (!isEmployeeValid(nlapiGetNewRecord())) {
            throw nlapiCreateError("STOIC_ERR_INVALID_DATA", "Employee data is not valid", true);
        }
    }

    function isEmployeeValid(employee) {
        return (!isProjectResource(employee) || hasValidLaborCost(employee));
    }

    function isProjectResource(employee) {
        return (employee.getFieldValue("isjobresource") === "T");
    }

    function hasValidLaborCost(employee) {
        var laborCost = parseFloat(employee.getFieldValue("laborcost"));

        return (Boolean(laborCost) && (laborCost > 0));
    }

    exports.beforeSubmit = beforeSubmit;
    return exports;
})();

// 2.0
define(["N/error"], function (err) {

    var exports = {};

    /**
     * User Event 2.0 example detailing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    function beforeSubmit(scriptContext) {
        if (!isEmployeeValid(scriptContext)) {
            throw err.create({
                "name": "STOIC_ERR_INVALID_DATA",
                "message": "Employee data is not valid",
                "notifyOff": true
            });
        }
    }

    function isEmployeeValid(scriptContext) {
        return (!isProjectResource(scriptContext.newRecord) || hasValidLaborCost(scriptContext.newRecord));
    }

    function isProjectResource(employee) {
        return (employee.getValue({"fieldId" : "isjobresource"}));
    }

    function hasValidLaborCost(employee) {
        var laborCost = employee.getValue({"fieldId" : "laborcost"});

        return (Boolean(laborCost) && (laborCost > 0));
    }

    exports.beforeSubmit = beforeSubmit;
    return exports;
});

Tenga en cuenta que pasamos referencias al nuevo registro en nuestra validación porque no nos importa cuáles fueron los valores que solían ser; solo nos preocupan los valores que están por escribirse en la base de datos. En 2.0, lo hacemos a través de la referencia scriptContext.newRecord , y en 1.0 llamamos a la función global nlapiGetNewRecord .

Cuando los datos que se envían no son válidos, creamos y lanzamos un error. En un evento beforeSubmit , para evitar que los cambios se escriban en la base de datos, su función debe throw una excepción. A menudo, los desarrolladores intentan return false de su función, esperando que sea suficiente, pero eso no es suficiente. Los objetos de error se crean en 2.0 usando el módulo N/error y en 1.0 usando la función global nlapiCreateError ; luego generamos una excepción utilizando nuestro objeto de error creado con la palabra clave throw .

Después del envío: Determine si se cambió un campo

Una vez que el registro se almacena en la base de datos, queremos inspeccionar lo que se cambió en el registro. Haremos esta inspección comparando los valores entre las instancias de registro antiguas y nuevas.

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};
myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function afterSubmit(type) {
        notifySupervisor();
    }

    function notifySupervisor() {
        // Old and New record instances are retrieved from global functions
        var employee = nlapiGetNewRecord();
        var prevEmployee = nlapiGetOldRecord();

        // If Employee Status didn't change, there's nothing to do
        if (!didStatusChange(employee, prevEmployee)) {
            return;
        }

        // Otherwise, continue with business logic...
    }

    function didStatusChange(employee, prevEmployee) {
        var status = employee.getFieldValue("employeestatus");
        var prevStatus = prevEmployee.getFieldValue("employeestatus");

        /* !! Caution !!
         * Empty fields from the Old record come back as `null`
         * Empty fields from the New record come back as an empty String
         * This means  you cannot simply compare the old and new
         */
        return ((prevStatus || status) && (status !== prevStatus));
    }

    exports.afterSubmit = afterSubmit;
    return exports;
})();

// 2.0
define(["N/runtime"], function (runtime) {

    /**
     * User Event 2.0 example detailing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    var exports = {};

    function afterSubmit(scriptContext) {
        notifySupervisor(scriptContext);
    }

    function notifySupervisor(scriptContext) {
        // Old and New records are simply properties on scriptContext
        var employee = scriptContext.newRecord;
        var prevEmployee = scriptContext.oldRecord;

        // If Employee Status didn't change, there's nothing to do
        if (!didStatusChange(employee, prevEmployee)) {
            return;
        }

        // Otherwise, continue with business logic...
    }

    function didStatusChange(employee, prevEmployee) {
        var status = employee.getValue({"fieldId" : "employeestatus"});
        var prevStatus = prevEmployee.getValue({"fieldId" : "employeestatus"});

        /* !! Caution !!
         * Empty fields from the Old record come back as `null`
         * Empty fields from the New record come back as an empty String
         * This means  you cannot simply compare the old and new
         */
        return ((prevStatus || status) && (status !== prevStatus));
    }

    exports.afterSubmit = afterSubmit;
    return exports;
});

Tenga mucho cuidado al comparar valores entre registros antiguos y nuevos. Los campos vacíos desde el antiguo registro se devuelven como null , mientras que los campos vacíos desde el nuevo registro se devuelven como una cadena vacía. Esto significa que no puede simplemente comparar lo antiguo con lo nuevo, o obtendrá falsos positivos. Cualquier lógica que escriba debe manejar el caso donde uno es null y el otro es una cadena vacía de manera apropiada.



Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow