DAX

[PASCALESAAR]

Bonjour les experts dax
j'ai importé une table 'sinistres_regles' qui est une jointure de tables en SQL
j'ai écrit une mesure pour calculer le nombre de dossier en stock, le résultat match bien avec l'équivalent de ma requête SQL
j'ai écrit une mesure pour calculer le coût des sinistres, le résultat matche avec celui de la requête SQL existante

par contre quand je calcule le coût des sinistres en stock , le résultat est très différent de celui de la BD.

Mes requêtes SQL utilisent les mêmes jointures de tables que ma table 'sinistres regles' dans POWER BI  comme base du FROM.

je joins à mon message les captures des scripts dxa que j'ai écrit.

[v-karpurapud]

Hi @PASCALESAAR 

We have not received a response from you regarding the query and were following up to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank You.

[Praful_Potphode]

Hi @PASCALESAAR 

try measure below:

Montant Dossiers en Stock version 1= 
VAR startdate = MIN(Dates[Date])
VAR enddate = MAX(Dates[Date])

-- 1. Identify the Claims (Numesini1) that match your criteria in the SORT table
VAR FilteredNumesini = 
    CALCULATETABLE(
        VALUES(SORT_SINISTRE[NUMESINI1]),
        SORT_SINISTRE[CODTYPSO] IN {"AN", "TR"}
    )

RETURN
CALCULATE(
    -- 2. Simply SUM the amount. No need for SUMX/SUMMARIZE here.
    SUM('SINISTRES RÈGLES'[MONTREGL]),

    -- 3. Apply your date filters
    'SINISTRES RÈGLES'[DATEDECL] >= startdate,
    'SINISTRES RÈGLES'[DATEDECL] <= enddate,

    -- 4. Apply the filter from the SORT table using TREATAS
    -- This virtually propagates the filter from SORT_SINISTRE to SINISTRES RÈGLES
    TREATAS(
        FilteredNumesini, 
        'SINISTRES RÈGLES'[NUMESINI1]
    )
)

If this doesn't work, then provide sample pbix with data.

Please give kudos or mark it as solution once confirmed.

Thanks and Regards,

Praful

[PASCALESAAR]

Bonjour j'ai essayé ça ne fonctionne toujours pas

[v-karpurapud]

Hi @PASCALESAAR 

Thank you for contacting the Microsoft Fabric community forum.

Use CALCULATE over the fact table and make sure the set of claim IDs from SORT_SINISTRE is filtered by the same date window or apply the date window directly in the CALCULATE. This keeps DAX behavior identical to SQL: apply filters first, then aggregate.

Coût Sinistres En Stock =

VAR startdate = MIN(Dates[Date])

VAR enddate   = MAX(Dates[Date])



---Build the set of claim IDs that are "in stock" AND are in the date window

VAR FilteredNumesini =

    CALCULATETABLE(

        VALUES(SORT_SINISTRE[NUMESINI1]),

        SORT_SINISTRE[CODTYPSO] IN { "AN", "TR" },



        -- Important: apply the same date filter to the SORT table if SORT has a date.

        -- If the date is in SORT_SINISTRE use that column; if not, remove these two lines.

        SORT_SINISTRE[DATEDECL] >= startdate,

        SORT_SINISTRE[DATEDECL] <= enddate

    )



RETURN

CALCULATE(

    SUM('SINISTRES RÈGLES'[MONTREGL]),



    -- apply the virtual filter from SORT_SINISTRE into SINISTRES RÈGLES

    TREATAS(FilteredNumesini, 'SINISTRES RÈGLES'[NUMESINI1]),



    -- Also ensure payments are in the same date window if DATEDECL lives in payments table

    'SINISTRES RÈGLES'[DATEDECL] >= startdate,

    'SINISTRES RÈGLES'[DATEDECL] <= enddate

)

If a relationship exists and filter direction flows from SORT_SINISTRE -> SINISTRES RÈGLES, you can simplify:

 

Coût Sinistres En Stock (simple) =

CALCULATE(

    SUM('SINISTRES RÈGLES'[MONTREGL]),

    FILTER(

        SORT_SINISTRE,

        SORT_SINISTRE[CODTYPSO] IN { "AN", "TR" }

        -- + date filter on SORT_SINISTRE if needed

    )

  )

Use this only if you know the relationship is active and direction propagates from SORT to payments.

 

I hope this information is helpful. If you have any further questions, please let us know. we can assist you further.

Regards,

Microsoft Fabric Community Support Team.
 

[v-karpurapud]

Hi @PASCALESAAR 

I wanted to check if you’ve had a chance to review the information provided. If you have any further questions, please let us know. Has your issue been resolved? If not, please share more details so we can assist you further.

Thank You.

[PASCALESAAR]

la requete DAX que vous m'avez fournie me renvoie le même résultat que celle que j'ai ecrite

Montant Dossiers en Stock =

VAR startdate = MIN(Dates[Date])

VAR enddate = MAX(Dates[Date])

RETURN

CALCULATE(SUMX(

    SUMMARIZE('SINISTRES RÉGLES','SINISTRES RÉGLES'[NUMERO_REGL],'SINISTRES RÉGLES'[MONTREGL]),

    'SINISTRES RÉGLES'[MONTREGL]),

FILTER(

        ALL('SINISTRES RÉGLES'),

        'SINISTRES RÉGLES'[DATEDECL]>=startdate &&

        'SINISTRES RÉGLES'[DATEDECL]<=enddate),

        SORT[CODTYPSO] IN {"AN", "TR"},

        CROSSFILTER(SORT_SINISTRE[NUMESINI1], SINISTRE[NUMESINI1] , Both))

[v-karpurapud · Accepted solution]

Hi @PASCALESAAR 

The issue is not with your DAX logic but with the structure of the table imported into Power BI. The SINISTRES RÈGLES / CLAIMS RULES table is already the result of SQL joins, which leads to duplicated claim rows when there are multiple matches in the joined tables. SQL handles these duplicates during aggregation, but when you import this table into Power BI and apply additional filters like the CODTYPSO filter from the SORT_SINISTRE table Power BI effectively joins the data again. This causes COUNT measures to match SQL results since DISTINCTCOUNT removes duplicates, but SUM and SUMX give incorrect totals because they sum over the duplicated records.

To verify, check if the fact table has multiple rows per claim ID; if it does, the amounts will not match SQL as long as you use a pre-joined table. The best solution is to import the base fact table and the SORT_SINISTRE table separately, letting Power BI handle the join, which ensures accurate results. If you can't change the data model, you can work around this by deduplicating the fact table in your measure, such as by summarizing at the claim ID level and using a single amount per claim, to better match SQL behavior.

 If you have any further questions, please let us know. we can assist you further.

Best Regards.
 

[PASCALESAAR]

Bonjour @v-karpurapud 
Malheureusement je n'ai toujours pas pu résoudre ce problème, je reussis à bien compter le nombre de dossiersen stock et e nombre de dossiers prescirts mais au moment de calculer les montats associés , seul le montant des dossiers prescrits correspond avec le resultat de la BD.

[Zanqueta]

Hi @PASCALESAAR,

La logique pour « en stock » doit être appliquée dans CALCULATE, afin que le filtre soit imposé avant la somme.

(traduction automatique via Internet), sorry ...

Exemple simple :

Coût Sinistres En Stock =
CALCULATE(
    SUM(sinistres_regles[Montant]),
    sinistres_regles[Statut] = "En Stock"
)

Si la condition est « date de clôture vide » :

Coût Sinistres En Stock =
CALCULATE(
    SUM(sinistres_regles[Montant]),
    FILTER(
        sinistres_regles,
        ISBLANK(sinistres_regles[DateCloture])
    )
)

Pourquoi ?
En SQL, le filtre est appliqué dans le WHERE avant l’agrégation. En DAX, si vous ne l’appliquez pas correctement, le contexte peut inclure des lignes hors stock.
Utiliser CALCULATE recrée ce comportement.

If this response was helpful in any way, I’d gladly accept a 👍much like the joy of seeing a DAX measure work first time without needing another FILTER.

Please mark it as the correct solution. It helps other community members find their way faster (and saves them from another endless loop 🌀.

[PASCALESAAR]

en stock ici est une condition qui provient de la table sort_sinistre (SORT_SINISTRE[CODTYPSO] IN {"AN", "TR"} ) qui est liée à la table des sinistres.

la table sinistres_regles ne concerne que les montants réglés, et est elle aussi liée à la table des sinistres
la table sinistres est le pont entre les deux tables.