GESTION DES DONNÉES DE BASE

Répondez à tous vos besoins de GESTION DES DONNÉES DE BASE dans BUSINESS CENTRAL. Dans cet article, nous expliquons ce que vous devez exiger, comment éviter les personnalisations et quelles APPLICATIONS utiliser.

Que sont les données de base ?

Tous les systèmes ERP disposent de tables pour stocker les données relatives aux articles, aux clients et aux fournisseurs. Le défi tient à ce que les entreprises ont des besoins de données différents, ce qui conduit souvent à la création de nombreux nouveaux champs.

Tout le monde a besoin de champs supplémentaires pour stocker des données de base sur ses articles, comme la couleur, la hauteur, la résistance électrique, l'épaisseur, la dureté, etc. Certaines entreprises achètent des systèmes autonomes et spécialisés de gestion de l'information produit (PIM), qui doivent ensuite être intégrés au système ERP.

Les données de base peuvent aussi être des morceaux de texte sur l'article à afficher sur le site web ou la boutique en ligne. Ou nous pouvons vouloir faire figurer des données de base d'article sur la facture, ou disposer de descriptions de produits pour les étiquettes de rayon en magasin.

Les données de base peuvent aussi être des fichiers, comme des manuels d'utilisation, des instructions d'installation ou de montage, des informations de production, des documents de contrôle qualité, etc.

Les données de base peuvent être de nombreuses choses très différentes, et nous voulons les avoir à disposition dans Business Central, sans ajouter de champs personnalisés à la fiche article.

Aussi les clients et les fournisseurs

Le besoin de gérer des données de base vaut aussi pour les clients et les fournisseurs. Et nous voulons là aussi éviter les champs personnalisés sur la fiche client et sur la fiche fournisseur.

Nous pouvons enregistrer chez les clients un code de segment de marché, des classifications ABC, des relations de chaîne, des exigences de service, des structures de propriété, etc. Nous disposons de nombreuses informations sur les clients et les fournisseurs, qui sont elles aussi des données de base.

Un système PIM traditionnel se concentre uniquement sur les articles. De plus en plus, nous constatons que les entreprises souhaitent aussi des données de type PIM sur les clients et les fournisseurs, mais aussi sur d'autres entités comme les articles de service, les numéros de série, les nomenclatures, etc. Nous devons pouvoir travailler avec des données de base sur n'importe quoi.

La gestion des données de base recouvre plusieurs besoins différents que nous devons prendre en compte.

Enrichissement par des données de base

L'un d'eux est de pouvoir enrichir avec de nouvelles données de base. Nous aimerions disposer de nos propres dimensions de données, par exemple 20 nouveaux champs sur la fiche article, ou d'un système PIM dans lequel enrichir les articles avec des images et des données, ou d'autres possibilités d'ajouter des métadonnées à tous les types d'enregistrements du système.

Nous sommes habitués à travailler avec des données de base sur les articles, mais nous devons aussi pouvoir gérer des données de base sur les fournisseurs ou les clients, ou sur des articles dont les valeurs diffèrent selon le fournisseur.

Attributs personnalisés

Nous devons aussi pouvoir gérer des informations ou une configuration personnalisées pour une commande vente, afin d'ajouter des données de base à une ligne de commande vente précise.

Il peut s'agir d'un message à la production sur ce qui doit être imprimé sur l'article, ou sur la façon de l'emballer. Il peut aussi s'agir de l'information selon laquelle nous avons convenu de conditions particulières de retour, et cette information doit figurer sur la commande vente, le bon de livraison et la facture.

Ce n'est pas ce que nous entendons par données de base d'article « classiques », mais ce sont des attributs que nous devons pouvoir enregistrer sur les articles et les commandes et inclure dans les documents.

Nous devons pouvoir ajouter des données de base et des informations supplémentaires à tout élément de Business Central. Par exemple, nous aimerions pouvoir enregistrer des données de base sur les numéros de série afin d'effectuer un contrôle qualité. Nous pouvons aussi utiliser les données de base pour gérer les variantes de produit. Il existe de nombreux cas d'usage où nous pouvons ajouter des attributs à tout élément de Business Central.

Les données de base sur 3 niveaux

Il ne suffit pas de pouvoir ajouter un champ à la fiche article et d'y saisir du texte. Il nous faut une structure à 3 niveaux dans les données de base pour répondre à tous les besoins :

1. Nous devons pouvoir ajouter un champ. Ce pourrait être, par exemple, sur un article, « diamètre de roue ».
2. Ensuite, nous pouvons choisir si le diamètre est en pouces ou en cm, et
3. puis nous pouvons indiquer que la valeur est 27,5. Ce n'est pas une simple liste déroulante ordinaire. C'est ce qu'on appelle la logique de recherche (lookup) dans Business Central, et si elle n'existe pas dans la structure des données de base, nous nous heurterons à des limites.

Données de base unifiées

Nous avons besoin que les données soient unifiées, de sorte qu'elles aient la même structure et les mêmes valeurs d'une société et d'un système à l'autre, par exemple ERP, CRM et boutique en ligne, dans toutes les sociétés du groupe.

C'est ce qu'on appelle les Unified Master Data. Si vous avez des sociétés dans deux pays et utilisez l'intersociétés, il ne sert à rien qu'une commande échoue parce que le client porte un nom différent dans les deux sociétés.

Certaines données seront communes à toutes les sociétés, d'autres seront propres à chacune. Nous devons pouvoir contrôler où les données sont détenues et où elles ne peuvent pas être mises à jour parce qu'elles sont détenues ailleurs.

Données de base sur les documents

Les données de base doivent figurer sur de nombreux documents sortants ; elles doivent donc être transférées automatiquement entre les articles, les clients, les fournisseurs, les commandes vente et les commandes achat. Nous appelons cela Master Data on Documents (données de base sur les documents).

Lorsque nous ajoutons un commentaire à une commande vente, ce commentaire doit se propager à l'ordre de fabrication (ou à la société fournisseur via l'intersociétés, si nous faisons partie d'un groupe multisociétés), et lorsque le service de production achète des composants pour la production, notre commentaire doit apparaître sur la demande d'achat envoyée au fournisseur. Ou, lorsque nous envoyons un e-mail avec une facture pour un article, le manuel d'utilisation ou la documentation pertinents de l'article doivent être joints automatiquement.

Filtrage

Si nous avons 100 000 articles et un client au téléphone qui dit qu'il lui faut une certaine couleur et une certaine taille, nous devons pouvoir filtrer sur les données de base et voir les 14 articles qui répondent aux critères.

Maintenance des données

Lorsqu'un fournisseur envoie une nouvelle liste de données de base, nous voulons pouvoir l'importer facilement dans Business Central. Si nous avons 1000 articles avec un certain code couleur, qui va bientôt changer de nom, nous aimerions pouvoir créer une vue avec ces 1000 articles et mettre à jour en masse le nom de la couleur.

Une maintenance simple et la mise à jour en masse sont importantes lorsque nous avons beaucoup d'articles.

Outils de gestion

Il est très important de créer dès le départ une structure de données de base solide. Une fois que nous utilisons Business Central, il est difficile d'en changer la structure. Il est donc plus facile d'introduire une structure de données de base lors du choix d'un nouvel ERP ou d'une mise à niveau.

Mais il est important que la solution de données de base dispose d'outils pour mettre à jour en masse et nettoyer les données. Si nous avons un champ personnalisé sur la fiche article que nous souhaitons transformer en attribut de données de base pour nous débarrasser des personnalisations, nous devons pouvoir effectuer une mise à jour en masse qui déplace les données d'un champ personnalisé vers la structure des données de base.

Certaines entreprises trouvent les données de base beaucoup plus difficiles que d'autres. Quand nous avons un besoin d'enregistrement, il semble facile de créer simplement un nouveau champ à cet effet, et le problème est résolu.

Mais en général, nous ne voulons pas encombrer Business Central de nouveaux champs. Cela crée des difficultés de maintenance, et malheureusement les entreprises ne s'en rendent souvent compte que plus tard. Examinons-les brièvement :

• À terme, il y a tant de champs que l'on s'y perd, et différents services enregistrent chacun la même information dans leurs propres champs.
• Tout doit aussi être mis à jour dans l'ERP, dans la boutique en ligne (CMS) et dans le CRM (ou le système de commandes).
• Les mises à niveau de l'ERP deviennent compliquées à cause des nombreuses personnalisations à migrer.

Nous voulons créer et gérer les données de base sans personnalisations dans Business Central.

De manière traditionnelle, nous pourrions nous retrouver avec des centaines de champs sur la fiche article, servant à des usages très divers, et dont beaucoup se rapportent probablement à des catégories d'articles particulières.

Structure des données de base

Que gagnons-nous à disposer d'une structure de données de base ?

Des données cohérentes : nous pouvons traiter les situations où, par exemple, la couleur d'un article est enregistrée dans plusieurs champs de la fiche article. Le code couleur de production est RAL6005, tandis qu'un autre champ indique qu'un fournisseur appelle cette couleur British Racing Green. Dans un troisième champ, le marketing a écrit « vert foncé » pour la boutique en ligne, et un quatrième champ indique simplement « vert », car la couleur verte doit pouvoir être recherchée.

Des données structurées : un autre problème typique est que les données ne sont pas structurées. L'acheteur saisit la couleur sur l'article, et l'un écrit « racing green » tandis qu'un autre écrit « British green ». Pour la recherche, c'est un cauchemar.

Si nous utilisons des données structurées, l'acheteur sélectionnera la couleur dans une liste prédéfinie, et toutes les occurrences auront la même valeur. Les données de base doivent être soigneusement conçues et structurées pour pouvoir être utilisées dans toute l'organisation.

La mise à jour en masse : si nous décidons de changer le nom de la couleur, nous ne le changeons qu'à un seul endroit, et il se propage ensuite partout.

Sans fonction de mise à jour en masse, la mise à jour de nombreuses entrées s'effectue généralement en faisant appel à un consultant capable de configurer un traitement par lots pour modifier les données.

Vues, filtres et tris

Nous avons aussi besoin de bons outils pour consulter et manipuler les données.

Par exemple, le responsable marketing souhaite filtrer la table des articles et examiner certains articles pour la boutique en ligne, en choisissant les colonnes à inclure dans la vue et la manière de trier les données. Il veut aussi modifier et mettre à jour les données directement dans la vue afin de garder la maîtrise des données.

Et les unités doivent être dans des champs séparés. S'il s'agit d'un champ décimal, nous ne devons pas pouvoir saisir de texte. Souvent, les unités sont incluses dans le contenu du champ : on peut lire « 2,8 m » sur un article et « 280 cm » sur un autre, et une recherche d'articles de plus de 2 mètres de long ne donnera aucun résultat, car les données sont interprétées comme du texte et non comme des chiffres. Nous avons besoin des valeurs et des unités dans des champs séparés.

Si nous voulons filtrer et trier, ou utiliser intelligemment les données de base dans la planification, nous devons stocker les données sous forme structurée.

Gestion des langues

La gestion des données de base doit inclure la gestion des langues si nous travaillons en plusieurs langues. Si nous choisissons la couleur « Rouge » sur un article, le système doit disposer d'une autre table lui permettant de contrôler la façon dont la valeur « Rouge » apparaît dans les autres langues.

La bonne version linguistique des données de base doit être synchronisée intelligemment avec la boutique en ligne et fusionnée intelligemment dans les documents.

Nous devons pouvoir consulter tous les documents dans la langue de notre choix. Ainsi, notre personnel d'entrepôt anglophone peut voir en anglais le bordereau d'expédition chinois, et un collègue hispanophone de l'entrepôt peut consulter tous les documents en espagnol.

Business Central doit pouvoir produire de nombreux documents, comme des devis, des confirmations de commande, des bordereaux d'expédition, des factures, des avoirs, des relevés bancaires, des relances, etc.

Depuis la version 2013 de Dynamics NAV, les documents sont un défi permanent, car modifier la conception des documents et des états est désormais une entreprise de taille.

Nous voulons un outil pour contrôler à la fois le contenu et la mise en page de nos documents, sans avoir à solliciter un développeur chaque fois que nous voulons ajuster un document.

La gestion des documents doit offrir les cinq capacités suivantes :

1. Modèles
Nous avons besoin de modèles pour les documents dans Business Central. Lorsque nous créons une commande vente, nous voulons pouvoir choisir quel modèle de confirmation de commande convient dans ce cas.

Le choix du modèle doit aussi dépendre de la fiche client et être contrôlé automatiquement, afin que différents clients puissent avoir des conceptions d'état différentes.

2. Texte conditionnel
Il devrait aussi être possible que le contenu textuel détaillé d'un devis, d'une confirmation de commande, d'une facture, etc. varie selon les articles inclus dans la commande ou le client auquel on vend.

Nous pouvons ainsi ajouter un commentaire « Veuillez noter… » si un article particulier est inclus et que nous devons attirer l'attention du client sur un point important.

3. Données de base
Nous devons pouvoir stocker des données client ou article qui seront transmises à travers le système, d'un devis vente à une commande vente, puis à un ordre de fabrication, aux documents de vente enregistrés, etc.

Par exemple, pour un article particulier, nous pouvons vouloir que le bordereau d'expédition indique que le client doit vérifier l'article à son arrivée.

Autre exemple : les coordonnées du commercial doivent figurer sur la facture ; ces informations proviennent de la fiche client et doivent circuler à travers le devis et la commande vente pour apparaître sur la facture. Il en va de même pour les réglementations douanières, les conditions de réclamation, etc.

4. Langues
La gestion des langues est un enjeu important pour les entreprises ayant des clients internationaux. Elle ne doit pas se faire à la main : c'est une perte de temps.

Il doit être possible de stocker des données dans différentes langues. Nous pouvons avoir des réglementations douanières à faire figurer sur des factures en différentes langues, et chaque code de réglementation douanière doit contenir le texte en différentes langues afin que nous puissions associer le même code à tous les clients sans nous soucier de la langue dans laquelle ils ont besoin de la facture : cela sera contrôlé par le code langue du client.

5. E-mail
Enfin, nous devons bien sûr pouvoir créer un document à joindre à un e-mail et faire générer automatiquement le texte de l'e-mail. Nous devons pouvoir envoyer par e-mail aux clients les confirmations de commande, les factures, etc.

Nous devons pouvoir indiquer sur la fiche client la langue préférée du client, et que le bordereau d'expédition doit être envoyé à une adresse, la facture à une autre, etc.

Nous pouvons avoir cinq sociétés différentes (entités juridiques) qui, en pratique, auront les mêmes clients, articles, données de base, etc. Lorsque nous créons un nouvel article au siège, nous voulons qu'il soit répliqué dans les autres sociétés afin de ne pas avoir à le configurer plusieurs fois.

Retrouvez tout sur cette structure dans l'article sur le Global Business.