Panoramica
Questa è una cosa stimolante da chiedere a PowerBI, quindi potrebbe essere difficile trovare un approccio ordinato.
Il problema maggiore è che il modello di dati di PowerBI non supporta il concetto di un conteggio in corso - almeno non nel modo in cui lo facciamo in Excel. In Excel, una colonna può fare riferimento a valori che si verificano nella "riga precedente" di quella stessa colonna e quindi essere regolata da alcune "modifiche giornaliere" elencate in una colonna diversa.
PowerBI può solo imitare ciò sommando tutte le modifiche giornaliere su alcuni sottogruppi di righe. Prendiamo il valore della data nella nostra riga corrente e creiamo una tabella filtrata in cui tutte le date sono inferiori alla data della riga corrente e quindi sommiamo tutte le modifiche giornaliere da quel sottoinsieme. Questa può sembrare una differenza sottile, ma è abbastanza significativa:
Ciò significa che non c'è modo di "sovrascrivere" il totale corrente. L'unica matematica che si sta facendo sta accadendo sulla colonna contenente le modifiche giornaliere - la colonna contenente 'totale parziale' è solo un risultato - non viene mai utilizzata nel calcolo di nessuna riga successiva.
Dobbiamo abbandonare il concetto di "reset" e invece immaginare di creare una colonna che contenga un valore di "aggiustamento". La nostra rettifica sarà un valore che può essere incluso in modo tale che quando le condizioni descritte sono soddisfatte, il totale dei saldi e delle rettifiche giornaliere sarà pari a 1.
Se osserviamo la corsa calcolata fornita da OP, vediamo che il valore del nostro totale corrente in un giorno 'non lavorativo' appena prima di un giorno 'lavorativo' ci dà quella quantità necessaria che, se invertita, si sommerebbe a zero e fa aumentare di uno il totale parziale ogni giorno lavorativo successivo. Questo è il comportamento desiderato (con un problema che verrà descritto più avanti).
Risultato
Most Recent Date Prior to Work =
CALCULATE(
Max(Leave[Date]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] = EARLIER(Leave[Date]) -1 && Leave[Type] <> "Working" && Earlier(Leave[Type]) = "Working"
))
Aiuta a conoscere la differenza tra i contesti di riga e filtro e il modo in cui EARLIER opera per seguire questo calcolo. In questo scenario, puoi pensare a "EARLIER" come "questo riferimento punta al valore nella riga corrente" e altrimenti un riferimento a tutta la tabella restituita da "ALLEXCEPT (Leave, Leave [Id])." In questo modo, troviamo i luoghi in cui la riga corrente ha il tipo "Working" e la riga del giorno precedente ha un altro tipo.
Most Recent Date Prior to Work Complete =
CALCULATE(
Max(Leave[Most Recent Date Prior to Work]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] <= EARLIER(Leave[Date])
))
Questo calcolo imita un tipo di operazione di "riempimento". Dice "Osservando tutte le righe la cui data è precedente alla data in QUESTA riga, restituisci il valore più grande in" Data più recente prima di lavorare ".
Daily Balance Adjustment =
CALCULATE(
SUM(Leave[Running Daily Balance]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] = EARLIER(Leave[Most Recent Date Prior to Work Complete])
))
Ora che ogni riga ha un campo che spiega dove andare per trovare il saldo giornaliero da utilizzare come rettifica, possiamo semplicemente andare a cercarlo dalla tabella.
Adjusted Daily Balance = Leave[Running Daily Balance] - Leave[Daily Balance Adjustment]
E infine applichiamo l'adeguamento al totale corrente per il risultato finale.
Il problema
Questo approccio non riesce a stabilire che il conteggio non deve essere ripristinato a meno che il saldo giornaliero corrente non sia inferiore a zero. Mi è stato smentito prima, ma direi che questo non può essere realizzato nel solo DAX perché crea una dipendenza circolare. In sostanza, si richiede un requisito: utilizzare il valore aggregato per determinare cosa dovrebbe essere incluso nell'aggregazione.
Quindi questo è quanto posso portarti. Spero che sia d'aiuto.
