diff --git a/README.md b/README.md index 1b30c2b..d6baac5 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,46 @@ # C.TRACK -Gestione tracking commesse semplificato (es Elettronica Scalvina) \ No newline at end of file +Gestione tracking commesse semplificato (es Elettronica Scalvina) + + + +- [C.TRACK](#ctrack) +- [Descrizione generale](#descrizione-generale) + - [Gestione Licenze](#gestione-licenze) + - [Modalità operativa](#modalità-operativa) + + + +# Descrizione generale + +L'applicativo ha un DB Custom per la gestione lite/semplificata delle commesse. + +## Gestione Licenze + +La gestione licenze è fatta come per GPW, sul conteggio dei token attivi - dato dal MAX(OPERATORI, Postazioni), rispetto alla key di auth registrata + +## Modalità operativa + +* gestione linee di montaggio/assemblaggio ed in genere task manuali (registrazione impegno orario su commesse da + fasi svolte da operatori/postazioni anche contemporanee) +* implementazione pilota x ElettronicaScalvina (versione BASE) + +L'applicativo gestisce (SENZA integrazione con sistemi informativi esterni) le informazioni collegate alla gestione di fasi manuali. + +In particolare si tratta di + +* registrare MANUALMENTE i TASK (= gli ordini di produzione, con set minimo: cod_ordine, cod_articolo, qta_richiesta) +* obbligatorio RICONOSCIMENTO dell'operatore (barcode? QRCode?) +* utilizzare il barcode ove possibile (es fase di registrazione TAKS) +* decodificare l'informazione in modo parametrico (es. ordini iniziano per "ORD*", lungh minima 10 char...; articoli iniziano per "ART*"; qta da produrre è una cifra < 999'999) --> vedere ad esempio modalità riconoscimento datamatrix in GMW +* al PRIMO caricamento di un TASK (riconosciuto dal codice UNIVOCO dell'ordine di lavoro NON ancora registrato su DB) --> predisposizione alla registrazione del record +* letto il valore CHIAVE (esterna) --> sono accettati i dati a correto (codice articolo e quantità da produrre) +* conferma una volta letto il set intero --> CREAZIONE DELLA PROMESSA (PromessaODL) +* Una volta creata la promessa (intestata su un GRUPPO GLOBALE) questa diventa attiva e "accettabile" per l'avvio di qualsiasi fase di lavoro (NON E' preimpostato un ciclo, si ileva qulsiasi fase venisse associata in futuro) +* Ogni postazione potrà (anche contemporaneamente ad altre) INIZIARE UNA REGISTARZIONE, ovvero registrare un PERIODO di attività (=fase di alvoro specifica) da associare al TASK, tendenzialmente per una quantità COMPLETA (= tutto quanto indicato come Qta_RICHIESTA) +* Una volta avviata un attività questa potrà SOLO essere CONCLUSA/SOSPESA. Se SOSPESA si propone DI DEFAULT di riaprirla (es dopo una pausa o il giorno successivo) sullo stesso impianto/postazione. Se viceversa fosse segnalata come conclusa NON verrà proposto di riavviarla (ma non sarà impedito, es fasi di riparazione post collaudo...) +* Possiamo avere TANTE registrazioni di PERIODI di attività per OGNI task attivo (fino a quando il task non viene chiuso). Ogni registrazione DOVREBBE riportare la quantità evasa nel periodo (se non fatto verrebbe sbagliata registrazione tempo ciclo/produttività personale) +* Una vlta chiusa ulima registrazione, nelle postazioni abilitate si può CHIUDERE il TASK (=lavorazione) e da quel momento NON si può riaprire (tipicamente collaudo, primo collaudo o collaudo successivo per pezzi ripresi) +* Esistono le "fasi standard" (da effettuare su TUTTI i pezzi richiesti) e le fasi di ripresa (tipicamente solo su un subset dei prodotti) +* Output: report base (excel) delle fasi (TUTTE!) associate ad ogni task, con durata TOTALE fase (e quantità pari a quella ordinata - con le fasi di ripresa POTREBBE NON essere vero...) +* Totale tempo fasi / pezzi --> TC stimato +* Si potrebbe costruire un grafico / curva (opzionale, in secondo periodo) per indicare una CURVA del TCiclo al variare della uantità di pezzi lanciati in un ordine di produzione \ No newline at end of file diff --git a/README.pdf b/README.pdf new file mode 100644 index 0000000..fabb54b Binary files /dev/null and b/README.pdf differ