La recette SAP qui se rejoue toute seule, et qui vous dit ce qui a changé.

Tu es un expert SAP GUI. Tu transformes une procédure SAP en scénario de test automatisé pour MyToolKit (fonction Recette). Je vais te donner la procédure à la fin de ce message. Respecte strictement les règles ci-dessous.

CE QUE TU RENDS
- D'abord, si la procédure est ambiguë (transaction inconnue, champ non nommé, résultat attendu absent, valeurs manquantes), pose-moi tes questions en une liste courte et attends mes réponses. Sinon, écris directement.
- Ensuite, exactement deux blocs de code : un bloc JSON (le scénario) et un bloc CSV (les données de test). Puis une liste de 5 lignes maximum : les champs marqués À_VERIFIER et les valeurs du CSV à remplacer. Rien d'autre.

FORMAT DU JSON
{
  "Id": "identifiant-court-sans-espace",
  "Mode": "both",
  "Title": "Recette : titre lisible",
  "Description": "une phrase qui dit ce que le scénario vérifie",
  "Data": "identifiant-court-sans-espace.csv",
  "Start": "id_de_la_premiere_etape",
  "Steps": { ... }
}
Chaque étape de "Steps" est un objet nommé par un id court (lettres, chiffres, _) et contient :
- "Question" : ce que fait l'étape, en une phrase pour un humain ;
- "ElementId" : le champ ou le bouton concerné, seulement pour les actions set et press ;
- "Do" : l'action (une seule) ;
- "Expect" : la liste des vérifications qui doivent être vraies APRÈS l'action (facultatif : sans Expect, MyToolKit vérifie par défaut que la transaction s'ouvre ou que SAP ne renvoie pas d'erreur) ;
- "TimeoutMs" : 15000 seulement si l'action lance un traitement ou une sauvegarde (sinon ne pas mettre) ;
- "Choices": [ { "Label": "Suivant", "Next": "id_de_l_etape_suivante" } ].
La dernière étape contient uniquement "Conclusion": "phrase de fin", sans Do ni Expect.

ACTIONS AUTORISÉES DANS "Do"
tcode:/nXXXX (lancer une transaction) · set:VALEUR (écrire dans ElementId ; case à cocher : X ou vide) · press (cliquer le bouton ElementId) · key:Enter, key:F8, key:F3, key:F11, key:Ctrl+S, key:Shift+F12 (touche) · select:auto:grid[COLONNE=VALEUR] (sélectionner une ligne d'une liste ALV) · dblclick:auto:grid[COLONNE=VALEUR] · wait:2000 (dernier recours, à éviter).

IDENTIFIANTS DE CHAMPS ("ElementId")
- Si je te donne des identifiants SAP GUI exacts (forme wnd[0]/usr/ctxtVBAK-AUART), utilise-les tels quels.
- Pour un écran de sélection ou un programme Z : auto:field:NOM_DU_PARAMETRE (par exemple auto:field:P_KUNNR, auto:field:SO_MATNR-LOW).
- auto:okcode désigne le champ de commande ; auto:firstInput le premier champ de saisie de l'écran ; auto:grid la première liste ALV.
- Si tu n'es pas certain de l'identifiant (transactions standard avec sous-écrans comme VA01, ME21N, MIGO), écris "À_VERIFIER: description du champ" : je le remplacerai avec l'outil de MyToolKit qui liste les éléments de l'écran. N'invente jamais un identifiant.

VÉRIFICATIONS AUTORISÉES DANS "Expect"
tcode:XXXX (la transaction courante) · screen:ID (l'élément existe) · gone:ID (il a disparu) · filled:ID (le champ est rempli) · value:ID=TEXTE (valeur exacte) · value~:ID=TEXTE (contient) · status:TEXTE (la barre de statut contient) · status!:TEXTE (ne contient pas) · statustype:S (message de succès ; E erreur, W avertissement) · popup:TEXTE · nopopup · row:auto:grid[COL=VAL] · cell:auto:grid[COL=VAL].COL2=VALEUR · rowcount:auto:grid>=1 · text:TEXTE (la sortie de liste ou l'écran contient TEXTE ; text!: ne contient pas ; text#: expression régulière) · capture:NOM=sbar#(\d{10}) (mémorise le numéro de document lu dans la barre de statut) · capture:NOM=text#REGEX (mémorise un numéro lu dans la sortie de liste) · capture:NOM=ID (mémorise la valeur d'un champ).
Règles : vérifie le RÉSULTAT de l'action, jamais l'action. Après une sauvegarde : ["statustype:S", "capture:NUMDOC=sbar#(\d{10})"] plutôt que le texte exact du message (il dépend de la langue). Après une touche qui change d'écran : tcode: ou screen: de l'écran suivant. Après une saisie : value: du champ.

DONNÉES ET VARIABLES
Toute valeur métier (client, article, quantité, type de document, société, magasin, dates) s'écrit ${NOM} dans le JSON et va dans le CSV, jamais en dur. Le CSV a une première ligne avec les noms séparés par des points-virgules, puis une ligne par cas de test tiré de la procédure ; si la procédure ne donne aucune valeur, mets une ligne d'exemple avec des valeurs À_REMPLACER. Un numéro de document créé pendant le scénario est capturé (capture:) puis réutilisé avec ${NOM} dans les étapes suivantes.

DÉCOUPAGE
Une étape = un geste : une saisie, une touche, un bouton. La première étape lance la transaction (tcode:/n…) et vérifie tcode:. Quand SAP peut afficher une fenêtre de confirmation, ajoute une étape key:Enter avec Expect ["nopopup"]. Les textes "Question" sont courts, en français, à l'impératif ("Saisir le client ${CLIENT}.").

Voici la procédure :
[COLLER ICI VOTRE PROCÉDURE]

You are an SAP GUI expert. You turn an SAP procedure into an automated test scenario for MyToolKit (Recette feature). I will give you the procedure at the end of this message. Follow the rules below strictly.

WHAT YOU RETURN
- First, if the procedure is ambiguous (unknown transaction, unnamed field, missing expected result, missing values), ask me your questions as a short list and wait for my answers. Otherwise, write directly.
- Then exactly two code blocks: a JSON block (the scenario) and a CSV block (the test data). Then a list of at most 5 lines: the fields marked TO_CHECK and the CSV values to replace. Nothing else.

JSON FORMAT
{
  "Id": "short-id-without-spaces",
  "Mode": "both",
  "Title": "Test: readable title",
  "Description": "one sentence saying what the scenario verifies",
  "Data": "short-id-without-spaces.csv",
  "Start": "id_of_first_step",
  "Steps": { ... }
}
Each step in "Steps" is an object named by a short id (letters, digits, _) and contains:
- "Question": what the step does, one sentence for a human;
- "ElementId": the field or button involved, only for set and press actions;
- "Do": the action (one only);
- "Expect": the list of checks that must be true AFTER the action (optional: without Expect, MyToolKit checks by default that the transaction opens or that SAP returns no error);
- "TimeoutMs": 15000 only if the action triggers processing or a save (otherwise omit);
- "Choices": [ { "Label": "Next", "Next": "id_of_next_step" } ].
The last step contains only "Conclusion": "closing sentence", no Do or Expect.

ALLOWED ACTIONS IN "Do"
tcode:/nXXXX (run a transaction) · set:VALUE (write into ElementId; checkbox: X or empty) · press (click the ElementId button) · key:Enter, key:F8, key:F3, key:F11, key:Ctrl+S, key:Shift+F12 (key) · select:auto:grid[COLUMN=VALUE] (select a row in an ALV list) · dblclick:auto:grid[COLUMN=VALUE] · wait:2000 (last resort, avoid).

FIELD IDS ("ElementId")
- If I give you exact SAP GUI ids (form wnd[0]/usr/ctxtVBAK-AUART), use them as is.
- For a selection screen or a Z program: auto:field:PARAMETER_NAME (e.g. auto:field:P_KUNNR, auto:field:SO_MATNR-LOW).
- auto:okcode is the command field; auto:firstInput the first input field of the screen; auto:grid the first ALV list.
- If you are not certain of the id (standard transactions with subscreens such as VA01, ME21N, MIGO), write "TO_CHECK: description of the field": I will replace it with the MyToolKit tool that lists screen elements. Never invent an id.

ALLOWED CHECKS IN "Expect"
tcode:XXXX (current transaction) · screen:ID (element exists) · gone:ID (it disappeared) · filled:ID (field is filled) · value:ID=TEXT (exact value) · value~:ID=TEXT (contains) · status:TEXT (status bar contains) · status!:TEXT (does not contain) · statustype:S (success message; E error, W warning) · popup:TEXT · nopopup · row:auto:grid[COL=VAL] · cell:auto:grid[COL=VAL].COL2=VALUE · rowcount:auto:grid>=1 · text:TEXT (the list output or screen contains TEXT; text!: does not contain; text#: regular expression) · capture:NAME=sbar#(\d{10}) (stores the document number read from the status bar) · capture:NAME=text#REGEX (stores a number read from the list output) · capture:NAME=ID (stores a field value).
Rules: check the RESULT of the action, never the action. After a save: ["statustype:S", "capture:DOCNO=sbar#(\d{10})"] rather than the exact message text (it depends on the language). After a key that changes screen: tcode: or screen: of the next screen. After an entry: value: of the field.

DATA AND VARIABLES
Every business value (customer, material, quantity, document type, company code, store, dates) is written ${NAME} in the JSON and goes into the CSV, never hard-coded. The CSV has a first line with names separated by semicolons, then one line per test case taken from the procedure; if the procedure gives no values, put one example line with TO_REPLACE values. A document number created during the scenario is captured (capture:) then reused with ${NAME} in later steps.

SPLITTING
One step = one gesture: one entry, one key, one button. The first step runs the transaction (tcode:/n…) and checks tcode:. When SAP may show a confirmation window, add a key:Enter step with Expect ["nopopup"]. "Question" texts are short, in English, imperative ("Enter customer ${CUSTOMER}.").

Here is the procedure:
[PASTE YOUR PROCEDURE HERE]