Quando gli attributi articolo diventano un problema

Frequentemente ci troviamo di fronte a clienti che desiderano gestire in Business Central informazioni aggiuntive sull'anagrafica articolo. Esempi tipici sono la lunghezza, lo spessore, la densità, il diametro e molte altre caratteristiche del prodotto.

Da diversi anni Business Central mette a disposizione gli Attributi articolo, una funzionalità che consente di aggiungere e gestire queste informazioni senza modificare la struttura della tabella articoli.

L'idea è valida e, in molti casi, rappresenta la soluzione migliore. Tuttavia, prima di creare decine o centinaia di attributi – e soprattutto prima di proporli come soluzione al cliente – è opportuno comprenderne il funzionamento e le implicazioni.

Come funzionano

Gli attributi articolo si definiscono nella pagina omonima di Business Central.

Una volta definito l’attributo, dobbiamo dire al sistema che tipo di dato contiene. Abbiamo a disposizione cinque possibilità:

1. Opzione

2. Testo

3. Intero

4. Decimale

5. Data

   
   

Da un punto di vista tecnico, ogni attributo non è in realtà identificato dal suo nome (anche se questo deve essere comunque univoco), bensì da un numero intero progressivo assegnato dal sistema all’atto della creazione.

Questo aspetto si ribalta quando assegniamo un attributo con un valore ad un articolo. Questi valori vanno infatti a finire nella tabella Item Attribute Value Mapping, il cui contenuto è mostrato qui sotto.

In sostanza, da un punto di vista squisitamente tecnico, il sistema memorizza, per ogni articolo, l’ID dell’attributo. Non solo. Guardando meglio la tabella, ci accorgiamo che il valore associato all’attributo non è il suo valore reale, ma un ID associato a tale valore.

Nell’esempio sopra, l’articolo 1896-S risulta avere Profondità pari a 100, che però il sistema memorizza come valore 12 dell’attributo numero 2 associato all’articolo 1896-S.

Questo significa che ogni volta che un utente inserisce una profondità nuova, il sistema crea un nuovo record nella tabella Item Attribute Value. Immaginatevi su un attributo di tipo decimale che cosa può significare.

Primo problema: importare gli attributi

L’aspetto tecnico non è secondario a quello funzionale, perché se ci troviamo di fronte un cliente che intende portarsi i valori di lunghezza, spessore ecc. dei suoi articoli dal vecchio sistema informativo a BC, importarli diventa assai complicato, perché per ciascuna coppia attributo-valore, dovremo prima di tutto determinare l’ID dell’attributo cui quel valore fa riferimento, ma soprattutto determinare se il valore indicato è già stato mappato oppure no e, nel caso, inserirlo nella tabella Item Attribute Value.

Qualcuno di voi dirà: un gioco da ragazzi, soprattutto se il codice ce lo scrive l’AI.

Forse è vero, ma una volta inseriti i valori, che cosa succede quando l’utente giustamente inizia a usare questi attributi per cercare articoli con determinate caratteristiche?

Secondo problema: il filtraggio degli articoli per attributi

Come sappiamo, in BC possiamo filtrare gli articoli per ciascun attributo. Funzionalità in effetti molto comoda, se si pensa a richieste del tipo: trovami tutti gli articoli con una lunghezza compresa tra 10 e 20 e con spessore inferiore a 2.

Questo filtro è applicabile in diversi contesti: possiamo farlo dalla lista degli articoli

o, anche, dalla più recente funzionalità Seleziona articoli presente sugli ordini di vendita e di acquisto.

Ora, considerando che i valori degli attributi di un articolo sono memorizzati in una tabella diversa dall’anagrafica, ci domandiamo: in che modo agiscono esattamente questi filtri?

Proviamo ad effettuare una ricerca di tutti gli articoli con larghezza compresa tra 50 e 150 e profondità inferiore a 100.

Una volta applicati i filtri, troviamo il risultato con una sorpresa.

Il filtro che abbiamo applicato è stato convertito in un filtro sul codice dell’articolo. Apriamo il riquadro dei filtri:

In pratica il nostro bel filtro su lunghezza e profondità si è trasformato in un filtro in OR sui codici articolo, in particolare, nel caso specifico il filtro è diventato:

1900-S|1908-S|1960-S..1964-S|1968-S|1972-S..1988-S|2000-S

A questo punto domandiamoci: supponiamo che il nostro cliente abbia 100.000 articoli in anagrafica con una codifica piena a 20 caratteri ciascuno e supponiamo che un giorno faccia una ricerca per così dire, “blanda”, che dia come risultato 90.000 articoli diversi.

Applicando il filtro in OR, nell'ipotesi peggiore che questi articoli non si trovino uno sotto l'altro ma sparsi, il filtro risultante conterrebbe 90.000 valori distinti concatenati con l'operatore "|". Siamo proprio sicuri che un filtro così esteso funzioni senza problemi?

In realtà, senza entrare nel dettaglio del codice AL che sta dietro questa complessa procedura, il problema è gestito e il risultato viene comunque dato, ma in funzione, diciamo così, del numero di valori distinti contenuti nel filtro, Business Central passa da una modalità di filtraggio puro a una modalità di visualizzazione di record temporanei.

Facciamo infine un ultimo passaggio. Se prima di applicare il filtro per attributi, applico un filtro sul codice articolo, quando poi applico il filtro sugli attributi, cosa succede? La risposta, se vogliamo, è figlia della spiegazione data sopra, ovvero Business Central elimina il filtro sul codice e lo rimpiazza con quello sugli attributi.

Nel nostro caso, insomma, non potremmo mai chiedere a Business Central di estrapolarci gli articoli con larghezza compresa tra 50 e 150, profondità inferiore a 100 e codice che inizia per 2.

Conclusioni

Gli attributi articolo non sono una funzionalità da evitare. Sono anzi estremamente utili quando devono classificare gli articoli e consentirne la ricerca.

Diventano invece una scelta discutibile quando vengono utilizzati per rappresentare dati strutturali del prodotto, come dimensioni, pesi o caratteristiche tecniche che sono parte integrante dell'anagrafica e che potrebbero essere utilizzate frequentemente nei processi aziendali.

In questi casi qualche campo in più nella tabella Articolo può rivelarsi una scelta decisamente più semplice, più efficiente e più facile da mantenere.

Potremmo quindi concludere riassumendo i pro e i contro nel loro utilizzo:

Vantaggi:

• Non bisogna aggiungere un campo per ogni nuovo attributo

• L’utente è libero di definire attributi nuovi senza passare da una richiesta di modifica tecnica

• Il filtraggio per valori di attributo è intuitivo

Svantaggi:

• L’importazione dei valori da un sistema all’altro non è semplice

• Il filtraggio per valori di attributi può comportare dei rallentamenti e ha dei limiti oggettivi

Lascio a voi la scelta della strada da intraprendere.

© 2022–2026 Marco Francesco Ferrari. Tutti i diritti riservati.