Guide d’intégration de NetSuite à SkyPlanner APS pour l’ordonnancement de la production

Oracle a fixé le cap. À partir de la version 2026.1, il est recommandé de concevoir les nouvelles intégrations avec les services web SuiteTalk REST et OAuth 2.0. À partir de la version 2027.1, aucune nouvelle intégration ne sera possible avec SOAP ou Token-Based Authentication (TBA). Les points de terminaison SOAP seront désactivés dans la version 2028.2. Toute intégration d’ordonnancement lancée aujourd’hui doit donc utiliser REST.

Authentification

Pour un outil d’ordonnancement fonctionnant de serveur à serveur, utilisez OAuth 2.0 Client Credentials (machine-to-machine). Le chemin d’accès dans l’administration est Setup > Integration > Manage Authentication > OAuth 2.0 Client Credentials (M2M) Setup. Vous chargez un certificat public, puis l’associez à une entité, à un rôle et à l’enregistrement d’intégration. Chaque enregistrement d’intégration peut contenir au maximum cinq certificats actifs.

Créez un rôle dédié à l’intégration : accès en lecture aux articles, révisions de nomenclature, gammes de fabrication et postes de charge ; accès en modification aux ordres de fabrication, déclarations de production et sorties de composants. L’API REST de SkyPlanner (référence de l’API) utilise JWT : le middleware conserve donc les deux jeux d’identifiants.

Événements : aucun webhook standard

La documentation d’Oracle ne décrit aucun webhook sortant natif. La solution consiste à utiliser un script SuiteScript User Event sur Work Order (afterSubmit) qui met en file d’attente un appel sortant via N/task ou un script Map/Reduce, puis effectue cet appel avec N/https. N’effectuez jamais d’appel sortant synchrone dans afterSubmit : l’appel s’exécute pendant l’enregistrement effectué par l’utilisateur. Un point de terminaison lent ralentit donc cet enregistrement ou le fait échouer.

Les événements User Event ne couvrent pas toutes les voies de modification. Les mises à jour en masse et les imports CSV peuvent les contourner. Complétez le script événementiel par une interrogation SuiteQL périodique sur lastmodifieddate pour réconcilier les données sans rien manquer. Dans l’autre sens, les webhooks de SkyPlanner déclenchent la réécriture des données : NetSuite reçoit ainsi les nouvelles dates dès que le planning change.

1. Chargement initial des données de base. Avec SuiteQL, lisez d’abord les postes de charge, puis les articles, les révisions de nomenclature et les gammes de fabrication. Les gammes font référence aux postes de charge : l’ordre de chargement compte donc. Pendant l’essai, exportez ces mêmes données au format CSV et importez-les dans SkyPlanner. Le planning est ainsi validé avant d’écrire la moindre ligne de code.

2. Synchronisation des ordres. Récupérez les ordres de fabrication aux statuts Released et In Process. Décidez dès le départ si les ordres au statut Planned doivent aussi être inclus. Si c’est le cas, traitez-les comme une demande provisoire. Synchronisez les commandes d’achat ouvertes dans le même cycle : l’ordonnancement vérifie ainsi chaque opération en tenant compte des stocks et des réceptions de matières à venir, et non des seuls stocks.

3. Réécriture des dates du planning. Quand le planning change, un webhook SkyPlanner transmet les nouvelles dates des opérations au middleware. Celui-ci envoie PATCH /services/rest/record/v1/manufacturingOperationTask/{id} (référence Oracle de l’enregistrement) avec startDate et endDate pour chaque opération modifiée. Un PATCH supplémentaire sur l’en-tête workOrder définit les champs Production Start et End Date. N’écrivez que les dates et, si vous en utilisez un, un champ de séquence personnalisé. Ne réécrivez jamais de quantités ni de données de nomenclature. Pour mettre à jour de nombreuses opérations dans une seule transaction, un petit RESTlet enregistre toute la liste des opérations en un seul appel. L’API d’enregistrements reste la solution par défaut.

4. Déclarations en atelier. Les opérateurs saisissent leur travail dans SkyPlanner Mobile Confirmations. Le middleware transmet chaque déclaration au moyen des transformations de Work Order avec POST /services/rest/record/v1/workOrder/{id}/!transform/workOrderCompletion, en renseignant startOperation, endOperation, la quantité produite et le temps saisi sur les lignes d’opération. Les ordres de fabrication sans gestion des en-cours WIP se terminent quant à eux avec !transform/assemblyBuild. Work Order Completion via REST nécessite la fonctionnalité Manufacturing Work In Process. Les écritures de stock et de coûts restent dans NetSuite.

5. Idempotence et nouvelles tentatives. Chaque déclaration de production utilise l’identifiant du relevé de temps SkyPlanner comme identifiant externe dans NetSuite. Les identifiants externes sont uniques par type d’enregistrement : un webhook rejoué est donc rejeté comme doublon, au lieu de comptabiliser deux fois les quantités et les coûts. Les écritures passent par une file d’attente. Tout appel en échec (limite d’appels simultanés, enregistrement verrouillé, certificat expiré) fait l’objet d’une nouvelle tentative et est journalisé. Les échecs persistants sont visibles par l’équipe SkyPlanner chargée du support de l’intégration.

6. Répartition des responsabilités. NetSuite fait autorité sur ce qui est fabriqué : article, quantité, nomenclature, gamme de fabrication et site. SkyPlanner fait autorité sur le moment et les ressources : séquence des opérations, poste de travail, début et fin. Les dates modifiées dans NetSuite sont écrasées lors de la prochaine réécriture. Verrouillez donc les champs Production Start/End Date en personnalisant le formulaire ou à l’aide d’un workflow.

• Ordres de fabrication sans gamme. Un ordre de fabrication sans Manufacturing Routing ne contient aucune opération à ordonnancer. Oracle le précise aussi pour son propre outil d’ordonnancement de production tenant compte de la capacité réelle des ressources : « Work orders not associated with a NetSuite routing should not be scheduled. » (Les ordres de fabrication qui ne sont pas associés à une gamme NetSuite ne doivent pas être ordonnancés.) Repérez-les avec SuiteQL avant la mise en production.
• Des postes de charge peu détaillés. Dans NetSuite, un poste de charge est un Group comportant deux compteurs, Machine Resources et Labor Resources (tous deux à 0 par défaut), et un Work Calendar, généralement « Default Work Calendar ». Chargez les postes de charge une fois, puis gérez dans SkyPlanner les postes de travail individuels, les horaires par personne, les outils, la matrice des temps de changement et les postes de travail de remplacement.
• Qualité des valeurs Setup Time et Run Rate. L’ordonnancement à capacité infinie de NetSuite utilise ces champs, mais comme il ne tient pas compte de la capacité, les valeurs erronées passent inaperçues. Un ordonnancement de production qui respecte la capacité réelle des ressources les révèle dès le premier jour.
• Avec ou sans WIP. Avec Manufacturing WIP, la production est comptabilisée via Work Order Issue, Work Order Completion et Work Order Close. Sans WIP, c’est un Assembly Build qui est utilisé. L’intégration crée des Work Order Completions pour les articles WIP et des Assembly Builds pour les autres. Le modèle de chaque article fait donc partie des correspondances à définir.
• Advanced Manufacturing sur le même compte. Si le compte utilise aussi l’Advanced Manufacturing SuiteApp, ses enregistrements Manufacturing Work Bench doivent correspondre exactement à la gamme : séquence des opérations, nom de l’opération et poste de charge. Décidez quel système fixe les dates des opérations. Deux outils d’ordonnancement sur les mêmes ordres de fabrication produisent deux plannings concurrents.
• Limites d’appels simultanés. Les appels aux services web et aux RESTlets partagent une même limite d’appels simultanés par compte, définie par le niveau de service et augmentée de 10 par licence SuiteCloud Plus. Des interrogations parallèles, enregistrement par enregistrement, atteignent vite cette limite. Utilisez SuiteQL avec pagination pour les lectures et placez les écritures dans une file d’attente.
• L’actualisation de la sandbox efface la configuration M2M. Les associations OAuth 2.0 Client Credentials sont effacées lors de l’actualisation de la sandbox et ne sont pas copiées entre les comptes. Un certificat expiré ou révoqué interrompt la synchronisation jusqu’à la création d’une nouvelle association. Configurez des alertes en cas d’échec d’authentification.