Fase 1B - Catalogo moduli business¶

Data audit: 2026-06-30

Documento collegato: docs/processo/inventario_fase1_catalogo_moduli_tenant.md

Scopo¶

Questa fase traduce l'inventario tecnico in una proposta business-operativa. L'obiettivo e' decidere quali moduli sono prodotti attivabili per tenant, quali sono componenti core, quali sono add-on e quali sono integrazioni.

Questo documento non introduce codice e non modifica il runtime.

Principio guida¶

Un modulo vendibile deve avere identita autonoma:

nome commerciale chiaro;
codice stabile;
menu principale o esperienza utente riconoscibile;
profili collegabili;
stato attivabile per tenant;
eventuale piano/listino;
eventuali limiti;
dipendenze esplicite.

Una capability core invece serve piu moduli e non dovrebbe essere venduta da sola, anche se puo avere feature flag o menu tecnici.

Classificazione proposta¶

Codice canonico proposto	Nome business	Tipo	Codice tecnico attuale	Owner funzionale	Decisione proposta
`core_anagrafiche`	Anagrafiche e Tenant Data	Core	`anagrafiche` / feature `feature.anagrafiche.tenant_access`	Platform / Operations	Core non vendibile, prerequisito per quasi tutto
`core_documentale`	Documentale Base	Modulo base vendibile o incluso	`documentale`	Documentale / Operations	Tenere come modulo base esplicito, evitare force-enable a regime
`safe_ras`	Safe RAS	Modulo vendibile	`ras` + parti `commerciale` + `documentale`	Safecondo / RAS	Prodotto verticale principale
`safe_commerciale`	Commerciale e Contratti	Modulo vendibile	`commerciale`	Sales Operations	Separare CRM/listini/contratti dal portale amministratore
`safe_formazione`	Formazione	Modulo vendibile	`formazione`	Formazione	Modulo autonomo con add-on portale/SSO/sync
`safe_tecnici`	Tecnici e Incarichi	Modulo vendibile	`tecnici`, `interventi`	Operations tecniche	Accorpare tecnici + interventi in un prodotto operativo
`safe_ticketing`	Ticketing e Servizi	Modulo vendibile leggero	`tickets`	Customer Operations	Vendibile solo se c'e' un workflow assistenza chiaro
`safe_calendar`	Calendario Operativo	Capability core/add-on	`calendar`	Platform / Operations	Non vendere da solo nella prima versione; agganciarlo ai moduli che lo usano
`safe_mailops`	MailOps	Add-on	`mailops`	Operations / Documentale	Add-on di documentale o commerciale
`safe_file_space`	Spazio File Tecnici	Add-on quantitativo	`tecnico_file_space`	Operations tecniche	Add-on di `safe_tecnici`, con quote
`safe_dvr`	DVR e Valutazioni	Modulo verticale/add-on	`dvr`	Sicurezza / Documentale	Add-on verticale di documentale, candidato a modulo separato
`safe_compila`	Compila Digitale	Add-on	`safecondo_compila` / feature `feature.compila.*`	RAS / Documentale	Add-on di RAS/documentale
`safe_admin_portal`	Portale Amministratore	Add-on/prodotto verticale	`amministratore_condominio`	Safecondo	Add-on di commerciale/RAS, non modulo tecnico isolato
`integration_osm`	Integrazione OSM/Dorotech	Integrazione	`osm`	Integrations	Capability a pagamento o inclusa per tenant specifici
`core_catalogo_servizi`	Catalogo Servizi e Listini	Core control-plane	`service_catalog`, `CommercialeListino*`	Commerciale / Platform	Motore prezzi/listini, non modulo tenant

Pacchetti iniziali consigliati¶

Pacchetto Core Platform¶

Sempre presente, non venduto come modulo autonomo:

core_anagrafiche
core_catalogo_servizi
tenant registry;
IAM/RBAC;
policy menu;
audit accessi;
provisioning tenant.

Nota: il core puo essere nascosto ai tenant non amministrativi. L'attivazione commerciale non dovrebbe mai disattivarlo in modo distruttivo.

Pacchetto Documentale¶

Prodotto base per gestione documenti:

modulo: core_documentale;
menu: documenti, categorie, template, pacchetti, archivio;
feature: export bundle, versioning, fast upload;
profili: cliente, admin tenant, readonly;
limiti possibili: spazio storage, numero documenti, numero template, export mensili;
add-on: safe_mailops, safe_compila, safe_dvr.

Pacchetto Safe RAS¶

Prodotto verticale principale:

modulo: safe_ras;
dipendenze: core_documentale, safe_commerciale;
menu: offerta RAS, calcolo RAS, RAS in lavorazione, monitor, export;
service code correnti: AMM_PORTALE_RAS, AMM_RAS_SCAD_DOC, RAS_CONDOMINIO, RAS_CONDOMINIO_RED, RAS_CONDOMINIO_RIAL;
listini: CommercialeListino, CommercialeListinoServizio, CommercialeListinoFascia, CommercialeListinoRegola;
limiti possibili: condomini attivi, pratiche RAS/mese, export ZIP, utenti amministratore, storage allegati;
add-on: portale amministratore, Compila Digitale, integrazione OSM, moduli DVR/DUVRI.

Pacchetto Commerciale¶

Prodotto per richieste, offerte, contratti e listini:

modulo: safe_commerciale;
menu: cruscotti, richieste, offerte, contratti, listini, attivazioni, rendicontazione;
profili: gestione, commerciale, operatore admin;
feature: print engine esterno contratti, print engine AMM portale;
limiti possibili: offerte/mese, contratti attivi, utenti commerciali, listini attivi;
dipendenze: core anagrafiche e catalogo servizi.

Pacchetto Formazione¶

Prodotto autonomo:

modulo: safe_formazione;
menu: pianificazione, didattica, monitoraggio, WooCommerce, reportistica;
profilo: operatore formazione;
feature: portale esterno, SSO, sync attestati;
limiti possibili: discenti, corsi, edizioni, attestati, sync WooCommerce;
add-on: portale discenti, SSO, sync certificati.

Pacchetto Tecnici¶

Prodotto operativo:

modulo: safe_tecnici;
assorbe: tecnici + interventi come prodotto unico;
menu: cruscotto tecnici, incarichi, rapportini, fornitori, calendario tecnico;
profili: tecnico, admin tecnico;
limiti possibili: tecnici attivi, incarichi/mese, rapportini, allegati, spazio file;
add-on: safe_file_space, calendario avanzato.

Pacchetto Ticketing¶

Prodotto leggero o incluso nei piani superiori:

modulo: safe_ticketing;
menu: ticket, kanban, conversazioni, import;
limiti possibili: ticket/mese, canali, utenti operatori;
dipendenze: core anagrafiche; opzionale calendario.

Moduli da non vendere da soli nella prima versione¶

Codice	Motivo
`safe_calendar`	E' aggregatore trasversale; meglio abilitarlo come capability inclusa nei moduli che lo richiedono
`core_catalogo_servizi`	E' motore amministrativo/listini, non esperienza tenant
`core_anagrafiche`	E' fondazione dati; venderlo da solo rischia di rompere flussi
`integration_osm`	E' integrazione specifica, meglio come add-on o capability tenant-specific

Dipendenze proposte¶

Modulo	Dipendenze obbligatorie	Dipendenze opzionali
`core_documentale`	`core_anagrafiche`	`safe_mailops`, `safe_compila`, `safe_dvr`
`safe_ras`	`core_anagrafiche`, `core_documentale`, `safe_commerciale`	`safe_admin_portal`, `safe_compila`, `integration_osm`, `safe_tecnici`, `safe_calendar`
`safe_commerciale`	`core_anagrafiche`, `core_catalogo_servizi`	`safe_admin_portal`, `safe_ras`, `integration_osm`
`safe_formazione`	`core_anagrafiche`	portale esterno, SSO, sync certificati, WooCommerce
`safe_tecnici`	`core_anagrafiche`	`safe_calendar`, `safe_file_space`, `core_documentale`
`safe_ticketing`	`core_anagrafiche`	`safe_calendar`, `safe_mailops`
`safe_dvr`	`core_documentale`, `core_anagrafiche`	`safe_compila`, `safe_tecnici`
`safe_mailops`	`core_documentale`	`safe_ticketing`, `safe_commerciale`
`safe_file_space`	`safe_tecnici`	`core_documentale`

Service code preliminari¶

I service code attuali vanno normalizzati ma non rimossi subito. Proposta:

Service code attuale	Service code canonico proposto	Modulo	Tipo prezzo
`AMM_PORTALE_RAS`	`SAFE_RAS_ADMIN_PORTAL`	`safe_admin_portal` / `safe_ras`	canone annuo
`AMM_RAS_SCAD_DOC`	`SAFE_RAS_ADMIN_DOC_EXPIRY`	`safe_admin_portal` / `safe_ras`	canone/servizio
`RAS_CONDOMINIO`	`SAFE_RAS_CONDOMINIO`	`safe_ras`	servizio base
`RAS_CONDOMINIO_RED`	`SAFE_RAS_REDAZIONE`	`safe_ras`	fascia/forfait/unita
`RAS_CONDOMINIO_RIAL`	`SAFE_RAS_RIALLINEAMENTO`	`safe_ras`	fascia/forfait/unita
codici formazione WooCommerce	`SAFE_FORM_TRAINING_*`	`safe_formazione`	per corso/posto/piano
codici tecnici/interventi futuri	`SAFE_TECH_*`	`safe_tecnici`	piano o consumo
codici ticket futuri	`SAFE_TICKET_*`	`safe_ticketing`	piano o consumo

Compatibilita: nella fase tecnica si puo mantenere mapping legacy -> canonico, evitando di rompere offerte, contratti e documenti gia esistenti.

Piani commerciali suggeriti¶

Struttura comune¶

Ogni modulo vendibile dovrebbe avere almeno:

trial: attivo con scadenza e limiti bassi;
base: funzionalita essenziali;
pro: automazioni, export, maggiori limiti;
enterprise: limiti custom, integrazioni, supporto e regole avanzate;
addon: attivazione puntuale collegata a un modulo padre.

Esempio piani per `safe_ras`¶

Piano	Include	Limiti indicativi	Add-on
`trial`	RAS base, documentale minimo	poche pratiche, scadenza breve	nessuno o demo
`base`	RAS redazione/riallineamento, offerte, contratti	pratiche e condomini limitati	Compila, portale amministratore
`pro`	export, monitor, automazioni, listini completi	limiti piu alti	OSM, DVR
`enterprise`	limiti custom, integrazioni, regole dedicate	custom	tutti

Esempio piani per `safe_formazione`¶

Piano	Include	Limiti indicativi	Add-on
`base`	corsi, edizioni, discenti, attestati	discenti/corsi limitati	nessuno
`pro`	monitoraggio, reportistica, WooCommerce	limiti superiori	portale discenti
`enterprise`	SSO, sync certificati, regole custom	custom	tutti

Regole e limiti standard¶

La fase tecnica dovrebbe introdurre un vocabolario comune di limiti:

Chiave limite	Ambito	Esempi moduli
`users.max`	tenant/modulo	tutti i moduli vendibili
`storage.bytes`	tenant/modulo/utente	documentale, tecnici, mailops
`documents.max`	tenant/modulo	documentale, RAS, DVR
`exports.monthly`	tenant/modulo	documentale, RAS
`practices.monthly`	tenant/modulo	RAS, DVR, tecnici
`tickets.monthly`	tenant/modulo	ticketing
`courses.active`	tenant/modulo	formazione
`students.active`	tenant/modulo	formazione
`integrations.enabled`	tenant/modulo	OSM, WooCommerce, SSO

Stati standard:

trial
active
readonly
suspended
expired
disabled

Ogni modulo deve dichiarare:

menu root;
sottomenu;
route o endpoint;
ordine;
icona;
feature richiesta;
profilo richiesto;
stato minimo richiesto;
comportamento in readonly.

Esempio concettuale:

Modulo	Menu root	Sottomenu
`core_documentale`	Documentale	Documenti, Categorie, Template, Pacchetti, Archivio
`safe_ras`	RAS	Offerte RAS, Calcolo RAS, RAS in lavorazione, Monitor, Export
`safe_commerciale`	Commerciale	Richieste, Offerte, Contratti, Listini, Attivazioni
`safe_formazione`	Formazione	Pianificazione, Didattica, Monitoraggio
`safe_tecnici`	Tecnici	Cruscotto, Incarichi, Rapportini, Fornitori, File
`safe_ticketing`	Ticket	Lista, Kanban, Conversazioni, Import

Decisioni consigliate ora¶

Usare core_* per componenti non vendibili e safe_* per moduli/prodotti tenant.
Considerare safe_ras, safe_formazione, safe_commerciale, safe_tecnici, safe_ticketing i primi moduli vendibili.
Tenere core_documentale come modulo base esplicito, non come forzatura invisibile.
Trattare safe_calendar come capability trasversale nella prima versione.
Trattare safe_mailops, safe_file_space, safe_compila, safe_admin_portal, integration_osm come add-on.
Non generalizzare subito CommercialeListino* a tutto: usarlo come motore listini verticale RAS e collegarlo al catalogo tramite adapter.
Usare ServiceCatalog come ponte iniziale verso il futuro catalogo prezzi dei moduli.
Mantenere mapping legacy dei service code per non rompere contratti/offerte esistenti.

Rischi da evitare¶

Migrare tutto il menu in una volta sola.
Cambiare service code esistenti senza mapping.
Rendere CommercialeListino* motore universale prima di aver stabilizzato il modello prezzi.
Confondere modulo tenant con servizio venduto a cliente finale.
Disattivare moduli core come anagrafiche o catalogo servizi tramite entitlement commerciale.
Continuare a usare solo menu nascosto come forma di autorizzazione.

Output fase 1B¶

Questa fase produce una proposta di perimetro:

moduli vendibili iniziali;
core non vendibile;
add-on;
integrazioni;
dipendenze;
service code canonici preliminari;
piani commerciali di base;
vocabolario limiti e stati.

La fase successiva puo essere la fase 2: specifica tecnica del modello dati, con tabelle, campi, indici, migrazioni e adapter verso le tabelle esistenti.