Scripts de gamme pour la sélection de l'étape suivante 
Le système supporte le scripting pour la sélection de l'étape suivante dans la gamme.
Certains points de la gamme peuvent avoir plusieurs étapes suivantes selon la manière dont sont traités les défauts au niveau de votre installation. Ce processus peut varier d'une installation à l'autre, ainsi que dans une même gamme. Le système vous permet cette flexibilité par le biais de la logique de scripting personnalisée. Dès qu'une étape est terminée au niveau d'une opération, la logique personnalisée effectue la sélection d'étape lorsque plusieurs étapes suivantes sont possibles.
Lorsqu'une étape a plusieurs étapes suivantes, il y a plusieurs connecteurs qui partent de l'étape. Chacun des connecteurs (lignes) peut avoir un script de décision qui lui est associé. Ces scripts sont analysés lorsqu'un SFC termine l'étape. Les valeurs de retour de toutes ces étapes suivantes sont utilisées pour déterminer l'étape suivante pour les SFC.
Chaque script est associé aux chemins d'accès entre les étapes. Dans la Gestion des gammes, pour afficher la boîte de dialogue de scripting pour l'étape suivante, affichez le panneau Gamme et double-cliquez sur l'étiquette de la ligne représentant le chemin d'accès à l'étape suivante.
Le graphique suivant représente un exemple de la gamme incluant la logique de reprise :

Dans l'exemple ci-dessus, la gamme inclut un ensemble simple de logique pour déterminer l'étape suivante après l'opération TEST. Lorsqu'un SFC termine l'étape TEST, il peut le faire de quatre manières différentes.
Supposez que l'ingénieur de production a inclus le scripting suivant pour les possibilités d'étape suivante :
Pour l'étape suivante TEST-to-SCRAP, le SFC devra être mis au rebut s'il échoue et qu'il a été retesté un trop grand nombre de fois (3 fois). Par conséquent, la définition d'étape suivante entre TEST et SCRAP pourrait inclure le code de scripting suivant :
if (NC_CODE!=null && LOOP_COUNT>=3) exit(true);
L'étape suivante TEST-to-PMR_ROUTER est définie pour couvrir le cas où le SFC échoue, mais le nombre de boucles est inférieur à 3, comme indiqué dans cet exemple de code source :
if (NC_CODE!=null && LOOP_COUNT<3) exit(true);
L'étape suivante TEST-to-PMR_ASSEMBLE est définie pour traiter le cas spécial où la défaillance (NC) qui est journalisée est MISSING_COMPONENT, pour renvoyer le SFC directement à ASSEMBLE. La logique de script pour cela serait la suivante :
if (NC_CODE =="MISSING_COMPONENT") exit(true);
L'étape suivante TEST-to-PMR_ASSEMBLE est définie dans cet exemple de codage sans scripting. Si aucune des exceptions décrites ci-dessus n'est rencontrée, le SFC peut être transmis à SHIP.
Des exemples supplémentaires de la sélection de l'étape suivante peuvent être :
Le graphique suivant représente une gamme simple qui commence par une opération TEST suivie de l'étape SHIP ou DEBUG :

Notez que l'étape DEBUG retourne toujours à TEST pour un retest.
Le tableau suivant décrit la logique de script associée à l'étape TEST :
Étapes de/à |
Script |
|---|---|
TEST à SHIP (aucune défaillance) |
|
TEST à DEBUG (défaillance) |
|
Aucun script n'est associé aux autres étapes suivantes. Deux scénarios sont possibles avec cette gamme :
Le SFC passe le TEST et poursuit avec SHIP.
Le SFC échoue au TEST et est envoyé à DEBUG. Le SFC est réparé au niveau de DEBUG par l'ajout d'un code NC de réparation. Le SFC est alors renvoyé à TEST. Il passe le TEST et est envoyé à SHIP.
Le graphique suivant représente une gamme qui envoie le SFC défaillant dans deux endroits différents, selon le NC_CODE :

Notez qu'on peut faire la même chose avec l'ID défaillance associé au NC_CODE.
Le tableau suivant décrit la logique de script associée à l'étape suivante TEST :
Étapes de/à |
Script |
|---|---|
TEST à SHIP (aucune défaillance) |
|
TEST à DEBUG (défaillance) |
|
TEST à ASSEMBLE (défaillance au niveau de l'assemblage) |
|
Aucun script n'est associé aux autres étapes suivantes. Les scénarios possibles avec cette gamme sont les suivants :
Le SFC passe le TEST et poursuit avec SHIP.
Le SFC échoue au TEST avec le code de non-conformité MISSING_COMP et est envoyé à ASSEMBLE. Le problème d'assemblage est fixé au SFC et à ASSEMBLE. Le SFC est alors renvoyé à TEST. Il passe le TEST et est envoyé à SHIP.
Le SFC échoue au TEST et est envoyé à DEBUG. Le SFC est réparé au niveau de DEBUG par l'ajout d'un code NC de réparation. Le SFC est alors renvoyé à TEST. Il passe le TEST et est envoyé à SHIP.
Cette gamme utilise la zone personnalisée associée à l'article du SFC pour déterminer où envoyer le SFC lorsqu'il échoue.

La logique de script associée à l'étape suivante TEST est représentée ci-dessous :
Étapes de/à |
Script |
|---|---|
TEST à SHIP (aucune défaillance) |
|
TEST à DEBUG (défaillance) |
// Appelle la propriété personnalisée COST
// Propose le coût par défaut 100 $
// Si l'article a une valeur inférieure à 500 $, passe à DEBUG
|
TEST à MRB (défaillance - valeur élevée) |
// Appelle la propriété personnalisée COST
// Propose le coût par défaut 100 $
// Si l'article a une valeur supérieure à 500 $, passe à Material Review Board (MRB)
|
Les deux scripts les plus longs pour les cas de défaillance montrent comment récupérer des données pour les objets dans le système, y compris les zones de données personnalisées.
Le script pour TEST à MRB est décrit ci-dessous :
S'il n'y a aucune défaillance, le SFC ne doit pas suivre le chemin TEST vers MRB :
if (NC_CODE==null) exit(false);
Cette instruction appelle la propriété personnalisée COST pour l'article à l'aide de la méthode getCustomItemProperty() :
cost=getCustomItemProperty("COST");
L'instruction suivante définit une valeur par défaut pour le coût de l'article si la propriété COST n'est pas définie :
if (cost==null) cost =100;
La dernière instruction inclut la logique permettant de décider s'il faut envoyer le SFC à MRB :
if (cost>=500) exit(true); else exit (false);
La taille du script n'est pas limitée, mais les scripts plus longs sont exécutés plus lentement.