Découvrez les modèles de données parent-enfant pour devis, commandes, demandes de remboursement et checklists, avec des schémas simples pour des formulaires à lignes modifiables.
Un devis, une commande, une demande de remboursement ou une checklist décrivent rarement une seule chose. La plupart de ces formulaires ont un enregistrement principal en haut, puis de nombreuses entrées plus petites en dessous. Si vous forcez tout dans un seul enregistrement, le formulaire devient difficile à lire, difficile à modifier et facile à casser.
Un long champ de texte peut sembler plus simple au départ, mais il pose des problèmes presque immédiatement. Les gens ne peuvent pas ajouter un élément proprement, corriger une ligne sans toucher le reste, ou retirer une information obsolète en toute confiance. La validation devient aussi plus faible, car le système voit un bloc de texte au lieu d'éléments clairs et séparés.
Pensez à un devis commercial. Une demande client peut inclure cinq produits, et chacun a besoin de sa propre quantité, de son prix unitaire, d'une remise et d'une note. Une demande de remboursement fonctionne de la même manière. Une soumission appartient à un employé, mais chaque dépense a sa propre date, catégorie, montant et statut de reçu.
C'est là qu'un modèle parent-enfant aide. L'enregistrement parent stocke les détails partagés pour tout le formulaire, comme le demandeur, la date, le service ou le statut d'approbation. Les enregistrements enfants stockent les lignes. Chaque ligne peut être ajoutée, modifiée ou supprimée indépendamment sans abîmer l'enregistrement principal.
Cette séparation rend le formulaire plus simple à utiliser et plus fiable pour les équipes. Si une ligne comporte un montant erroné ou un champ manquant, vous pouvez corriger uniquement cette ligne. Le reste du document reste intact.
Le même schéma fonctionne pour les checklists modifiables. La checklist peut avoir un responsable et une date limite, tandis que chaque tâche a son propre libellé, assigné, note et statut de complétion. Les détails partagés restent au même endroit. Les détails des éléments restent là où ils doivent être.
Un formulaire à lignes est plus facile à gérer quand vous le scindez en deux parties : un enregistrement principal et plusieurs enregistrements liés pour les éléments.
L'enregistrement parent contient les informations qui doivent apparaître une seule fois. Dans un devis, cela peut être le client, la date du devis, le commercial et le statut actuel. Dans une demande de remboursement, ce peuvent être le nom de l'employé, le département, la date de soumission et l'étape d'approbation.
Chaque enregistrement enfant stocke un élément modifiable lié à ce parent. Dans un devis, un enfant peut représenter une ligne produit ou service. Dans une checklist, un enfant peut être une tâche. Dans un formulaire de remboursement, chaque enfant est généralement une dépense avec des champs tels que catégorie, montant, date de dépense et note de reçu.
La façon la plus simple de le conceptualiser est :
Cette structure est importante parce que les totaux et résumés doivent provenir des lignes enfants, pas d'une saisie manuelle dans le parent. Quand quelqu'un ajoute, supprime ou modifie un élément, le total doit se mettre à jour à partir des données réelles. Cela réduit les erreurs et rend les approbations plus fiables.
Cela rend aussi la validation plus précise. Vous pouvez exiger une quantité, refuser un montant négatif ou signaler une date manquante sur une ligne sans bloquer tout le formulaire.
Vous voyez ce schéma partout où un enregistrement nécessite de nombreuses lignes modifiables en dessous.
Les devis en sont un exemple clair. Un commercial crée un devis, puis ajoute une ligne pour chaque produit ou service. Chaque ligne peut nécessiter son propre nom d'article, quantité, prix unitaire, remise, taxe ou note, tandis que le parent garde le client, la date et le statut d'approbation.
Les commandes utilisent la même idée, mais les lignes portent souvent plus de détails opérationnels. Une commande peut inclure plusieurs produits, et chaque ligne peut nécessiter le statut de stock, des notes d'entrepôt, des détails d'expédition ou des dates de réalisation. Les lignes d'articles pilotent le travail qui se déroule après la commande.
Les workflows de remboursement sont un autre cas courant. Une demande appartient à un employé et à une période de reporting, mais peut contenir de nombreuses dépenses. Chaque ligne de dépense nécessite en général une date, un montant, une catégorie, un fournisseur et une référence de reçu. Les managers examinent souvent ces lignes une par une plutôt que de traiter la demande entière comme une décision oui/non.
Les checklists s'adaptent au même modèle, même quand elles semblent plus simples. Le parent peut être un plan d'intégration, une inspection de site ou une revue hebdomadaire. Chaque ligne enfant devient une tâche avec son état de réalisation, sa note, son propriétaire ou sa date d'échéance.
Un bon test est simple : le formulaire a-t-il un en-tête et de nombreuses lignes que les gens doivent ajouter, modifier ou supprimer ? Si oui, une structure parent-enfant est généralement le choix le plus propre.
Les bons formulaires commencent souvent par une question : qu'est-ce qui appartient à l'ensemble du document et qu'est-ce qui se répète à chaque ligne ?
Répondez à cela d'abord et beaucoup de problèmes disparaissent. Vous évitez les champs dupliqués, les totaux désordonnés et les lignes difficiles à gérer.
Pour l'enregistrement parent, conservez uniquement les champs qui décrivent le document complet. Dans un devis, cela peut être le nom du client, la date, la devise, le commercial et le statut d'approbation global. Dans une demande de remboursement, ce peut être le nom de l'employé, le département, la date de soumission et la décision finale.
Pour les enregistrements enfants, conservez les champs qui appartiennent à chaque ligne. Cela peut inclure le nom de l'article, la quantité, le prix unitaire, la date de dépense, la catégorie, le type de reçu, le libellé de tâche ou des notes de ligne. Si une valeur peut être différente sur chaque ligne, elle appartient en général à l'enfant.
Un test utile : si vous supprimez une ligne, la valeur doit-elle disparaître avec elle ? Si la réponse est oui, ce champ appartient probablement à l'enregistrement enfant.
Chaque ligne doit aussi avoir son propre identifiant unique. Ne dépendez pas uniquement de la position (première, deuxième, troisième). Un ID de ligne facilite l'édition d'une dépense spécifique, la restauration d'un élément supprimé ou le suivi des modifications.
Avant de construire, décidez comment les gens vont manipuler les lignes. Peuvent-ils ajouter une nouvelle ligne, en dupliquer une, en supprimer une, les réordonner ou filtrer une longue liste ? Décidez aussi quand les totaux et les statuts doivent se mettre à jour. Certaines équipes veulent que les totaux se recalculent dès qu'une ligne change. D'autres préfèrent que les mises à jour interviennent uniquement à l'enregistrement du document ou à sa soumission. Les deux approches peuvent fonctionner, mais la règle doit rester cohérente.
Les règles de statut comptent aussi. Si une dépense est rejetée, la demande complète revient-elle en brouillon, reste-t-elle en attente ou passe-t-elle en partiellement approuvée ? Il est bien plus facile de répondre à ces questions tôt que d'essayer de les régler après que les utilisateurs se soient habitués au formulaire.
Un formulaire à lignes fonctionne mieux quand les utilisateurs voient les détails du parent et les lignes ensemble. Placez l'enregistrement principal en haut, puis affichez le tableau éditable juste en dessous. Si quelqu'un crée un devis, il doit pouvoir confirmer le client, la date et le statut avant d'ajouter des produits.
Cette mise en page simple réduit les erreurs car les gens n'ont pas à passer d'un écran à l'autre juste pour vérifier ce qu'ils modifient.
Ajouter une nouvelle ligne doit être rapide. Un bouton clair Ajouter un élément au-dessus ou au-dessous du tableau suffit généralement. Lorsqu'on clique dessus, ouvrez une ligne vide ou un petit formulaire inline plutôt que d'envoyer l'utilisateur sur une page séparée.
C'est particulièrement important sur les formulaires longs. Si une personne doit saisir dix dépenses, chaque clic supplémentaire la ralentit et augmente le risque d'erreur.
Les actions de ligne les plus utiles sont en général les plus simples : ajouter, dupliquer, supprimer et parfois déplacer. Dupliquer est particulièrement pratique quand plusieurs lignes se ressemblent, comme des nuits d'hôtel répétées ou des éléments de checklist avec peu de différences.
Les formulaires longs doivent sauvegarder automatiquement le travail partiel ou au moins permettre d'enregistrer un brouillon. Perdre vingt minutes de saisie parce qu'un onglet s'est fermé est l'une des façons les plus rapides de rendre un formulaire peu fiable.
La validation doit être tout aussi claire. Si une ligne manque un montant ou a une quantité invalide, affichez l'erreur sur la ligne et le champ exact. Ne forcez pas les gens à chercher un message vague sur tout le formulaire.
Si sept lignes de dépenses sont correctes et qu'une seule manque un numéro de reçu, marquez uniquement cette ligne. Gardez le reste de la demande intact et laissez l'utilisateur corriger le problème sur place.
Une demande de remboursement montre précisément pourquoi ce modèle fonctionne si bien. Une demande agit comme parent, et chaque dépense devient une ligne enfant.
Le parent contient les détails applicables à la réclamation : nom de l'employé, période de la demande, manager et statut global. Ce statut peut passer de Brouillon à Soumis, puis à Partiellement approuvé ou Approuvé.
Chaque ligne de dépense stocke les détails propres à cet élément. Une ligne peut contenir le commerçant, la date d'achat, le montant, la catégorie et le reçu pour une course en taxi. Une autre ligne peut contenir les mêmes champs pour une facture d'hôtel.
Une demande simple peut inclure trois lignes :
Cette structure est importante car les managers examinent souvent les lignes une par une. Le taxi et l'hôtel peuvent être approuvés, tandis que le repas peut être rejeté avec une raison courte comme « Reçu manquant » ou « Repas dépassant la limite quotidienne ».
Une ligne rejetée ne doit pas compromettre toute la demande. L'employé doit toujours être remboursé pour les éléments approuvés, et la ligne rejetée doit rester visible avec sa raison. Cela rend le processus plus compréhensible et plus simple à auditer ensuite.
Les totaux doivent provenir des lignes enfants, pas d'un nombre saisi à la main dans le parent. Beaucoup d'équipes conservent deux totaux : le total soumis basé sur toutes les lignes incluses, et le total approuvé basé uniquement sur les lignes acceptées. Cela explique clairement pourquoi le paiement peut être inférieur à la demande initiale.
Un formulaire à lignes devient fiable quand les chiffres et les statuts se mettent à jour au bon moment.
Si un utilisateur modifie une quantité, un prix ou un montant de dépense, les totaux doivent se recalculer à partir de ce changement. Attendre la soumission finale crée souvent de la confusion, surtout quand remises, taxes ou limites d'approbation sont impliquées. Dans la plupart des cas, le total parent doit être calculé, non éditable.
Les règles d'approbation exigent la même clarté. Une fois un enregistrement entièrement approuvé, décidez si les lignes doivent être verrouillées. Si des lignes approuvées restent modifiables, les données peuvent diverger de ce que le manager a effectivement validé.
Parfois, l'approbation se fait ligne par ligne plutôt que globalement. Les remboursements en sont un bon exemple. Le voyage peut être approuvé, les repas partiellement rejetés, et une autre dépense renvoyée pour clarification. Dans ce cas, chaque ligne enfant doit avoir son propre statut pendant que le parent garde l'état global.
Une petite liste d'états généraux suffit généralement :
Cette séparation maintient l'honnêteté du formulaire. Le parent indique où en est la demande globalement, et les lignes enfants expliquent ce qui est arrivé à chaque élément.
Il est aussi utile de conserver un historique simple des changements pour des champs importants comme le montant, le statut, l'approbateur ou le total. Vous n'avez pas toujours besoin d'un système d'audit complet dès le départ, mais il faut assez d'historique pour expliquer les changements clés.
Les lignes supprimées ont aussi besoin d'une règle. Avant la revue, une suppression définitive peut convenir. Après le début de la revue, archiver est souvent plus sûr que supprimer complètement afin que les totaux passés et les décisions d'approbation restent cohérents.
La confiance chute rapidement lorsqu'un formulaire semble propre à l'écran mais stocke des données en désordre en dessous.
L'une des erreurs les plus courantes est de mélanger champs parentaux et champs d'élément dans une même table plate. Un devis, une commande ou une demande de remboursement a des détails qui appartiennent au document entier, comme le demandeur, la date ou le statut d'approbation. Ses lignes ont leurs propres détails, comme le nom d'article, le montant, la quantité ou la date du reçu. Quand tout est mélangé, les modifications deviennent confuses, les rapports plus difficiles à exploiter, et les doublons se multiplient rapidement.
Un autre problème fréquent est de laisser les utilisateurs saisir les totaux à la main alors que le système devrait les calculer. Si quelqu'un ajoute trois lignes de dépenses puis saisit un total général séparément, les chiffres peuvent diverger. Une fois cela arrivé plusieurs fois, les réviseurs cessent de faire confiance au formulaire.
Une grande zone de texte libre cause un trouble similaire. Cela peut sembler plus rapide de demander aux utilisateurs de coller tous les éléments dans un champ, mais le texte non structuré est difficile à valider, trier, filtrer ou approuver. Les lignes structurées demandent plus de réflexion, mais elles sont bien plus faciles à gérer ensuite.
Les contrôles au niveau de la ligne sont souvent négligés. Lignes vides, dates invalides, entrées en double, montants négatifs et éléments à moitié complétés doivent être détectés avant que le formulaire n'avance. La plupart des erreurs réelles se produisent à l'intérieur des lignes enfants, pas dans l'en-tête.
La suppression est un autre point faible. Si les utilisateurs peuvent enlever des lignes d'un simple clic sans confirmation, des données importantes peuvent disparaître par accident. C'est encore pire quand aucun enregistrement n'indique qui a fait le changement.
Une approche plus sûre est simple : confirmer la suppression d'une ligne, verrouiller les champs calculés et enregistrer les changements clés effectués par les utilisateurs.
Avant de publier un formulaire avec des lignes répétées, testez-le comme le feront les vrais utilisateurs.
Commencez par l'essentiel. Assurez-vous qu'un utilisateur peut ajouter, éditer, dupliquer et supprimer des lignes sans perdre d'autres données. Vérifiez que le formulaire se comporte encore correctement avec dix lignes, puis avec cinquante ou cent. Les erreurs doivent apparaître sur la ligne exacte qui nécessite une attention, pas seulement en haut de la page.
Testez ensuite ce qui se passe après les modifications. Mettez à jour une quantité, supprimez une ligne, dupliquez un élément et changez un statut. Après chaque action, confirmez que l'enregistrement parent affiche toujours les bons totaux, compte et état de synthèse.
Testez aussi les cas limites qui révèlent généralement les faiblesses : toutes les lignes supprimées, une ligne invalide parmi beaucoup de lignes valides, entrées en double, montants nuls, longues notes et modifications effectuées après soumission.
Un formulaire est prêt quand il reste clair en usage normal et continue de se comporter de façon prédictible dans des conditions désordonnées du quotidien.
Si vous construisez cela dans une application no-code, commencez par un workflow que les gens connaissent déjà, comme les remboursements ou les devis. Construisez d'abord la structure de données, puis ajoutez les règles qui relient l'enregistrement parent à ses lignes enfants, et ne peaufinez la présentation qu'après.
Utiliser des données réelles d'exemple aide bien plus que des données de test parfaites. Saisissez des doublons, des notes manquantes, des montants corrigés et des lignes incomplètes. Ces cas montrent où le formulaire devient confus et où la confiance commence à se fissurer.
AppMaster est un bon choix pour ce type de construction car la structure parent-enfant se mappe naturellement à des modèles de données séparés, des formulaires liés et la logique métier au même endroit. Si le processus évolue ensuite, AppMaster permet aussi de transformer le même modèle en backend, application web et application mobile native sans reconstruire le workflow depuis zéro.
L'objectif principal reste le même quel que soit l'outil : gardez le parent propre, laissez chaque ligne modifiable indépendamment, et faites en sorte que les totaux et statuts proviennent des données réelles. Quand cette partie est bien pensée, les formulaires à lignes deviennent beaucoup plus faciles à utiliser et beaucoup plus fiables.
Pourquoi ne pas tout garder dans un seul enregistrement ?Parce qu'un seul enregistrement mélange en général des détails partagés et des éléments répétitifs. Un modèle parent-enfant garde l'en-tête propre et permet d'ajouter, modifier, valider ou supprimer chaque ligne sans casser tout le formulaire.
Que doit-on mettre dans l'enregistrement parent et que faut-il mettre dans les enregistrements enfants ?Mettez des valeurs sur le parent si elles décrivent l'ensemble du document, comme le demandeur, le client, la date, le département ou l'état global. Mettez des valeurs sur l'enfant si elles peuvent varier d'une ligne à l'autre, comme la quantité, le montant, la catégorie, la note ou la date d'échéance.
Quand devrais-je utiliser une structure parent-enfant ?Utilisez-le quand un formulaire a un en-tête unique et de nombreuses lignes modifiables en dessous. Les devis, commandes, remboursements et checklists sont des exemples courants car chaque ligne nécessite ses propres champs et actions.
Les lignes doivent-elles avoir leur propre identifiant ?Oui. Donnez à chaque ligne enfant un ID propre au lieu de compter sur la position dans la liste. Cela rend l'édition, le suivi des changements, la restauration d'éléments supprimés et la synchronisation beaucoup plus sûrs.
Les utilisateurs doivent-ils saisir les totaux à la main ?Habituellement oui. Le choix le plus sûr est de calculer les totaux à partir des lignes enfants et de laisser le total parent en lecture seule. Cela évite les incohérences et facilite la confiance lors des approbations.
Comment la validation doit-elle fonctionner dans un formulaire à lignes ?Affichez l'erreur sur la ligne et le champ exacts qui en sont la cause. Si un élément est incorrect, les gens doivent pouvoir corriger cette ligne en place sans perdre le reste du formulaire.
Les approbations doivent-elles se trouver uniquement sur l'enregistrement parent ?Pas toujours. Si les réviseurs approuvent ligne par ligne, chaque enfant doit avoir son propre état pendant que le parent garde l'état général. C'est utile pour les remboursements où certaines dépenses peuvent être approuvées et d'autres rejetées.
Les lignes supprimées doivent-elles être complètement enlevées ?Avant la revue, une suppression complète peut convenir. Une fois la revue lancée, l'archivage est généralement plus sûr afin que les totaux passés et les décisions d'approbation restent cohérents.
Qu'est-ce qui rend un formulaire à lignes plus facile à utiliser ?Gardez les détails parentaux et les lignes modifiables sur un même écran quand c'est possible. Les actions Ajouter, Dupliquer et Supprimer doivent être faciles à trouver, et la sauvegarde en brouillon ou partielle évite la frustration sur les formulaires longs.
Comment puis-je construire cela dans un outil no-code comme AppMaster ?Commencez par des modèles de données séparés pour le parent et l'enfant, puis ajoutez les règles pour les liens, les totaux et les états. AppMaster est bien adapté car il permet de modéliser les données liées, d'ajouter la logique métier et de transformer le même workflow en backend, application web et mobile.
07 mars 2026
11 min
07 mars 202610 min
20 févr. 202610 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
