Bienvenue dans un nouvel épisode des Microsoft Knowledge Nuggets. Je suis votre hôte, Miro Peters. Voici le scénario. Vous travaillez dans Business Central et vous avez besoin d'une petite modification. Peut-être un champ supplémentaire dans une fiche client, une étape de validation différente, ou une règle qui vérifie une commande avant sa validation. Puis quelqu'un évoque les extensions, AL, les tables, les pages et les codonites, et soudain, cette demande simple semble parler un tout nouveau langage. C'est un langage certes, mais il n'a pas besoin d'être mystérieux. Imaginez Business Central comme un immeuble de blu. AL donne aux développeurs les instructions pour ajouter une pièce, un formulaire ou une nouvelle règle sans avoir à percer les murs du bâtiment. C'est ça, le Knowledge Nuggets du que du loup. A la fin de cet épisode, vous saurez ce qu'est le développement AL, pourquoi les extensions existent et comment le travail personnalisé s'intègre dans Business Central.

Pourquoi les entreprises personnalisent-elles Business Central ? Business Central gère déjà beaucoup de tâches quotidiennes, finances, clients, commandes, factures de stock, le tout, dans un système connecté au lieu d'une pile de feuilles de calcul et d'outils séparés. Pour beaucoup d'entreprises, cette configuration standard couvre l'essentiel du travail. Mais voici le point clé. Il n'y a pas deux entreprises qui fonctionnent de la même manière. Prenez un distributeur alimentaire ayant besoin de détails de lots qu'une autre entreprise n'utilise jamais. Une entreprise de service exigeant un processus de validation spéciale avant facturation, un détaillant souhaitant des niveaux de récompense pour des remises, ou quelqu'un d'autre ayant besoin d'un formulaire avec ses propres champs de texte et ses règles internes. L'entreprise ne changera pas ses méthodes pour un champ manquant. Et vous ne voulez pas non plus que chaque petite demande se transforme en une modification risquée pour tout le système.

C'est un problème plus important par le passé. Dans les anciens systèmes, les développeurs ouvraient le code original et le modifiaient directement. Cela fonctionnait jusqu'à l'arrivée de la mise à jour suivante. L'entreprise se retrouvait alors, avec la nouvelle version de Microsoft d'un côté et ses propres modifications de l'autre, et il fallait réconcilier le tout avant d'avancer. Imaginez un bureau où chaque locataire fait passer de nouveaux câbles dans les murs sans aucun plan. Ça fonctionne un temps, mais quand le bâtiment a besoin de réparation, personne ne sait quel câble appartient à qui. Business Central adopte une approche différente. Au lieu de réécrire l'application standard, les développeurs construisent un module séparé qui s'y connecte, préservant la partie standard, tandis que les modifications de l'entreprise s'exécutent via des points d'accès supportés. Cette séparation est cruciale lors des mises à jour, car Microsoft met à jour sa partie du bâtiment tandis que le travail personnalisé reste dans son propre espace.

Il y a toujours des tests et des correctifs, ce sont des logiciels après tout, mais le développeur n'a plus à copier et à retravailler chaque modification au sein du code original de Microsoft. Alors qu'est-ce qu'une entreprise personnalise réellement ? Les personnalisations ajoutent des données. Le système standard ne stocke pas, par exemple, des instructions de livraison, un score de risque interne, un niveau d'adhésion ou un lien vers un système externe. Elles ajoutent également des écrans qui guident le personnel à travers une tâche dans le bonheur. Elles appliquent aussi des règles, comme l'arrêt d'une commande lorsqu'un document requis est manquant. Le travail personnalisé aide également les collaborateurs à éviter les étapes manuelles. Imaginez le personnel copiant des données clients de Business Central vers un autre outil chaque vendredi, vérifiant manuellement les conditions, puis envoyant un rapport à un responsable.

Un changement bien conçu conserve ses informations dans Business Central, applique la règle de manière cohérente et offre au personnel un bouton ou une page adaptée à leur travail quotidien. Mettons fin à un mythe. Vous ne voulez pas tout personnaliser. Business Central Standard intègre déjà de nombreux processus. Modifiez quelque chose simplement parce que cela semble différent d'un ancien système créé du travail supplémentaire par la suite. Ainsi, un bon travail personnalisé commence par une raison commerciale claire. A quel problème les gens sont-ils confrontés ? Que devrait-il se passer à la place ? Et le produit standard peut-il déjà le faire ? Lorsque le produit standard ne répond pas à ce besoin, AL entre en jeu. AL se concentre sur Business Central lui-même en lisant, ajoutant et modifiant des enregistrements au niveau de la base de données tout en contrôlant ce qui se passe sur les pages, les rapports et d'autres parties de l'application.

Il calcule également des valeurs, déplace des données et affiche des messages lorsque des règles ne sont pas respectées au cours des processus. C'est beaucoup de travail pour un seul langage. Mais AL n'est pas un outil généraliste pour tout type de logiciel. Et vous ne le choisiriez pas pour créer un site marchand public, un jeu mobile ou une application de bureau autonome. AL existe pour une tâche ciblée, façonner les données et le comportement au sein de Business Central afin que le système corresponde au fonctionnement d'une entreprise. Et c'est exactement ce que nous allons examiner ensuite. AL est Extensions, le modèle de complément sécurisé. AL signifie Application Language. C'est le langage de programmation de Microsoft pour Business Central. Et il offre aux développeurs un moyen structuré de créer de nouvelles fonctions métiers ou de modifier le comportement des parties existantes du système.

Mais le mot Extension est tout aussi important qu'AL. Une extension est une application distincte que Business Central peut installer. Elle contient le travail personnalisé de l'entreprise, tandis que l'application Business Central Standard reste intacte. Voyez cela moins comme la réécriture d'un manuel que comme l'ajout de pages approuvées à celui-ci. Oh, des pages qui respectent les règles originales sans les effacer. Cela peut sembler être un détail technique, mais cela change la façon dont le travail personnalisé vaut mieux finir. Imaginez qu'une entreprise ait besoin d'un nouveau bureau pour une équipe spéciale. L'ancienne approche signifiait percer un mur dans le bâtiment principal et modifier la structure elle-même. Cela peut répondre aux besoins aujourd'hui. Mais les réparations futures deviennent un cauchemar. Car le bâtiment d'origine ne correspond plus à ses plans. Une extension fonctionne différemment.

Le bâtiment dispose déjà de portes, de prises électriques et de règles pour ajouter de l'espace. Vous construisez la nouvelle pièce via ses connexions approuvées ? La pièce appartient à l'entreprise, mais le bâtiment principal peut toujours être entretenu sans avoir à détruire chaque mur personnalisé. C'est exactement ainsi que fonctionnent les extensions de Business Central. L'application de base contient le travail standard fourni par Microsoft. Une extension peut ajouter ses propres champs, écran, boutons, règles, rapports et même des liens vers d'autres systèmes. Elle peut réagir lorsque certaines actions métiers surviennent, mais elle le fait via des moyens de connexion pris en charge vers l'application standard. Les limites sont donc intégrées. C'est une bonne chose ? Sans limite, une petite demande personnalisée peut atteindre en profondeur des zones qu'elle ne devrait pas toucher.

Avec les extensions, le développeur travaille avec des types d'objets clairs et des points de connexion définis. Ce qui rend le code plus facile à comprendre pour quelqu'un d'autre plus tard. Cette approche s'adapte aussi parfaitement à la version cloud de Business Central. Microsoft met régulièrement à jour le service. Une entreprise doit toujours tester son extension après les changements, surtout si elle dépend de parties du produit qui ont évolué. Un logiciel ne supprime jamais le besoin de maintenance. Mais garder le code personnalisé séparé réduit le risque que chaque mise à jour se transforme en une reconstruction majeure des anciennes modifications. Vous entendrez peut-être parler de C-SR-L lorsque les gens mentionnent les anciens systèmes Dynamics NL. C-SR-L est issu d'un modèle de développement antérieur où les développeurs modifiaient souvent directement les objets de l'application d'origine.

De nombreuses entreprises ont utilisé ces systèmes avec succès pendant des années, mais cela liait étroitement le travail personnalisé au code standard et les mises à jour exigeaient beaucoup de comparaisons et de réparations. AL a fait basculer Business Central vers un développement basé sur des applications. Cela ne signifie pas que chaque extension est vaste ou complexe. Une extension peut simplement ajouter un champ à une fiche client et l'afficher sur un écran familier. Une autre peut contenir une solution complète pour un type d'activité particulier avec ses propres enregistrements, processus, pages et rapports. Les deux suivent le même principe de base. L'application personnalisée vit aux côtés de Business Central au lieu de dissimuler une réécriture de celui-ci. Vous pouvez également installer plus d'une extension. Une entreprise peut utiliser une extension d'un partenaire logiciel pour la paie, une autre pour l'expédition et une petite extension interne pour des règles spécifiques à cette entreprise.

Business Central les réunit dans le même système de travail tant qu'elle respecte les règles de la plateforme et ne sont pas en conflit. Ainsi à elle n'est pas seulement un moyen d'écrire du code. C'est le langage que les développeurs utilisent pour créer ces applications complémentaires et les extensions sont le conteneur qui apporte ces changements dans Business Central. Ce modèle permet à une entreprise de personnaliser le système tout en conservant un produit standard reconnaissable et plus facile à maintenir. Ouvrons maintenant l'une de ces extensions pour examiner les éléments qui la composent. Les principaux éléments de construction à elle à l'intérieur d'une extension à elle. Les développeurs travaillent avec des objets. Un objet est un élément nommé de l'application ayant une tâche précise comme stocker des informations, afficher un écran, exécuter une règle ou générer un document.

Une fois que vous voyez ces tâches séparément, à elle semble beaucoup moins être un mur de code. Commençons par l'endroit où résident les informations commerciales. Les tables stockent les données dans Business Central. Considérez une table comme un classeur numérique pour un type d'enregistrement. Un classeur peut contenir des clients, un autre des articles et un autre encore des commandes clients. Chaque enregistrement est affiché à l'intérieur de ce classeur. Une table client contient un enregistrement pour chaque client. Une table article contient un enregistrement pour chaque produit. Si votre entreprise a besoin d'informations que Business Central Standard ne stocke pas, une extension peut créer sa propre table, peut-être pour des niveaux de récompense, des inspections d'équipements ou des approbations de projets. Les champs sont les espaces étiquetés à l'intervalle de chaque enregistrement.

Un enregistrement client peut inclure un nom, une adresse, un délai de paiement et un numéro de téléphone, car la table client contient des champs pour ses détails. Les champs peuvent contenir du texte, des dates, des montants, des réponses par oui ou non, ou un choix parmi une liste fixe. Un champ peut également pointer vers un autre enregistrement. Par exemple, un client pourrait contenir un champ ID de récompense. Au lieu de saisir du texte au hasard, le personnel sélectionne un niveau de récompense dans une table de récompense distincte. Ce lien maintient les données propres car tout le monde choisit dans la même liste connue. Ainsi, les tables contiennent les faits. Mais comment les gens voient-ils et travaillent-ils avec ces faits ? Les pages. Une page est l'écran que vous ouvrez dans Business Central. La fiche client est une page. Une liste de commandes client est une page. Une page contrôle ce que les utilisateurs peuvent voir, saisir, rechercher et modifier.

Différentes pages conviennent à différentes tâches. Une page de fiche se concentre sur un enregistrement à la fois comme un client ou un article. Une page de liste affiche de nombreux enregistrements en ligne, ce qui est utile pour scanner, filtrer ou trouver quelque chose rapidement. Une page de feuille de travail prend en charge le travail où les personnes saisissent ou traitent plusieurs lignes d'informations ensemble. La table stocke les informations. La page les présente à l'utilisateur. Cette séparation est utile car vous pouvez modifier l'écran sans changer l'emplacement des données ou réutiliser la même table sur plusieurs pages lorsque différentes équipes ont besoin de vues différentes des mêmes enregistrements. Maintenant, que faire si les données appartiennent déjà à un enregistrement Business Central Stand ? En règle générale, vous ne créez pas une table client de remplacement juste parce qu'il vous faut un champ supplémentaire.

Vous utilisez une extension de table. Une extension de table ajoute votre champ à la table client existante. L'enregistrement client standard reste à sa place tandis que votre extension ajoute les détails spécifiques à l'entreprise à côté des champs standards. Il peut s'agir d'un identifiant de récompense, d'un bon de livraison, d'un responsable de compte ou d'un champ lié à une autre partie de l'activité. Mais l'ajout du champ à la table ne l'affiche pas automatiquement à l'écran. Pour cela, vous utilisez une extension de page. Une extension de page ajoute un champ, un groupe ou une action à une page existante. Si l'entreprise doit permettre au personnel de choisir un niveau de récompense lors de la consultation d'un client, l'extension de page peut placer le champ ID de récompense sur la fiche client là où le personnel travaille déjà. Cela permet de conserver une expérience familiale. Au lieu d'envoyer les utilisateurs vers un écran personnalisé séparé pour un simple détail, l'extension ajoute ce détail à la page qu'ils connaissent déjà.

Une extension de page peut également ajouter des actions comme un bouton ou une commande de menu qui lance une tâche. Par exemple, une fiche client pourrait inclure une action de récompense qui ouvre la liste des récompenses. En coulisses, il faut un endroit pour stocker les règles métiers. Cet endroit est souvent une codonie. Une codonie contient des procédures AL qui sont des morceaux de code nommés effectuant une tâche particulière. Voyez cela comme une équipe de back-office qui gère une tâche lorsqu'une page, un rapport ou un autre processus demande de l'aide. Supposons que le niveau de récompense détermine la remise appliquée à un client. Le calcul de la remise doit se trouver dans une codonie et non dans la page de fiche client elle-même. Ainsi, un processus de vente, un rapport ou une future page peut utiliser la même règle sans avoir à la copier à plusieurs endroits. Une seule règle, un seul endroit pour la maintenir.

Business Central inclut également d'autres types d'objets pour différentes tâches. Les rapports collectent des données et les présentent dans un document ou une mise en page, comme une facture ou un rapport de vente. Les requêtes posent des questions ciblées sur les données, par exemple quels clients ont commandé un article spécifique sur une période de données. Par exemple, les XML ports aident à importer ou exporter des données dans un format structuré, souvent lorsqu'un autre système doit échanger des informations avec Business Central. Assemblez ces éléments et vous pourrez imaginer une petite extension de récompense client. Une table de récompense toque chaque niveau et son pourcentage de remise. Les pages de récompense permettent au personnel de gérer ses nus. Une extension de table client ajoute un ID de récompense à chaque client, tandis qu'une extension de page de fiche client l'affiche.

Une action de page ouvre la liste des récompenses et l'unité de code calcule la règle de remise. Chaque objet gère une partie du travail. Cela rend l'extension plus facile à lire, à tester et à modifier lorsque la règle métier change six mois plus tard. Mais une règle métier doit souvent s'exécuter au moment précis, par exemple lorsqu'une commande est validée. C'est là qu'interviennent les déclencheurs et les événements. Événements, déclencheurs et règles métiers. Donc vous avez ajouté un champ de récompense client. Bien, voici la vraie question. Quand Business Central doit-il réellement utiliser ce champ ? Imaginez que vous êtes sur le point de valider une commande client. Avant que le système ne crée les écritures finales, vous souhaitez une vérification supplémentaire. Peut-être le client a-t-il besoin d'un niveau de récompense approuvé avant qu'une remise ne s'applique. Ou peut-être qu'un document de livraison requis doit exister avant que la commande puisse avancer.

Vous laissez de vérification au bon moment. Mais vous ne voulez pas copier tout le processus de validation des ventes dans votre extension juste pour ajouter une règle. Ce processus gère déjà beaucoup de choses en arrière-plan. Si vous le copiez, votre extension sera coincée à devoir maintenir tous ses futurs changements. Pas idéal. AL offre donc aux développeurs plusieurs moyens d'exécuter du code. Le choix dépend de ce qui doit se passer. Tout d'abord les déclencheurs. Un déclencheur est un point nommé à l'intérieur d'un objet AL où le code peut s'exécuter. Lorsqu'une valeur est modifiée sur un champ de table, le déclencheur lance du code. Lorsqu'une page s'ouvre ou se ferme, le déclencheur lance du code. Les rapports, requêtes, XML ports, tables, extensions, AO ont tous ces points où un développeur peut ajouter des règles. Prenons le champ ID de récompense sur un client. Lorsqu'un utilisateur choisit un niveau de récompense, un déclencheur de validation peut s'exécuter.

Le code vérifie le client est-il bloqué. Le niveau de récompense existe-t-il ? Un autre champ doit-il être mis à jour ? La vérification se fait au moment où la valeur change. Pas plus tard lorsqu'une erreur est découverte. Les déclencheurs fonctionnent bien lorsque la règle est étroitement liée à cet objet. Mais Business Central utilise aussi des événements. Un événement est comme un avis. Une partie de l'application l'envoie quand quelque chose se produit. Cela peut annoncer qu'un enregistrement est sur le point d'être inséré, qu'un document va être validé ou qu'un processus est terminé ou qu'un processus est terminé. Votre extension peut écouter cet avis. Le code qui écoute est appelé « abonné d'événement ». Il attend un événement nommé spécifique. Lorsque Business Central déclenche cet événement, l'abonné exécute sa propre procédure. Le processus standard reste aux commandes. Par exemple, quand Business Central commence à valider une commande client, il lève un événement avant de continuer.

Votre extension de récompense reçoit cet avis. Elle vérifie l'ID de récompense et la règle de remise du client. Ensuite, elle autorise la poursuite du processus ou l'interrompt avec un message clair. Le processus de validation standard appartient toujours à Business Central. Votre extension ajoute simplement sa règle spécifique à l'entreprise à ce point de connexion. Vous entendrez souvent des noms d'événements comme « on before or on after who ». « On before ago » signifie que votre code s'exécute avant la fin d'une action. C'est parfait pour une vérification qui peut empêcher l'étape suivante. Comme « arrêter une commande client si une condition n'est pas remplie ». « After que » signifie que l'action a déjà eu. Vous pouvez alors réagir. Créer un enregistrement associé, mettre à jour une note ou démarrer une autre tâche. Les noms indiquent le moment et le moment est important. Une règle qui s'exécute après la validation ne peut pas l'empêcher.

Une règle qui s'exécute trop tôt peut ne pas disposer des données nécessaires. Les développeurs choisissent donc l'événement en fonction de ce que la règle métier doit faire et quand. Le code peut également être déclenché par une action. Un utilisateur clique sur un bouton comme CAQ et vérifie le statut de récompense CAQ et cette action appelle une procédure. Le code peut aussi s'exécuter lorsqu'un objet en appelle un autre via une variable. Cela semble technique, mais c'est simple. Une partie de l'extension demande à une autre d'effectuer une tâche. Les variables aident à cela. Une variable est un espace nommé qui contient une valeur pendant l'exécution du code. Il peut s'agir d'un nombre, d'un texte, d'une date ou même d'un enregistrement business central comme le client actuel. En L, vous les déclarer avec TAC varicule. Par exemple, une procédure de récompense peut utiliser une variable nommée customer, customer actuel, pour stocker l'an actuel.

Une autre variable appelée CA discount percent que contient le pourcentage de remise. Ce ne sont pas des enregistrements permanents. Ce sont juste des valeurs de travail pour cette partie du code. Voici ce qu'il faut savoir sur l'emplacement du code. Si une règle doit être utilisée à plusieurs endroits, placez-la dans une codonie. Ainsi, la fiche client, un processus de vente et un rapport peuvent tous appeler la même procédure de remise au lieu d'avoir chacun leur version. Cela évite un problème bien connu. Un écran applique une remise de 10%, un autre 5% et personne ne sait quelle règle est la bonne. Conserver les règles métiers partagées dans une codonite donne à l'extension une source unique pour cette décision. Les déclencheurs triggers gèrent donc les règles proches d'un objet. Les événements permettent à une extension de réagir au propre processus de business central. Les codonites regroupent la logique partagée.

Une fois ces éléments connectés, la question suivante est Où les développeurs écrivent-ils, testent-ils et inspectent-ils tout ce code AL ? Le développement AL se fait généralement dans Visual Studio Code, souvent appelé VS Code. C'est votre espace de travail pour rédiger les fichiers AL. Il permet d'organiser votre extension. Il vous aide à trouver des problèmes et envoie l'application terminée vers un environnement business central pour les tests. Mais VS Code seul n'est qu'un éditeur de code général. Il nécessite l'extension de langage AL de Microsoft. Cette extension apprend à VS Code comment fonctionne business central. Elle peut suggérer des noms d'objets pendant que vous tapez. Elle signale les erreurs avant que vous ne publiez. Elle vous aide à parcourir les champs et les procédures. Et elle connecte votre projet à un environnement business central. Cela permet d'éviter bien certitude.

Lorsque vous démarrez un nouveau projet AL, vous pouvez exécuter la commande calgo.cscode dans VS Code. Elle crée le dossier de projet de base et les fichiers de paramètres du nom de l'extension AL, l'éditeur, la version et l'environnement business central à utiliser. Considérez ce dossier de projet comme l'établi de l'extension. Chaque fichier AL est à sa place. Un fichier peut contenir une table, un autre une extension de page et une codonie peut avoir son propre fichier. Ainsi, quand quelqu'un ouvre le projet, il peut trouver la bonne partie sans faire défiler un document immense. Lorsque le code est prêt à être testé, VS Code le compile en un package d'application. C'est la version installable de l'extension. Business Central lit ce package et ajoute l'extension à l'environnement. S'il manque un champ, s'il y a une faute de frappe ou tout autre problème empêchant la compilation, VS Code vous en informe avant que le package n'atteigne Business Central.

Les tests doivent d'abord s'effectuer dans un environnement sandbox. Sandbox est un environnement business central séparé où vous pouvez tester des modifications sans risquer de perturber les activités réelles. Publiez l'extension, vous ouvrez les pages modifiées, vous saisissez des enregistrements de tests et vous vérifiez si les règles fonctionnent comme prévu. Cette séparation est importante. Vous ne voulez pas découvrir qu'une nouvelle règle de validation bloque les commandes clients pendant que le personnel tente de travailler. Dans un sandbox, vous pouvez commettre des erreurs, supprimer des données de test, modifier le code et publier à nouveau sans affecter les données réelles. Parfois le code s'exécute, mais le résultat semble incorrect. C'est là que le débogage est utile. Vous placez un point d'arrêt dans le code, lancez le processus et l'extension se met en pause pendant l'exécution.

Lors de cette pause, vous pouvez inspecter des valeurs comme le client actuel, le niveau de récompense sélectionné ou le pourcentage de remise calculé par la procédure. Au lieu de deviner pourquoi une règle a échoué, vous pouvez voir exactement ce que le code a reçu. Les équipes de développement utilisent également Git pour conserver un historique de leur travail. Git enregistre les modifications apportées au fichier du projet au fil du temps. Si quelqu'un modifie une règle et crée un problème, l'équipe peut comparer les versions, voire les changements et annuler si nécessaire. Cela aide également lorsque plusieurs développeurs travaillent sur la même extension. Pour un débutant, la meilleure approche consiste à commencer petit. Apprenez d'abord à connaître Business Central, puis créez une table et une page. Ensuite, étendez une page standard, ajoutez une règle métier simple et apprenez comment les événements et les données d'installation s'intègrent au projet.

Connectons maintenant ces éléments via une petite extension qu'une entreprise pourrait réellement utiliser.

Un exemple simple, créez une extension de récompense client. A quoi ressemble réellement une extension à elle ? Plongeons-nous dans un exemple simple. Imaginez que votre entreprise souhaite définir des niveaux de récompense client, chacun avec sa propre remise. Vous commencez par créer une table de récompense. Considérez-la comme un classeur numérique où chaque fichier contient un ID, une description et un pourcentage de remise. Leur bénéficie de 10% de réduction par exemple. Votre personnel doit pouvoir gérer ses niveaux sans utiliser d'outils techniques. Vous ajoutez donc deux pages, une liste de récompense pour voir tous les niveaux et une fiche de récompense pour modifier ou créer un niveau. Ils peuvent ajouter un nouveau niveau, ajuster un pourcentage ou consulter les données sans ouvrir l'environnement de développement. Ensuite, vous étendez la table client avec un nouveau champ appelé ID de récompense.

Ce champ lit chaque client à un enregistrement de récompense et vous placez ce champ directement sur la fiche client où le personnel gère déjà les détails. Puis vous ajoutez une action de récompense pour qu'il puisse ouvrir la liste directement depuis cette même fiche. La règle de remise elle-même réside à l'intérieur d'une codonie. Lorsqu'un autre processus a besoin de la remise d'un client, il appelle cette codonie au lieu de la calculer encore et encore sur chaque page. C'est efficace. Une codonie d'installation ajoute des niveaux de récompense de base lors de la première installation de votre extension. Et un abonné aux événements, vérifiez le niveau de récompense choisi pendant le processus de vente, appliquant la règle de votre entreprise au bon moment. C'est une petite extension, mais observez tout ce qu'elle contient. Table de données, écran utilisateur, action de navigation, logique de configuration et règles métiers.

Tout fonctionne ensemble. C'est là la véritable puissance d'aide. Très bien. En conclusion, votre point de départ en développement AL. Voici ce qu'il faut retenir. Le développement AL vous permet d'ajouter les fonctionnalités spécifiques dont votre entreprise a besoin à Business Central sans toucher à l'application principale. Et vous n'avez pas besoin de tout construire en une seule fois. Commencez par un champ, une extension de page et une règle claire. C'est votre première brique de construction. Si cette pépite de savoir vous a été utile, abonnez-vous sur votre plateforme de podcast préférée et partagez-la avec quelqu'un qui débute dans le développement Business Central. Rejoignez-nous la prochaine fois pour ajouter une nouvelle pièce au puzzle. Je suis Marco Peters, c'était un nouvel épisode des Microsoft Knowledge Nuggets sur M365FM. Merci.