Lier, ordonner et indenter des éléments de données
Les exemples suivants illustrent la plupart des modèles standard pour la conception de jeux de données dans les états Microsoft Dynamics 365 Business Central. Diverses combinaisons de ces modèles s’affichent dans les états Business Central réels.
La façon dont vous ajoutez des éléments de données à un état détermine la manière dont les enregistrements sont ajoutés dans le jeu de données d’exécution de l’état. Comprendre comment le jeu de données d’exécution d’un état est créé vous aide lorsque vous concevez la présentation de l’état. En outre, la création d’un jeu de données approprié, sans ajout ni duplication d’informations inutiles, est considérée comme une bonne pratique en matière de conception d’états.
Ce premier exemple illustre deux éléments de données qui ne sont pas liés ni indentés, par exemple, lorsque vous ajoutez un élément de données pour des clients et un autre élément de données pour des fournisseurs :
dataitem(Customer; Customer)
{
column(CustomerNo; "No.")
{
}
column(CustomerName; Name)
{
}
}
dataitem(Vendor; Vendor)
{
column(VendorNo; "No.")
{
}
column(VendorName; Name)
{
}
}
Dans cet exemple, les colonnes N° et Nom des tables client et fournisseur sont ajoutées au jeu de données en utilisant deux éléments de données l’un après l’autre. Il en résulte le jeu de données suivant :
Comme le montre l’exemple précédent, tous les enregistrements des deux tables sont ajoutés au jeu de données dans leurs colonnes correspondantes.
L’exemple suivant montre deux éléments de données indentés :
dataset
{
dataitem(Customer; Customer)
{
column(CustomerNo; "No.")
{
}
column(CustomerName; Name)
{
}
dataitem(CustomerLedgers;"Cust. Ledger Entry")
{
column(CustomerLedgersCustomerNo;"Customer No.")
{
}
column(CustomerLedgersAmountLCY;"Amount (LCY)")
{
}
}
}
}
Cette modification génère le jeu de données suivant :
Comme le montre l’exemple précédent, le jeu de données comporte de nombreux enregistrements. La capture d’écran n’en montre que le début. Le jeu de données réel comporte 48 pages d’enregistrements. De toute évidence, quelque chose ne va pas.
Si vous examinez attentivement ce jeu de données, vous noterez que les enregistrements client et les enregistrements écriture comptable client ne sont pas liés ou sont liés de manière incorrecte. Cela s’explique par le fait que la propriété DataItemLink est manquante. L’état effectue une jointure croisée entre la table client et la table des écritures comptables client, ce qui génère un jeu de données volumineux et inutile.
L’exemple suivant modifie le jeu de données et ajoute une propriété DataItemLink :
dataitem(Customer; Customer)
{
column(CustomerNo; "No.")
{
}
column(CustomerName; Name)
{
}
dataitem(CustomerLedgers; "Cust. Ledger Entry")
{
DataItemLinkReference = Customer;
DataItemLink = "Customer No." = field("No.");
column(CustomerLedgersCustomerNo; "Customer No.")
{
}
column(CustomerLedgersAmountLCY; "Amount (LCY)")
{
}
}
}
Cette modification génère le jeu de données suivant :
Dans le jeu de données résultant, les enregistrements client sont liés aux écritures comptables client appropriées. Cependant, si un client n’a aucune écriture comptable client, il est également ajouté au jeu de données, comme illustré dans le premier enregistrement.
En implémentant la propriété PrintOnlyIfDetail, vous pouvez supprimer ces enregistrements :
dataitem(Customer; Customer)
{
PrintOnlyIfDetail = true;
column(CustomerNo; "No.")
{
}
column(CustomerName; Name)
{
}
dataitem(CustomerLedgers; "Cust. Ledger Entry")
{
DataItemLinkReference = Customer;
DataItemLink = "Customer No." = field("No.");
column(CustomerLedgersCustomerNo; "Customer No.")
{
}
column(CustomerLedgersAmountLCY; "Amount (LCY)")
{
}
}
}
Il en résulte le jeu de données suivant :
La propriété PrintOnlyIfDetail indique s’il faut imprimer les données dans un état pour l’élément de données parent lorsque l’élément de données enfant ne génère pas de sortie.



