Ticket #27 (new compito)
E' opportuno chiedere ai Gasisti di confermare i Prodotti inseriti nel Carrello ?
| Reported by: | lfranc | Owned by: | somebody |
|---|---|---|---|
| Priority: | importante | Milestone: | Documento di analisi funzionale |
| Component: | analisi | Keywords: | |
| Cc: |
Description
Ipotizzando una risposta affermativa al ticket #26, è necessario/auspicabile/opportuno richiedere ai Gasisti di confermare i Prodotti inseriti nel Carrello prima che venga impartita una effettiva disposizione di ordine Gasista -> GAS ?
Change History
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 2 years ago by lfranc
Replying to dom_thual:
Se è un azione che serve solo al sistema direi NO. Vuole dire che il sistema non è in sintonia con l'utente.
Non sono sicuro di aver capito quello che vuoi dire; la domanda in oggetto non è se l'azione di conferma serva o meno al Sistema (non ci interessa, almeno in questa fase) ma se un meccanismo di conferma degli ordini da parte dei Gasisti sia utile/necessario. Teniamo presente che, generalmente, le procedure informatiche che producono effetti significativi per l'utente (e l'invio di una disposizione di ordine rientra in questa categoria, a mio parere) prevedono uno step di conferma, da parte dell'utente, dell'azione da eseguire.
Il progetto deve cercare il meno click.
Verissimo, ma non fino al punto di eliminare passaggi utili o necessari.
Questa conferma intende una view con un azione da fare.
Implica di analizzare tutti casi possibili. "Che succede se l'utente non lo fa" "che succede quando l'ha fatto"
Ad esempio, si potrebbe stabilire che se l'utente non conferma una VoceDiCarrello, alla chiusura dell'OrdineProduttore essa viene cancellata automaticamente. Una volta confermata, una VoceDiCarrello diventerebbe un OrdineGasista (oppure, a livello implementativo, l'OrdineGasista passa da NON_CONFERMATO a CONFERMATO).
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 2 years ago by fero
Replying to lfranc:
Replying to dom_thual:
Se è un azione che serve solo al sistema direi NO. Vuole dire che il sistema non è in sintonia con l'utente.
Non sono sicuro di aver capito quello che vuoi dire; la domanda in oggetto non è se l'azione di conferma serva o meno al Sistema (non ci interessa, almeno in questa fase) ma se un meccanismo di conferma degli ordini da parte dei Gasisti sia utile/necessario.
Credo che Dominique intendesse proprio dire che secondo lui non è necessario.
Comunque questo ticket è da chiudere perché abbiamo verificato le posizioni differenti del GAS di Dominique e del GAS di Peppe e sia l'uno che l'altro si trovano bene nella propria modalità e la ritengono indispensabile. Dominique non conferma il Carrello, mentre Peppe sì.
Questo accompagnato al fatto che non sono una cattiva pratica né l'uno, né l'altro modo di operare, vuol dire che dobbiamo rendere questa possibilità configurabile nello strumento di configurazione "wizard" per i GAS.
Cerchiamo di non tornare su aspetti analizzati pls.
comment:4 in reply to: ↑ 3 Changed 2 years ago by lfranc
Replying to fero:
Cerchiamo di non tornare su aspetti analizzati pls.
Sono d'accordo, ma mi sembrava un passaggio necessario per fissare le idee e lasciare una traccia delle nostre discussioni nella documentazione (per noi e per i posteri ;-))
comment:5 Changed 2 years ago by dom_thual
Quindi si da la possibilità di confermare o no il carrello secondo le impostazioni del GAS.
Questa decisione implica una gestione a stati. I stati da gestire sono 2
- NON_CONFERMATO
- CONFERMATO dal Gassista
Questa gestione interviene a livello di OrdiniGasista o a livello di Carrello Gasista?
Nel GAS esiste la chiusura Ordine. Questo evento non esiste nelle piattaforma di e-commerce dove è la conferma del carrello di un consumatore a permettere di proseguire l'acquisto creando un ordine.
Che succede quando un referente chiude e ci sono dei OrdiniGassista o carrelli non confermati?
Sul Vocabolario sono stati definiti per l'OrdineGassista 7 stati!
Adesso servono 2 stati. Questo per i GAS che intendono obbligare i loro Gassisti a confermare che quello che c'è dentro il carrello e veramente quello che hanno messo dentro il loro carrello.
Gli altri stati servono?
In quanto i stati
FINALIZZATO
INVIATO
CONSEGNATO sono stati già gestiti a livello di OrdineProduttore. O si intende creare una gestione a livello di prodotto di questi concetti?
In quanto i stati
RITIRATO
ANNULLATO sono facile da scrivere ma implica un implementazione e degli impegni umani che non si verificano nel mondo dei GAS.
il stato ANNULLATO può essere fatto nella nota associata al OrdiniGasista quando un prodotto non è consegnato durante la consegna.
il stato ANNULLATO viene già gestito quando si usa uno degli globali l'Eventi
il Produttore rimuove un Prodotto dal CatalogoProduttore
il Produttore aggiorna la disponibilità dei Prodotti nel ListinoProduttoreGAS
L'OrdineProduttore viene annullato (non verrà consegnato)
Definendo questo stato ANNULLATO al livello di prodotto si intende creare un implementazione?
Cioè un interfaccia manuale dove il turnista potrà:
per ogni produttori
per ogni gassista
per ogni prodotto
fare una seria di operazioni?
- il prodotto non c'è
- il prodotto è stato consegnato parzialmente
- il costo è variato
scrivo anche per lasciare una traccia delle nostre discussioni nella documentazione.

Se è un azione che serve solo al sistema direi NO. Vuole dire che il sistema non è in sintonia con l'utente.
Il progetto deve cercare il meno click.
Questa conferma intende una view con un azione da fare.
Implica di analizzare tutti casi possibili. "Che succede se l'utente non lo fa" "che succede quando l'ha fatto"
Non mi sembra che porta un miglioria ma solamente qualcosa in più.
Nel mondo dei GAS esiste un evento importantissimi
dove vengono congelati tutti ordini fatti e vengono mandati al produttore dopo elaborazione data