Item model group e item group: due responsabilità che non si sovrappongono
L’item model group è l’attributo che decide come l’articolo si comporta a magazzino e come vale. Al suo interno stanno il flag stocked product (se il prodotto genera o meno transazioni di inventario: un servizio non stocked non movimenta giacenza), il modello di valorizzazione (FIFO, LIFO, weighted average, le varianti date-controlled, standard cost, moving average), la politica di reservation (manuale, automatica, explosion), il consenso alle giacenze negative — distinto fra physical negative inventory e financial negative inventory — e i flag post physical inventory / post financial inventory, che stabiliscono se packing slip e fattura generano scritture di magazzino in contabilità.
L’item group, invece, non tocca nulla di tutto questo: è il raggruppamento a cui si agganciano gli inventory posting profiles, cioè determina quali conti di contabilità generale la transazione va a movimentare, oltre a servire come chiave di reporting. La regola mnemonica da portare all’esame è semplice: l’item model group decide come si comporta e quanto vale l’articolo, l’item group decide dove finisce in contabilità. Entrambi sono obbligatori sul released product e vivono a livello di legal entity, non a livello condiviso: due legal entity possono rilasciare lo stesso product master con item group diversi.
Unità di misura, conversioni e default order settings
L’inventory unit è l’unità in cui si tiene la giacenza e si valorizza il magazzino: è la più delicata, perché cambiarla su un prodotto che ha già transazioni non è una modifica innocua. Le altre unità operative — purchase unit, sales unit, BOM unit — si impostano sul released product, nelle rispettive sezioni di acquisto, vendita e distinta base, e servono a esprimere il documento nell’unità con cui si tratta con fornitore o cliente, lasciando che il sistema converta verso l’inventory unit.
Le conversioni si organizzano per unit of measure class: le conversioni intra-class (grammi/chilogrammi, litri/millilitri) sono definite una volta a livello di classe e valgono per tutti; quelle inter-class (pezzi verso chilogrammi, cartoni verso pezzi) vanno definite esplicitamente, in forma generica oppure specifica per prodotto. Quando esistono entrambe, la conversione product-specific prevale su quella generica: è il punto su cui l’esame costruisce lo scenario dei due articoli che usano lo stesso cartone con contenuto diverso.
I default order settings sono un’altra cosa ancora: portano sito, magazzino, lead time, quantità minima/massima/multipla, tipo di ordine di default e i flag di blocco per acquisto, inventario e vendita. Non contengono le unità di misura, e possono essere sovrascritti per combinazione sito/magazzino tramite gli item order settings.
Categorie di prodotto e organizzazione del catalogo
Le category hierarchy classificano i prodotti per finalità diverse: la gerarchia di procurement category guida policy e regole di acquisto e la ricerca nel catalogo fornitori, quella di sales category organizza l’offerta commerciale, mentre altre gerarchie servono a reporting e ricerca. Un prodotto può appartenere a più gerarchie contemporaneamente, ma a un solo nodo per gerarchia. Le categorie sono organizzazione e ricerca: non valorizzano, non contabilizzano e non pianificano. Attribuire loro effetti sul costing o sui conti è l’errore che la domanda a scelta multipla si aspetta.
Ciclo di vita e blocchi selettivi
Il product lifecycle state marca la fase del prodotto (in sviluppo, attivo, obsoleto) e porta con sé un flag decisivo: se lo stato non è attivo per la pianificazione, il prodotto viene escluso dal master planning, senza bisogno di cancellarlo o bloccarne le transazioni. È lo strumento giusto per un articolo in phase-out che si continua a vendere finché c’è giacenza ma non si vuole più riapprovvigionare.
Per fermare invece i processi si usano strumenti diversi e più chirurgici: i flag stopped nei default order settings bloccano selettivamente acquisto, vendita o movimenti di inventario; l’inventory blocking e gli inventory status (in scenari WMS avanzato) rendono indisponibile una quantità specifica; i batch disposition code governano l’utilizzabilità di un lotto. Sono leve di ambito crescente: prodotto, quantità, lotto.
Trappole tipiche d’esame
- Le transazioni di un articolo devono andare su conti di magazzino diversi → item group: modificare l’item model group non cambia un solo conto; la contabilizzazione passa dagli inventory posting profiles per item group.
- Cambiare metodo di costing o consentire giacenza negativa → item model group: e attenzione alla distinzione physical/financial negative, perché lo scenario descrive spesso solo la spedizione senza fattura.
- Il prodotto si vende in cartoni ma si valorizza a pezzi → unità sul released product: purchase unit e sales unit stanno sul prodotto rilasciato; i default order settings portano sito, magazzino, lead time e quantità, non le unità.
- La stessa conversione cartone→pezzi vale per un articolo ma non per un altro → conversione product-specific: quella definita per il prodotto sovrascrive la generica; se lo scenario dice “solo per questo articolo”, la risposta non è la classe.
- Articolo in phase-out che non deve più essere pianificato ma resta vendibile → lifecycle state non attivo per la pianificazione: bloccarlo nei default order settings o cancellare il coverage group è la risposta sbagliata perché ferma anche la vendita o cambia la logica di copertura.
- Servono raggruppamenti per ricerca e policy di acquisto → product category, non item group: l’item group non è una tassonomia commerciale, e usarlo come tale produce piani dei conti ingestibili.