Fermer

août 16, 2018

Modèles de conception pour les traductions historiques dans Oracle HFM partie 1


Le sujet de la conversion des devises dans Oracle Hyperion Financial Management (HFM) suscite toujours beaucoup de confusion. Je me concentrerai ici sur l'un de ses aspects les plus difficiles – la traduction de comptes de capitaux propres / capitaux, alias traduction historique. Je soutiens que:

  • «Remplacer les comptes», la conception traditionnelle des traductions historiques, n'est pas la solution idéale pour les applications où les structures de consolidation nécessitent des traductions multicouches ou où les journaux ou les détails personnalisés sont actifs.
  • La raison principale est que les comptes de substitution fonctionnent, mais ne traitent pas directement le problème de la conversion périodique des comptes de capital comme l'exigent les PCGR
  • Une meilleure solution consiste à utiliser le TransPeriodic intégré de HFM. fonction à:
    • Rationaliser la traduction périodique des comptes de capital avec le taux de fin de mois
    • Réserver les différences d'échange résultantes aux comptes de conversion cumulative
    • Créer une interface d'ajustement manuel pour que les utilisateurs affinent le résultat rationalisé

Un design traditionnel et pourquoi il est mauvais

D'après mon expérience, dans le monde des HFM, la traduction en actions est le plus souvent gérée par un ensemble de comptes dits «de substitution». Cet ensemble de remplacement, qui comprend des doublons pour tous les comptes nécessitant une traduction historique, est un cumul placé à l’extérieur du bilan et utilisé pour suivre les soldes en devises et peut-être aussi pour saisir des montants pré-convertis. Ce suivi et cette entrée ont lieu au niveau de ; Une fois que HFM traite une devise étrangère, il extrait les soldes de pour remplacer (c.-à-d. remplacer) les résultats de la traduction par défaut HFM – d'où le nom "remplacer les comptes".

  1. Les soldes d'ouverture sont retirés de l'année précédente
  2. Le processus peut varier ici:
    • Parfois, les règles de calcul collectent le numéro de la devise locale et lui appliquent un taux de change: fin, moyenne ou un certain taux pondéré saisi par l'utilisateur;
    • dans les comptes de dérogation.
  3. Le solde final est calculé comme le solde d'ouverture plus l'activité.
  4. Les nombres calculés ci-dessus sont extraits de à .

Je note en passant un certain degré de douleur implicite dans la conception de l'administrateur HFM: il / elle doit conserver des comptes de substitution dupliqués pour chaque devise de reporting, maintenir un code moins lisible avec beaucoup de ifs imbriqués et d'impacts contre-intuitifs (impact de dans la dernière période jusqu'à l'année suivante par exemple) et traitent de l'adaptation des entrées périodiques pour les numéros de remplacement (car les utilisateurs les plus probables n'apprécieront pas de les entrer de manière cumulative). Mais tout cela est tolérable par rapport aux défauts qui pourraient être perçus comme des facteurs de rupture lors de l’établissement de la traduction:

  • Tout d’abord, il ya ce problème apparent de pré-stadification (à ) avant de traiter ). Il est pertinent de comparer cela à la façon dont la traduction native se produit dans HFM: elle lit d'abord les numéros locaux de puis traduit et écrit le résultat dans . Bien entendu, le calcul de pré-staging récupérera également les numéros locaux à traduire à partir de afin d’essayer d’afficher les ajustements de journal enregistrés dans les comptes de capitaux propres ou dans le compte de résultat. Mais le problème est que, à ce stade, aucune logique de calcul affectée à la couche ne s'est encore produite, est en état CH (données a changé), et également. En fin de compte, il en résulte:
    • Lecture de nombres à partir de cellules CH, c'est-à-dire à partir d'une source non fiable.
    • Absence de l'optimisation de calcul intégrée HFM (avec l'option Consolider par opposition à Consolider tout avec données ou Consolider tout) calculs à partir de la couche inférieure (), même si elle est en état OK. Par exemple, considérez la situation où les utilisateurs mettent à jour leurs journaux, mais les données chargées dans ont été calculées il y a longtemps.
  • Deuxièmement, cette conception est mal adaptée aux traductions à plusieurs étapes, qui sont des situations dans lesquelles les données sont traduites plus d'une fois dans la hiérarchie de consolidation. Le problème ici est de pousser les chiffres supérieurs. Étant donné que ces nombres sont destinés à remplacer les données, la logique de pré-staging doit désormais s’appuyer sur des entités qui ne sont pas destinées à être utilisées (pensez par exemple aux entités USD situées au bas des différentes hiérarchies, qui finissent toutes en USD) ou ne l’est que partiellement et intègrent tous les ajustements de consolidation rencontrés en cours de route dans plusieurs devises. Très probablement, la solution qui en résultera sera adaptée à des chemins de traduction spécifiques et nécessitera des mises à jour de métadonnées et de calcul à mesure que de nouvelles devises seront ajoutées à l’application. En outre, il s'avère étonnamment difficile de prélever des soldes d'ouverture pour de nouvelles devises ou de nouvelles entités mères.
  • Troisièmement, cette présentation préalable, normalement effectuée au moyen d'une série de relevés HS.Exp, aboutit presque invariablement à perte de détails personnalisés lors de la traduction – en particulier les détails intersociétés et les reports, qui sont extrêmement importants pour l'élimination des capitaux propres intersociétés. Cela se produit soit parce que la syntaxe HS.Exp appelle à affiner la résolution du POV, soit, si les utilisateurs entrent en outre des données de substitution manuellement, car il est impossible de forcer les utilisateurs à remplacer chaque intersection existante. Et pour cette raison, elle ne prend pas suffisamment en compte les nouveaux détails personnalisés ajoutés à l'application.

Mon expérience personnelle de problèmes d'évolutivité lors des mises à jour HFM suggère que toutes ces failles ont pour effet de forcer la logique de traduction périodique dans les comptes de compte de résultat) dans la perspective de cumul annuel. Une fois que l'outil approprié pour manipuler les données périodiques a été adopté, la logique s'intégrera et les préoccupations ci-dessus n'existeront plus.

Traduction périodique dans les exigences des PCGR

regarder de plus près comment les comptes de capital sont censés être traduits selon les règles de la comptabilité. Les PCGR des États-Unis et les IFRS impliquent tous deux la conversion de toute variation des soldes d’actions (c’est-à-dire l’activité en actions comprenant les opérations en capital) au taux à la date de la transaction correspondante (le taux de transaction). J'insiste sur le mot "impliquer" car le problème n'est abordé nulle part dans les sujets relatifs aux devises étrangères (ASC 830, IAS 21). L'idée implicite ici est de pouvoir concilier les transactions en capital et les soldes en résultant au sein du groupe, comme l'exigent explicitement les thèmes de consolidation (ASC 810, IAS 27). En d'autres termes, les comptes de placement dans les livres de référence et les capitaux propres dans les filiales doivent correspondre en devise de présentation pour être correctement éliminés, et c'est précisément ce que garantissent les soldes de fin de contrat à terme via les taux de transaction. Les différences de change qui en résultent sont comptabilisées dans le compte d’ajustement à la conversion cumulé dans les PCGR des États-Unis ou dans les réserves de conversion dans les autres éléments du résultat global selon les normes IFRS.

Les applications HFM ne suivent normalement pas l'activité quotidienne) et 2) la manière dont le solde de clôture n'est pas converti au taux de clôture (lorsque les comptes du bilan ne sont pas disponibles), mais accumule chaque modification du solde, dûment traduite au le taux approprié.

Le premier défi attire habituellement l’attention sur le second. Au lieu de trouver des solutions créatives à cet égard, je suggère d’utiliser le truc d’approximation que j’ai appris des clients qui effectuent leurs consolidations dans des classeurs Excel: pour accélérer les choses pendant les processus de clôture mensuelle, ils utiliseraient systématiquement le taux de fin de mois. en tant que solution de rechange pratique pour toutes les transactions effectuées pendant la période. L'approximation fonctionne généralement bien pour les rapports de fin de mois rapides et peut être affinée dans les rapports audités. Dans HFM, cela signifierait avoir un outil spécial pour le faire, et je reviendrai sur la mise au point des résultats de la traduction grâce à des ajustements de devises dans le prochain article du blog.

Voilà pour les taux de transaction. Nous pouvons maintenant reconsidérer le deuxième défi et le formuler ainsi: les soldes capitaux / capital accumulent chaque changement du solde converti au taux de fin de mois.

Maintenant que cette formulation est en place, j'aimerais souligner le fait que HFM connaît bien cette méthode de traduction. La case à cocher PVAforBalance sous les paramètres de l'application, une fois cochée, force tous les comptes de type actif et passif à se traduire exactement de cette manière. Maintenant, dans HFM, cette traduction est appelée traduction PVA (Periodic Value Added). La méthode de traduction étant en place lorsque la case n’est pas cochée – c’est-à-dire lorsque les nombres sont traduits dans la vue YTD à la place – est appelée dans le guide d’administration la traduction VAL (VALue à taux de change). Nous pouvons dire que dans la configuration typique de HFM, les comptes de bilan sont convertis en VAL et que les comptes de résultat et de flux de trésorerie sont convertis en PVA (conformément à la méthode des taux courants).

apprécions cette opposition PVA-VAL si nous l'inscrivons dans le contexte plus large de l'opposition périodique-YTD, qui se trouve au cœur même de HFM. Cette opposition est mieux décrite en termes de données remontant à travers les couches de consolidation et devenant sujettes aux réglages correspondants de HFM:

Il y a beaucoup à dire sur ce diagramme et sur L'interaction YTD en général, mais pour le moment, je signale simplement que:

  • À partir de la saisie des données en bas, à chaque niveau, HFM amène l'administrateur à sélectionner la vue principale, c'est-à-dire entre périodique et cumul. L'autre vue sera dérivée, c'est-à-dire calculée par HFM en fonction de la vue principale. Par exemple, dans la couche inférieure, la vue maître est la vue dans laquelle HFM attend des utilisateurs qu'ils chargent des données.
  • Bien que cela puisse sembler évident, il est important d'ajouter ici que la vue maître est également la vue dans lequel HFM s'attend à ce que les règles de calcul calculent les données.
  • Au niveau de la traduction, le niveau les paramètres PVA donnent à l'administrateur un certain contrôle sur les éléments à prendre en compte et sur ce qu'il faut considérer. Pour la traduction PVA, la vue périodique est la vue principale. C'est-à-dire que les données traduites sont considérées comme périodiques et que YTD est ensuite dérivé par HFM. Et pour la traduction de VAL, YTD est la vue principale et Periodic est dérivée.

HS.TransPeriodic

Avec cette introduction rapide, nous pouvons à nouveau considérer le paramètre PVAforBalance pour des besoins de traduction en équité. Cela semble être le bon endroit pour regarder, mais malheureusement, il semble être une chose tout-ou-rien – une fois allumé, il deviendra le mode de traduction par défaut pour tous les comptes de bilan. Il est toutefois utile de savoir que le moteur de calcul HFM est doté d’un ensemble de fonctions connexes, à savoir HS.DefaultTranslate et HS.Trans / TransPeriodic.

Le premier permet de remplacer les paramètres de traduction, c’est-à-dire (PVA ou VAL), – pour une unité de calcul spécifique: par exemple, un scénario particulier ou un scénario / entité. Mais c’est cette dernière fonction, qui vous donne le même contrôle sur un POV particulier au sein de l’unité de calcul, ce qui est très prometteur. En effet, nous aimerions restreindre ce comportement à certains comptes – celui de type d'équité uniquement.

La capture d'écran ci-dessus provient du guide d'administration HFM ( https: / /docs.oracle.com/cd/E57185_01/OHFMA/transperiodic.htm). TransPeriodic est la fonction qui calcule la différence d'échange entre Rate1 et Rate2 sur la partie périodique du POV source et écrit le résultat dans la partie périodique du POV cible [1]. Le POV source peut différer de la cible, mais si la source est omise dans l'appel de fonction, le même POV est utilisé.

Apparemment, si Rate2 est omis, le résultat est simplement une traduction PVA du POV source à Rate1. Par exemple, la ligne ci-dessous indique à HFM de convertir le compte de capital-actions au taux de fin de mois (EOM) (taux de clôture ou taux de clôture):

] Il n’est pas nécessaire de mentionner spécifiquement les détails personnalisés ou le protocole ICP pour le compte; la nouvelle méthode de traduction est simplement appliquée à toutes les intersections valides.

Traduction simplifiée de l'équité en aval Dans cet exemple, les comptes d’actions sont assortis des détails suivants:

Ligne 199: La liste de comptes mise en boucle ici ("PVAatEOM") est UD -based – c'est la liste des comptes qui ont tapé "PVAatEOM" dans leur propriété UD1. C'est la liste à laquelle la traduction historique se limitera.

Ligne 200: La conception préférée pour la dimension roll-forward (désignée dans tout le code par son nom abrégé "RF") est la " true "solde final se trouvant au sommet, représentant toujours en tant que telle la somme du solde d'ouverture et de tous les membres de l'activité. Dans la grille ci-dessous, cette relation est indiquée par des lignes bleues.
Pour les membres de l'activité SwitchTypeForFlow = Y.

Lignes 201-202: Nous supposons ici que les soldes d'ouverture sont extraits des année précédente. Il ne reste donc plus qu'à traduire les membres de l'activité PVA au taux EOM trouvé dans A # EOMRate. C'est ce qui se passe à la ligne 202: TransPeriodic PVA: traduit toutes les combinaisons des comptes capturés dans la liste des membres PVAatEOM et des membres de la base de données qui représentent les actions (c'est-à-dire les membres où SwitchTypeForFlow est vraie – ligne 201). ] Le solde final est alors le membre principal regroupant le solde d'ouverture et tous les membres d'activité traduits par PVA. Les lignes rouges ci-dessous illustrent ce processus – l'activité est traduite dans la vue périodique par TransPeriodic, puis le nombre YTD est dérivé (indiqué par des lignes pointillées rouges).

Le coût de maintenance est faible: aucune action supplémentaire du côté de l’administrateur n’est nécessaire pour associer une nouvelle devise, un nouveau membre ou un compte de fonds propres. En outre, tous les détails personnalisés, y compris les détails ICP essentiels, sont soumis à la même approche de traduction et préservés lors de la traduction et de la contribution ultérieure au parent.

Conversion simplifiée des soldes d’équité

les pièces traduites du roll-forward sont la conception préférée, mais il n'est pas rare que le solde final soit chargé à partir du grand livre général. Comparez-la à la hiérarchie décrite ci-dessus:

Deux différences méritent d'être soulignées: premièrement, la cellule que nous souhaitons traduire n'est pas un flux, mais un solde (car la propriété SwitchTypeForFlow lit Non). Dans HFM, les cellules de flux prennent en charge le concept Periodical-YTD, contrairement aux cellules de balance. Comme nous allons le voir, TransPeriodic fait le même travail de traduction des cellules de type balance que des cellules de type flux. Deuxièmement, même si TransPeriodic peut "voir" la portion périodique de l'activité, cette activité est regroupée avec le solde d'ouverture au cours de la première période.

Nous pouvons généraliser davantage cette situation en l'absence de report à all, c'est-à-dire où les comptes de capitaux propres sont simplement des soldes:

Lignes 149-151: Les comptes de la liste PVAatEOM sont convertis en PVA au taux final. Aucune action supplémentaire n'est nécessaire – TransPeriodic fonctionne de la même manière avec les cellules de type balance.

Lignes 153-172: Dans la première période de la traduction PVA ci-dessus, nous pouvons distinguer deux parties du solde final: Balance @ EOM rate = Activité @ EOM rate + Opening Balance @ EOM rate. Ce qui est en fait prévu pour la première période est le solde final = le taux d'activité @ le taux de change moyen + le solde d'ouverture @ le taux historique (le taux combiné à la fin de l'année précédente). La différence entre les deux est Solde d'ouverture @ Taux historique – Solde d'ouverture @ Taux EOM = Solde d'ouverture @ (Taux historique – Taux d'ouverture). Un peu bizarrement, c'est ce qui est accompli à la ligne 169. Le taux historique combiné est calculé individuellement pour chaque intersection de solde final de l'année précédente – la liste des intersections est extraite par l'appel OpenDataUnit à la ligne 154.

ci-dessus sont deux conceptions très basiques (avec et sans roll-forward) pour construire une solution de traduction historique. Dans le prochain article, je montrerai comment TransPeriodic est également utile lors du développement de solutions complémentaires pour l'impact historique de la traduction sur le CTA et l'ajustement de la traduction

[1] . A partir de la base de données HFM, les données de perspective sont toujours stockées YTD et les données périodiques sont calculées à la volée, donc bien sûr, toute "écriture" dans la base de données se fera en YTD.




Source link