8f2b3255abd2e6008d82f6bff205855c91aaef55
Entry (l'Audit), Signature e Retainer a confronto: quante offerte sono partite questo mese, quante nell'anno, quanto valgono e quanto e' stato incassato. Le categorie si leggono da offer_macros.category, cioe' dalla stessa tassonomia che si edita da /admin/impostazioni: aggiungerne una la fa comparire, senza toccare il codice. Le categorie configurate compaiono sempre, anche a zero — "questo mese non e' partito nessun audit" e' una risposta, una riga mancante no. Il punto delicato e' l'attribuzione dell'incassato. I pagamenti stanno sul PROGETTO, non sull'offerta: per dire quanto ha incassato una linea di prodotto bisogna ridiscendere dal progetto alle sue offerte. Un'offerta sola prende tutto; piu' offerte si spartiscono in proporzione all'accepted_total; nessuna offerta finisce in una riga "Senza offerta", separata e visibile. Quella riga separata non e' prudenza teorica. Sui dati di oggi vale il 100% dell'incassato: 5.300 EUR su 5.300. I due progetti che hanno incassato (Caruso Speaker, Protocollo Estetico) non hanno nessuna offerta assegnata; i due che l'hanno (Rossi Inc, Teckell) non hanno ancora incassato. Spalmando quei soldi sulle tre categorie la dashboard avrebbe mostrato numeri inventati con un totale che quadra. Cosi' invece si vede che c'e' da assegnare le offerte. Lo stato dell'offerta non filtra niente: un retainer disdetto oggi ha comunque incassato quello che ha incassato. Stessa ragione gia' scritta in getOffersSoldBreakdown — il ciclo di vita riguarda il forecast, non lo storico. Attesi per il 2026, verificati a mano sul DB: Entry 0, Retainer 1 offerta / 200 EUR, Signature 1 / 7.000 EUR, Senza offerta 5.300 EUR incassati. Nessuna partenza ad agosto. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
ClientHub portale clienti
Languages
TypeScript
80.5%
HTML
18.6%
Shell
0.4%
CSS
0.4%