Soit un fichier TIERS
contenant entre autres les champs "tiers facturé" et "tiers payeur"

si on veut voir figurer sur la fiche client les raisons sociales de ces deux
TIERS différents du tiers de base....

l'instruction FichierVersEcran() met un peu le bazar .....et pour cause (relecture du même fichier mais de 2 autres enregistrements... l'enregistrement courant est changé ... )


et le parcours du fichier est bien compromis...

Une solution consiste à ne pas renseigner les liaisons de ces 2 champs (qui
devrait pointer AUSSI sur le fichier TIERS ) et à la gérer par code à part.

Voyer vous d'autres solutions ?

Merci d'avance

Louis

Bonjour,

Afin de préserver le contexte d'un fichier avant d'effectuer une seconde recherche, vous pouvez utiliser la syntaxte:

= HSauvePosition()
//Effectuer vos recherches ici
HRetourPosition()
On restaure le contexte pointeurs et clés

sinon vous pouvez utiliser des requêtes pour récupérer les tiers facturés et tiers payeurs

merci pour votre contribution mais...
Je n'ai jamais parlé de : seconde recherche !!!


Je ne parle que d'une fenêtre de type fiche affichant le fichier TIERS (ou client si on veut)

je précise et simplifie:

une fenêtre avec les champs:

"code client" (saisi)
"Raison sociale" (saisi)
...
...
"code client PAYEUR" (saisi)
(car ce n'est pas jourjours le client qui passe la commande, qui paye)

et,

"Raison sociale de du client PAYEUR" (champ lié par la clef "code client PAYEUR" vers le MEME fichier: lien réflexif...)

la fonction HFichierVersEcran() change l'enregistrement actif à cause de ce champ dont le fichier de liaison final est le même que le fichier de base...

Le parcours en est affecté


Un problème similaire se poserait avec un fichier "Personnes" et l'affichage en mode fiche des
nom et prenom des ascendants; par exemple pour reprendre l'exemple WD "lien réflexif".

Mais dans l'exemple WD, cet affichage en liaison directe n'est pas proposé...

merci

Bonjour,

Je pense qu'il faut dans ce cas passer par une requete SQL du style :

"SELECT a.codeClient, a.raisonClient, a.codeClientPayeur, b.raisonClientPayeur from Client a, Client b WHERE a.codeClientPayeur = b.codeClient"

C'est vrai que les fonctions H... sont bien pratiques mais elles ont leur limite.

@+

Bonjour,

Ce procéder est tout a fait logique et il me parrait anormale d'avoir deux champs qui sont liés à la meme rubrique et pouvant recevoir tout deux des valeurs différentes.

la derniere saisie réaffectant les champs qui lui sont liés.

Il vous faut donc pour la saisie du tier payeur le codé entierement. Mais comme le tiers payeur etant dans le meme fichier que le code client il est n'écessaire de sauvegarder le contexte du fichier avant d'effectuer la nouvelle recherche.

J'insiste sur le mot Recheche puisque vous voulez récupérer le champ Raison social de celui ci, le prog doit rechercher si le code tier payant existe bien dans le fichier et donc il y a déplacement du curseur dans le fichier.
Une fois le code tier payant trouvé, vous récupérer la raison social et affecté un a un les champs voulus

Vous restituer ensuite le contexte pour repositionner le curseur fichier au niveau de l'enregistrement correspondant au code client.

Vous pouvez aussi utiliser une Requete comme le préconise
Issyn mais l'utilisation d'un HLitRecherche(,,) est plus rapide.
Cependant cela ne vous empêchera pas de faire les affectations manuellement.