PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Besoin d'aide pour construire un état "Bon de livraison"
Besoin d'aide pour construire un état "Bon de livraison"
Débuté par Marc_LR71, 20 oct. 2014 21:05 - 10 réponses
Membre enregistré
104 messages
Posté le 20 octobre 2014 - 21:05
Bonjour à tous,

Editer un Bon de livraison pour une seule commande ça ne me pose aucun problème. Mais pour sortir les BL de toutes les commandes du jour là je butte sur un écueil :

Ma requête m'extrait toutes les commandes du jour, ainsi que toutes les lignes de commandes liées.

Dans mon état :
En haut de page, j'imprime les informations de la commande (destinataire, adresse, etc.). Je récupère ces informations depuis le premier enregistrement retourné par la requête.
En corps de page, j'imprime les lignes de commande.
J'ai mis une rupture sur le numéro de commande, avec un saut de page en bas de rupture. De sorte qu'à chaque changement de commande, on imprime une nouvelle page.

Et là le problème survient : L'entête de la deuxième page (Destinataire, Adresse, etc.) vient puiser ses informations dans l'enregistrement en cours, et me ressort les infos de la commande précédente.
Je ne sais pas comment lire l'enregistrement suivant avant que celui-ci soit imprimé dans le corps de l'état.

Un peu d'aide serait la bienvenue.

--
Cordialement,

Bon dev à tous.
Posté le 21 octobre 2014 - 00:07
Tu passes par l'Editeur d'Etat , et IimprimeEtat() , ou bien tu programmes ton état ligne à ligne, par IImprime().


Si tu passes par la 2me option, montre nous ton code qu'on puisse t'expliquer.
Membre enregistré
104 messages
Posté le 21 octobre 2014 - 08:38
Bonjour Joël,

Je passe par la première option : Editeur d'état et iImprimeEtat.

--
Cordialement,

Bon dev à tous.
Membre enregistré
104 messages
Posté le 21 octobre 2014 - 11:14
Finalement j'ai modifié ma façon de faire, mais ça ne me plait pas :

Au lieu d'avoir une seule requête qui renvoie en même temps les infos de la commande et les lignes de commande, j'ai fait une requête qui ne contient que les infos commande pour imprimer l'entête du BL, et dans le corps de l'état j'ai mis un état interne lié à une requête qui me retourne les lignes de commande de la commande en cours.
Le problème est une énorme lenteur d'exécution car à chaque page imprimée l'état exécute une nouvelle requête.

Je suis sûr qu'on peut faire plus rapide car là c'est impossible pour les utilisateurs d'attendre plus de trente secondes pour afficher à peine une centaine de commandes. Ce n'est même pas la peine que j'essaie de livrer ça en l'état.
A noter que j'ai des sites distants qui travaillent sur une base de données HFCS hébergée dans le site principal. Donc je dois optimiser au maximum le volume de données à transférer et limiter les accès à la base de données.

Merci pour votre aide, j'en ai vraiment besoin.

cordialement,

--
Cordialement,

Bon dev à tous.
Membre enregistré
103 messages
Popularité : +4 (4 votes)
Posté le 21 octobre 2014 - 12:43
Bonjour Marc,

A priori je ne vois pas pourquoi ta 1ère solution ne fonctionnerait pas, si toutes les rubriques propres à une commande sont bien placées dans ta rupture. T'es sûr de la structure de ton état ?

A+
Membre enregistré
104 messages
Posté le 21 octobre 2014 - 13:41
Bonjour Multipass, merci pour ton aide.

Et non je ne suis pas sûr de la structure de mon état.
Les infos de la commande (Destinataire, ...) sont placés dans le bloc haut de page, et c'est là que le bât blesse.
Si je les mets dans le haut de rupture (rupture sur le numéro de commande) les infos sont bien à jour à chaque page, mais le haut de rupture ne se réimprime pas si j'ai plusieurs pages pour une même commande.
Si je les mets dans le haut de page, elles se réimpriment bien à chaque page, mais la première page de chaque commande m'indiquera en fait les coordonnées du destinataire de la commande précédente.

Ce que je n'arrive pas à faire, c'est à lire, dans le bloc haute de page, de informations qui me viennent du prochain enregistrement qui sera imprimé dans le corps de l'état.

Dis moi comment je peux t'aider à m'aider.

Cordialement,

--
Cordialement,

Bon dev à tous.
Membre enregistré
103 messages
Popularité : +4 (4 votes)
Posté le 22 octobre 2014 - 08:55
Bonjour Marc,

Faire un seul traitement de toutes les commandes via un état généré à partir de l'éditeur te pose déjà des problèmes et même si tu le combines avec une partie programmée (dans le code de l'état), tu seras toujours +/- obligé de bricoler, par exemple pour conserver une numérotation cohérente de tes pages...

Faire un état 100% programmé est aussi une solution mais à mon avis peu rentable vu le temps investi...

Du coup je te suggère, compte-tenu des contraintes dû au mode distant, de rester sur ton idée de départ en rapatriant toutes les données en une seule requête, mais de les traiter localement et de manière individuelle.

En bouclant la requête, tu isoles les données d'une commande et tu lances autant d'impression qu'il y a de commandes en conservant ton état d'origine (sans rupture).

A toi de voir comment passer les données d'une commande vers l'état... tu peux par exemple utiliser une variable (globale) qui te permettra d'affecter directement les rubriques dans l'éditeur.

Penses également à gérer la consommation de la mémoire, surtout si tu envoies un nombre important d'impressions.

A+
Membre enregistré
103 messages
Popularité : +4 (4 votes)
Posté le 22 octobre 2014 - 09:00
(re)

Je suis parti du principe que l'utilisateur imprime directement les commandes sans passer par l'aperçu.
(sinon, faudra réfléchir autrement...)

A+
Membre enregistré
104 messages
Posté le 23 octobre 2014 - 12:22
Bonjour Multipass,

La solution que tu me suggères semble être la meilleure, je vais m'orienter vers cette direction.
Ensuite il est vrai que les utilisateurs aiment passer par le mode aperçu avant impression. Maintenant qu'ils y ont goûté on ne peut plus leur enlever.
Mais je dois pouvoir gérer ça en envoyant toutes les impressions dans un PDF temporaire et un lanceAppliAssociée à la place de l'aperçu WinDev.

Merci beaucoup pour ce coup de main qui m'aura été très utile. :merci:

--
Cordialement,

Bon dev à tous.
Membre enregistré
351 messages
Popularité : +75 (75 votes)
Posté le 23 octobre 2014 - 13:10
Bonjour,

Une réponse vite faite qui peut t'aider ...

Selon ce que tu écris, tu as un problème au moment de l'impression de ton haut de rupture où tes données sont en fait celles de la rupture et non celles à venir alors voici ce que tu peux faire :

1°) Déclare une variable de type booléen à Faux dans ton état
2°) Met ton haut de rupture invisible
3°) Créer un bloc d'itération et met ton entête dedans
4°) A l'impression de ton corps ... si ta variable est à Faux alors tu imprimes ton bloc d'itération et tu passes ta variable à Vrai
5°) A l'impression du bas rupture ... tu passes ta variable à Faux

Tu restes ainsi dans la logique de ton état et sans problème de numérotation et avec l'aperçu.

--
Bon développement, Patrick [3po.fr]
Posté le 28 octobre 2014 - 18:10
Salut,

J'ai régulièrement le même problème, et je pense que c'est plutôt un bug de windev qui traîne depuis longtemps...

Voilà comment je le contourne :
Il faut que tu décoches l'option "Saut de page après le bloc" dans ton bloc Bas de Rupture.
Puis dans le code du bloc de Bas de Rupture (Après Impression) tu mets le code "iTerminePage"

A+

Mickael