En utilisant les RUPTURES : on définit un regroupement sur une rubrique (le client, le mois, la catégorie), ce qui crée un bloc de début et un bloc de fin de rupture — c'est dans le bloc de FIN que se placent les sous-totaux du groupe. Le mécanisme de la rupture : (1) Une RUPTURE signifie « regrouper les enregistrements par la valeur de telle rubrique ». Chaque fois que cette valeur CHANGE, l'état « rompt » : il ferme le groupe précédent et en ouvre un nouveau. (2) Cela crée deux blocs supplémentaires : un bloc de DÉBUT de rupture (imprimé à l'ouverture du groupe : idéal pour un titre, « Client : DUPONT ») et un bloc de FIN de rupture (imprimé à la fermeture : c'est là qu'on met le SOUS-TOTAL du groupe). (3) Entre les deux, le bloc CORPS se répète pour chaque enregistrement du groupe. (4) En fin de document, on place le TOTAL GÉNÉRAL. Le prérequis absolu : le TRI : (1) Les données doivent être TRIÉES sur la rubrique de rupture. C'est la condition indispensable et l'erreur la plus fréquente. (2) Pourquoi ? Parce que la rupture se déclenche au CHANGEMENT de valeur. Si les données ne sont pas triées, un même client réapparaîtra plus loin dans la liste et créera un nouveau groupe : vous obtiendrez plusieurs blocs « DUPONT » avec des sous-totaux partiels et faux. (3) Assurez donc le tri dans la REQUÊTE source (ORDER BY sur la rubrique de rupture, puis sur ce que vous voulez à l'intérieur du groupe). (4) Symptôme typique du problème : le même groupe apparaît plusieurs fois dans l'état. Les points pratiques : (1) Les CALCULS : WinDev sait totaliser automatiquement une rubrique numérique sur une rupture (somme, moyenne, compteur). On place le champ de calcul dans le bloc de fin de rupture, en précisant la portée (le groupe) ou en fin de document (l'ensemble). (2) Ruptures IMBRIQUÉES : on peut regrouper par région PUIS par client, avec des sous-totaux à chaque niveau et un total général. Le tri doit alors suivre la même hiérarchie (région, puis client). (3) Lisibilité : soignez la présentation des blocs de rupture (mise en évidence du titre de groupe, séparation visuelle, alignement des totaux sous les colonnes correspondantes). Un état de gestion doit se lire d'un coup d'œil. (4) Saut de page par groupe : souvent souhaitable (une page par client), c'est une option du bloc de rupture. (5) Vérifiez toujours vos totaux sur un jeu de données connu : un total faux dans un document comptable est un défaut grave, d'autant plus dangereux qu'il ne provoque aucune erreur visible. La méthode complète : (1) Préparer une REQUÊTE avec les bonnes données, filtrées et TRIÉES selon la hiérarchie de regroupement. (2) Créer l'état sur cette requête. (3) Définir la ou les ruptures. (4) Placer les rubriques dans le CORPS, les titres dans les débuts de rupture, les sous-totaux dans les fins de rupture. (5) Ajouter le total général en fin de document. (6) Tester et CONTRÔLER les chiffres. En résumé : on obtient des sous-totaux par groupe grâce aux RUPTURES — un regroupement défini sur une rubrique (client, mois, catégorie) qui génère un bloc de DÉBUT de rupture (pour le titre du groupe) et un bloc de FIN de rupture, où se placent les SOUS-TOTAUX ; le bloc CORPS se répète entre les deux pour chaque enregistrement, et le total général va en fin de document. La condition IMPÉRATIVE est que les données soient TRIÉES sur la rubrique de rupture (via ORDER BY dans la requête source), car la rupture se déclenche au changement de valeur : sans tri, un même client réapparaît plus loin et produit plusieurs groupes avec des sous-totaux faux — c'est l'erreur la plus fréquente, et son symptôme est un groupe qui apparaît plusieurs fois. WinDev calcule automatiquement sommes, moyennes et compteurs par rupture, gère les ruptures IMBRIQUÉES (région puis client, avec le tri correspondant) et permet un saut de page par groupe. Enfin, contrôlez toujours vos totaux sur un jeu de données connu : un total faux sur un document comptable est un défaut grave qui ne déclenche aucune alerte.

Parce que la requête fait le travail au bon endroit — le moteur de base de données filtre, trie et calcule efficacement — ce qui rend l'état plus SIMPLE, plus RAPIDE et RÉUTILISABLE, alors que tout traiter dans l'état conduit à des états lents, complexes et difficiles à maintenir. Les avantages de la requête en amont : (1) PERFORMANCE : le moteur filtre avec ses INDEX et ne renvoie que les lignes utiles. Un état basé directement sur un fichier entier peut parcourir des centaines de milliers d'enregistrements pour n'en imprimer que quelques dizaines. (2) SIMPLICITÉ de l'état : l'état ne fait plus que METTRE EN FORME des données déjà prêtes. Sa conception devient claire — chaque chose à sa place : la requête sélectionne, l'état présente. (3) Les JOINTURES au bon endroit : afficher le nom du client à côté de sa commande relève de la requête (jointure), pas de calculs ou de lectures manuelles dans l'état. (4) Les CALCULS d'agrégat (totaux, moyennes, comptages) sont bien plus efficaces côté base (GROUP BY) que ligne à ligne. (5) RÉUTILISABILITÉ : la même requête peut alimenter un état, un champ TABLE et un export. Une seule définition, plusieurs usages — et une seule correction si la règle change. (6) TESTABILITÉ : on peut exécuter la requête seule pour vérifier les données AVANT de se préoccuper de la mise en page. C'est un énorme gain de temps en cas de résultat inattendu : on sait tout de suite si le problème vient des données ou de l'état. (7) PARAMÈTRES : une requête paramétrée (période, client, catégorie) rend l'état réutilisable au lieu d'en créer une version par cas. (8) TRI garanti : essentiel pour les ruptures, comme on l'a vu. Les inconvénients de tout faire dans l'état : (1) L'état devient un fourre-tout mêlant sélection, calcul et présentation — difficile à comprendre et à modifier. (2) Les performances se dégradent, parfois très fortement sur de gros volumes. (3) Le diagnostic est pénible : impossible de distinguer un problème de données d'un problème de mise en page. (4) Aucune réutilisation : la logique est enfermée dans un état particulier. (5) La maintenance devient risquée : toucher à l'état, c'est toucher à la fois aux données et à la présentation. Le principe général (séparer les responsabilités) : (1) La REQUÊTE : quelles données, filtrées comment, triées comment, avec quels calculs d'ensemble. (2) L'ÉTAT : comment ces données sont présentées (mise en page, blocs, ruptures, mise en forme). (3) Cette séparation est un principe de conception général, valable bien au-delà de WinDev. (4) Certains calculs restent naturellement dans l'état : les totaux de rupture, la numérotation des pages, les mises en forme conditionnelles — c'est de la présentation. En résumé : préparez les données avec une REQUÊTE parce que chaque outil doit faire ce qu'il fait le mieux — le moteur de base de données filtre (avec ses index), joint, trie et calcule les agrégats bien plus efficacement que du traitement ligne à ligne dans l'état. Les bénéfices sont cumulatifs : PERFORMANCE (seules les lignes utiles circulent, au lieu de parcourir tout un fichier), SIMPLICITÉ (l'état ne fait plus que mettre en forme), RÉUTILISABILITÉ (la même requête alimente un état, une table et un export, avec une seule correction en cas de changement de règle), TESTABILITÉ (exécuter la requête seule permet de vérifier les données avant la mise en page — et de savoir immédiatement d'où vient un problème), paramétrage (une requête paramétrée évite de dupliquer les états) et TRI garanti pour les ruptures. À l'inverse, tout faire dans l'état produit un objet fourre-tout qui mélange sélection, calcul et présentation : lent sur les gros volumes, difficile à diagnostiquer, impossible à réutiliser et risqué à maintenir. C'est l'application d'un principe de conception universel : séparer la préparation des données de leur présentation. Seuls les calculs de présentation (totaux de rupture, numéros de page, mises en forme conditionnelles) restent légitimement dans l'état.