# C.TRACK

Gestione tracking commesse semplificato (es Elettronica Scalvina)

<!-- TOC -->

- [C.TRACK](#ctrack)
- [Descrizione generale](#descrizione-generale)
  - [Gestione Licenze](#gestione-licenze)
  - [Maschere principali](#maschere-principali)
  - [Modalità operativa](#modalità-operativa)

<!-- /TOC -->

# 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

## Maschere principali

Ci sono le seguenti maschere principali:

* Creazione TASK (commesse) - nuova
* MAIN BCode (derivata da XPST)
* DATA EXPORT (esportazione tracciati RAW delel registrazioni x commessa, formato csv reale o da tab con type excel/csv)

## 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