Calcolo valore magazzino e performance report L’argomento è risolto

[alex77]

Buongiorno a tutti,
torno su un report che avevo iniziato mesi fa e poi lasciato lì "a macerare". L'oggetto sono le giacenze di magazzino. Al tempo il mio problema era che nel gestionale non c'è una tabella con le giacenze, ma "solo" quella con i movimenti e volevo ricreare le giacenze con PQ (mi avete fatto capire che non era il caso ). Ho allora creato la misura sommando i movimenti "alla data", in questo modo:

Codice: Seleziona tutto

DAX.Giacenza = calculate(TOTALYTD(sum(Movimenti[Qta]),dimCalendario[Data]), dimArticoli)

Uso calculate perchè dai movimenti devo escludere alcune categorie di articoli (escluse dalla dimArticoli, ma che per escluderle dai movimenti dovrei fare merge con articoli, filtrare... penso sarebbe "pesante"). Filtro per dimCalendario per motivi simili (devo onestamente ricontrollare l'effettivo perchè...)

Il mio obiettivo è però calcolare il valore di magazzino, usando un listino mensile. La misura è la seguente:

Codice: Seleziona tutto

DAX.Valore Giacenza =
VAR vDataMax =
    MAX ( dimCalendario[Data] )
VAR vValore =
    SUMX (
        SUMMARIZE (
            Listino,
            Listino[Articolo Codice],
            "_ImportoGiacenza",
                [DAX.Giacenza]
                    * IF (
                        MAX ( dimDepositi[Deposito Valorizzato] ) = "N",
                        0,
                        CALCULATE ( MAX ( Listino[Prezzo Listino] ), dimCalendario[Data] = vDataMax )
                    )
        ),
        [_ImportoGiacenza]
    )
RETURN
    vValore

Per chiarezza: devo testare se il magazzino in cui è un codice è un magazzino che non va valorizzato ([Deposito valorizzato]="N")

Di principio, "tutto bene", ma gli oggetti sono "un po' lenti", se esplodo da anno a mese, o filtro una categoria, i grafici ci mettono un po' di secondi ad aggiornarsi. Tenete conto che i movimenti di magazzino per 3 anni "e rotti" sono circa 7 milioni di righe, gli articoli 50k, in 40 categorie, i depositi 80.

Volevo quindi chiedere se secondo voi c'è qualche strada alternativa per rendere più fluido il report - dal filtrare prima i movimenti, in PQ, a un approccio alternativo a SUMX(SUMMARIZE...) - .
Anche perchè, per completezza dovrei aggiungere ulteriore misura che calcola il wip alla data (materiale che viene scaricato dal magazzino da bolle di lavoro, ma che va considerato giacenza finchè la bolla non viene chiusa) da sommare alla giacenza e quindi aumenterebbe la complessità (senza contare che poi vorrei anche calcolare degli indici di rotazione... ma c'è tempo... )
Allego immagine del modello dati, che magari può aiutare.

Grazie per un eventuale aiuto

[Enrico Galli]

Ciao, posso sapere per quale motivo la relazione tra dimCalendario e Listino è molti-a-molti? Non può essere corretta questa cosa. Per il resto, sinceramente non so proprio che dirti... sono test che vanno fatti sul file reale guardando il performance analyzer. Così, "a capocchia", direi che FORSE Alberto Ferrari e Marco Russo potrebbero avere qualche idea utile... forse!

[alex77]

Ehm… ho creato aaaamm (annomese) nel listino è l’ho collegato con calendario. Ma effettivamente potevo collegare la data fine mese (che è quella originale nel listino) con corrispondente data nel calendario eh? Sono abile a complicarmi la vita.
Ho capito faccio una telefonata a Ferrari…
Comunque mi pare di capire che non è “dovuto” che sia lento, giusto? Quindi ci lavoro!

[Enrico Galli]

Sì, decisamente la relazione deve essere 1-molti su un campo data. E non escludo che questo di per sé migliori di molto le prestazioni, perché le relazioni molti-molti sono più deboli e molto più lente

[Enrico Galli]

Un'altra cosa: non usare mai SUMMARIZE per aggiungere colonne calcolate. E' un'opzione pressoché deprecata. Usa sempre il costrutto
ADDCOLUMNS(SUMMARIZE(tabella, tabella[colonna]), "nuovocampo", espressione)
Che nel tuo caso può anche essere un più sintetico
ADDCOLUMNS(VALUES(tabella[colonna]), "nuovocampo", espressione)

[alex77]

Buongiorno Enrico Galli
e grazie delle varie dritte. Effettivamente avevo letto che con summarize non si deve aggiungere colonne... ma quando uno è mulo...
Visto che poi mi consigli di usare values, summarize in sostanza lo devo usare quando ho bisogno di raggruppare più colonne?

Ultima questione (quella importante, al momento). Usando addcolums e values al posto di summarize la misura dà risultato errato... qualche migliaio di miliardo di euro di magazzino... un po' troppo... dico male se la misura così fatta perde il filter context sul prezzo di listino? Dipende da addcolums?

Codice: Seleziona tutto

DAX.Valore Giacenza =
VAR vDataMax =
    MAXX ( ENDOFMONTH ( dimcalendario[Data] ), [Data] )
VAR vValore =
    SUMX (
        ADDCOLUMNS (
            VALUES ( Listino[Articolo Codice] ),
            "_ValoreGiacenza",
                'Misure DAX'[DAX.Giacenza] * CALCULATE ( MAX ( Listino[Prezzo Listino] ), dimCalendario[Data] = vDataMax )
        ),
        [_ValoreGiacenza]
    )
RETURN
    vValore

[Enrico Galli]

Perché hai tolto dall'espressione di ADDCOLUMNS quel costrutto IF che mi sembrava importante?
Al di là di quello, il calcolo mi sembra scritto in modo plausibile. E no, non si perde nessun filter context eccetto quelli che sovrascrivi con i filtri di CALCULATE

[alex77]

Grazie Enrico Galli ,
La if l’ho tolta solo per alleggerire il calcolo finché non arrivo ad un dunque. Se il filter context resta devo esplorare meglio la cosa, sto facendo prove a tempo perso solo perché no resisto al desiderio di trovare una soluzione, visto che sono chiuso n casa con moglie e figli tutti col covid! Tra l’altro sistemata la relazione con la tabella calendario se torno alla mia formula originale con summarize la misura mi dà errore per mancanza di memoria. Ci lavorerò !

[alex77]

Enrico Galli ,
mi autocandido a "volpe d'oro dell'anno": era sufficiente mettere in VALUES il codice articolo dalla dimensione dimarticolo, mentre prima c'era il codice articolo dalla tabella fatti "listino". Con summarize funzionava lo stesso (o almeno mi pare), con addcolumns evidentemente no.
Comunque (dovrei controllare un po' meglio, ma...) grazie ai tuoi consigli siamo passati da 9 secondi per l'aggiornamento del grafico a 2-3. Poi in verità una volta che esplodi ad esempio una categoria e poi "torni sù" mi sembra di capire che PBI tiene in memoria il drilldown e se lo fai una seconda volta è praticamente istantaneo.

Grazie ancora per i consigli!

A.

[alex77]

Ciao Enrico Galli (o chi volesse rispondere),
un'ulteriore domanda sul tema. Ho creato una misura che calcoli la giacenza (in quantità) modificandola rispetto alla semplice somma dei movimenti. Nel dettaglio controllo che la giacenza totale (cioè in tutti i depositi, esclusi quelli che non vanno valorizzati) sia positiva, se lo è sommo la quantità altrimenti no. Poi uso questa misura nel calcolo del valore giacenza che ho postato all'inizio della discussione (al posto della misura "DAX.Giacenza", metto "DAX.Giacenza Modificata"). Il calcolo è questo:

Codice: Seleziona tutto

DAX.Giacenza Modificata = 
 var vGiacenzaNoDep = calculate('Misure DAX'[DAX.Giacenza],filter(all(dimDepositi),dimDepositi[Deposito Valorizzato]="S"))

var vGiacenzaDaValorizzare = calculate('Misure DAX'[DAX.Giacenza],dimDepositi[Deposito Valorizzato]="S")

var vTabGiac = ADDCOLUMNS(SUMMARIZE(dimArticoli,[Articolo Codice]), "GiacMod", if(vGiacenzaNoDep>=0, vGiacenzaDaValorizzare))

var vResult = SUMX(vTabGiac,[GiacMod])

return
vResult

All'interno della misura per la valorizzazione della giacenza tutto funziona perchè lavora a livello di singolo codice e poi somma con SUMX. Controllando però in una matrice il risultato di DAX.Giacenza Modificata mentre la stavo sistemando, ho visto che si comporta in modo "strano". I singoli codici hanno valore corretto, ma la somma per deposito è completamente "senza senso", dà valori altissimi (allego immagine, vedete il deposito 29, che ha pochi codici, somma totale di qualche centinaio, ma subtotale con numero abnorme). Presumo sia questione di evaluation context... qualcuno sa spiegarmi il perchè?

Grazie