Tracciabilità lavorazioni

Si tratta questa volta di generare una lista di tutte le lavorazioni presenti e, per ognuna di esse, elencare i piatti prodotti e gli articoli di magazzino utilizzati. Per capire il concetto di lavorazione si rimanda alla sezione 4.3.7.1. Una lavorazione può produrre un piatto complesso o direttamente un articolo. Per esempio, una lavorazione in cui si prelevano dal magazzino delle pesche per tagliarle a fette e servirle come dessert avrà come piatto prodotto sempre pesche. Questo report andrà a fare parte dell'applicazione adibita alla tracciabilità; per descriverlo si partirà dalla parte graca per nire ad analizzare la sezione di controllo (query SQL).

Sviluppo della parte graca

Figura 4.58: Documento PDF stampabile

Questo report si compone idealmente di tre parti, sviluppate singolarmente: ˆ lista lavorazioni: contiene il nome della lavorazione, la data di inizio e il numero

di lotto

ˆ lista piatti prodotti in seguito alla lavorazione

ˆ lista degli articoli impiegati16 per svolgere la lavorazione con annesse infor-mazioni aggiuntive relative alla data di prelievo, alla quantità prelevata e ai codici di lotto interno e del fornitore

Si può quindi pensare di ridurre la query generale alla generazione della lista delle lavorazioni e utilizzare poi due sottoreport, o due liste con due dataset diversi, per sviluppare l'elenco dei piatti e quello degli articoli. Per mantenere il report più compatto e più semplice ho optato per quest'ultima soluzione.

iReport consente la creazione di liste; ogni lista creata viene collegata automa-ticamente ad un nuovo dataset, ossia ad un serbatoio di dati del quale la lista si serve per generarsi. Come si può vedere in gura4.58, i due elenchi di piatti-articoli

16La lista degli articoli può essere vuota se in cucina sono già presenti tutti gli ingredienti necessari, senza bisogno di prelievi dal magazzino.

non hanno punti in comune, ma sono riconducibili alla stessa lavorazione; quest'ul-tima rappresenterà quindi il parametro interno passato automaticamente di volta in volta per generare le liste.

Retrocedendo di un passo nell'analisi del report si passa al layout, mostrato in gura5.16 assieme al 'Report inspector':

Figura 4.59: Layout e Report inspector

Guardando il 'Report inspector' è evidenziata la presenza di un solo gruppo, 'lavChange'; esso cambia al variare della lavorazione.

Tutte le informazioni riguardanti le lavorazioni, oltre alle due liste ausiliari, si trovano nella banda 'Detail'. La banda relativa al gruppo, invece, contiene solamente un oggetto linea, in modo da operare la suddivisione opportuna fra una lavorazione e la seguente.

Query SQL

Come accennato precedentemente, le interrogazioni sono tre, una per il report generale e le altre due per i rispettivi sottoreport.

Figura 4.60: Query SQL per il report principale

La query generale non ha bisogno di nessuna spiegazione pertanto si prosegue nell'interrogazione atta a generare la lista dei piatti prodotti. Prima di analizza-re questa query bisogna panalizza-resentaanalizza-re la tabella 'Tpla_piattilav' che contiene le informazioni relative ai piatti prodotti dalle lavorazioni.

ˆ Pi_id: id di un piatto (collegato alla tabella 'Piatti')

ˆ Ilavid: id di una lavorazione (collegato a 'Tlav_lavorazioni') ˆ Iplaqta: quantità prodotta

ˆ Iplaid: chiave primaria

Figura 4.61: Query SQL per lista piatti

La query si divide in due fasi:

ˆ nella prima incrocio la tabella dei lotti, quella dei piatti e quella delle lavora-zioni, per ottenere solo la lista dei piatti prodotti dalla lavorazione;

ˆ nella seconda incrocio la tabella dei lotti, delle lavorazioni e degli articoli, per ottenere la lista dei piatti prodotti visti come articoli17.

L'unione delle due restituisce la lista completa per la singola lavorazione passata come parametro al dataset.

Di seguito si descrive la query relativa alla lista di rintracciabilità degli articoli prelevati dal magazzino. Prima di procedere alla spiegazione è necessario presentare una nuova tabella e i collegamenti fra questa e le altre che verranno usate.

'Tsca_scarichi': per scarico si intende il prelievo di una certa quantità dello stesso prodotto dal magazzino. Non necessariamente uno scarico è eettuato per necessità di materie prime in fase di lavorazione, anche se questo è il solo caso con-siderato al momento. La tabella 'Tsca_scarichi' contiene un campo 'ILAVID' e se quest'ultimo non è nullo, signica che il prodotto prelevato serve per una lavora-zione; più precisamente, serve per la lavorazione il cui codice 'ILAVID' nella tabella 'Tlav_lavorazioni' corrisponde a 'ILAVID' nella tabella appena descritta.

17Quando il campo 'IARTID' nella tabella delle lavorazioni non è nullo signica che il piatto prodotto è un articolo.

L'altra connessione di interesse è quella con 'Tcar_carichi' mediante il campo 'ICARID': questo collegamento indica da quale carico di magazzino è stato prelevato il prodotto da utilizzare. Ad esempio, se ci sono due carichi dello stesso prodotto, con due scadenze diverse, lo scarico andrà fatto per il prodotto con scadenza più vicina in modo da gestire meglio le risorse di magazzino.

Figura 4.62: Query SQL per lista articoli

La query (in gura4.69) contiene un'interrogazione interna; quest'ultima svolge la maggior parte del lavoro poiché si occupa di mettere in relazione le tre tabelle relative a carichi, scarichi e lavorazioni.

La sottoquery con alias 'allScarichi' contiene quasi tutte le informazioni neces-sarie, mancano all'appello solamente il lotto interno dello scarico (di cui possediamo solamente l'id) e la descrizione dell'articolo prelevato (anche qui l'id è il solo ele-mento noto), quindi vengono chiamate in causa anche le tabelle 'Tart_articoli' e 'Tnlot_numlotti'.

Come si può vedere, quest'ultima tabella è fatta corrispondere al resto con un left outer join; ciò accade perché lo scarico non deve per forza corrispondere a un lotto di magazzino.

La tabella 'Tumi_unitamisure' è necessaria al ne di poter visualizzare sul report l'unità di misura della quantità di merce prelevata.