Modellare un gestionale ristorazione multi-tenant con fornitori globali, fornitori tenant, prodotti, prezzi, anomalie, preferiti, ordini e ruoli.
Cosa e stato studiato
Sono stati studiati i flussi di ristoranti e consulenti food cost: fornitori multipli, prodotti con formati diversi, storico prezzi, ricette, menu, carrelli, ordini e confronto tra alternative. Il problema tecnico era separare i dati di ogni cliente mantenendo componenti comuni riusabili.
Cosa e stato fatto
E stata costruita una base SaaS multi-tenant con entita, servizi e migrazioni per tenant, utenti, fornitori globali e tenant, prodotti, preferiti, anomalie, prezzi, ricette, menu, carrelli e ordini. Il catalogo comune e le associazioni tenant permettono di evitare duplicazioni inutili senza mescolare i dati dei clienti.
Come e stato fatto
La realizzazione usa PHP custom, MariaDB, migrazioni SQL, JavaScript, componenti Vue/Vite dove previsti, servizi applicativi e integrazione OpenAI per normalizzazione prezzo/kg. Le scelte tecniche sono orientate a isolamento dati, qualita dei listini, comparazione prezzi e continuita tra menu e acquisti.
Architettura e tecnologie
Come lo stack e stato usato nel progetto
Multi-tenant e isolamento dati
ChefSupport separa perimetri cliente, utenti e dati operativi, mantenendo moduli comuni per cataloghi, fornitori, ricette e ordini. L'architettura multi-tenant permette di servire piu clienti senza duplicare tutto il prodotto e senza confondere dati commerciali o listini.
Catalogo globale e associazioni tenant
Prodotti e fornitori possono avere una dimensione globale e una dimensione specifica del tenant. Le associazioni servono a riusare una base comune quando ha senso, ma consentono a ogni cliente di lavorare con preferiti, anomalie, prezzi e configurazioni proprie.
Food cost, ricette e ordini
Ricette, ingredienti, prodotti, prezzi e ordini vengono collegati per ridurre la distanza tra progettazione del menu e acquisto. Questa continuita consente di leggere il costo del piatto come risultato di dati aggiornati, non come calcolo isolato.
AI prezzo/kg come supporto governato
La normalizzazione prezzo/kg con AI viene usata per dati disomogenei, non come automatismo incontrollato. Il servizio aiuta a produrre valori confrontabili, ma richiede gestione amministrativa, controllo sugli esiti e protezione delle chiavi.
Pattern implementativi
Dettagli tecnici che hanno guidato le scelte
Migrazioni e modello dati evolutivo
Il progetto usa migrazioni SQL per far crescere il dominio in modo controllato. In un SaaS verticale il modello dati cambia con il prodotto: tenant, fornitori, prodotti, prezzi e ordini devono evolvere senza rompere dati gia acquisiti.
Servizi applicativi per food cost e prezzi
Il calcolo food cost e la normalizzazione dei prezzi vengono affidati a servizi dedicati, evitando logica dispersa nelle viste. Questa scelta rende piu verificabili calcoli, ricalcoli e casi anomali.
Import e qualita dei listini
Listini e prodotti arrivano spesso con formati imperfetti. Parser, anomalie e controlli amministrativi servono a trasformare dati disomogenei in informazioni utili senza assumere che ogni fonte sia pulita.
Governance OpenAI e controllo umano
Il client OpenAI e il manager AI prezzo/kg devono essere trattati come strumenti amministrativi: costi chiamata, qualita output, revisione umana e protezione delle chiavi sono parte della soluzione tecnica, non dettagli opzionali.
Risultati e apprendimenti
Base SaaS verticale per ristorazione e food service, con tenant, fornitori, cataloghi, prezzi, ricette, menu, carrelli, ordini e supporto AI alla normalizzazione.
- nel food service il dato utile nasce dal collegamento tra listino, ricetta e ordine
- multi-tenant non significa duplicare clienti ma separare perimetri con moduli comuni
- AI e utile quando resta dentro un processo amministrabile