Mais si voulez afficher les informations du client de la ligne, il faut :
Si c'est bien BPRNUM sur la ligne.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Read [F:BPR]BPR3=[M:CSE]BPRNUM(I_)
Mais si voulez afficher les informations du client de la ligne, il faut :
Si c'est bien BPRNUM sur la ligne.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Read [F:BPR]BPR3=[M:CSE]BPRNUM(I_)
L'index BPR3 est un index que j'ai rajouté pour la recherche par numéro SIRET, ce n'est donc pas par numéro client que je veux rechercher, les champs standards font déjà ça très bien...
J'ai également créé un index BPR4 pour la recherche sur code NAF.
Aussi, toujours le même souci d'affichage (besoin d'un clic dans le tableau pour afficher les codes NAF et n° SIRET) car vous m'aviez parlé d'utiliser nolign pour régler ce problème et il n'est utilisé nul part dans votre "correction".
Oui pardon, il faut changer l'index aussi.
On peut remplacer I_ par nolign, mais ça ne changera rien, j'avais lu un peu vite le code initial.
Votre souci vient de l'action APRES_MODIF, il faut utiliser une autre action. Tout dépend du modèle (cf l'action dans le dictionnaire des actions) : quel est-il ?
Le modèle est "Traitement standard".
Merci de prendre le temps de m'aider parce que sur ce type de devs où il n'y a pas de spé déjà fait duquel je peux m'inspirer, j'ai un peu de mal.
Il faudrait mieux utiliser l'action EXEC, peut-être après le standard (si c'est cette action qui remplit le tableau) via :
en début d'action.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 Gosub ACTION from SUBxxx GPE=1
J'ai essayé ça, mais déjà l'action $EXEC ne s'exécute qu'une fois que j'appuie sur le bouton Fin...
J'ai trouvé des traitements (un peu compliqué par contre) en tapant *CUSSEA* et en tabulant dans le dictionnaire des traitements (W0CUSSEA, etc...) donc je vais voir de ce côté là si ça peut me donner des idées.
Edit : J'ai l'impression que ces traitements là sont générés à partir du traitement spé et/ou standard...
Bon alors je me suis renseigné, et visiblement ce que je cherche à faire n'est pas possible de cette manière.
Je m'explique :
Il existe un point d'entrée via la liste de patch 26 afin d'autoriser l'ajout de champs dans les critères de recherche et/ou pour modifier la requête.
Cependant, nous sommes à la liste de patch 22, donc impossible pour moi de faire cela.
Merci pour votre aide tout de même.
Je viens de tester cet écran que je n'avais jamais utilisé auparavant.
Il n'y a pas de bouton de recherche, la recherche est déclenchée après la modification d'un champ (cas assez rare dans X3). Je comprends mieux pourquoi vous utilisez APRES_MODIF...
Le plus simple est donc de se servir des actions d'avant zone, une sur chaque colonne ajoutée. Le code est quasiment le même, il n'y a plus de boucle bien sûr. Et là il faut utiliser "nolign-1".
J'ai essayé les avant_zone sur les colonnes à tout hasard mais malgré tout cela ne fonctionne pas :
Comme je l'indiquais sur mon précédent post, il est impossible de modifier cet écran en rajoutant de nouveaux critères de recherche autrement que par point d'entrée, ajouté au patch 26, et notre X3 est au patch 22.
Pour information, le point d'entrée pour les critères est SEACAT et celui pour modifier la requête est SQLREQ.
Merci pour votre aide précieuse.
Je viens de tester, ça fonctionne parfaitement (je suis en V9, mais je ne pense pas que ça joue à ce niveau).
Champ ZTEST juste après le code client, action d'avant zone qui affiche la catégorie :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13 Subprog AV_ZTEST(VALEUR) Variable Char VALEUR() local file bpcustomer [zbpc] read [f:zbpc]bpc0=[m:cse]dbprnum(nolign-1) if !fstat valeur=[f:zbpc]BCGCOD endif close local file [zbpc] End
Je ne suis pas sûr que vous ayez compris mon problème donc je vais essayer de le reformuler.
Dans cet écran, vous avez des champs liste en haut, qui sont les critères de recherche. Ils conditionnent les résultats affichés dans le tableau juste en dessous.
Ce que je cherche à faire est d'ajouter des critères de recherche en champs liste afin de sortir en résultat dans le tableau les clients ayant tel SIRET ou tel NAF, d'où les nouveaux index que j'ai créé (un sur le SIRET et un sur le code NAF).
L'affichage de ces deux données (SIRET et NAF) dans le tableau des résultats n'est au final que secondaire mais fait quand même partie de la demande.
Et j'ai bien eu confirmation de notre intégrateur que précisément ceci n'était pas possible dans la liste de patch actuelle de notre X3.
À moins que j'ai raté quelque chose ou que je n'ai pas du tout compris votre raisonnement, je pense que vous ne m'avez pas compris dès le début.
A partir du post 12, j'avais compris qu'il ne restait qu'un problème d'affichage dans le tableau
Aha oui à ce moment là je pensais que ça fonctionnait bien, mais je n'avais pas bien testé avec des cas de figure particuliers.
En fait j'ai compris plus tard qu'il fait la recherche si je lis le numéro de SIRET/NAF via les index que j'ai créé ET que j'effectue un transclasse du code client associé dans le champ liste [M:CSE]BPRNUM...
Donc en gros, si je ne renseigne pas le code client associé au SIRET/NAF dans le champ [M:CSE]BPRNUM, il n'effectue aucune recherche, ce qui rend la chose difficile en cas de client ayant commandé chez plusieurs sociétés du groupe, donc apparaissant plusieurs fois dans la base client, avec le même SIRET/NAF...
Toutes mes excuses si je n'ai pas été assez clair.
Partager