coreBOS: il pattern di Passaggi Correlati

Vuoi leggere questo articolo di Joe Bordes nella sua versione originale in inglese? Clicca qui!

12cb1fc6a6e8e74a7a99148e471597b123cd6de5-relatedstepspattern.jpeg

Un caso di utilizzo molto comune nelle applicazioni software per il business è l’avere un set di passaggi definiti, o una procedura da seguire quando si verifica un evento. Il pattern di implementazione qui spiegato mostra come farlo in coreBOS.

Casi di uso comune

Iniziamo con alcuni esempi di situazioni in cui si può utilizzare questo pattern.

  • Supporto dei ticket. La nostra compagnia ha un set di ticket tipici che hanno una serie di passaggi da seguire
  • Risoluzione di claim, dove il team di controllo qualità deve soddisfare determinati standard e seguire passaggi definiti
  • Progetti e task progetti per progetti ben definiti e controllati
  • Acquisizione acquisti e procedura di ricevimento
  • Controllo di pagamenti parziali

Controllo di pagamenti parziali di fatture

Entriamo nell’esempio “controllo di pagamenti parziali delle fatture”, perché è il più richiesto su coreBOS.

L’obiettivo è semplice ed estremamente comune. La soluzione è ugualmente semplice ed estremamente potente, in quanto coreBOS offre completo supporto per questo pattern.

Abbiamo fatture pagate in modo frazionato su giorni diversi. Abbiamo bisogno di controllare le date e lo stato di ogni pagamento.

Supponiamo di avere un form a tendina per i pagamenti sulla nostra fattura, con le diverse opzioni di pagamento supportate dalla nostra compagnia.

 

PartialPayment01.png

La selezione di questa picklist definisce le date e il numero di pagamenti parziali che verranno ricevuti. Per questo esempio supporrò che le nostre regole di business siano:

  • Pagamento completo: un solo pagamento per la fattura, una sola data per il totale
  • 50 50: un pagamento alla creazione della fattura e l’altro pagamento in una data precisa. Ogni pagamento sarà il 50% del totale
  • 30 30 40: un pagamento alla creazione della fattura, un altro 30 giorni dopo e l’ultimo in una data precisa. I primi due pagamenti saranno il 30% del totale e l’ultimo il 40% mancante.

Il nostro primo requisito sarà la creazione dei record di pagamento parziale in base al valore di questa picklist.

Questo può essere fatto utilizzando il task di workflow create entity. Creeremo un workflow sul modulo della fattura per ogni opzione di pagamento supportata in azienda, che aggiungerà record di pagamento sulle date indicate con l’ammontare corrispondente.

Una volta creati i record possiamo stabilire altri workflow per la notifica di pagamento, creare report per i pagamenti in ritardo e per ogni altro controllo dei pagamenti che vogliamo avere in azienda.

Non c’è molto altro, l’evento è un modulo sul quale creeremo un workflow e i passaggi correlati sono in un modulo correlato per il quale creeremo record con il task di workflow crea entità.

Ma c’è più di un aspetto a cui fare attenzione, che è il caso in cui l’utente seleziona il valore sbagliato per la forma di pagamento o il cliente chiede di cambiare la forma di pagamento. In questo caso, bisogna eliminare i record esistenti e creare un nuovo set di passaggi. Il task cancella record correlati è lì proprio per questi casi. Questo task di workflow eliminerà tutti i record correlati di un determinato tipo che appartengono ad un record.

Per farlo è importatissimo cancellare prima di aggiungere i nuovi record, altrimenti quelli appena creati potrebbero venire cancellati.

Questo pattern diventa un po’ più complicato perché dobbiamo anche controllare se uno o più record di pagamenti sono già stati pagati quando il cambiamento di metodo di pagamento si verifica sulla fattura. In questo caso, non possiamo cancellare un record di pagamento già segnato come pagato. Inoltre, dovremmo anche controllare il caso di uso in cui un utente cancella un record di pagamento che potrebbe lasciare la configurazione in uno stato non coerente. Entrambi i casi possono essere controllati in coreBOS usando il sistema di validazione. Metteremmo delle limitazioni sulle azioni consentite agli utenti sui record di pagamento in base alle impostazioni. Questo non è direttamente correlato al pattern di cui ci stiamo occupando, ma sono cose da considerare quando lo si configura per la propria azienda.

In questo video si può vedere questo esempio in azione.

Fateci sapere come utilizzate questo pattern!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s