ACTIVITÉ
MONDIALE

Répondez à tous vos besoins de gestion d'une ACTIVITÉ INTERNATIONALE dans BUSINESS CENTRAL.
Dans cet article, nous expliquons ce que vous devez exiger, comment éviter les personnalisations et quelles APPLICATIONS utiliser.

Lorsque nous gérons plusieurs sociétés avec Business Central, des besoins supplémentaires apparaissent. Cela tient souvent à la présence de sociétés dans plusieurs pays, mais il peut aussi s'agir simplement de plusieurs sociétés dans le même pays.

Les sociétés ont généralement des rôles différents dans la chaîne logistique, par exemple des sociétés de logistique, des sociétés de production et des sociétés de vente, avec un certain nombre de processus entre elles.

Intercompany

Nous avons une société de vente qui reçoit des commandes vente parce qu'elle reçoit des commandes de clients finaux. La société de vente transmet des prévisions au siège, qui planifie le besoin en produits et s'approvisionne auprès de la société d'entrepôt/logistique pour la livraison, ou auprès d'un prestataire logistique externe ; pour certaines commandes, la société de logistique peut livrer directement le client final.

Le siège achète également des marchandises à la société de production, qui fait appel à un certain nombre de fournisseurs externes, produit les articles et les livre dans un conteneur à la société de logistique/d'entrepôt.

Ce n'est qu'un exemple. Quelle que soit la structure de notre entreprise, nous devons pouvoir la gérer dans Business Central, et les processus doivent être pris en charge afin que nous n'ayons pas à traiter manuellement toutes les données et la comptabilité.

En standard, Business Central gère bien les transactions intercompany, notamment depuis la version d'octobre 2023, mais nous avons rapidement besoin de plus de structure et d'automatisation afin de pouvoir valider automatiquement dans plusieurs sociétés à la fois.

Lorsque la société de vente crée une commande achat, une commande vente doit être créée automatiquement dans la société qui doit livrer, et ainsi de suite tout au long de la structure des sociétés. Nous voulons aussi pouvoir consulter les niveaux de stock des autres sociétés, afin de voir, dès la prise de commande auprès du client, si l'article est en stock dans une autre société.

Nous devons aussi gérer la tarification entre les sociétés. C'est également un défi si nous avons des taux de change différents dans les différentes sociétés.

Nous devons utiliser la même source pour les prix et les taux de change afin de faciliter les éliminations et d'obtenir les mêmes valeurs pour les mêmes articles dans les comptes de consolidation.

Gestion globale des données de référence

La gestion des données de référence est un sujet important dans un groupe comptant de nombreuses sociétés (entités juridiques). Nous devons disposer d'une structure globale pour les données de référence et pouvoir les synchroniser entre les sociétés, et nous devons inclure les données de référence sur les documents utilisés pour les commandes vente, achat et transfert entre toutes les sociétés. Nous abordons ce sujet en détail dans un chapitre distinct consacré aux données de référence.

Nous avons peut-être cinq sociétés différentes qui auront en pratique les mêmes clients, articles, données de référence, 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 créer plusieurs fois, ni à le maintenir dans plusieurs sociétés. Nous avons besoin de données de référence organisées selon une hiérarchie maître/abonné.

Conteneurs

Les conteneurs sont un sujet important lorsque nous expédions des marchandises sur de longues distances, que nous envoyions ou recevions des marchandises en conteneurs.

En tant qu'acheteur, il se peut qu'un conteneur soit posté chez le fournisseur, que nous remplissons progressivement avec des commandes achat, et lorsqu'il est suffisamment plein, nous le faisons expédier chez nous. Nous voulons alors gérer ensemble toutes les commandes achat du conteneur. Si le conteneur a 4 jours de retard en cours de route, nous voulons mettre à jour toutes les lignes d'achat en une seule fois et trouver les conflits que cela crée.

De la même manière, si nous sommes le vendeur, c'est nous qui expédions le conteneur, et nous voulons planifier au mieux la capacité du conteneur avant de l'envoyer.

Assortiments

Il existe souvent des différences quant aux marchandises et aux variantes qui peuvent être achetées et vendues dans les différentes sociétés.

Dans la société d'entrepôt, nous avons 8 couleurs d'un article ; une société de vente doit acheter les 8, tandis qu'une autre ne peut en acheter que 2, car elle ne commercialise que ces 2 couleurs.

Sur la boutique en ligne, les 8 couleurs doivent également être disponibles pour les clients du premier pays, mais seulement 2 pour les clients du second pays. Et le siège a décidé qu'une des couleurs devait être abandonnée, de sorte que seules 7 couleurs doivent être recommandées auprès du fournisseur.

La structure internationale doit pouvoir gérer tout cela dans Business Central.

Emballages et étiquettes

Lorsque vous proposez des marchandises dans de nombreux pays, les emballages et les étiquettes deviennent un défi particulier. Une étiquette d'ingrédients peut comporter 3 langues : anglais, espagnol et portugais, ce qui détermine dans quels pays le produit peut être vendu.

Nous avons le même article en stock avec d'autres combinaisons de langues, par exemple anglais, italien et grec. Il se peut que nous ayons 1 000 unités de l'article en stock et que nous puissions livrer les 1 000 dans des pays anglophones, mais seulement 80 en Italie, car les 920 autres n'ont pas l'italien sur l'étiquette d'ingrédients.

Les nombreuses variantes d'emballages et d'étiquettes constituent un défi supplémentaire dans Business Central.

Reporting et suivi

Le reporting relève de la Business Intelligence. Dans une configuration internationale, nous voulons pouvoir établir des rapports sur l'ensemble de la structure de l'entreprise. Que vendons-nous dans quelles régions du monde ? Quels sont nos délais de livraison ?

Si la Business Intelligence montre que le délai d'approvisionnement d'un article est en réalité de 3 mois, alors que les données de référence de l'article dans l'ERP indiquent 2 mois, nous devons corriger les données de référence afin de ne pas promettre aux clients quelque chose que nous ne pouvons pas tenir.

Consolidation

La consolidation financière est un autre sujet souvent traité avec un outil de reporting.

Nous voulons pouvoir analyser les entités de la structure de l'entreprise de manière comparable. Il est inutile de devoir remapper les données à partir de zéro à chaque fois pour obtenir des chiffres comparables. Nous devons pouvoir gérer la structure de manière centralisée pour l'ensemble du groupe.

En général, nous établissons des comptes de groupe, dans lesquels nous consolidons toutes les données des sociétés sous-jacentes jusqu'aux comptes de groupe et éliminons les transactions. À moins que toutes les sociétés n'utilisent Business Central, il est judicieux de réaliser la consolidation avec une solution de Business Intelligence, mais cela suppose que nous ayons des plans comptables et des codes de dimension harmonisés dans toutes les sociétés.

Si notre entreprise opère à l'international, ou si nous avons de nombreuses sociétés dans notre système ERP qui doivent être intégrées, l'« intercompany » est un sujet important.

Dans une société de vente, nous créons une commande vente pour un client ; lorsque nous la lançons, une commande achat doit être créée pour acheter l'article auprès d'une autre société du groupe, et une commande vente doit être créée (automatiquement) dans la société de production ou de stockage de notre groupe.

Nous avons maintenant trois documents de commande liés entre eux sur deux sociétés, et nous devons pouvoir les gérer ensemble et les modifier comme un tout.

Gestion des modifications

La gestion des modifications est la partie difficile. Dans la société de production, nous devons pouvoir modifier des quantités ou des prix, et la modification doit se propager à la fois à la commande achat et à la commande vente de la société de vente.

Nous devons pouvoir modifier n'importe lequel des trois enregistrements, et la modification doit se répercuter sur les autres. Cela ne sert à rien si notre solution est trop figée pour prendre en charge le monde dans lequel nous vivons.

Il existe plusieurs domaines dans lesquels nous avons besoin de flexibilité au quotidien.

Une seule commande vente

Notre société de vente a besoin de pouvoir créer une commande vente contenant des lignes provenant de plusieurs sociétés, par exemple deux articles de la société de vente locale elle-même, quatre articles de la société de stockage en Allemagne et trois articles à produire par la société en Pologne.

Expédition directe

Nous devons pouvoir indiquer s'il s'agit d'une expédition directe, c'est-à-dire si toutes les sociétés doivent envoyer les articles directement au client final, ou si les sociétés allemande et polonaise doivent envoyer les articles à notre société de vente locale, qui les expédiera ensuite au client.

C'est en fait l'un des aspects les plus difficiles des transactions intercompany. Si les sociétés allemande et polonaise expédient directement au client, elles doivent pouvoir joindre un bordereau de livraison ou une facture imprimés selon la logique de la société de vente locale d'origine, avec laquelle le client a après tout traité. Cela devient compliqué lorsque différentes sociétés et entités comptables sont impliquées.

Lorsque la société locale vend à un client local à des prix et avec des remises locaux, les documents doivent pouvoir sortir de l'imprimante en Allemagne et en Pologne.

Traçabilité des articles

Nous voulons également pouvoir suivre les articles d'une société à l'autre.

Lorsque le magasinier en Allemagne prélève des articles avec numéros de série, il doit scanner le numéro de série, qui doit ensuite être transmis jusqu'à notre société de vente locale afin que nous puissions voir localement quels numéros de série ont été prélevés pour la commande.

Configuration

Avec la configuration d'articles, les données doivent circuler dans l'autre sens. Nous enregistrons sur la commande vente locale les spécifications de l'article configuré, et peut-être le fait qu'un logo d'entreprise doit être imprimé sur le couvercle. Ces détails doivent ensuite être transmis à la société de production polonaise, qui produira les articles et imprimera le logo sur le couvercle.

Gestion des erreurs

Enfin, comment la solution intercompany gère-t-elle les erreurs ? Si quelque chose se passe mal entre les sociétés (par exemple si le numéro d'article n'existe pas dans l'autre société), la commande est-elle placée dans un journal d'erreurs dont quelqu'un doit assurer le suivi avant que la commande puisse avancer ?

Nous recommandons vivement que la solution fonctionne en ligne et que les erreurs soient renvoyées à l'utilisateur en temps réel. Cela signifie que, si dans notre société de vente locale nous saisissons une commande qui prélèvera des articles dans les sociétés allemande et polonaise, nous verrons les éventuelles erreurs à l'écran dès la saisie, et nous ne pourrons pas avancer dans le processus tant que l'erreur n'aura pas été traitée.

Nous constatons une nette hausse de la demande de solutions intercompany. Il devient assurément de plus en plus courant que les transactions traversent les frontières et les sociétés.

Les fondamentaux sont relativement simples, mais la flexibilité face aux défis du quotidien est la véritable marque d'une bonne solution intercompany.

Nous avons peut-être cinq sociétés différentes (entités juridiques) qui auront en pratique les mêmes clients, articles, données de référence, 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.

Nous pouvons aussi avoir un système ERP différent dans l'une des filiales. Nous avons besoin que les données de référence soient synchronisées sur toutes les plateformes, Business Central comme les autres systèmes ERP du groupe. Cela vaut aussi pour les données de référence que nous avons créées nous-mêmes, c'est-à-dire la couleur, la taille, la matière ou de nombreux autres types de données de référence sur les articles, les clients et les fournisseurs

Le défi consiste à faire dialoguer des systèmes ERP différents, aux structures de données différentes. Nous devons réfléchir soigneusement lors de l'élaboration d'une structure de données afin que les clés correspondent dans toutes les sociétés, d'un système ERP à l'autre.

Stratégies de synchronisation des données

Plusieurs stratégies sont possibles.

Une stratégie centralisée signifie que nous avons une société principale dans laquelle nous configurons toutes les données de référence sous forme consolidée, en regroupant tous les clients, tous les articles et tout ce que nous voulons faire gérer par l'équipe centrale. Le système « pousse » les données de la société principale vers les sociétés périphériques.

La gestion centralisée présente certains avantages, mais l'inconvénient est que les données sont plus difficiles à maintenir lorsque moins de collaborateurs y ont accès.

Un utilisateur local en France remarque peut-être qu'une information sur un article est erronée, mais il ne la fait pas corriger, car il est très compliqué de la signaler au siège. S'il corrige ses données locales, elles seront simplement écrasées par les données de la société principale lors de la prochaine exécution de la tâche de synchronisation.

Nous penchons donc pour une stratégie hybride dans laquelle les données peuvent être synchronisées dans les deux sens.

Il est acceptable que les données soient rassemblées dans une société principale centrale, mais nous estimons essentiel que les utilisateurs locaux puissent mettre à jour les données, de sorte que l'utilisateur français puisse mettre à jour les données article locales, que la modification soit resynchronisée vers la société centrale, et que la tâche de synchronisation suivante réplique sa modification dans toutes les sociétés.

Nous devons naturellement garder le contrôle des droits de modification dont il a besoin, c'est-à-dire des champs qu'il peut mettre à jour et de ceux auxquels il n'a pas le droit de toucher.

Il doit aussi pouvoir saisir des données en français sans écraser les autres variantes linguistiques.

Il doit également pouvoir créer un article qui n'est pertinent qu'en France et qui ne doit pas être diffusé aux autres sociétés.

Plus le groupe est grand, et moins nous avons d'articles ou moins notre structure d'articles est dynamique, plus nous estimons pertinente une stratégie centralisée avec une société principale.

C'est également le cas si nous avons des contrôles qualité stricts sur nos articles et que notre service de développement ou de qualité sécurise et nettoie les données de manière très rigoureuse. Dans ces cas, il est logique de renoncer à la mise à jour et à la création décentralisées.

S'abonner aux données

Nous devons pouvoir construire une structure de données de référence avec un propriétaire des données et des abonnés aux données. Dans chaque filiale, nous choisissons les données auxquelles nous souhaitons nous abonner.

Par exemple, s'il y a une filiale française dans un groupe allemand, la filiale française peut s'abonner aux articles, clients et autres données de référence partagés, mais elle peut aussi créer des articles locaux qui ne sont pertinents qu'en France.

Si la filiale française achète un article qui n'existe qu'en France, il n'y a aucun intérêt à répliquer ce numéro d'article dans 20 autres filiales dans le monde.