Ciao Daniele,
la tua risposta se da un lato mi chiarisce il
dubbio sulla nomenclatura dei file da sottoporre ad acquisizione massiva,
dall'altro mi solleva un'altra serie di interrogativi non banali.
Provo ad esporli:
1) Il codice a barre stampato dal sistema sull'etichetta di
protocollo, riporta un valore che non ha niente a che vedere con il numero del
protocollo stesso. Immagino sia un identificativo univoco della registrazione
di protocollo che non viene duplicato nemmeno per AOO diverse e anni diversi.
Questo a prima vista parrebbe una scelta logica, poiché lo scopo di quel codice
a barre dovrebbe essere quello di ricondurre il documento cartaceo, e la sua
successiva immagine ottica, alla singola registrazione fisica. La metodologia
che mi indichi per la nomenclatura, però, mi porta a non capire la sua utilità
(vedi punto 2)
2) L'operazione di registrazione con etichettatura dei documenti è a
mio avviso necessaria e utile per permettere la separazione delle operazioni di
protocollazione da quelle di scannerizzazione. La caratteristica, a mio avviso
tanto più utile quanto più aumenta il numero di documenti protocollati su base
giornaliera, consente di rendere la scannerizzazione un processo
"asincrono" e successivo alla registrazione, delegabile a risorse con
nessuno skill in merito alla protocollazione dei documenti o al limite anche a
service esterni. L'operatore in questione infatti deve semplicemente alimentare
uno scanner e gestire eventuali errori di lettura del software OCR che,
leggendo il barcode sull'etichetta, nomina il file in modo da permettere
l'acquisizione massiva.
3) Se la vogliamo dire tutta, potrebbe essere utile avere anche la
funzionalità inversa, rendendo possibile la scannerizzazione prima della
protocollazione. Mi spiego meglio: data una lista di pdf nominata in modo
casuale e comunque senza rispondenza di protocollazioni già fatte, l'acquisizione
massiva, invece che limitarsi a scartare il documento, proponga un pulsante
"Protocolla ora" che apra la maschera di registrazione del protocollo
con il file in oggetto già preselezionato.
4) Il metodo di associazione da te indicato, tra l'altro, mi
suggerisce anche un altro possibile problema: come si può gestire
l'acquisizione massiva verso differenti registri (uno ufficiale ed uno interno
ad esempio) se l'unico identificativo è il numero di protocollo che a questo
punto non è più univoco nemmeno all'interno della singola AOO nell'anno?
La mia opinione in merito sarebbe quella di far
lavorare l'acquisizione massiva sull'identificativo univoco, che risolverebbe
semplicemente i punti 1, 2 e 4.
Servirebbe magari dare maggiore evidenza a quell'identificativo
sull'etichetta, in modo da gestire eventuali numerazioni manuali o errori di
lettura del barcode.
Oppure si può pensare a inserire un opzione in
fase di acquisizione massiva che consenta di scegliere il parametro di
associazione (protocollo piuttosto che identificativo univoco)
Fammi sapere che ne pensi; invito ovviamente
chiunque abbia opinioni in merito a partecipare alla discussione.
Grazie
Gianni
----------
Messaggio inoltrato ----------
Da: Daniele Sanna <daniele.sanna@flosslab.it>
Date: 16 febbraio 2009 22.15
Oggetto: Re: [Utenti-eprot] Acquisizione massiva documenti
A: Gianni Bracali
<gianni.bracali@romaentratespa.it>
Cc: Sara Didaci <sara.didaci@flosslab.it>
Salve Gianni,
sono Daniele Sanna di Flosslab.
Per far funzionare l'importazione massiva devi in primo luogo configurare il
path Dati amministrazione: Path documenti acquisizione massiva.
Ricordati che sotto tale directory vengono create tante directory quante sono
le aoo, ed è li che devi inserire i file pdf.
I file da inserire devono avere si il numero del protocollo come nome del file,
ma escludendo l'ultimo carattere. Mi spiego meglio con un esempio.
Se vuoi creare un collegamento con il protocollo nr 3, dovrai inserire un file
pdf con un nome tipo 00003x.pdf dove la x può essere qualsiasi carattere. La
motivazione di tale carattere di controllo è un po complessa da dare ora, e
risulta anche inutile per il momento. Mi preoccuperò di toglierla nella
prossima release, ma per ora c'è, quindi ricordati sempre di aggiungere un
carattere finale qualsiasi.
Altre considerazioni sulla funzionalità:
- Il file deve essere un pdf (una volta importato
viene modificato tale file inserendo un'intestazione con data
protocollazione, ufficio, aoo e numero protocollo).
- Vengono allegati solo come documenti principali,
e dunque se il protocollo al quale stai effettuando il collegamento
possiede già un documento principale il sistema non effettua l'operazione
(tale comportamento dovrebbe comparire nei log dell'importazione massiva).
- Tutti i documenti che non presentano come nome il
path che ti ho illustrato o che non trovano un protocollo esistente con il
numero specificato vengono scartati.
- I file da importare devono seguire solo questi
vincoli e non c'è bisogno che siano stati etichettati precedentemente.
Anzi, una volta importato al file pdf verrà aggiunto un "timbro"
contenente numero di protocollo, data, aoo e ufficio che hanno eseguito la
protocollazione
Se hai ancora qualche dubbio o non ti dovesse
funzionare fammi sapere che proviamo a risolvere insieme.
Il giorno
16 febbraio 2009 19.14, Gianni
Bracali <gianni.bracali@romaentratespa.it> ha scritto:
Buonasera
a tutti,
stavo
cercando di capire il funzionamento dalla funzionalità "Acquisizione
Massiva" dei documenti di e-prot.
Leggendo
nell'help, mi è sembrato di capire che il file pdf, per essere correttamente
associato al protocollo deve avere un formato particolare. Ho provato in
svariati modi, sia utilizzando il progressivo di protocollo che l'id univoco
del protocollo, ma la risposta è sempre "Non esiste il
protocollo per il documento"
Mi
sarei aspettato che l'associazione venisse fatta tramite l'id univoco, sia per
logica sia perché, leggendo il barcode stampato dall'applicativo sull'etichetta
di protocollo, l'informazione che si ottiene non fa riferimento al numero di
protocollo ma all'id univoco.
Qualcuno
utilizza la funzionalità di acquisizione massiva e mi sa dare qualche lume su
come deve essere nominato il file per una sua corretta acquisizione?
Grazie
Gianni Bracali
Responsabile U.O. Sviluppo ed Esercizio Software Applicativo
Sistemi Informativi
Roma Entrate spa
via
Ostiense 131/L - 00154 ROMA
tel 06 57131.201 - fax 06 57131.400
e-mail: gianni.bracali@romaentratespa.it
![]()
Questa
comunicazione ed ogni documento allegato sono di uso esclusivo del destinatario
o dei destinatari sopra menzionato/i e possono contenere informazioni
confidenziali coperte da segreto professionale. Qualunque uso non autorizzato
delle dette informazioni è proibito. Se si è ricevuta questa comunicazione per
errore, si prega di notificarlo immediatamente al mittente rispondendo alla
comunicazione e cancellandola successivamente dal proprio sistema informatico.
Per informazioni si
prega contattare info@romaentratespa.it
Grazie
This communication
and any attachments is intended solely for the addressee(s) named above and may
contain confidential and legally privileged information. Unauthorized use,
disclosure or copying is prohibited. If you received this communication in
error, please notify the sender immediately by replying to this communication
and then deleting it from your system.
Should you have any
questions, please contact us by replying to info@romaentratespa.it
Thank you
_______________________________________________
Utenti-eprot mailing list
Utenti-eprot@gov4j.it
http://www.gov4j.it/mailman/listinfo/utenti-eprot
--
Ing.Daniele Sanna
~~~~~~~~~~~~~~~~~~~~~
Software Engineer
Flosslab s.r.l.
Viale Elmas, 142
09122 Cagliari (CA)
tel. +39070490189
cell. +39 3406740061
e-mail daniele.sanna@flosslab.it
- www.flosslab.it
--
Ing.Daniele Sanna
~~~~~~~~~~~~~~~~~~~~~
Software Engineer
Flosslab s.r.l.
Viale Elmas, 142
09122 Cagliari (CA)
tel. +39070490189
cell. +39 3406740061
e-mail daniele.sanna@flosslab.it
- www.flosslab.it