CPQ in Accordo: dal preventivo all'ordine immutabile

In breve. Il flusso commerciale di Accordo parte da un catalogo — prodotti, versioni, offerte, componenti, fasce — e arriva a un unico ordine immutabile passando per righe prezzate sul server, una versione congelata del preventivo, una decisione umana e una firma con eventi verificati. La tesi che ne ricavo, ed è interpretazione mia: il CPQ funziona quando ogni passo congela ciò che il passo dopo deve credere — il preventivo congela i termini, la firma congela l'impegno, l'ordine congela il fatto. Con il flusso e i limiti scritti. Pubblicato il 6 ottobre 2026.

Dal catalogo alla versione congelata

Il modello di prezzo è una catena: prodotto, versione di prodotto, offerta con i suoi componenti, fasce di prezzo. Un'offerta può mescolare addebiti una tantum e ricorrenti; ogni componente dichiara il suo modello — fisso, per unità, a volume, a fasce graduate. Si sincronizza il catalogo, si crea il preventivo su un'opportunità con un listino e una valuta, si aggiungono righe con quantità e sconto: ogni importo è calcolato dal server, ogni mutazione è la stessa azione server che usa anche l'interfaccia.

Alla sottomissione, il preventivo congela una versione immutabile: identità e revisione dell'offerta, definizioni dei componenti, intero programma delle fasce, quantità, listino, sconto e netto per componente, provenienza e totali raggruppati. Tutto ciò che serve a riprodurre la decisione dopo qualsiasi cambio di catalogo — provato così: un cambio di fasce e prezzi crea nuove revisioni di offerta mentre ogni versione esistente resta byte-identica, e le nuove bozze prezzano alla revisione nuova. È il cuore dell'hub sulle approvazioni commerciali: termini calcolati, approvati e congelati, ricostruibili sempre.

Dalla firma all'ordine unico

Una versione approvata continua oltre: la busta di firma produce eventi verificati e un artefatto firmato con hash, e dalla versione approvata nasce esattamente un ordine immutabile. Poi l'ordine attiva contratto commerciale, versione immutabile del contratto, sottoscrizione e obbligazioni esplicitamente in attesa — ogni componente classificato, mai indovinato.

Ogni passo ha il suo limite scritto. La sincronizzazione del catalogo gira contro un provider di comodo: nessun catalogo esterno reale è collegato, e il denaro è in centesimi interi senza cambi — le valute non si sommano mai. La firma usa un provider di comodo con chiave webhook solo per test: nessun connettore reale esiste, e l'hash dell'artefatto è quello dichiarato dal provider, non ricalcolato in modo indipendente. E dopo l'ordine non c'è esecuzione automatica di rinnovi, cancellazioni, fatturazione o notifiche al cliente. Niente tasse, conversioni, consumi misurati, prorate, PDF, pagamenti o fatturazione: fasce a volume e graduate sì, il resto no.

Chi decide, e con quale prova

Tra versione e firma sta la decisione umana, con le stesse regole del discount approval con soglie: un solo attore può decidere — l'umano — e un agente che chiede di approvare viene rifiutato. Una decisione per versione, concorrenza ottimistica sulle bozze, rifiutato che torna in bozza e risottomette come versione 2.

E la tesi completa sul perché — agenti che propongono, policy deterministica che governa, umani nominati che decidono, audit su ogni verdetto — è nel pillar sull'autonomia sotto controllo. Lo stato di ogni job dell'area è nel job Commercial Operations / CPQ: una riga esce dallo stato non supportato solo quando un test la prova. La solution Commercial Operations rimanda al registro dei claim per la verità di implementazione.

Fatti e limiti, separati

Fatti: catena prodotto-versione-offerta-componenti-fasce; righe prezzate sul server con totali raggruppati; versione immutabile che congela tutto il necessario alla riproduzione; firma con eventi verificati e artefatto con hash; esattamente un ordine immutabile per versione approvata; attivazione in contratto, sottoscrizione e obbligazioni classificate.

Limiti: catalogo e firma su provider di comodo, nessun connettore reale; centesimi interi senza cambi; hash dichiarato dal provider; nessuna esecuzione automatica dopo l'ordine; niente tasse, prorate, PDF, pagamenti, fatturazione. Un flusso e tre congelamenti non misurano quanto il disegno regga in produzione: misurano che la catena esiste, gira e dichiara i suoi confini.

Domande frequenti

Cosa congela una versione di preventivo?

Tutto ciò che serve a riprodurre la decisione: offerta e revisione, componenti, fasce, quantità, listino, sconto, netto e totali. Dopo un cambio di catalogo le vecchie versioni restano byte-identiche.

Cosa succede dopo l'approvazione?

La versione approvata va in firma — eventi verificati e artefatto con hash — e ne nasce esattamente un ordine immutabile, che poi attiva contratto, sottoscrizione e obbligazioni in attesa.

Cosa manca nel flusso commerciale?

I connettori reali: catalogo e firma girano su provider di comodo. E dopo l'ordine non c'è nulla di automatico: niente rinnovi, cancellazioni, fatturazione o notifiche eseguite dal sistema.

Come è prezzata una riga?

Sul server, da catalogo: ogni componente con il suo modello — fisso, per unità, a volume o a fasce graduate — con quantità e sconto in basis point. L'interfaccia mostra gli stessi numeri perché chiama le stesse azioni server.