Progetto di gestione dei verbali di montaggio

L’esempio propone un azienda qualsiasi che abbia bisogno di implementare un flusso organizzato per la gestione del “montaggio” di alcuni elementi di arredo, ma può essere esteso ad altre realtà. Questo caso specifico può essere applicato sia ad un azienda produttrice di arredi che ad un azienda che li distribuisce. In particolare, si vorrebbe gestire l’apertura di un “Ticket” per l’avvio del verbale di montaggio, la notifica a chi eseguirà il montaggio accentandone o meno la data e infine il completamento del verbale di montaggio in loco non appena l’attività omonima non è stata completata. Si tratta di costruire il flusso sulla base dei requisiti funzionali e non funzionali discussi durante lo studio di fattibilità di progetto. In termini pratici il tutto è stato gestito e implementato in modo semplice tramite un software di gestione documentale che ha permesso di costruire le fasi del progetto senza alcuna preoccupazione o intoppo qualsiasi genere. E’ ovvio, che in tale contesto non nominerò ne l’azienda e nel software documentale cercando di proporre una soluzione generica o in termini più friendly la “solution“. Di seguito un elenco degli argomenti trattati nell’articolo.

Analisi dei requisiti
Architettura tecnica
Progettazione RDBMS dell’implementazione del verbale di montaggio
Progettazione dell’interfaccia utente
Sviluppo prototipale dell’interfaccia utente
Gli stati del verbale di montaggio e la gestione di un workflow

Analisi dei requisiti

In questo articolo cercherò di descrivere brevemente i requisiti di progetto e in particolare farò riferimento a quelli funzionali richiesti dal cliente e a quelli non funzionali dettati dal sistema. Procediamo con ordine e di seguito la lista dei requisiti.

Tabella 1
(Mappatura dei requisiti funzionali e non funzionali di progetto).

Architettura tecnica

Quali sono i componenti di progetto? Nella prossima immagine descriverò in modo sommario tali componenti che comporranno il progetto e che permettono attualmente tale soluzione.

Come si vede, nel diagramma visualizzato nell’immagine uno, sono presenti i seguenti componenti:

1. L’utente (Utente) interno all’azienda che inserisce il verbale di montaggio e ne avvia il flusso
2. Il Software Documentale che ho chiamato DOCX permette la gestione del workflow del flusso del verbale di montaggio.
3. Un ERP Aziendale che restituisce informazioni a DOCX
4. Un Utente esterno (Utente Tablet) appartenente ad una società esterna di montaggio, di solito una cooperativa.
5. Un Tablet che attraverso l’APPDOCX permette la comunicazione con il software documentale DOCX per la compilazione del verbale di montaggio.

Progettazione RDBMS dell’implementazione del verbale di montaggio

Prima di passare alla costruzione delle tabelle vere e proprie cerchiamo di rappresentare un diagramma E-R che mi servirà per la costruzione del RDBMS del progetto.

Ecco di seguito una prima soluzione:

Come si vede dal diagramma E-R, ho rappresentato solo le chiavi primarie composte delle entità e le chiave esterne. Le entità sono, nella prima versione, solo tre: VERBALE DI MONTAGGIO, SEGNALAZIONE e CATALOGO FOTO SEGNALAZIONE. Per quanto concerne le relazioni tra le entità sono 1 a 1 e in particolare ad un VERBALE di MONTAGGIO possono essere associate una o più SEGNALAZIONI. Ad una SEGNALAZIONE può essere associato un CATALOGO FOTO SEGNALAZIONE.

In pratica, l’oggetto principale è il VERBALE DI MONTAGGIO, a cui sono associati una o più DDT che contengono a loro volta gli articoli da assemblare. Per ognuno degli articoli presenti nel DDT e quindi nel VERBALE DI MONTAGGIO si possono “aprire” più SEGNALAZIONI di anomalia, e cmq una soltanto per riga DDT. All’interno della maschera delle SEGNALAZIONI si possono aggiungere più FOTO che vengono salvate su un CATALOGO FOTO SEGNALAZIONE. Una maschera esterna conterrà un documento in formato PDF in cui saranno presenti le foto salvate sul CATALOGO FOTO SEGNALAZIONE.

Ora, è il momento di iniziare con il progetto vero e proprio e definire gli oggetti del RDBMS che servono per l’implementazione del flusso di gestione del verbale di montaggio.

Partiamo con la prima Tabella (VERBALE DI MONTAGGIO) con la definizione dei campi seguenti:

Ora si tratta di definire i campi della seconda Tabella, quella delle SEGNALAZIONI. Ecco di seguito i campi.

E’ il momento di aggiungere i dettagli della tabella CATALOGO FOTO SEGNALAZIONE

Termino con l’ultima tabella per la gestione del progetto che si chiama IMMAGINE FOTO SEGNALAZIONE e che viene utilizzata per “immagazzinare” le foto relative al catalogo. Tale tabella non l’ho aggiunta al diagramma E-R perchè di supporto alla tabella CATALOGO FOTO SEGNALAZIONE

Ora si tratta di progettare il Layout dell’azione di inserimento del Verbale di Montaggio.

Progettazione dell’interfaccia utente

Per la realizzazione del progetto procediamo a suddividere in tre parti la realizzazione del progetto:

1. Realizzazione del disegno del Layout
2. Recupero delle Query di interrogazione verso l’ERP
3. Sviluppo prototipale dell’interfaccia Utente

Nella prima parte si realizzerà l’interfaccia utente partendo dal Layout dell’inserimento / modifica del verbale di montaggio. Successivamente si procederà a disegnare il Layout della parte relativa alla gestione delle segnalazioni.

Nella seconda parte, una volta disegnati i Layout si procede ad identificare tutte le query che permetteranno di interagire con l’interfaccia utente sia del verbale di montaggio, sia della gestione delle segnalazioni.

Infine, nella terza parte, si procederà a realizzare l’interfaccia vera e propria del verbale di montaggio e della gestione delle segnalazioni sviluppando il codice in linguaggio Python.

Realizzazione del disegno del Layout

Come da progetto, partiamo col disegnare l’azione di inserimento/modifica del verbale di montaggio. Una prima versione è quella presente di seguito

Come si vede vi sono diversi campi, partiamo dall’altro verso il basso. Il campo “STATO VERBALE” ci permette di capire se un verbale è ancora aperto o completato o in qualche altro stato.

I campi di “Ricerca” permettono di selezionare una commessa dall’elemento di “Dropdown” corrispondente in parte alla stringa inserita nel campo di ricerca. Dopo aver scelto la commessa nel campo “Commessa nr.”, il campo “Dropdown” “DDT nr” sarà popolato dai DDT appartenenti alla commessa selezionata. A questo punto il campo “Cliente” verrà popolato in modo automatico e così anche i campi relativi alla consegna (Cons.*).

Si potrebbe anche procedere ricercando il DDT e popolando in automatico il campo “Commessa nr.” e il campo “Cliente” e i campi relativi alla consegna (Cons.*).

Nei campi “Data Montaggio” e “Ora Montaggio” si inseriscono rispettivamente la data e l’ora in cui avverrà il montaggio presso il cliente. Il campo Nr. Operatori sarà un campo non obbligatorio in cui si inseriranno il numero di operatori che parteciperanno al montaggio.

I campi “Ricerca Fornitore Montaggio” e “Fornitore” permettono la ricerca e l’inserimento del fornitore che eseguirà il montaggio.

I successivi campi di consegna vengono popolati leggendo le informazioni del DDT. Volendo, quest’ultimi si possono modificare premendo il tasto “Modifica Consegna“

Infine, vi è il campo Note che permette di inserire delle note specifiche del verbale di montaggio. Il taso “OK” non fa altro che confermare le informazioni inserite.

Ora che abbiamo definito in maniera abbastanza precisa il layout dell’azione di inserimento/modifica del verbale di montaggio passiamo all’azione di completamento del verbale di montaggio che eseguiranno in loco dal cliente gli operatori designati per tale attività.

Di seguito trovate il layout che ho realizzato l’azione di completamento del verbale di montaggio.

L’azione di completamento del verbale di montaggio (prima versione) è abbastanza diversa da quella precedente, come deve essere. In alto, troviamo lo “STATO VERBALE” di cui abbiamo già capito quale sia la funzionalità. Successivamente, sono presenti i campi “Commessa Nr” e “DDT Nr” che non possono essere modificati. Poi seguono le informazioni di “Data Montaggio Prevista” e “Ora Montaggio Prevista“. Quest’ultime sono quelle inserite con l’azione precedente. Anche il campo cliente non è modificabile e corrisponde a quello della commessa, così come i campi “Indirizzo Cliente” e “Indirizzo di Consegna“.

Seguono le informazioni che dovranno essere modificate dagli operatori del montaggio. La “Data di Arrivo“, l'”Ora di Arrivo“, la “Data Fine Lavori” e l'”Ora Fine Lavori” sono campi che devono essere compilati. La valorizzazione viene eseguita copiando le informazioni contenute nei campi “Data Montaggio Prevista” e “Ora Montaggio prevista“. Non so se ragionando la “Data Fine Lavori” e l'”Ora Fine Lavori” non sia da applicare ad una specifica azione di chiusura (forse automatizzandola con la firma del cliente).

Più in basso troviamo la prima sezione chiamata “PRIMA DEL MONTAGGIO” che dovrà essere compilata “flaggando” i campi richiesti prima di eseguire il montaggio. Questi sono tutti obbligatori. Sono di fatto tre flag in sequenza a cui l’operatore dovrà rispondere prima di procedere. Nel DBMS chiameremo tali campi PRMONTFLAG1, PRMONTFLAG2, PRMONTFLAG3.

Segue la sezione “AZIONI OBBLIGATORIE DA PARTE DEGLI ADDETTI AL MONTAGGIO” che richiedono una risposta. Per ognuna di queste azioni corrisponderà un campo integer nel DBMS che chiameremo AZIONIADD1, AZIONEADD2, AZIONEADD3, AZIONEADD4, AZIONEADD5, AZIONEADD6, AZIONEADD7 e via dicendo contenente i valori 1 (True), 0 (False), 2 (Nulla). Si tratta di poche opzioni.

Nella seconda tabella, quella di inserimento delle non conformità verranno visualizzate le righe del DDT e poi eventualmente compilati campi “QTARIC” (qta ricevuta), “QTADAN” (qta danneggiata) e l’anomalia riscontrata nel campo “NON CONFORMITA‘”. Questa per ora non verrà implementata in quanto verrà gestita in una terza azione presente al di fuori

Proseguendo, vi sono tre campi da compilare “LAVORI DA COMPLETARE“, “PROBLEMI RISCONTRATI” E “IMPREVISTI” in cui possono essere inserite le informazioni di contesto. Sono stati aggiunti i campi “KM PERCORSI” e infine un campo “NOTE“. Infine, saranno inserite le informazioni del “RESPONSABILE DEL MONTAGGIO” e quelle di “LUOGO E DATA“.

In un successivo momento è stata redatta una seconda versione con alcune informazioni aggiuntive come di seguito descritto.

In questa seconda versione sono stati introdotti dei campi da “flaggare” da eseguire prima del montaggio e due campi “Km Percorsi” e “Note” che completano l’azione.

A questo punto non resta che disegnare l’azione che mi permetterà di aggiungere delle foto di eventuali danni o anomalie. Nella precedente azione, sono state compilate le righe con le anomalie (segnalazioni) e sono queste che verranno inserite nel template specifico.
Da questo template si potranno aggiungere le foto attraverso l’azione specificata nel layout successivo.

Come si vede in questa azione sono inseriti i campi “Commessa Nr“, “DDT Nr.”, “Riga DDT“, “Articolo“, “Descrizione“. Tutti i precedenti sono non modificabili. Mentre, i seguenti, “Qta Ricevuta“, “Qta Danneggiata” e “Anomalia” possono essere cambiate solo nel caso si prema il pulsante “EDIT“. Successivamente, vi sono i campi “Foto*” che possono essere associati alla riga DDT (al massimo 6 foto).

Recupero delle Query di interrogazione verso l’ERP

Per quanto concerne le query ho inizialmente interrogato le commesse per il campo di ricerca immesso. Poi eventualmente se c’è un codice cliente associato allora ho individuato le commesse e i relativi DDT.

Per quanto concerne l’ERP individuato la tabella delle commesse poteva essere interrogato con la seguente:

select * from ComTes  

La query indicata nel riquadro esegue un interrogazione su tutte le righe della tabella delle commesse. Come indicato nel riquadro della select queste sono presenti all’interno della tabella ComTes. Adesso, cerchiamo di aggiungere i vari elementi che ci servono per l’azione di inserimento/modifica montaggio.

I campi selezionati sono l’anno, il numero commessa e lo stato della commessa come descritto nel seguente riquadro:

select C.AnnDoc AS Anno, C.NumDoc As Numero, C.Stato As StatoCommessa from COmTes 
inner join TipiDoc T on T.id = C.idTipiDoc
where T.TipDoc<>'Q')

In questo caso si selezionano tutte le commesse tranne le offerte (T.TipDoc <> ‘Q’)

A questo punto non resta che selezionare tutti i DDT di quella particolare commessa e scegliere i campi restituiti.

select C.ID AS IDBamTes,C.AnnDoc AS Anno, C.NumDoc As Numero, C.Stato As StatoDDT, C.IDTIPIDOC As TipoDDT, C.ORDCLI AS Commessa, C.DATORDCLI As DataCommessa, C.IDRIFCOMM as RiferimentoCommessa, IDCLIDEST as IdCliDestDoc, DESCLI as DescCliInsDoc, INDDES AS IndDestInsDoc, INDCLI AS IndCliInsDoc, IDINDDEST as IDIndDestMerce, DESCRDEST as DescrDestDoc, CAPDEST AS CAPDestDoc, LOCDEST AS LocDestDoc, IDNAZDEST AS NazDestMerci, PRODES AS ProvDestInsDoc, INDDEST AS IndDestDoc, PROVDEST AS ProvDestDoc,COMUNEDEST AS ComuneDestDoc, COMUNEDES AS ComuneInsDoc, COMUNECLI as ComuneCliInsDoc, PROCLI As ProvCliInsDoc, LOCCLI As LocCliInsDoc, CAPCLI AS CapCliInsDoc, IDCLIENTE AS IdCliente,   Stato, RIFERI1 As Riferimento1, RIFERI2 As Riferimento2, RIFERI3 AS Riferimento3
from BAMTES C
where C.IDTIPIDOC = '42'
order by C.ANNDoc Desc, C.NumDoc Desc

La query suddetta estrae una serie di informazioni come descritto dall’istruzione AS di ogni campo. Tutto ciò ci facilita il compito perchè abbiamo quasi tutti i valori che ci servono per iniziare a sviluppare la prima azione di inserimento del verbale di montaggio.

Ovviamente, vi sono altre interrogazioni che sono state eseguite verso l’ERP, ma nel contesto di questo articolo ho pensato di pubblicare solo due esempi.

Sviluppo prototipale dell’interfaccia utente

A questo punto, avendo le query, e il layout, iniziamo la progettazione del form utente e quindi sviluppiamo l’interfaccia prototipale della prima azione o Form di inserimento / modifica del verbale di montaggio.

Il nome che daremo all’azione o Form sarà “Inserisci/Modifica Verbali di Montaggio“. Il risultato del layout dell’azione di inserimento del verbale di montaggio è il seguente e rappresenta il primo prototipo.

Ora, si tratta di sviluppare a codice il secondo layout dell’azione di compilazione del verbale di montaggio. Si tratta dell’azione che utilizzeranno gli addetti al montaggio per completare le informazioni richieste nella sede di montaggio come specificato poc’anzi. L’azione o Form lo chiamata “Compilazione Verbale di Montaggio“. Quella che vedete successivamente è una prima versione prototipale abbastanza scarna.

Di seguito potete vedere il terzo form a cui daremo il nome “Segnalazioni Verbali” utilizzato per la gestione delle segnalazioni sulle righe del verbale di montaggio.

Come si vede, una volta individuata la riga del DDT “non conforme” è possibile inserire la quantità mancante, l’eventuale quantità danneggiata e inserire delle foto per documentare la segnalazione.

Una volta completate le informazioni del verbale e le segnalazioni è possibile firmare il verbale. Il cliente e il responsabile del montaggio in loco hanno il compito di firmare tramite il form o meglio l’azione “Firma Verbale” (v. immagine successiva) il verbale di montaggio con una firma semplice.

Una volta firmato il verbale, questo verrà inviato tramite e-mail al cliente e all’assistenza clienti dell’azienda che ha venduto il materiale al cliente.

Gli Stati del verbale di montaggio e la gestione di un workflow

Al verbale di montaggio sono attribuiti diversi stati e un workflow per la gestione delle e l’avvio di ulteriori step di interazione.

Durante l’inserimento del verbale lostato attribuito è cinque ossia uno lo STATO BOZZA. In tale stato l’addetto che inserisce il verbale può riaprirlo per completarne eventuali altre parti. Una volta che l’addetto dell’ufficio ha terminato il verbale di montaggio nelle parti che a lui competono, questo viene inviato in “compilazione” agli addetti di montaggio (STATO IN COMPILAZIONE) e a questi (alla società che si occupa del montaggio) viene inviata una e-mail con tutte le indicazioni relative al luogo e alla tipologia di montaggio con un apposito workflow.

Il workflow genera un evento di notifica per cui gli addetti di montaggio che possono aprirlo e compilarlo nelle informazioni di propria competenza.

Nello stato “In compilazione”, il verbale può essere rivisto, solo nelle parti che competono agli addetti del montaggio e possono essere inserite delle segnalazioni sulle righe del DDT in caso di mancanza o danneggiamento del materiale.

Una volta terminato il verbale di montaggio, viene chiuso tramite l’azione firma verbale (eseguita dal responsabile del montaggio, e dal cliente) e automaticamente viene modificato lo stato del verbale in STATO CHIUSO. Durante la chiusura viene inviata un e-mail contenente il verbale al cliente, e all’azienda fornitore del materiale.

Conclusioni

In questo articolo, abbiamo visto un progetto di gestione dei verbali di montaggio. Tale è stato implementato in Azienda e ha prodotto un considerevole risparmio, in termini di tempo, per la gestione del flusso documentale, oltre ad aver delineato una gestione rigorosa del verbale di montaggio da parte di una società esterna all’azienda.

Come al solito, per  eventuali domande, integrazioni e correzioni inviate un e-mail a webmaster@megalinux.cloud.

Sostenete The Megalinux: In un mare di siti web sovraccarichi di pubblicità invadente, The Megalinux si distingue come l’unico rifugio libero da annunci. Abbiamo scelto di offrirvi un’esperienza di navigazione pulita e ininterrotta, ma per fare ciò, abbiamo bisogno del vostro supporto. Considerate l’idea di contribuire alla nostra missione inviando Bitcoin al nostro indirizzo. Anche una piccola donazione può fare la differenza e ci aiuterà a mantenere il sito libero da pubblicità.

È davvero difficile immaginare che esista qualcuno che, indipendentemente dalle donazioni ricevute (che non ci sono), continui a scrivere in totale libertà, tutto ciò o quasi che trova interessante?

3LpoukFpvDHTZPn5qGbLwUzve3rX9zsSq6