# LUX Progetto per la realizzazione del "MES dei Falegnami"; che deve gestire il flusso logistico almeno di * produzione finestre e serramenti * produzione porte ... ## To Do - [ ] Completare la documentazione - [ ] Setup repo agli sviluppatori - [ ] Definizione struttura progetti - [ ] gestione articoli e gruppi (legno/vetro/ferramenta/vernici) con sottocategorie - [ ] elenco tipi legno - [ ] elenco tipi vetro - [ ] gestione listini alternativi x fornitori diversi (es preso = costoso, economico ma a lungo periodo) - [ ] gli item BOM-ALT vanno definiti a aprtire da un item BOM da configuratore/calcolo engine - [ ] gestione ricalcolo preventivo da cambio materiale BOM mantenendo coerenza del BOM parent ## Elementi della soluzione - Entità gestite ### Offerta L'offerta è il primo documento che il cliente si trova a generare prima di realizzare un nuovo progetto. Lofferta deve contenere riferimenti alle seguenti entità ARTICOLO: * prodotti forniti (i serramenti) * servizi forniti (installazione) * accessori impliciti (certificazioni prodotto, ) * accessori opzionali L'offerta è intestata ad una PERSONA (fisica o legale) L'offerta avrà dei dati di testata (relativi alla persona di chi offre e di chi riceve) + dati di dettaglio di tutti gli ARTICOLI offerti + dei dati di reseconto in termini di * tempi * costi indicati in modo analitico per ogni articolo (quantià * prezzo) + riassunti globalmente L'offerta ha un termine di validità (STANDARD) L'offerta è archiviata in un set informativo e può evolvere di stato o natura (offerta confermata vs ordine) L'offerta di norma è generata dal cliente, ma può essere prodotta per suo conto da un AGENTE /mandatario/rivenditore, che è anche lui una persona con permessi speciali che può generare offerte per nome e conto. Gli agenti costituiscono un criterio di ricerca e raggruppamento delle offerte per poter essere indivuate. Gli agenti hanno un "listino" dato da * prezzo a listino (aumentato...) * prezzo standard proposto di vendita * prezzo rock bottom minimo concesso * costo effettivo aziendale (comprensivo di margini minimi, ricarichi, costi OH) La valutazione degli agenti permette di classificarne l'efficienza in termini di% sulla differenza costo proposto/rockbottom e valutare se gestire la provvigione sulal abse di questo (step 2) L'offerta ha uno stato * aperta * chiusa con ordine * persa Un offerta può essere modificata nel tempo. Di un offerta teniamo sempre ultima versione + numero revisione (x tracciare numero modifiche ) + eventuale pdf dei documenti di ogni revisione (opzionale) ### PERSONA La persona individua un soggetto fisico o giuridico destinatario di una operazione o un riferimento. Avrà gli attributi per definire la sua natura in termini di ruoli ammessi tra * cliente * fornitore in qudsto caso i dati fiscali di riferimento devono essere completi per la documentazione tecnico/economica e fiscale di goni offerta/commessa/ordine Inoltre un tipo speciale di PERSONA è quello dell'utente applicativo distinto almeno dai seguenti ruoli * utente interno standard * agente * responsabile/amministratore interno ### ARTICOLO Gli articoli possono essere distinti per * fisico / servizio * make / buy * in caso di varianti fornitori articolo è 1 solo e gestiamo varianti fornitori come relazione esterna (con prezzo/quantità/tempi) Gli articoli conterranno minimo i seguenti dati * codice univoco interno * descrizione * codice fornitore (opzionale) * codice parlante interno * costo/prezzo (? listini esterni?) * margine standard (per classe?) Gli articoli saranno una classe di abse, estesa dalle tipologie specifiche con attributi (es dimensioni, tipologia, colore...) specifici opzionali ### Composer Il flusso di realizzazione di un offerta, dopo la fase di intestazione dell'offerta ad una persona, prevede di inserire 1-n articoli di diversa natura. Quelli in rivendita/servizi sono esplicità (quantità/costo) Gli articoli più complessi e oggetto del progetto saranno inseriti con una procedura SPECIALE; che prevede di * TIPO DI OFFERTA (x ora fissa a serramenti) * selezionare 1-n attributi "generali" dell'offerta, ad esempio * tipologia (legno, legno-alluminio, pvc) * tipologia del vetro * spessore del serramento * ... tutti gli attributi sono bloccabili a livello di istanza o meno (x evitare sovrascritture da parte dell'offerta contenitore) * selezione di un articolo DA TEMPLATE (da ragioanre se davvero articolo o un sotto oggetto) * l'articolo da template è a tutti gli effetti una singola istanza (SALVATA) di un progetto di una finestra template con le informazioni necessarie e sufficienti a definirla completamente fino a tempi/costi * questo articolo pò essere ricalcolato ogni giorno/settimana/... per essere valido come prima stima * il tempalte può essere inserito con valori standard di impostazione e valori calcolati standard di prezzo/tempi x avere una prima stima dell'offerta * l'elenco dei template è ovviametne estendibile da aprte dell'utente finale * ogni istanza di finestra (comprensiva dei suoi dati di calcolo) deve essere salvata insieme ai vari file/json/set informativi di corredo, tracui * json di progettazione * json/xml di richiesta/risposta ferramenta * json/csv di configurazione della BOM prevista dei vari componenti * altri file o oggetti encessari alle fasi di offerta fornitore e/o calcolo effettivo in produzione * l'insieme delle informazioni collezionate a livello di offerta sono poi oggetto di VALIDAZIONE in fase di conferma ordine prima della traduzione in termini di COMMESSA effettiva di lavoro. #### Template Ogni template rappresenterà un intero serramento configurato. Idealmente si parte SEMPRE da un template di fiestra definito. I template di base (nell'ordine di una decina) saranno installati da noi con il sw, l'utente potrà modificarli e/o intergrare con nuovi. Un template può essere salvata solo se valido (validato dal motore di calcolo). ### Engine CI saranno ALMENO 2 motori: * engine completo che contiene il CAM e fa calcoli esatti * eingine semplificato da browser (Threejs?) questi 2 motori sono in grado di leggere entrambi il json di configurazione serramento (JWD = Json Windows Definition) e generare uno un modello completo e l'altro uno semplificato L'operatività di editing sarà fatta nel browser sul modello semplificato Eventuali "equilibrismi" richiederanno valutazione/gestione con motore CAM. ### BOM Esempi materiali finestre | **Tipo di Legno** | **Categoria** | **Vantaggi principali** | | ------------------ | -------------------- | --------------------------------------------------------------- | | Pine | Softwood | Economico, versatile, facile da lavorare | | Douglas Fir | Softwood | Stabile, robusto, ideale per serramenti di grandi dimensioni | | Cedar | Softwood | Resistente al marciume e agli insetti, ottimo per esterni | | Engineered Redwood | Softwood (lamellare) | Stabile, durevole, adatto a climi umidi | | Accoya® | Softwood trattato | Durabilità estrema, stabile, eco-sostenibile | | Red Grandis | Softwood (denso) | Sostenibile, resistente, simile alla quercia | | Oak | Hardwood | Duro, isolante, elegante e molto resistente | | Mahogany | Hardwood | Elegante, durevole, resistente all’umidità | | Teak | Hardwood | Estremamente stabile, durevole e resistente agli agenti esterni | | Sapele | Hardwood | Aspetto decorativo, venatura a nastro simile al mogano | | Walnut | Hardwood | Pregiato, tonalità scure e venatura marcata | | Cherry | Hardwood | Caldo, elegante, si scurisce con il tempo | | Maple | Hardwood | Duro, chiaro, moderno, resistente | | Ash | Hardwood | Resistente, lavorabile, grana diritta | | Beech | Hardwood | Robusto, resistente all'abrasione, lavorabile | Esempi di vetri | **Tipo di Vetrata** | **Spessore Totale** | **Note** | | ---------------------------- | ------------------- | ---------------------------------------- | | 4 / 12 / 4 | 20 mm | Vetro doppio standard | | 33.1 / 12 / 4 | 21.5 mm | Stratificato + vetro semplice | | 6 / 14 / 6 | 26 mm | Miglior isolamento termico/acustico | | 4 / 12 / 4 / 12 / 4 (triplo) | 36 mm | Triplo vetro per case ad alta efficienza | ### Cicli #### Pezzo ## Info progetto 2026.01.21: aggiornata struttura dipendenze pacchetti con Directory.Package.props, Per aggiornare progetti esistenti, si è impiegato un tool installago globalmente (https://github.com/Webreaper/CentralisedPackageConverter), col comando (da package manager console): dotnet tool install CentralisedPackageConverter --global e poi test con central-pkg-converter -d . ed esecuzione con central-pkg-converter -f . Per ulteriori info vedere link: - https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management - https://devblogs.microsoft.com/dotnet/introducing-central-package-management/ - https://www.milanjovanovic.tech/blog/central-package-management-in-net-simplify-nuget-dependencies - https://github.com/Webreaper/CentralisedPackageConverter - https://www.youtube.com/watch?v=BwHvI6lj7xA ## Version History tabella versioni | Versione | Data | Note | | -------- | ---------- | ----------------------------------------------------------------------------------- | | 0.9.x.x | 2025.08.20 | Gestione cicli lavoro (configurazione) preliminare | | 0.9.x.x | 2025.08.20 | Gestione cicli lavoro (configurazione) preliminare | | 0.8.x.x | 2025.08.19 | Riorganizzazione DbModels e inserimento voci calcolo fasi/stage e costo lavorazioni | | 0.7.x.x | 2025.08.17 | Implementate correzioni calcoli BOM | | 0.6.x.x | 2025.08.14 | Implementati HwList | | 0.5.x.x | 2025.08.09 | Init DB completato, gestione SVG e BOM preliminari | | 0.4.x.x | 2025.08.04 | Primi test con API calcolo | | 0.3.x.x | 2025.07.24 | Aggiunta layer test REST con Insomnia | | 0.2.x.x | 2025.07.03 | Primi layer DB | | 0.1.x.x | 2025.06.14 | Avvio progetto |