L'integrità dei dati è uno degli aspetti più importanti di cui tenere conto nella progettazione di un software gestionale con FileMaker, dalla compilazione degli archivi alla generazione di documenti come DDT e fatture.

La fase di inserimento dati: una strada irta di pericoli

Chiunque abbia avuto a che fare con programmi gestionali sa che la maggior parte dei problemi ha origine dalla mancata o errata compilazione dei dati. Soprattutto quelli che sembrano verificarsi in modalità random e che spesso sono i più noiosi da risolvere.

Un esempio banale: se facciamo una fattura a un cliente ma nella sua scheda anagrafica non è stato definito il codice di pagamento, il software incontrerà dei problemi nel generare automaticamente le scadenze.

Senza contare poi i casi più complessi, come quello del file delle RI.BA. che non viene accettato dal sito della banca perché la ragione sociale di un cliente contiene un carattere "a capo” che ha creato un errore nella generazione del flusso.

O ancora, l'esempio di un articolo che non viene inserito in una importante statistica di vendita perché abbinato ad una categoria che è stata successivamente eliminata e ricreata con un codice differente.

Tutte situazioni che in molti casi possono farci perdere molto tempo nella ricerca della causa, per scoprire poi che all’origine del male non c’era un’errata programmazione di uno script, ma una banale distrazione dell’impiegata che tre mesi prima ha compilato la scheda di quel cliente o di quell'articolo.

Inutile dire che non è compito dello sviluppatore FileMaker controllare la produttività degli uffici e assicurarsi che tutti facciano il loro dovere. Rientra però nelle sue responsabilità evitare che si possano commettere degli errori nella fase di input dei dati.

Non stiamo ovviamente parlando di un numero civico errato (quel tipo di errore non lo possiamo proprio evitare), ma di un errore concettuale in fase di progettazione del software: se il programma permette di emettere una fattura senza inserire la Partita Iva, la colpa è solo ed unicamente dello sviluppatore.

Ed è per questo che tutti noi, durante la fase di test, ci avventuriamo nell'erta strada dei controlli. Non si può stampare il DDT se non ci sono righe o se non compare il peso netto, nel campo email ci deve essere una @ e almeno un punto, il codice fiscale deve essere lungo 16 caratteri…

Ma i controlli in fase finale possono essere faticosi da programmare. Talvolta poi sono inefficaci perché l’utente trova in modo di bypassarli e, come se non bastasse, sono scomodi per chi si trova a dover correggere errori qua e là per fare in modo che le procedure funzionino.

Molto più corretto sarebbe intervenire prima, cioè su quello che succede al momento dell’inserimento dei dati, per essere sicuri che il flusso di informazioni si muova all’interno del database in modo compatto e ordinato.

Come si gestisce l’input dei dati?

Gestire al meglio la fase di inserimento dati con FileMaker

I metodi che si possono adottare sono diversi.

Quasi sempre viene progettato un layout di immissione o modifica dati, oppure una finestra modale, di quelle che non si possono chiudere se non attivando uno script.

A seconda delle preferenze, i dati possono essere inseriti in campi globali o in tabelle temporanee, oppure ancora direttamente sul database, salvo poi eliminare il record che non si desidera validare.

Ma ciò che accomuna tutti questi sistemi che servono a costringere l’utente a non lasciare record incompleti o con dati errati sono due bottoni: Annulla e Conferma.

Screen-Shot-2014-12-16-at-10.15.00

Cliccando su Conferma si eseguono i controlli sui dati inseriti. Se qualcosa non va bene lo si segnala, altrimenti il record viene accettato. Premendo su Annulla la finestra si chiude e tutto ritorna alla situazione originaria.

Dunque, seppure con qualche sfumatura di forma, il concetto di base di tutti questi metodi è sempre lo stesso. O hai scritto tutto per bene, e allora ti valido il record (e se qualcosa non va ti tengo in ostaggio con un pop-up bloccato fino a quando non avrai messo tutto a posto), oppure tanti saluti: clicchi su Annulla e ci rivedremo la prossima volta che avrai un po’ più voglia di impegnarti. Intanto per punizione cancello tutto quello che hai scritto.

Così di sicuro nessuna scheda potrà essere lasciata incompleta. Tutti gli articoli avranno la loro categoria, l’unità di misura e il prezzo, gli agenti la provvigione ad essi riservata e i clienti il loro codice di pagamento, il proprio IBAN ed il proprio listino prezzi. E tutti saranno felici e contenti.

Ma cosa succede se, mentre sta completando una scheda articolo, l'utente riceve la telefonata di un cliente che vuole fare un ordine o desidera sapere lo stato delle sue fatture?

Le alternative sono due: l'utente dirà al cliente di richiamare un’altra volta, oppure sarà costretto ad abbandonare la scheda che stava compilando perdendo i dati scritti fino a quel momento.

Ahi ahi. Forse il cliente che deve richiamare o l’impiegata che deve reinserire i dati saranno un po’ meno felici e contenti.

E poi… fatemi pensare. Cosa succede se veniamo in possesso di un elenco di clienti potenziali, dei quali ovviamente abbiamo solo alcuni dei dati principali e non gli estremi di fatturazione? Vorremmo magari inserirli nel nostro database per potergli inviare gli auguri di Natale, riservandoci di completare le schede solo di quelli che nel tempo diventeranno clienti effettivi.

Nessun problema: basta creare un’altra tabella per i clienti potenziali, per poi in futuro spostarli nella tabella principale tramite uno script. Ma poi ci troviamo dei dati scritti due volte, e ci perdiamo la storia dell’attività di marketing svolta sul cliente quando questi era ancora potenziale… Insomma, anche qui c’è qualcosa che non ci convince fino in fondo.

Dunque, se è vero che nel caso della creazione di una fattura è necessario assicurarsi che questa venga compilata integralmente dall’inizio alla fine e controllata in tutte le sue parti, vediamo che lo stesso concetto forse non è applicabile agli archivi come gli elenchi articoli o le anagrafiche, dove sarebbe bello poter essere un po’ meno rigidi.

L’alternativa che quindi vorrei proporvi in questo articolo è quella di usare un un metodo differente, che per comodità chiameremo On/Off. Si tratta di una metodologia che personalmente trovo molto efficace, proprio perché tiene conto dell’esigenza di integrità dei dati  ma anche dell'elasticità e praticità d’uso del software. Un aspetto che, nell’era degli smartphone, è sempre più sentito e apprezzato dagli utenti.

In realtà più che di metodo sarebbe più corretto parlare di un concetto, che potremmo riassumere in: puoi scrivere quello che vuoi, tanto per le cose importanti il software userà solo i record buoni.

Screen-Shot-2014-12-13-at-17.16.20

Come funziona?

Il metodo On/Off in azione

On/Off, come avrete probabilmente intuito, non è altro che un interruttore, ovvero un campo collegato a una lista valori 1/0, dove 1 è On, 0 è Off.

Quindi compilo la mia scheda e quando credo di avere compilato tutti i dati clicco su On.

Solo a questo punto parte uno script che esegue i controlli, mi avvisa degli eventuali errori e se tutto va bene porta l’interruttore a ON, ovvero scrive 1 nel campo flag_on.

Screen-Shot-2014-12-13-at-17.08.44

Da questo momento il record diventa usabile dalle altre sezioni del database, quindi sostanzialmente potrà comparire nelle liste valori, lo farò apparire nei portali e nei pop-up (escludendo dalle ricerche i record off) e se vorrò esagerare potrò differenziare i record On dai record Off usando la formattazione condizionale (Es. On nero bold, Off grigio italic)

Screen-Shot-2014-12-16-at-15.59.15

Se il record non è in stato On significa che non è completo, e non potrò inserirlo in una fattura o in un DDT.  Lo potrò tuttavia utilizzare per stampare un’etichetta, come destinatario di una lettera o come intestatario di un preventivo. Allo stesso tempo potrò importare un elenco di articoli dei quali non ho ancora definito i prezzi di listino o un elenco di nominativi senza indirizzo, senza che il software si ribelli per il sopruso subito.

E se una volta completato un record e messo in stato ON dovessi cambiare qualcosa al suo interno? Per esempio, potrei decidere di cambiare il pagamento da contrassegno a RI.BA. 30gg, dimenticandomi però di compilare i dati della banca, che prima non erano necessari. Oppure potrei inavvertitamente togliere o aggiungere un carattere al codice fiscale, rendendo il campo non più valido.

Niente paura. Al commit del record, ovvero al tentativo di FIleMaker di memorizzare i dati, scatterà un trigger sul layout che eseguirà lo stesso script On-Off, e poichè i controlli daranno luogo ad uno o più errori, il flag da 1 tornerà a 0, ovvero il record On sarà riportato a Off.

Screen-Shot-2014-12-13-at-17.02.06

Screen-Shot-2014-12-13-at-17.03.16

Riassumendo: con questo sistema posso decidere di tenere nella mia base dati dei record incompleti, che sarò costretto a completare solo quando mi serviranno veramente.

Ogni volta che qualcuno apportarà una variazione al record lo script di controllo ripartirà, rieseguirà le verifiche e, nel caso riporterà il record allo stato Off, dopo avermi comunicato con un messaggio la causa del downgrade.

Screen-Shot-2014-12-13-at-17.00.45

Conclusioni

Quello che abbiamo visto in questo articolo è molto semplice dal punto di vista della programmazione. Quanto presentato vuole rappresentare solo un punto di partenza per nuove idee di sviluppo, ma è importante soprattutto sotto il profilo concettuale perché concilia le esigenze di elasticità richieste dall’utente con quelle di rigidità di cui necessita lo sviluppatore, che ha il compito di assicurarsi che le tabelle siano debitamente compilate.

E, aspetto altrettanto rilevante, toglieremo quell’impressione di rigidità del programma che sta andando un po’ fuori moda, non solo tra gli utenti Mac.

Qual è il tuo metodo per inserire i dati a prova di errore? Raccontaci la tua soluzione e condividi le tue idee con gli altri Guru: scopri la comunità Filemaker su Guru Corner!

2 Commenti

  1. Bravo, va benissimo e utile implrmrntazione.
    Ma!, siamo in Italia abbiamo una meravigliosa lingua che possiamo chiamane qualsiasi cosa in molti modi diversi e più mirati selettivamente secondo i casi; mi domando "perchè noi Italiani scriviamo e/o tentiamo di scrivere in inglese" ?.
    Penso che chi scrive un testo lo fa per essere capito da molti che leggono, ci sono anche che non sanno l'inglese, devono essere esclusi ?.
    Pertanto caro Sandro, visto che Filemaker è anche in italiano "io e moltissimi altri lo hanno" non escluderci Noi poveri "ignoranti Italiani Doc" che purtroppo non siamo anglico-dipendenti.
    Ciao e grazie,
    P.s. sono un tuo fans non un polemico.

    • Purtroppo oggigiorno una infarinatura seppur minima dell'inglese è indispensabile per "sviluppare". Resta il fatto che uno dei motivi per cui abbiamo aperto FileMaker Guru è proprio l'idea di creare una community che parli e scriva in italiano, la nostra madre lingua. Quindi ti ringrazio per la segnalazione. Se qualche termine non è chiaro segnalacelo e inseriremo a fianco una traduzione (questo perché purtroppo nella maggior parte dei casi il termine inglese rende il significato in modo più appropriato).

      Grazie anche a nome di Sandro e degli altri guru!

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here