Come gestisce sconti di volume che variano per regione e per prodotto?

01Il problema di business

Un produttore vende un ampio catalogo tramite distributori regionali. Tre elementi variano contemporaneamente, e interagiscono:

• Regione. Lo stesso articolo ha un costo diverso in due territori, e le due regioni non hanno a magazzino un catalogo identico.
• Quantità. Chi ne compra dieci paga un prezzo; chi ne compra cento ne paga un altro. Lo schema di scaglioni non è uniforme: varia da prodotto a prodotto.
• Eccezioni. Alcuni articoli non hanno alcun prezzo di listino. Sono solo su preventivo, e quali siano varia da regione a regione.

Un distributore che prepara un preventivo dovrebbe ottenere il numero giusto senza sapere nulla di tutto questo. E quando arriva l'aggiornamento annuale dei prezzi, deve essere un caricamento di dati, non un progetto.

Quest'ultima frase è il requisito che decide in silenzio l'intero progetto, ed è di solito quello che nessuno esplicita.

02Perché l'approccio ovvio non funziona

Un listino per regione per scaglione di quantità

La mossa naturale, una volta capito che un listino consente prezzi regionali, è crearne altri: Europa 10–49, Europa 50–99, Europa 100+, e lo stesso per ogni altra regione. Fallisce per un motivo strutturale e non estetico:

L'aritmetica della manutenzione è il secondo problema, e si aggrava. Poiché un listino può essere reso disponibile in base a quasi qualsiasi condizione, un catalogo reale tende ad accumularne: territorio, canale, un paio di accordi negoziati. Moltiplichi quel numero, qualunque sia, per gli scaglioni: su un catalogo di 1.637 prodotti, due regioni per quattro scaglioni fanno già otto listini e oltre diecimila righe di prezzo da mantenere coerenti tra loro a ogni revisione dei prezzi. Trasforma inoltre il menu a tendina in un elenco di nomi quasi identici tra cui un distributore deve scegliere correttamente ogni volta.

Memorizzare prezzi assoluti per scaglione

Ovunque finiscano gli scaglioni, l'istinto è memorizzare il prezzo dello scaglione, perché è ciò che contiene il foglio di calcolo di origine. Così ogni futura variazione di prezzo diventa una ricostruzione: il prezzo di listino si sposta, e ogni scaglione di quel prodotto va ricalcolato e reinserito. Nella pratica questo non avviene, e gli scaglioni finiscono in silenzio per descrivere i prezzi dell'anno scorso.

Memorizzi invece la percentuale. Il prezzo di listino si sposta, lo scaglione lo segue automaticamente, e l'aggiornamento annuale è una sola importazione in un solo listino.

Prezzare a zero ciò che non ha prezzo

Gli articoli solo su preventivo non hanno un prezzo, e la scorciatoia allettante è una riga di prezzo pari a 0. Uno zero è un numero: confluisce nel totale della riga, nel valore del preventivo, nella previsione, e sembra del tutto legittimo per tutto il percorso. Omettere la riga è meglio ma ancora non basta, perché una riga di prezzo mancante è indistinguibile da una che nessuno ha ancora configurato, e su un catalogo di queste dimensioni molte mancano semplicemente.

Uno sconto sull'intero preventivo

Esiste uno sconto nativo a livello di preventivo, sia in percentuale sia come importo. È lo strumento giusto per una concessione negoziata su una trattativa, e quello sbagliato qui, perché non può dire questa riga ha diritto a uno sconto di volume e quella no. Il prezzo per volume è un fatto che riguarda la singola riga.

03Modello dati

Quattro aspetti, quattro collocazioni diverse. Le fondamenta sono trattate nel Blueprint 007: un prodotto non ha alcun prezzo; il prezzo risiede su una riga di collegamento tra il prodotto e un listino, e tutto ciò che segue poggia su questo. Questo esempio prezza per regione, ma nel meccanismo nulla è regionale: legga «regione» qui sotto come «la dimensione che separa i suoi listini, qualunque sia». L'articolo del centro assistenza Coevera Price lists offre solo una panoramica dei listini e non è la fonte per le loro regole di disponibilità; il livello di sconti descritto sotto non vi è documentato, ed è per questo che viene modellato.

La riga di listino è l'intero vincolo

Una riga di listino è un prodotto, un listino, una valuta, un prezzo, e un oggetto di impostazioni il cui contenuto completo è un livello di accesso e un elenco facoltativo di ruoli. Non c'è quantità minima, né massima, né raccolta di scaglioni, né tabella di soglie. Una riga, un prezzo. Ogni decisione di progettazione che segue discende da questo solo fatto.

Tre fatti per regione che non sono lo stesso fatto

La gestione delle eccezioni funziona solo quando si nota che sono distinti, perché confonderne due qualsiasi produce numeri sbagliati senza che nulla lo segnali:

Il terzo esiste proprio per togliere l'ambiguità al secondo. Con esso, una riga mancante più una casella non spuntata è un allarme di qualità dei dati; senza, lo stesso stato è invisibile.

La forma che ne è risultata su un catalogo reale

Circa un quarto di tutti gli inserimenti regionali non ha un prezzo per scelta. Questa proporzione è il motivo per cui il meccanismo delle eccezioni qui non è un caso limite: è una parte fondamentale del modello.

04Configurazione a livello di campo

Proprietà del listino da conoscere

Come un listino diventa disponibile

Il filtro rules ha la stessa anatomia dei filtri nel resto della piattaforma: un flag di attivazione, un operatore di gruppo, un riquadro di filtro principale che indica un'entità, e riquadri affiancati per le entità correlate. In una configurazione funzionante a due regioni ogni listino contiene:

• isEnabled: true, operatore And;
• un riquadro principale su Opportunity senza condizioni;
• un riquadro affiancato su Quote con esattamente una condizione: un menu a tendina Region, operatore Is, che corrisponde all'opzione della regione di quel listino.

Entrambi i listini filtrano lo stesso campo e ne rivendicano un'opzione diversa, quindi impostare la regione sul preventivo restringe il menu a tendina a una sola scelta sensata. Il listino che l'utente sceglie poi viene registrato sul preventivo in una relazione nativa con il listino, così il preventivo conserva una traccia permanente dei prezzi da cui è stato costruito.

E non c'è nulla di regionale: un menu a tendina della regione è semplicemente ciò su cui filtrava questo catalogo. Il selettore del campo di condizione propone il preventivo, l'opportunità e l'account, quindi la disponibilità può basarsi su un livello dell'account, un tipo di contratto, un flag di partner, un attributo dell'opportunità. Queste tre entità sono l'intero ambito: la regola non va oltre.

E tra tutto ciò che può verificare, la quantità manca: la quantità appartiene alla riga del preventivo, e nessun record valutato dal filtro la contiene. È l'intero motivo per cui il prezzo per volume non può risiedere in un listino, ed è il perno su cui ruota il resto di questo blueprint.

Che cosa succede quando si sceglie un listino

• Prima della scelta: il pannello indica "Without price list" e ogni prodotto aggiunto arriva a un prezzo pari a zero.
• Dopo la scelta: i prodotti aggiunti successivamente prendono il prezzo da quel listino.
• Al momento della scelta: l'interfaccia chiede se le righe già presenti sul record debbano essere riprezzate con il listino appena scelto, quindi cambiare listino a metà preventivo è un'azione con richiesta di conferma, non un ricalcolo silenzioso.

Il pannello ha anche un proprio selettore di valuta e un interruttore di sincronizzazione dei prodotti, ed esiste solo su Opportunity e Quote. Qualsiasi flusso di lavoro che abbia bisogno di righe prezzate su un'altra entità deve passare per una di queste due.

Lo schema di sconti sul prodotto

Sei campi interi, tre scaglioni, due regioni:

Due proprietà di questa struttura sono deliberate e una è un costo da accettare:

• Per prodotto, non globale. Lo schema è un attributo del prodotto, quindi un prodotto senza sconto di volume ha semplicemente campi vuoti: nessun elenco di eccezioni necessario.
• Percentuali, non prezzi. Una revisione dei prezzi è un'importazione nel listino e nient'altro. Lo schema non va mai toccato.
• I limiti degli scaglioni sono nei nomi dei campi, il che significa che sono schema, non dati. Cambiare 50–99 in 50–149 significa rinominare un campo più una migrazione, e ogni report, modulo e processo che vi fa riferimento. Il §6 torna su questo punto.

Sulla riga del preventivo

La riga del preventivo ha nativamente quantity, price, amount, discount_percentage e discount_value. Una configurazione funzionante aggiunge un campo personalizzato, un prezzo unitario netto, così il valore scontato viene memorizzato esplicitamente anziché dedotto in seguito dagli altri.

Una nota pratica osservata su quel campo: la sua etichetta e il suo api_name erano divergenti, con il nome API che portava ancora un suffisso di regione di un progetto precedente che l'etichetta non menziona più. Le etichette sono modificabili e i nomi API sono ciò a cui si legano integrazioni, importazioni e modelli dei processi, quindi il nome API con cui crea un campo è quello con cui convivrà. Gli dia il nome di ciò che è, non del primo posto in cui è stato usato.

05Automazione e logica

Che cosa va calcolato

Tutto quanto sopra è modello dati. L'unico elemento di logica è: data la quantità di una riga e la regione del preventivo, trovare lo scaglione giusto e applicarlo. In sequenza: leggere la quantità dalla riga del preventivo; selezionare il campo dello scaglione corrispondente alla regione del preventivo; se contiene una percentuale, scriverla nella percentuale di sconto della riga, oppure calcolare e scrivere il prezzo unitario netto.

Perché questo è un unico processo

La maggior parte delle automazioni su questa piattaforma si frammenta in diversi processi, perché un processo porta un solo filtro i cui rami seguono la regola della prima corrispondenza, e condizioni indipendenti quindi non possono condividerlo: è il vincolo alla base del Blueprint 011.

Gli scaglioni di quantità sono il caso opposto. Si escludono a vicenda: una riga di 60 unità è in esattamente uno scaglione. Quindi la regola della prima corrispondenza non è un ostacolo, è la semantica desiderata, e un unico filtro con i rami ordinati dallo scaglione più grande in giù è la forma corretta e completa. Li ordini in modo decrescente e la prima corrispondenza sarà sempre quella giusta.

Il ramo di eccezione che è facile dimenticare

Un prodotto con prezzo su richiesta non deve ricevere uno sconto senza che nessuno se ne accorga: non ha un prezzo di listino da scontare. Il filtro degli scaglioni ha bisogno di un ramo precedente sul flag di prezzo su richiesta che indirizzi la riga a una persona. Senza di esso, un articolo solo su preventivo su una riga di grande quantità applica in silenzio una percentuale di sconto a un prezzo che non esiste.

La precedenza, che va decisa anziché scoperta

Il preventivo ha anche uno sconto nativo sull'intero preventivo. Quando una riga ha uno sconto di volume, due sconti sono in gioco, e nulla nella piattaforma decide se si sommano, se prevale il maggiore o se uno sconto negoziato sul preventivo sostituisce lo schema. Lo decida, lo scriva nel processo e lo inserisca nel modello del preventivo: altrimenti ogni distributore risponde in modo diverso e il reporting sui margini perde di significato.

Che cosa il listino farà e non farà al suo posto

La regola di disponibilità decide quali listini vengono proposti: non prezza nulla. È una persona che seleziona un listino a prezzare le nuove righe nell'interfaccia, e il Blueprint 007 documenta l'equivalente sul percorso API: una riga creata senza un prezzo esplicito arriva a zero indipendentemente da quanto costi il prodotto in qualsiasi listino. Entrambi i percorsi convergono sullo stesso errore, quindi qualsiasi importazione, integrazione o automazione che costruisce righe deve impostare il prezzo da sé.

06Limiti e compromessi

• I limiti degli scaglioni sono schema. Poiché ogni scaglione è un campo, i limiti sono fissati nei nomi dei campi e nei moduli. Aggiungere uno scaglione o spostare un limite è una modifica di campo, una migrazione dei dati e una modifica a tutto ciò che vi fa riferimento, non una modifica di configurazione. Scelga gli scaglioni aspettandosi che sopravvivano a diversi listini.
• Ogni listino deve condividere un'unica struttura di scaglioni. Un catalogo che arriva con cinque scaglioni in un listino e tre in un altro non può essere rappresentato fedelmente: o si normalizza sugli scaglioni comuni e si perde la granularità più fine, o si moltiplicano i campi per listino e il modulo del prodotto diventa inutilizzabile. Il modello attivo ha scelto la prima opzione e ha eliminato due scaglioni a bassa quantità che esistevano in una sola regione. Si noti l'asimmetria: la selezione scala liberamente con nuovi listini, lo schema di sconti no.
• La quantità non può mai arrivare a un listino. La regola di disponibilità valuta i campi del preventivo, dell'opportunità e dell'account; la quantità è una proprietà della riga del preventivo. Quasi ogni altra dimensione le è accessibile, questa no, ed è il motivo strutturale per cui l'intero approccio risiede sul prodotto anziché nel listino.
• Lo zero è l'impostazione predefinita, non l'eccezione. Il pannello si apre su "Without price list", quindi un record il cui autore non ha mai toccato il menu a tendina prezza ogni riga a zero e sembra completo. Nessuna regola lo impedisce, perché le regole decidono solo che cosa propone il menu a tendina. Dove i preventivi contano, tratti le «righe salvate senza listino» come un errore di validazione e le intercetti deliberatamente.
• Regole di disponibilità sovrapposte producono una scelta, non una soluzione. Più listini possono essere validi contemporaneamente, quindi due regole che corrispondono entrambe lasciano l'utente davanti a due opzioni plausibili senza indicazioni, e scegliere di nuovo chiede di riprezzare tutto ciò che è già sul record. Scriva regole che si escludano a vicenda.
• Una riga di prezzo mancante è ambigua a meno che non intervenga per disambiguarla. L'assenza significa solo su preventivo oppure non configurato, e la piattaforma non può dirle quale dei due. È il flag a separarli, e deve essere mantenuto da ciò che carica il catalogo, altrimenti degenera nella stessa ambiguità.
• Due sconti possono applicarsi a una riga e nulla fa da arbitro. Lo sconto a livello di riga e lo sconto a livello di preventivo coesistono senza una precedenza definita.
• I listini pianificati non sono stati messi alla prova. Tipo, stato e limiti di data sono verificati nello schema ma non nel comportamento: come un listino Scheduled diventi Active, e che cosa succeda ai preventivi che fanno riferimento a uno Expired, non è stato osservato.
• La riga del preventivo non registra la provenienza del prezzo, come descritto nel Blueprint 007. Il preventivo registra quale listino ha usato; la singola riga non registra da quale riga di prezzo proviene, quindi una successiva variazione di prezzo non può essere ricondotta ai preventivi che avrebbe modificato.
• Un nome API è di fatto permanente; un'etichetta no. Divergono, e il nome API è quello a cui si lega ogni integrazione.

Il compromesso da dichiarare apertamente

Mettere lo schema sul prodotto sotto forma di percentuali garantisce la cosa che conta di più in una vita pluriennale: la revisione annuale dei prezzi resta un caricamento di dati. I nuovi prezzi vengono importati nel listino, e lo schema di sconti, i flag di eccezione e l'automazione restano tutti intatti. Il costo è che i limiti degli scaglioni diventano schema, un'unica struttura deve servire ogni regione, e il calcolo è una costruzione anziché un'impostazione. Per un catalogo di migliaia di articoli riprezzato ogni anno è un buon compromesso. Per una manciata di prodotti con scaglioni su misura per cliente è la forma del tutto sbagliata: quelli sono prezzi contrattuali, e appartengono a un listino per cliente, che è territorio del Blueprint 007 anziché di questo.

07Verifica

Letto il 2026-09-16 da uno spazio in produzione che contiene un catalogo di distribuzione per due regioni interamente importato.

• Il vincolo è stato confermato a livello di schema: l'oggetto di impostazioni di una riga di listino espone esattamente due proprietà, un enum di accesso e un elenco di ruoli. Nessuna proprietà di quantità, scaglione o soglia esiste in alcun punto del listino o delle sue righe.
• Catalogo e righe di prezzo tornano esattamente. 1.637 prodotti; 788 righe di prezzo in una regione, 1.193 nell'altra. Rispetto ai file di origine, 1.158 e 1.532 inserimenti regionali, di cui 370 e 339 contrassegnati come solo su preventivo, entrambe le cifre si riproducono con precisione: 1.158 − 370 = 788 e 1.532 − 339 = 1.193. Gli inserimenti solo su preventivo hanno un flag di prezzo su richiesta e nessuna riga di prezzo, ed è ciò che confermano quelle due sottrazioni.
• Le regole di disponibilità sono state lette per intero su entrambi i listini attivi, validi contemporaneamente: attivate, operatore And, un riquadro principale vuoto su Opportunity e un riquadro affiancato su Quote con una sola condizione Is su un menu a tendina, lo stesso campo su entrambi i listini, ciascuno dei quali ne rivendica un'opzione diversa. La regola è un normale filtro sui campi, quindi il fatto che il menu a tendina sia una regione è una proprietà di questo catalogo e non del meccanismo.
• Le proprietà del listino, cioè il tipo Standard/Scheduled, lo stato a quattro valori, le date di inizio e di fine che delimitano un periodo di prezzi, e un listino predefinito fornito inattivo che contiene ancora righe dalla creazione dei prodotti, sono state lette dai record in produzione.
• Lo schema di sconti è stato letto dallo schema del prodotto: sei campi interi di percentuale, tre scaglioni per due regioni, più due caselle di prezzo su richiesta per regione e un campo di disponibilità a selezione multipla.
• I campi della riga del preventivo sono stati letti, compresi quantità, prezzo, importo, percentuale di sconto e valore dello sconto nativi, e un campo personalizzato del prezzo unitario netto la cui etichetta e il cui nome API sono divergenti.

Non osservato, e dichiarato come tale:

• Il calcolo dello scaglione. Nessun processo nello spazio calcola uno sconto di volume. Il modello è popolato; la logica non è costruita. Il progetto del §5 è ciò che le primitive consentono, non qualcosa visto funzionare.
• Il comportamento dei listini pianificati: attivazione, scadenza e l'effetto sui record che fanno già riferimento a un listino.
• Se uno sconto a livello di riga e uno sconto a livello di preventivo si compongano, e in quale ordine.
• Se il menu a tendina del listino e la richiesta di riprezzare abbiano un equivalente sul percorso API, dove una riga creata senza prezzo arriva semplicemente a zero.

Che cosa segnalerebbe una regressione

• Righe del preventivo che arrivano a un prezzo pari a zero. L'errore di gran lunga più probabile, e sembra un numero reale fino alla previsione. Controlli qualsiasi importazione o automazione che crea righe senza impostare esplicitamente un prezzo.
• Righe di prezzo più numerose degli inserimenti regionali dopo una revisione dei prezzi. Significa che l'importazione ha creato righe per prodotti solo su preventivo, e quei prodotti riceveranno ora in silenzio sconti di volume su un prezzo che non dovrebbe esistere.
• Record con righe ma senza alcun listino registrato. Nessuno ha spostato il menu a tendina da "Without price list", quindi ogni riga è a zero. È lo stato predefinito, non un guasto raro, ed è per questo che va inserito nella validazione anziché in una revisione mensile.
• Un campo di scaglione compilato su un prodotto con il flag di prezzo su richiesta spuntato. Una contraddizione nei dati che il ramo di eccezione del §5 esiste per intercettare.

Blueprint correlati

• Blueprint 007 — Come fissa prezzi diversi per lo stesso prodotto per regione, segmento o contratto? — il modello di listino su cui si basa tutto questo, e il rifiuto dell'API di risolvere un prezzo.
• Blueprint 011 — Come mantiene gestibili centinaia di automazioni del CRM? — i filtri con regola della prima corrispondenza, e perché gli scaglioni di volume sono il caso in cui è esattamente ciò che si vuole.
• Blueprint 005 — Come migra i contatti da un altro sistema senza perdere dati senza accorgersene? — perché un'importazione del catalogo ha bisogno di un controllo del tasso di riempimento, e quanto silenziosamente un valore può non arrivare a destinazione.
• Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un oggetto? — il quadro per decidere che uno schema di scaglioni appartiene al prodotto anziché a una nuova entità.