Discussion :

[dbash]

Bonjour,

J'ai une question portée au niveau modélisation. Comment modéliseriez vous un compte de résultat (comptabilité).
Je sais que cela dépend fortement de la db source, mais je voulais voir si certains d'entre vous avaient déjà pu mettre en place des modèles financiers.

D'avance merci pour vos idées.

[foxrol]

Bonjour,
Regardes un tout petit peu quelles informations tu veux avoir dans ta table de fait(désolé je ne m'y connais pas du tout en compta) mais je supposes que tu dois avoir des charges/produits d’exploitations, charges/produits financiers, charges/produits exceptionnels, total des charges/produits.

A partir de la regarde les tables dans lesquelles tu retrouves ces enregistrements et petits à petit tu remonte pour construire ton schéma ainsi que les cardinalités qui vont bien. Par la suite essaie de peaufiner ton schéma en effectuant si possible une dé-normalisation (plus ici un problème de perf et d'accès aux données).
J’espères t'avoir donné un début de solution.

[Goundy]

Bonjour,

J'ai une question portée au niveau modélisation. Comment modéliseriez vous un compte de résultat (comptabilité).
Je sais que cela dépend fortement de la db source, mais je voulais voir si certains d'entre vous avaient déjà pu mettre en place des modèles financiers.

D'avance merci pour vos idées.

Faux! C'est les données source qui doivent s'adapter au modèle du Data Warehouse, ça marche pas dans l'autre sense (autrement dit, pourquoi aurons nous besoin d'un DWH).

Le but d'une Fact P&L est de pouvoir identifier les revenues, les coûts et le profit (d'ou le nom Profit & Loss), donc la fact doit résoudre l'équation: Revenues - Coûts = Profit
Pour simplifier les calculs les coûts seraient idéalement inscrits en négatif et les revenues en positif pour pouvoir tout simplement sommer dessus (surtout par le biais d'une solution OLAP).

Le modèle concrètement est très simple:
Structure de la fact:
- SK_FactProfitLoss
- FK_Date --Dépend de la granularité recherchée mais idéalement il est préférable d'être au niveau atomique de la transaction
- FK_CostCenter-- Pointe vers une dimension Centre de Coût
- FK_OperationalUnit -- Génériquement, ceci dépend du business contexte qui n'a pas été décrit dans la question initiale
- FK_TransactionType -- Optionnel, il permet d'identifier la direction des montants (+ ou -)
- Amount -- Montant -- peut être + ou -

Je me suis permis de répondre super rapidement à la question, mais il faut un peu plus de détail sur le business case pour pouvoir identifier ce qu'il faut et comment il le faut :-)
Avec plus de détail on peut étudier le cas pour une meilleure réponse

Cordialement
M.

[dbash]

Faux! C'est les données source qui doivent s'adapter au modèle du Data Warehouse, ça marche pas dans l'autre sense (autrement dit, pourquoi aurons nous besoin d'un DWH).

Euhh Faux également ! Je parlais de la DB source, pas des données ! Faut lire/comprendre ce qui a été écrit...
heureusement que les données via les ETL doivent etre dénormalisées, ce n'était pas la question...
Je parlais de la diversité des systèmes financiers de types ERP qui peuvent modéliser leur système/business de manière différentes, d'où ma question pour ceux qui ont une expérience aussi dans les ERP/BI (SAP, DAX, Sage etc...). Passez vous par un star schema par erp ou êtes vous arrivés à avoir un modèle pour différents ERPs ?

D'avance merci

[Goundy]

Euhh Faux également ! Je parlais de la DB source, pas des données ! Faut lire/comprendre ce qui a été écrit...
heureusement que les données via les ETL doivent etre dénormalisées, ce n'était pas la question...

Archi faux également ! DB Source ou données sources, le modèle doit en être globalement indépendant. Le modèle est business-driven or il représente un business case et non une autre forme de stockage pour une DB ou des données sources; ces dernières permettent simplement d'alimenter le DWH (data mart ou peu importe comment l'appelle t-on. Mais on va pas tergiverser sur ce qu'est une source et un DWH je suis certain que vous le saviez très bien, je stressais juste l'aspect séparatif des deux composantes.

Maintenant est-ce que le modèle d'un compte de résultat diffère en fonction de si on lisait dans un logiciel comptable ou dand SAP...etc etc; je dirais que le modèle diffère en fonction de la complexité du modèle comptable mis en place. Puis il n'y a pas d'autre modèle qu'un star-schema, quand on parle de reporting à la sauce BI, le dérnier layer est toujours, idéalement, sous forme multi-dimensionnelle (aka Kimball). Maintenant on peut très bien envisage une étape entre les sources et le star schema (architecture In-Mon) dans laquelle on peut par exemple appliquer quelques règles business universelle à l'entreprise et autre.... (je pense également à la méthodo Data Vault)

En conclusion, la question est très vague, il faut quelque chose de plus concret, la réponse que j'ai donné plus tôt est toujours valable et constitue une base de travaille sur laquelle toute modélisation de compte de résultat se baserait puis après il faut l'étendre pour supporter les règles spécifiques introduites par la complexité du cas. Peut être que quelqu'un de plus expérimenter que moi pourrait mieux expliquer, je ne sais pas, en tous cas je pense que le top du top c'est de travailler sur un cas concret.

J'espère que c'est plus clair que mon intervention précédente

Remarque: Je trouve votre réponse relativement agressive et dirigé à quelqu'un qui essaie de répondre à votre question initiale. Ce serait bien d'éviter ce genre de comportement ça n'aide personne... Merci.

Cordialement

[Invité]

Il est possible d'arriver à un modèle BI compta qui prend en source plusieurs ERP. C'est bien la le but de la BI d'ailleurs, de consolider.

Ca dépendra non seulement des logiciels sources, mais aussi de l'utilisation qui en est faite : le type de comptabilité (générale, analytique, ...). Il te faut donc de bonnes connaissances ou des experts métier qui peuvent répondre à tes questions, afin d'arriver à une modélisation qui consolide le tout.

Thibault

[Goundy]

Il est possible d'arriver à un modèle BI compta qui prend en source plusieurs ERP. C'est bien la le but de la BI d'ailleurs, de consolider.

Absolument; et ceci est généralement atteignable par l'application des deux axes Top-Down et Bottom-Up en parallèle, donc on peut dans un sens dire que ça dépend des logiciels sources (surtout côté technique) mais le modèle est toujours et toujours le fruit des activités d'analyse business. Après ce qui est mis dedans comme information dépend des sources c'est tout à fait le cas. J'écris ça juste par enlevé toute ambiguïté par rapport à mes réponses précédentes.

Ca dépendra non seulement des logiciels sources, mais aussi de l'utilisation qui en est faite : le type de comptabilité (générale, analytique, ...). Il te faut donc de bonnes connaissances ou des experts métier qui peuvent répondre à tes questions, afin d'arriver à une modélisation qui consolide le tout.

Tout à fait, lorsqu'on parle de compta générale/analytique on est déjà au niveau du business case, donc que l'audience utilise des classeurs format A4 ou SAP FICO le modèle restera spécifique au business case. C'est le point que je veux mettre en évidence.

[dbash]

Archi faux également ! DB Source ou données sources, le modèle doit en être globalement indépendant. Le modèle est business-driven or il représente un business case et non une autre forme de stockage pour une DB ou des données sources; ces dernières permettent simplement d'alimenter le DWH (data mart ou peu importe comment l'appelle t-on. Mais on va pas tergiverser sur ce qu'est une source et un DWH je suis certain que vous le saviez très bien, je stressais juste l'aspect séparatif des deux composantes.

On est dans du Hors sujet là... et j'ajouterai en contradiction avec ce que vous disiez précédemment.

Maintenant est-ce que le modèle d'un compte de résultat diffère en fonction de si on lisait dans un logiciel comptable ou dand SAP...etc etc; je dirais que le modèle diffère en fonction de la complexité du modèle comptable mis en place. Puis il n'y a pas d'autre modèle qu'un star-schema, quand on parle de reporting à la sauce BI, le dérnier layer est toujours, idéalement, sous forme multi-dimensionnelle (aka Kimball). Maintenant on peut très bien envisage une étape entre les sources et le star schema (architecture In-Mon) dans laquelle on peut par exemple appliquer quelques règles business universelle à l'entreprise et autre.... (je pense également à la méthodo Data Vault)

Vous vous orientez dans un sujet qui ne correspond pas aux problématiques posées...

En conclusion, la question est très vague, il faut quelque chose de plus concret, la réponse que j'ai donné plus tôt est toujours valable et constitue une base de travaille sur laquelle toute modélisation de compte de résultat se baserait puis après il faut l'étendre pour supporter les règles spécifiques introduites par la complexité du cas. Peut être que quelqu'un de plus expérimenter que moi pourrait mieux expliquer, je ne sais pas, en tous cas je pense que le top du top c'est de travailler sur un cas concret.

La question, vous ne l'avez tout simplement pas comprise... mais pas de soucis pour ça. Je vais attendre d'autres réponses.

Remarque: Je trouve votre réponse relativement agressive et dirigé à quelqu'un qui essaie de répondre à votre question initiale. Ce serait bien d'éviter ce genre de comportement ça n'aide personne... Merci.

Si je l'ai été, ce n'était pas mon but, mais revoyez plutôt votre manière de répondre car apparemment vous ne vous en rendez pas compte.
Merci donc de respecter le sujet et d'éviter le HS.

[dbash]

Il est possible d'arriver à un modèle BI compta qui prend en source plusieurs ERP. C'est bien la le but de la BI d'ailleurs, de consolider.

Ca dépendra non seulement des logiciels sources, mais aussi de l'utilisation qui en est faite : le type de comptabilité (générale, analytique, ...). Il te faut donc de bonnes connaissances ou des experts métier qui peuvent répondre à tes questions, afin d'arriver à une modélisation qui consolide le tout.

Thibault

Bonjour,
Merci pour votre réponse.
Oui je cherchais juste à avoir des retours d'expériences dans le domaine financier par exemple. Pour le type d'utilisation, on commencera toujours par du basique, donc compta générale. Ce qui manque ce sont les connaissances dans certains ERP...

[Goundy]

Si je l'ai été, ce n'était pas mon but, mais revoyez plutôt votre manière de répondre car apparemment vous ne vous en rendez pas compte.
Merci donc de respecter le sujet et d'éviter le HS.

La Question:

Comment modéliseriez vous un compte de résultat (comptabilité).

La Réponse:

Le but d'une Fact P&L est de pouvoir identifier les revenues, les coûts et le profit (d'ou le nom Profit & Loss), donc la fact doit résoudre l'équation: Revenues - Coûts = Profit
Pour simplifier les calculs les coûts seraient idéalement inscrits en négatif et les revenues en positif pour pouvoir tout simplement sommer dessus (surtout par le biais d'une solution OLAP).

Le modèle concrètement est très simple:
Structure de la fact:
- SK_FactProfitLoss
- FK_Date --Dépend de la granularité recherchée mais idéalement il est préférable d'être au niveau atomique de la transaction
- FK_CostCenter-- Pointe vers une dimension Centre de Coût
- FK_OperationalUnit -- Génériquement, ceci dépend du business contexte qui n'a pas été décrit dans la question initiale
- FK_TransactionType -- Optionnel, il permet d'identifier la direction des montants (+ ou -)
- Amount -- Montant -- peut être + ou -

Sans vouloir faire de troll
Cordialement
M.

[dbash]

Sans vouloir faire de troll
Cordialement
M.

Sans vouloir faire de troll, mais vous essayez d'en faire quand même... (encore une incohérence de votre part...)
Bien qu'il n'y ait pas eu de troll, j'ai une 1re question à laquelle vous avez répondu maintenant le reste (de votre part) est plus du HS qu'autre chose.
Sans rancune...