Comment la configuration des ledgers parallèles permet-elle à Mécaform SA de produire simultanément des états GAAP local et IFRS, et quel rôle joue ACDOCA dans ce dispositif ?

En S/4HANA, le ledger principal 0L est actif par défaut pour tous les codes société et enregistre les écritures selon le GAAP local. Un ledger parallèle (ex. 1L) peut être configuré avec une variante d'exercice différente et des règles comptables distinctes (méthodes d'amortissement, valorisation) pour répondre aux normes IFRS. Chaque écriture est stockée dans la table universelle ACDOCA avec un champ identifiant le ledger cible, évitant toute redondance. Lors des mouvements AA, les zones de dépréciation sont assignées à des groupes de ledgers distincts : par exemple, la zone '01' poste dans 0L (amortissement linéaire GAAP) et la zone '15' dans 1L (composantes IFRS). Les états financiers sont générés via la FSV qui agrège les comptes GL selon le ledger sélectionné, permettant ainsi la publication de deux jeux d'états financiers à partir d'une source unique de données.

Décrivez le processus de valorisation des postes ouverts en devise étrangère pour la filiale polonaise lors de la clôture de novembre, en précisant les paramètres techniques impliqués.

La filiale polonaise détient des postes clients/fournisseurs libellés en EUR alors que sa devise de code société est le PLN. À la clôture, il faut exécuter la valorisation de devise (foreign currency valuation) pour comptabiliser les écarts de change non réalisés. Le processus repose sur : (1) la méthode de valorisation affectée à la zone de valorisation, qui définit le type de cours (ex. cours moyen BCE au 30/11), les clés d'écriture et les comptes d'écart de change ; (2) la sélection des postes ouverts gérés en OI (Open Item Management) pour les comptes clients, fournisseurs et GL concernés ; (3) la comptabilisation d'écritures d'ajustement dans ACDOCA pour les 1 250 000 EUR de postes ouverts, avec génération de produits ou charges de change non réalisés. Ces écritures sont temporaires et seront extournées à l'ouverture de la période suivante. La variante de périodes (OB52) doit avoir la période de novembre ouverte pour les types de comptes concernés (D, K, S) avant l'exécution.

Quel est le rôle de l'Intercompany Reconciliation (ICR) pour traiter l'écart de 48 500 EUR entre la filiale française et allemande, et comment le Financial Closing Cockpit organise-t-il cette étape dans le processus de clôture ?

L'ICR (Intercompany Reconciliation) a pour objectif d'identifier et résoudre les écarts entre transactions réciproques des entités d'un même groupe. Pour l'écart de 48 500 EUR, l'ICR compare les soldes et mouvements intercompany déclarés par la filiale française (prestation facturée) et la filiale allemande (charge enregistrée) et trace le statut de résolution. Si un écart subsiste (différence de montant, de période de comptabilisation ou de classification), les équipes comptables doivent l'analyser et passer des écritures correctives avant la consolidation. Dans le Financial Closing Cockpit, cette tâche ICR est modélisée comme une étape avec dépendances : elle ne peut démarrer qu'après la clôture des sous-livres (AR/AP) des deux sociétés, elle est assignée à un responsable groupe, et son statut (en cours / validé) est journalisé. Le FCC fournit également des jalons bloquants : la publication des états financiers consolidés ne peut être déclenchée que si la tâche ICR est marquée comme résolue.

Quelles sont les causes probables pour lesquelles des factures fournisseurs valides sont exclues de la proposition F110, et quels paramètres doivent être vérifiés dans les données maîtres du Business Partner et dans FBZP ?

Plusieurs raisons peuvent expliquer l'exclusion de factures de la proposition F110 : (1) Absence de méthode de paiement valide dans la vue Comptabilité fournisseur du Business Partner au niveau du code société — c'est la condition indispensable pour que F110 propose le règlement ; (2) Aucun compte bancaire fournisseur actif n'est renseigné dans le BP pour la méthode de paiement concernée ; (3) La date d'échéance calculée (basée sur la condition de paiement et la clé de date de base, souvent la date de facture) dépasse ou précède la fenêtre de paiement paramétrée dans le run F110 (dates de prochain paiement et d'exécution) ; (4) Un blocage de paiement positionné au niveau du poste fournisseur (champ 'blocage de paiement') exclut automatiquement ce poste — comportement correct pour les 14 postes litigieux détectés, mais à corriger si le blocage est positionné par erreur sur des factures valides. Dans FBZP, il faut vérifier que les méthodes de paiement sont bien configurées par pays et code société, que les banques propres sont actives et assignées aux sociétés, et que la détermination des comptes bancaires (ranking, optimisation) est cohérente avec les devises de paiement.

Comment paramétrer l'Extended Withholding Tax (EWT) pour les fournisseurs marocains soumis à un taux de 10 %, et quel est le moment d'application (facture ou paiement) à privilégier ?

L'Extended Withholding Tax se configure via un couple Type de retenue + Code de retenue, paramétrés au niveau du code société et assignés au Business Partner fournisseur. Pour les fournisseurs marocains : (1) Créer un type de retenue défini pour le Maroc avec le moment d'application 'Au paiement' (recommandé dans ce contexte, car la retenue est prélevée lors du décaissement) ou 'À la facture' selon la réglementation locale ; (2) Créer un code de retenue avec le taux de 10 % et la base de calcul (montant brut de la facture ou montant HT selon règle locale) ; (3) Assigner ce type et code au BP fournisseur marocain dans sa vue de données fiscales. Lors de l'exécution de F110, si le moment est 'Au paiement', la retenue de 10 % est calculée et comptabilisée automatiquement au moment du run : le montant payé au fournisseur est réduit du montant de la retenue, qui est enregistré dans un compte de dette fiscale. Si le moment est 'À la facture', la retenue est comptabilisée dès la saisie de la facture (FB60/MIRO). Les comptes de comptabilisation de la retenue sont déterminés par la configuration EWT liée au code société.

Comment garantir que les postes fournisseurs bloqués pour litige sont systématiquement exclus de F110, et quelle procédure contrôlée doit encadrer la levée d'un blocage ?

En S/4HANA, un blocage de paiement positionné au niveau du poste fournisseur (champ Payment Block dans le document FI, via FB02 ou lors de la saisie) exclut automatiquement ce poste de la proposition F110 — c'est le comportement standard et attendu. Pour les 14 fournisseurs détectés dans les propositions erronées, il faut vérifier si le blocage est positionné au niveau du poste (correct) ou absent alors qu'il devrait être là. La procédure de contrôle recommandée est : (1) Lors de l'ouverture d'un litige, bloquer immédiatement le poste concerné via le motif de paiement approprié (ex. 'R' pour litige) ; (2) La levée du blocage doit faire l'objet d'une validation formelle (workflow de validation ou approbation par un responsable comptable) avant modification via FB02 ; (3) Un rapport de contrôle hebdomadaire liste les postes bloqués et leur statut afin d'éviter des blocages orphelins. Concernant les postes mal inclus dans les propositions, si le run F110 a déjà généré une proposition incluant des postes problématiques, il est possible de supprimer manuellement ces postes de la proposition avant l'étape de paiement, sans avoir à relancer un run complet.

Comment la configuration des zones de dépréciation et des groupes de ledgers permet-elle à Energitec de gérer simultanément les amortissements IFRS et GAAP français, et quel impact cela a-t-il sur les écritures générées par AFAB dans ACDOCA ?

Chaque zone de dépréciation représente un référentiel de valorisation indépendant avec sa propre clé d'amortissement (méthode linéaire/dégressive, base, taux, contrôle de période). Pour Energitec : la zone '01' est configurée avec un amortissement linéaire à 10 %/an selon les règles fiscales françaises et postée dans le ledger principal 0L (GAAP FR) ; la zone '15' est configurée selon IFRS 16 avec potentiellement une durée de vie utile économique différente, assignée au ledger parallèle 1L. Lors de l'exécution mensuelle via AFAB, le programme calcule l'amortissement pour chaque zone et génère des écritures distinctes dans ACDOCA, taguées par ledger. Ainsi, le compte de résultat 0L affiche la dotation aux amortissements fiscaux, tandis que le ledger IFRS affiche la dotation selon la durée économique. La détermination automatique des comptes GL de dotation et d'amortissements cumulés est pilotée par la configuration 'account determination' liée à la classe d'actifs et à la zone de dépréciation. La date de début du calcul d'amortissement est déclenchée par la date de mise en service/capitalisation de l'actif, selon le contrôle de période défini dans la clé d'amortissement.

Décrivez le traitement comptable des trois situations particulières d'Energitec (transfert intra-société, cession avec produit, dépréciation non planifiée) en précisant les transactions SAP et les impacts dans ACDOCA.

Pour le transfert intra-société de la machine industrielle entre deux sites : la transaction ABUMN est utilisée. Elle transfère la valeur nette comptable (VNC) d'un actif source vers un actif cible au sein du même code société, ajuste la base d'amortissement résiduelle, et conserve l'historique des valeurs dans ACDOCA. Les écritures générées débitent le compte APC du nouvel actif et créditent celui de l'ancien, avec ajustement des amortissements cumulés. Pour la cession de l'équipement informatique avec produit de 12 000 EUR (VNC 8 500 EUR) : la transaction de cession avec produit génère : sortie de la valeur brute et des amortissements cumulés de l'actif, comptabilisation du produit de cession (12 000 EUR), constatation d'une plus-value de cession (3 500 EUR = 12 000 - 8 500 EUR). Ces écritures impactent ACDOCA simultanément en AA et GL via la détermination automatique des comptes (clés de comptabilisation cession). Pour la dépréciation non planifiée sur le bâtiment : elle s'enregistre via une transaction de dépréciation exceptionnelle (AB08 ou app Fiori équivalente), constituant un ajustement de valeur en plus de l'amortissement planifié. Elle corrige la valeur comptable indépendamment de la clé d'amortissement standard et est comptabilisée dans ACDOCA comme charge exceptionnelle.

Quelles sont les étapes et précautions à respecter pour migrer les 3 200 actifs via le Migration Cockpit SAP, et comment vérifier l'exhaustivité et la cohérence des données après migration ?

Le Migration Cockpit (app Fiori 'Migrate Your Data') fournit des objets de migration dédiés aux immobilisations avec des templates de chargement structurés. Les étapes sont : (1) Extraction des données source : pour chaque actif, collecter la classe d'actifs, la date d'acquisition, la date de mise en service, la valeur brute APC, les amortissements cumulés et la VNC par zone de dépréciation ; (2) Mapping des champs dans le Migration Cockpit : associer les classes d'actifs source aux classes SAP cibles (qui portent la détermination des comptes et les valeurs par défaut) ; (3) Simulation/staging : charger les données en mode simulation pour détecter les erreurs (classes inexistantes, valeurs incohérentes, zones de dépréciation manquantes) ; (4) Migration définitive au 'cutover date' : les soldes sont chargés à la date de migration avec les valeurs de début d'exercice ou de la période de reprise ; (5) Contrôles post-migration : rapprocher la valeur brute totale SAP (87 500 000 EUR) avec le grand livre actif de l'ancien système, exécuter l'Asset History Sheet (AHS) pour vérifier les soldes d'ouverture par classe et zone, et lancer un run AFAB en simulation pour valider que les dotations calculées sont cohérentes avec les amortissements attendus. Une attention particulière est requise : le Migration Cockpit ne permet pas l'activation rétroactive de la gestion des postes ouverts sur des comptes GL existants avec solde non nul — ce point doit être anticipé dans la configuration avant migration.

Comment le Document Splitting garantit-il l'équilibre des états financiers par segment pour RetailNext, et que se passe-t-il techniquement lorsqu'une facture de loyer commune doit être répartie entre les trois segments ?

Le Document Splitting scinde automatiquement les lignes d'un document comptable selon les caractéristiques définies (ici le SEGMENT, dérivé du centre de profit). Lorsqu'une facture de loyer commune de, par exemple, 150 000 EUR mensuel est saisie avec une répartition entre trois centres de profit (donc trois segments), le moteur de Document Splitting : (1) Scinde la ligne fournisseur (crédit 150 000 EUR) en trois lignes proportionnelles correspondant à chaque segment (ex. 60 000 E-commerce / 50 000 Retail / 40 000 B2B) ; (2) Les lignes de charges sont déjà ventilées par segment via le Field Status Group qui impose la saisie du centre de profit ; (3) Pour garantir l'équilibre de chaque segment isolément, des lignes neutres (lignes de compensation intercompany-segment) sont ajoutées automatiquement, équilibrant les débits et crédits au sein de chaque dimension segment. Cela garantit qu'en extrayant les écritures ACDOCA filtrées sur un seul segment, le bilan de ce segment est équilibré. Sans Document Splitting, les lignes de contrepartie (compte fournisseur) resteraient sans affectation de segment, rendant le reporting par segment déficitaire ou excédentaire selon la dimension.

Quels mécanismes SAP S/4HANA empêchent la saisie directe sur les comptes de réconciliation clients et fournisseurs, et comment le Field Status Group contrôle-t-il les champs obligatoires sur les comptes de charges communes ?

Les comptes de réconciliation (reconciliation accounts) sont des comptes GL spéciaux configurés avec un type de compte (D pour clients, K pour fournisseurs) dans leurs données maîtres. Cette configuration interdit techniquement toute écriture directe via les transactions GL standards (FB50, F-02) : seules les écritures miroir automatiques issues des sous-livres AR/AP (lors de la comptabilisation de factures ou paiements) alimentent ces comptes. Toute tentative de saisie directe génère un message d'erreur bloquant. Pour les comptes de charges communes, le Field Status Group (FSG) assigné au compte GL détermine la visibilité et le caractère obligatoire des champs lors de la saisie. Pour imposer le centre de profit et le segment, le FSG est configuré avec ces deux champs en statut 'Required Entry' (saisie obligatoire). Le FSG est défini dans le plan de comptes et peut être surchargé par la clé de comptabilisation (posting key). En pratique, si un utilisateur tente de comptabiliser une charge commune sans renseigner le centre de profit, le système bloque la saisie avec un message d'erreur explicite, garantissant ainsi la cohérence du Document Splitting et la qualité du reporting par segment.

Comment la Financial Statement Version (FSV) et les apps Fiori analytiques s'appuyant sur ACDOCA permettent-elles à RetailNext de publier un reporting IFRS 8 par segment en temps réel, et quel rôle jouent les vues CDS dans ce dispositif ?

La Financial Statement Version (FSV) structure le reporting financier (bilan et compte de résultat) en agrégeant les comptes GL selon une hiérarchie définie (postes, groupes de postes, sous-totaux). Pour RetailNext, la FSV est configurée pour calculer les résultats par segment en filtrant les données ACDOCA sur le champ SEGMENT. Elle permet de publier des états financiers consolidés par segment conformément à IFRS 8, en s'appuyant sur les écritures splittées stockées dans ACDOCA. Pour le reporting en temps réel, les apps Fiori analytiques de type 'Analytical' s'appuient sur des vues CDS (Core Data Services) qui définissent la sémantique, les associations entre entités et les annotations analytiques. Ces vues CDS requêtent directement ACDOCA (45 000 lignes/mois) via le moteur HANA en mode in-memory avec calcul en push-down côté base de données, sans extraction préalable. Le résultat est exposé via des services OData consommés par les tuiles Fiori Smart Business, permettant un drill-down du KPI global vers le détail de chaque écriture par segment, centre de profit ou compte GL. Ce dispositif d'Embedded Analytics élimine le besoin de rapports batch périodiques et donne aux contrôleurs financiers une vision temps réel de la performance par segment.

Comment configurer et exécuter la procédure de relance (dunning) pour BioPharm Distribution, et quels éléments doivent impérativement être paramétrés dans les données maîtres du Business Partner client pour que le programme fonctionne correctement ?

La procédure de relance est configurée dans le Customizing avec : (1) Trois niveaux de relance avec leurs intervalles respectifs (ex. niveau 1 à J+10, niveau 2 à J+25, niveau 3 à J+45 après échéance) ; (2) Des montants minimum de relance par niveau pour éviter de relancer pour des montants insignifiants ; (3) Des textes de courrier distincts par niveau (rappel courtois / mise en demeure formelle / précontentieux avec mention des frais) ; (4) Des frais de relance configurés à partir du niveau 2, comptabilisés automatiquement sur un compte de produits dédié. Pour que le programme de relance calcule correctement les niveaux, la procédure de relance doit impérativement être assignée au master data du Business Partner client (vue Comptabilité client du code société). Sans cette assignation, le BP est ignoré par le run de dunning. Lors de l'exécution du programme de dunning (transaction F150 ou app Fiori équivalente), le système identifie les postes ouverts en retard (gérés en OI), calcule le niveau de relance applicable selon le dernier niveau atteint et l'intervalle configuré, génère les propositions de relance, et après validation, édite les courriers et comptabilise les frais éventuels. Le niveau de relance atteint est mémorisé dans le BP pour le prochain run.

Quelle est la différence entre 'paiement partiel' et 'solde résiduel' pour le traitement des encaissements incomplets de clients BioPharm, et comment les tolérances et reason codes interviennent-ils pour les écarts de paiement ?

Lorsqu'un client de BioPharm règle 95 % d'une facture de 10 000 EUR (soit 9 500 EUR), deux approches sont possibles : Le paiement partiel (partial payment) laisse le poste original de 10 000 EUR ouvert dans le système et crée un poste de paiement de 9 500 EUR également ouvert. Les deux postes coexistent en OI : la facture originale reste visible avec son montant intégral, et le lettrage n'est pas définitif. Cette approche facilite le suivi des relances puisque la facture reste 'ouverte'. Le solde résiduel (residual item) clôt définitivement la facture originale de 10 000 EUR et crée un nouveau poste ouvert pour le solde restant de 500 EUR, avec potentiellement un nouveau numéro de document et une nouvelle date d'échéance. Cette approche simplifie la liste des postes ouverts mais perd la référence à la facture initiale. Pour les écarts de paiement dans les limites des tolérances configurées (groupes de tolérance utilisateur) : si l'écart de 500 EUR est inférieur au seuil de tolérance, le système peut lettrer automatiquement avec comptabilisation de l'écart sur un compte de charges/escompte. Un reason code doit alors être saisi pour documenter la cause (escompte non prévu, déduction commerciale, litige partiel), permettant un reporting des motifs d'écarts. Au-delà des tolérances, la différence ne peut pas être passée automatiquement et nécessite une décision manuelle.

Comment configurer et exploiter le lettrage automatique F.13 pour les encaissements de masse de BioPharm, et quelles conditions préalables doivent être remplies pour que le programme fonctionne efficacement ?

Le programme de lettrage automatique F.13 permet de compenser des postes ouverts sans intervention manuelle, sous réserve que plusieurs conditions soient réunies : (1) Les comptes clients doivent être gérés en postes ouverts (OI Management activée) — condition sine qua non ; (2) Les postes à lettrer doivent respecter des critères d'égalité : même montant en devise, même devise, et correspondance sur des champs de correspondance définis (typiquement le champ 'Référence' contenant le numéro de facture, ou le champ 'Assignation' renseigné lors de l'import du relevé bancaire). La configuration de F.13 nécessite de définir les règles de correspondance : par compte ou groupe de comptes, en spécifiant quels champs doivent être identiques entre le débit (facture) et le crédit (encaissement) pour déclencher le lettrage automatique. Pour BioPharm, la clé de correspondance idéale est le numéro de facture dans le champ référence : lors de l'import du relevé bancaire (Bank Statement Processing), le référence de virement du client doit contenir le numéro de facture, qui est ensuite mappé dans le champ assignation ou référence du poste de paiement. F.13 tourne alors en mode simulation d'abord pour contrôle, puis en mode réel. Les postes non lettrés automatiquement (référence absente, montants non concordants) restent en suspens pour traitement manuel via F-28, où le comptable sélectionne manuellement les postes à compenser.