top of page

Il PROGETTO Parte 3

andreamorselli

Continuiamo da dove ci eravamo lasciati.

Il sistema ora è in grado di gestire i token e le eventuali problematiche associate ad esso.

La prima cosa che vogliamo andare a sostituire è il sistema di stampa delle etichette.

Infatti in questo momento abbiamo n diversi software installati in giro per la produzione e non solo, Nicelabel….easylabel ecc…ecc..

Ovviamente con varie versioni, a volte incompatibili tra di loro.

Dovete sapere che nel pharma/biomedical, le etichette sono parte integrante del prodotto stesso, per questo motivo il labeling è sottoposto ad un rigido controllo di versione.

In questo momento ogni pc in produzione utilizzato per stampare, punta ad una cartella di rete contenente l’ultima versione del layout dell’etichetta, ovviamente per lo stesso articolo possiamo avere più etichette, in quanto quella che andremo ad applicare al prodotto sarà la prima, quella sulla scatola che contiene il prodotto la seconda è se era previsto il confezionamento di n scatole in una più grande ci sarà la terza.

I problemi che ci capitano più spesso sono:

1-utilizzo di una versione non aggiornata (in quanto diversi operatori si salvano il layout dell’etichetta in locale, perdendo eventuali aggiornamenti rilasciati dalla qualità)

2-misslabeling: diverse volte l’operatore scorda di applicare una delle etichette.

3-etichette con barcode non leggibile

Prima di continuare è necessario specificare che il file contenente il layout dell’etichetta ha dei campi che conterranno i veri e propri dati, che puntano tramite ODBC alle tabelle di un dBase dell’ERP (i così detti campi variabili), così che tramite il lotto digitato dall’operatore in fase di preparazione della stampa, il sistema è in grado di ricavare tutti gli altri dati dall’ERP.

Un’altra particolarità dell’ambiente altamente regolamenterò in cui ci troviamo è che nel caso di in rework di un lotto, questo dovrà essere rietichettato con la versione di etichetta rilasciata alla data di quel determinato lotto; così che gli operatori sono costretti a salvarsi i layout sostituiti in cartelle locali dedicate. In questo modo, durante un rework, guardando sul DHR da rilavorate si ricaverà la versione dell’etichetta da utilizzare, salvata in locale.

Quindi ora partiamo a sviluppare un software che prenderà il nome dalla procedura che gestisce il rilascio delle etichette, il famoso DBMDD. Che non sarà altro che una funzione del nostro SISTEMA.

In prima battuta abbiamo dovuto trovare delle librerie grafiche in grado di lavorare in un ambiente web, in grado, una volta inserito in campo di spostarlo nella posizione desiderata. Ma prima di iniziare ad inserire etichette è necessario inserire in apposite tabelle il collegamento a “nome_campo_etichetta” ==> “tabella_db” ==> “campo_tabella”, perché ovviamente i campi sono decine.

Inutile dire che tutti questi record devono essere firmati da chi li inserisce, così come devono essere firmati i campi che conterranno le coordinate per posizionare correttamente sia le caselle di testo contenenti la descrizione del campo, sia il campo contenente il valore preso dinamicamente dall’ERP.

Ora siamo in grado di cominciare ad inserire le oltre 3.000 etichette.

Mentre i colleghi procedono con il preparare tutte i nuovi layout delle etichette , noi possiamo procede con il costruire la parte di programma tramite la quale digitando il numero dell’ordine di lavoro, la funzione del nostro sistema sarà in grado di creare un PDF contenente tutti i dati variabili, inserirlo in un’apposita tabelle, con la firma di chi ha richiesto la stampa e sempre tramite stessa funzione, avremo la possibilità di scegliere su quale stampante andare a stampare il pdf tramite un comando ZPL, così da poterne gestire anche il numero di copie, informazioni sempre da inserire a db con relative firme elettroniche elaborate tramite i token distribuiti.

Come avrete capito, DBMDD, è composto da due parti ben definite, una parte admin, che viene utilizzata da chi deve preparare il layout dell’etichetta e il collegamento tra l’ERP e i campi definiti variabili, e la parte user, che viene utilizzata dalla produzione, nel momento del bisogno. Infatti questi, dopo aver digitato il numero dell’ordine di lavoro il sistema gli farà scegliere il tipo di etichetta (prodotto, box, master box) e il numero delle etichette da mandare in stampa, mostrando il numero di etichette eventualmente già stampate, questo anche per garantire la riconciliazione del numero delle stesse. Procedura richiesta dalle norme GMP

Sempre per essere in compliance con FDA il sistema garantisce l’accesso solo alle persone autorizzate, autorizzazioni che come tutte le altre info vengono riportate a sistema e firmate in compliance PART11 CFR21

Come dicevamo all’inizio dovendo il sistema garantire, in caso di rework, la stampa dell’etichetta utilizzata durante il primo “confezionamento”, quando si chiede tramite la digitazione del work order, la stampa di un’etichetta, il sistema controlla se ne sono già state stampate e nel caso richiamerà il layout nella versione rilasciata in produzione nel al giorno n

Bene, direi che per il momento vi abbia dato un bel dettaglio di quanto è in grado di fare il sistema fino ad oggi….nei prossimi giorni proverò a spiegarvi tutte le altre…sono tantissime, ma per questo non meno interessanti.

Di seguito i link alla prima e alla seconda parte:




5 visualizzazioni0 commenti

Post recenti

Mostra tutti

コメント


andreamorselli.blog

  • alt.text.label.LinkedIn

©2023 by andreamorselli.blog. Orgogliosamente creato con Wix.com

bottom of page