Transactions intersociétés (ou intragroupe)

Si vous utilisez Business Central pour gérer plusieurs sociétés d’un même groupe, les fonctions ci-après vous permettront de rationaliser les flux entre ces sociétés.

Ainsi par exemple, si, au sein du groupe, la société « B » passe commande à la société « A », cette « Commande achat » de « B » peut être intégrée en « Commande vente » de « A », sans avoir à la ressaisir.

Si à l’inverse, « A » facture des frais à « B », la validation d’une « Facture vente » de « A » proposera la « Facture achat » dans « B ».

Enfin, si l’une des sociétés engage des frais pour le compte d’autres sociétés du groupe, elle pourra mentionner ligne à ligne le partenaire concerné afin que ces frais leur soient automatiquement réaffectés.

De plus, ces transactions identifiées comme intragroupe, permettront de déterminer les prestations réciproques lors de la consolidation le cas échéant.

Terminologie

Vous pouvez vous référer à la documentation Microsoft : Gestion des transactions intersociétés – Business Central | Microsoft Learn. Elle pâtit cependant d’incohérences de traduction avec l’application voire de traductions parfois erronée (ex : « intracom » au lieu de « intersociétés ») qui rendent difficile sa compréhension (plus généralement, la traduction française mériterait d’être améliorée mais là n’est pas le sujet).

Le présent article se veut plus concis et illustré de quelques cas d’usage.

Dans l’édition anglosaxonne, le terme ‘InterCompany’ est utilisé.
Il a été traduit intersociétés, ce qui n’est pas faux, mais le terme ‘intragroupe’ serait plus approprié dans ce contexte.

Les sociétés du groupe sont définies par la liste des « Partenaires intersociétés ».
Cependant, sur la fiche client ou fournisseur, la référence au partenaire concerné est nommée « N° partenaire IC » (IC étant un héritage de l’édition anglosaxonne).

Principe

Dans Business Central, les sociétés sont totalement indépendantes et ont des référentiel distincts (configuration, codifications, plan comptable…).

Un référentiel commun est défini pour les transactions intersociétés (Cf. configuration « Plan comptable intersociétés ») et une correspondance est établie entre celui-ci et celui de chacune des sociétés.

Ce sera généralement un extrait du plan comptable reprenant les quelques comptes concernés comme dans l’exemple suivant :

Si ce plan comptable intersociétés est homogène avec celui de la société courante, le « N° cpte gén pour corres » sera identique au « N° ».

Dans chacune des sociétés, une correspondance est ainsi établie entre son propre plan comptable et le plan comptable intersociétés.

De même, une liste des « Partenaires intersociétés » (Cf. configuration) permet de lier le N° client et/ou le « N° fournisseur » concerné au sein de chacune des sociétés (lignes surlignées dans l’exemple ci-dessous) :

Nous reviendrons bien sûr en détail sur la configuration mais voyons comment seront traitées les transactions concernées.

Les exemples cités concernent des transactions de « A » vers « B » (« B » est donc défini comme client dans « A », et « A » est défini comme fournisseur dans « B »).

Ces fonctions sont bien sur applicables dans l’autre sens, ainsi qu’avec toute autre société du groupe.

Seules les spécificités des transactions intersociétés sont décrites ci-après.

Facture de vente émise par « A »

Une facture de vente de « A » à « B » génèrera une facture d’achat dans « B » (il en est de même pour un avoir).

En en-tête, rien de particulier, si ce n’est que le « N° client » est celui associé au « Partenaire intersociétés ».

Pour les lignes, intéressons nous d’abord à celles de « Type » ‘Compte général’ qui pourront être utilisées pour la facturation de frais généraux (honoraires, loyer…).

Dans « A », elles seront imputées de façon habituelle, mais dans « B » elles devront être imputées sur des comptes d’achat.

En ajoutant (via Personnaliser) la colonne « Référence du partenaire IC » , vous pourrez sélectionner le compte souhaité en faisant référence au « Plan comptable intersociétés » :

La facture sera alors validée de façon habituelle dans la société A et la retrouverez en facture achat (non validée) dans la société B.

Boîtes d’envoi et boîte de réception

Le transfert de transactions d’une société à l’autre passe par un mécanisme de boîtes d’envoi et de réception :

La facture de vente validée dans « A » a été transmise via la « Transaction Boîte d’envoi intersociétés », puis archivée en « Boîte d’envoi intersociétés traitées » après transfert vers « B » :

Depuis celle-ci, vous pourrez si nécessaire « Recréer la transaction boîte d’envoi » afin de l’envoyer de nouveau au partenaire IC. Cette action ne devrait être utilisée que si le transfert a échoué.

Dans « B » le document est arrivé en « Transactions Boîte de réception Intersociétés » :

L’action « Détails » permet de visualiser le contenu du document avant acceptation.

Vous pouvez alors « Accepter » chacune des transactions reçues puis « Exécuter les actions de ligne » pour créer la facture correspondante.

Dans le cas contraire, vous pourrez :

  • Rejeter la transaction (et la renvoyer à votre partenaire) ou
  • Annuler la transaction (et la supprimer sans la renvoyer à votre partenaire).

La transaction intersociétés est archivée en « Transactions Boîte de réception Intersociétés traitées ».
Depuis celle-ci vous pouvez, moyennant confirmation « Recréer la transaction boîte de réception ».
Cette fonction ne devrait être utilisée que dans le cas où vous auriez malencontreusement supprimé la facture avant de l’avoir validée.

Facture d’achat reçue par « B »

En en-tête, rien de particulier si ce n’est que le « N° fournisseur » est celui associé au partenaire intersociétés et le « N° facture fournisseur » reprend le « N° » de la facture de « A ».

Les lignes sont imputées aux comptes d’achat (en tenant compte de la conversion en « N° cpte gén pour corres » définie au « Plan comptable intersociétés » dans « B »).

La suite du processus (approbation éventuelle, validation, paiement…) ne présente pas de particularité.

Commandes et articles

La facture de frais généraux ci-dessus, initiée par « A », est transmise de « A » vers « B ».
S’il s’agit d’article, c’est au contraire la « Commande achat » de « B » qui sera transmise en « Commande vente » à « A ».

Les articles concernés doivent être préalablement définis dans « A » et dans « B » mais peuvent avoir des « N° » différents. Une correspondance devra donc être définie (Cf. configuration).

La commande achat est saisie dans « B », puis l’action « Envoyer commande achat intersociétés » la transmet à « A ».

Les expéditions et factures relatives à cette commande de vente dans « A » ne seront pas transmises à « B ».
Il faudra donc valider la(les) réception(s) dans « B » et faire de même pour la(les) facture(s) correspondantes(s).

Remarques

Un processus similaire est associé au retour achat (action « Envoyer retour IC »).

Une même commande peut être envoyée plusieurs fois mais vous serez alerté qu’elle a déjà été transmise. Un nouvelle commande vente sera alors créée dans « A » et vous devrez veiller à y supprimer la précédente.
Vous pouvez retenir cette solution en cas de modification de commande tant qu’elle n’a pas été entamée pour « A ».
A défaut, vous devrez saisir les modifications de part et d’autre.

Type de ligne

Nous avons vu ci-dessus le cas des lignes de « Type » ‘Compte général’ et ‘Article’.

Notez qu’il est aussi possible de facturer directement des lignes de « Type » ‘Article’ ou de passer commande de lignes de « Type » ‘Compte général’.

Les lignes de « Type » suivant peuvent également être utilisées sur le document vente moyennant quelques remarques :

RessourceUne correspondance devra alors être établie en précisant sur la fiche ressource concernée le « N° cte gén achat parten IC » (en référence au « Plan comptable intersociétés »).
ImmobilisationLe « N° » de celle-ci n’est pas repris dans la société partenaire.
Sur le document reçu (facture achat dans « B » ou commande vente dans « A » dans les cas ci-dessus), le « N° » sera vide et devra être complété avant de pouvoir valider.
En cas de cession d’une immobilisation, il faudra créer manuellement l’immobilisation dans « B » puis modifier la facture achat reçue de « A ».
Il en est de même si un article vendu par doit être immobilisé dans « B ».

Réaffectation de charges

Au sein d’un groupe, des dépenses peuvent être engagées par l’une des sociétés pour le compte des autres.

Sur le document d’achat (commande ou facture) de « A » à un fournisseur quelconque (hors groupe), les colonnes « Code du partenaire IC » (voire « Type de réf. du partenaire IC » et « Référence du partenaire IC » ) peuvent alors être renseignées (vous devrez peut-être les ajouter par « Personnaliser ») pour mentionner la société bénéficiaire.

La charge correspondante sera comptabilisée dans « A » de façon habituelle, mais puis réaffectée aux partenaires concernés.

Exemple

« A » reçoit une facture de 2000€ HT dont 1000€ concernant « B » et 100€ pour le compte de « C » (les 900€ restants étant pour son propre compte).

Le jeu d’écritures dans chacune des sociétés est le suivant (convention débit +, crédit -) :

Société4014454516xx
A-24004002000
1100-1100
B-10001000
C-100100

Le compte intermédiaire (ici 451) est défini via la configuration des « Partenaires intersociétés ».

La réaffectation peut être soumise à la TVA (voir Allouer les coûts aux partenaires intersociétés – Business Central | Microsoft Learn).

Transactions intersociétés

Cet état reprend le détail des écritures comptables relatives aux transactions validées et sera utile à la consolidation.

Configuration

Si ce n’est déjà fait, veillez à activer la nouvelle fonctionnalité « Mise à jour des fonctions : accepter automatiquement les transactions feuille comptabilité intersociétés » (proposée depuis la version 21 elle sera automatiquement activée à partir de la version 22 en avril 2023).

Rappelons que les sociétés sont totalement indépendantes et que la configuration n’est donc pas partagée.
Les « Packages de configuration » permettront cependant d’exporter des données de configuration d’une société à l’autre.
Il faudra alors veiller à reporter les éventuelles modifications dans les sociétés concernées.

Les copies d’écran ci-après illustrent la configuration de la société « A » (à gauche) et « B » (à droite).

Paramètres intersociétés

Accessible depuis la page d’accueil ou la liste des « Partenaires intersociétés », c’est ici qu’est défini le code partenaire de la société courante (« A » est défini comme étant « A » et « B » comme étant « B »).

Il doit être strictement identique à celui défini pour celle-ci en « Paramètres intersociétés » ci-après.

Partenaires intersociétés

Remarque : à compter de la version 22 (2023 wave 1), la configuration des partenaires intersociétés figure sur la page « Paramètres intersociétés ».

Cette liste est à définir de façon identique sur chacune des sociétés. Elle permet, au sein de chaque société, d’associer les N° client/fournisseur des autres sociétés du groupe et les modalités de transmission des transactions (donc de définir « B » dans « A » et « A » dans « B »).

Notez qu’il n’est pas nécessaire de définir la société pour elle-même (« A » dans « A » ou « B » dans « B » entre parenthèses sur l’exemple ci-dessus) mais que cela permet de définir une liste exhaustive qui peut ainsi être transmise d’une société à l’autre.

En cas de transaction inverse (facturation de « B » à « A ») il faudra indiquer le « N° fournisseur » de « B » dans « A » et le « N° client de « A » dans « B ».

CodeChaque société est identifiée par un code (ici « A » et « B » mais toute autre codification plus significative peut être retenue).
Code deviseLes transactions seront transmises à la société partenaire dans sa propre devise après conversion au taux de celle-ci dans la société émettrice.
Type transfertDéfinit la méthode à utiliser pour transmettre les transaction à destination de la société concernée :
– ‘Emplacement du fichier’ : export vers un fichier à importer dans la société sœur (OnPremise uniquement).
– ‘Base de données’ : directement de la boîte d’envoi de l’une vers la boîte de réception de l’autre
– ‘E-mail’ : envoi d’un message à « Adresse e-mail » (l’option ‘Emplacement du fichier’ n’étant pas disponible en SaaS, cela permettra le transfert vers un autre environnement).
– ‘Pas de transfert intersociétés’ : permet d’identifier le « Code du partenaire IC » dans les transactions (pour en tenir compte lors de la consolidation) mais sans transfert des transactions, en particulier si la société partenaire n’a pas encore la chance de disposer de Business Central 😉
Auto. accepter les transactionsCette option évitera d’avoir à accepter les transactions reçues via une « Feuille intersociétés ».
Transactions de vente
N° clientLien avec le « N° client ». Celui-ci ne doit pas avoir d’écritures ouvertes.
Compte clientCompte général intermédiaire (Cf. Réaffectation des charges).
Type n° article venteCf. Articles
Transactions d’achat
N° fournisseurLien avec le « N° fournisseur ». Celui-ci ne doit pas avoir d’écritures ouvertes.
Compte fournisseurCompte général intermédiaire (Cf. Réaffectation des charges).
Type n° article achatCf. Articles
Imputations analytiquesUne section peut être définir pour chaque axe, avec le « Contrôle validation » habituel (Code obligatoire, Même code, pas de code).

Plan comptable intersociétés

Vous pouvez le « Copier à partir du plan comptable » puis l’élaguer pour ne conserver que les comptes concernés par les transactions intersociétés.

Notez que, si vous créez de nouveaux comptes susceptibles d’être utilisés pour les transactions intersociétés, vous devrez les ajouter au « Plan comptable intersociétés ».

Il faut alors pour chacune des sociétés, définir la correspondance avec son propre plan comptable, et ce dans chaque sens :

Envoi« N° cpte gén par déf parten IC » de son propre « Plan comptable » (à définir pour chacun des compte utilisé pour les transactions intersociétés).
RéceptionColonne « N° cpte gén pour corres » du « Plan comptable intersociétés ».
L’action « Faire correspondre au compte de même N° », appliquée aux lignes sélectionnées permet d’initialiser ceux de même N° de part et d’autre.

Vous pouvez alors « Exporter » cette liste vers un fichier (ICGLAcc.xml) pour l’importer dans les sociétés sœurs, puis définir la correspondance avec les comptes de chacune d’elles (envoi et/ou réception).

Les lignes imputées à un compte de vente dans la société « A » devront être imputées à un compte d’achat dans la société « B ».

Dans la société émettrice, il est possible de décliner plusieurs comptes de vente qui seront mappés avec autant de comptes d’achat distincts du « Plan comptable intersociétés ».

A l’inverse, dans la société réceptrice, plusieurs comptes du « Plan comptable intersociétés » peuvent correspondre à un même compte du « Plan comptable » .

Axes analytiques intersociétés

Le principe est le même que pour le plan comptable intersociétés.

Vous pouvez « Copier à partir des axes analytiques » puis les élaguer pour ne conserver que ceux utiles aux transactions intersociétés.

Vous devrez alors définir, pour chaque société, la correspondance entre ses propres axes et sections et ceux des « Axes analytiques intersociétés », et ce dans chaque sens.

EnvoiDéfinir pour chacun de ses propres « Axes analytiques » le « Code axe IC à faire corresp. » avec les « Axes analytiques intersociétés » et pour chacune de ses propres « Sections analytiques IC » le Code sect an. axe IC => corres ».
Vous devrez vraisemblablement « Personnaliser » la page pour voir ces informations.
RéceptionCompléter la colonne « Code axe à faire correspondre » du « Plan comptable intersociétés ».
L’action « Faire correspondre à l’axe analytique ayant le même code », appliquée aux lignes sélectionnées, permet d’initialiser ceux de même code de part et d’autre.

Vous pourrez alors « Exporter » ces informations (fichier ICDim.xml) pour les « Importer » dans chacune des sociétés partenaires et, là encore, y « Faire correspondre à l’axe analytique ayant le même code » (si la codification est homogène).

Si vous créez de nouveaux axes et/ou sections analytiques susceptibles d’être utilisés pour les transactions intersociétés, vous devrez, comme pour le plan comptable, les ajouter aux « axes analytiques intersociétés » et définir de part et d’autre les « Code axe à faire correspondre » et « Code section à faire corres ». 

Articles

Les options « Type n° article vente » / « Type n° article vente » retenue en « Paramètres intersociétés » définissent la correspondance entre les codification articles utilisées par chacune des société.

CommandeC’est la solution la plus simple si la codification des articles peut être commune avec celle du partenaire intersociétés.
Le « N° » article des lignes de commande achat de B est alors repris tel quel sur la ligne de la commande vente intégrée dans A.
N° article communChaque société peut utiliser des « N° » distincts, mais le « N° article commun » défini de part et d’autre sur la fiche article est le même (même principe que pour le plan comptable)
Référence articleTelle que définie en « Références d’articles »
Référence fournisseurNe s’applique qu’à « Type n° article achat ».
Vous devrez alors définir la correspondance depuis la fiche de ce dernier.

Fonctions connexes

File d’attente des travauxLe transfert entre société s’appuie sur la file travaux (Job Queue).

En cas de problème, après prise en compte du message d’erreur, la tâche pourra être relancée (Redémarrer ou « Exécution unique (premier plan) ».

L’utilisateur qui valide une transaction doit donc disposer des autorisations nécessaires (en particulier, cette fonction n’est pas autorisées à un administrateur délégué).
ConsolidationL’état « Transactions intersociétés » sera bien sûr utile mais il n’y a pas génération automatique des écritures d’élimination des prestations réciproques.
Master data synchronisationCette fonction (à partir de la version 22) s’avèrera particulièrement utile pour synchroniser des données entre sociétés partenaires.
Documents entrantsLa facture achat reçue ne fait pas référence à un « Document entrant » et à l’image de facture concernée.
TVAChaque société en tiendra compte sur sa déclaration, l’une en TVA collectée, l’autre en TVA déductible.
En cas de constitution d’un groupe TVA, la TVA sur les factures intersociétés peut être neutralisée (Cf. Fiscalité -Création d’un Groupe TVA : application depuis le 1er janvier 2023 | entreprendre.service-public.fr).
LocalisationPas de particularité fonctionnelle à ce niveau. Il faut cependant noter que les localisations distinctes relèvent d’un environnement distinct. Le « Type transfert » ‘Base de données’ n’est alors plus applicable.
Paiements & règlementsLe règlement par un compte bancaire de « B » au profit d’un compte bancaire de « A » (virement de « B » vers « A » ou prélèvement de « A » vers « B ») ne présente pas de particularités.
Il s’agit d’opérations distinctes qui ne relèvent pas du transfert intersociétés.
Un rapprochement bancaire sera réalisé de part et d’autre.
Il est également possible de passer par un compte courant (un « Compte bancaire » peut être défini à cet effet dans chacune des sociétés pour chaque société partenaire).
L’opération de règlement/paiement devra alors être comptabilisée de part et d’autre.
Produits et charges constatés d’avance (PCA/CCA)L’Extension WanaClose proposée à cet effet permet de définir les « Date début » et « Date fin » d’une ligne d’achat et de vente. Cependant, ces informations ne sont pas prises en compte pour les transactions intersociétés et devront donc, si nécessaire, être ressaisies dans la société partenaire.

Lien Permanent pour cet article : https://www.wanamics.fr/transactions-intersocietes-ou-intragroupe/

1 ping

  1. […] Transactions intersociétés (ou intragroupe) […]

Laisser un commentaire