ANS-0960 · SERVICES WEB ET INTéGRATIONS

Comment gérer la visibilité des champs SuiteTalk de NetSuite dans les formulaires personnalisés

Apprenez comment vous assurer que les champs sont accessibles via les services Web en ajustant les configurations des formulaires ou en utilisant SuiteScript.

Solution courte

Pour définir des valeurs pour les champs via les services Web SuiteTalk, ceux-ci doivent figurer sur le formulaire NetSuite sélectionné. Si un champ n’est pas visible, spécifiez un autre formulaire personnalisé pour l’appel du service Web, ou utilisez un script d’événement utilisateur SuiteScript 2.x afin d’ajuster dynamiquement le type d’affichage du champ lors de l’événement `beforeLoad` pour les contextes de service Web.

Scénario

Les utilisateurs qui tentent d’interagir avec des enregistrements NetSuite via les services Web SuiteTalk peuvent rencontrer des problèmes lorsqu’ils essaient de définir des valeurs pour des champs qui ne sont ni visibles ni activés dans le formulaire par défaut ou dans le formulaire personnalisé spécifié. Cela se produit souvent avec des champs qui sont généralement masqués ou désactivés dans l’interface utilisateur de NetSuite, mais qui nécessitent d’être modifiés via des intégrations externes.

Solution

Les champs doivent figurer sur le formulaire utilisé par l’appel aux services Web pour permettre la définition des valeurs. Il existe deux approches principales pour y parvenir :

  1. Spécifier un formulaire alternatif : lors d’un appel aux services Web SuiteTalk, spécifiez explicitement un formulaire personnalisé dans lequel le champ requis est présent et visible. Cela garantit que le champ est disponible pour l’interaction.

  2. Utiliser un script d’événement utilisateur : dans les cas où un champ doit être rendu visible ou modifiable de manière dynamique, en particulier dans le cadre des services Web, un script d’événement utilisateur (SuiteScript 2.x) peut être déployé. Ce script modifiera le type d’affichage du champ lors de l’événement beforeLoad.

    Il est important de noter que, bien que les propriétés d’affichage des formulaires puissent être modifiées lors de l’événement beforeLoad pour les enregistrements nouveaux et existants, la manipulation directe des données (définition des valeurs des champs) pour les enregistrements *existants* n’est généralement pas possible dans le contexte de l’événement beforeLoad sous SuiteScript 2.x. Toutefois, rendre un champ visible permet aux opérations suivantes (par exemple, dans beforeSubmit ou afterSubmit, ou par le service Web lui-même) d’interagir avec celui-ci.

    Vous trouverez ci-dessous un exemple de script d’événement utilisateur SuiteScript 2.x qui rend un champ spécifié visible lorsque le contexte d’exécution est webservices :

javascript
/**
 * @NApiVersion 2.x
 * @NScriptType UserEventScript
 */
define(['N/runtime', 'N/ui/serverWidget'], function(runtime, serverWidget) {

    function beforeLoad(context) {
        if (context.type === context.UserEventType.CREATE || context.type === context.UserEventType.EDIT) {
            if (runtime.executionContext === runtime.ContextType.WEBSERVICES) {
                var form = context.form;
                var field = form.getField({ id: 'field_id' }); // Replace 'field_id' with the actual field ID

                if (field) {
                    field.updateDisplayType({
                        displayType: serverWidget.FieldDisplayType.NORMAL
                    });
                }
            }
        }
    }

    return {
        beforeLoad: beforeLoad
    };
});

Dans ce script :

  • Les modules N/runtime et N/ui/serverWidget sont chargés pour la gestion du contexte et du formulaire.
  • La fonction beforeLoad est déclenchée avant le chargement d’un enregistrement.
  • runtime.executionContext === runtime.ContextType.WEBSERVICES vérifie si le script s’exécute à la suite d’un appel de services Web.
  • form.getField({ id: 'field_id' }) récupère l’objet champ.
  • field.updateDisplayType({ displayType: serverWidget.FieldDisplayType.NORMAL }) définit le type d’affichage du champ sur « normal », le rendant ainsi visible et modifiable.
  • La vérification context.type (CREATE ou EDIT) est ajoutée à des fins de robustesse, car beforeLoad peut également se déclencher pour des événements VIEW où les modifications d’affichage pourraient ne pas être pertinentes pour les services Web.

Support expert NetSuite

Besoin d’aide pour cet enjeu NetSuite ?

Accompagnement-conseil et configuration pour Services Web et intégrations

Parler à un consultant