Ticket #29 (closed compito: sistemata)

Opened 4 years ago

Last modified 9 months ago

Stabilire se può esistere più di un OrdineProduttore aperto per un dato Produttore in un dato istante

Reported by: lfranc Owned by: somebody
Priority: importante Milestone: Documento di analisi funzionale
Component: analisi Keywords: chiedereGAS
Cc:

Description

In linea di principio, in un dato istante possono coesistere più OrdiniProduttore aperti per un dato Produttore.

Bisogna però porsi alcune domande:

  • è un grado di libertà utile per favorire la gestione dei processi intra-GAS, inter-GAS e GAS-Produttore ?
  • è in conflitto con l'adozione di buone pratiche da parte dei GAS ?
  • qual è lo sforzo implementativo addizionale richiesto per supportare questo scenario ?

Change History

comment:1 Changed 4 years ago by dom_thual

in teoria...

In pratica all'interno di un GAS si verifica un ordine alla volta per produttore . 

La gestione di un ordine è strettamente gestita all'interno del GAS.

InterGAS: Cui si dobbiamo chiederci se un referente di un altro GAS può aprire un ordine?

In pratica: ciascun GAS apre il suo ordine. Ciascun GAS lo chiude. (motore)

Alla chiusura un referente, su una view particolare, ha la possibilità VIRTUALLE di aggregare varie ordini di più GAS per lo stesso produttore

Gestione mono ordine per produttore

  • il referente InterGAS seleziona il produttore
  • appare una lista di GAS (perché c'è un ordine chiuso per GAS)
  • Seleziona i GAS che intende raggruppare

Un piccola entità OrdineInterGAS viene creata.  E composta da una lista di OrdiniProduttore.

In modalità multi Ordine per produttore all'interno di un GAS lo sforzo per aggregare risulta assai più complesso. Ansi questo referente dovrebbe scendere a livello di listino parziale per poter scegliere gli ordini giusti.

Anche la gestione del motore diventerebbe complicata. Come si farà in automatico a fare una lista al volo di alcuni prodotti si ed alcuni no?

Non mi risulta utile la possibilità di aprire più ordine dello stesso produttore contemporaneamente. 

Richiederebbe uno sforzo maggiore per lo sviluppo perché cambia il modello.

Complica anche l'uso del sistema da parte dei utenti.

E molto più complicato perché questo piccolo "principio" apre 2 DIMENSIONI

da mono ordine/data --> Multi ordini/data

Gestione a livello di produttore --> Gestione al livello di prodotti/produttore.

Tutto il sistema sarebbe coinvolto nella variazione del modello. 

La scarterei subito. E dopo un anno di utilizzo del sistema. Riproporrei questo principio. (2011-2012)

comment:2 Changed 4 years ago by fero

  • Keywords chiedereGAS added
  • Component changed from preparazione to analisi

Capisco le perplessità di Dominique. Secondo me la questione è da porre ai GAS il 31 all'incontro territoriale.

Premesso che gli ordini multipli aperti contemporaneamente servono in particolar modo per l'offerta di servizi (viaggi, corsi, ...) che non sono il principale oggetto di questa prima fase di implementazione, ma sono utili e quindi il nostro modello dovrà PREVEDERE questo caso,

il nostro obiettivo è capire se i GAS useranno il software pur NON AVENDO la possibilità di ordini multipli aperti contemporaneamente.

Io penso di sì. Ma coinvolgiamoli su questa problematica e su questa scelta.
Per questo aggiungo il tag chiediGAS a questo ticket.

comment:3 Changed 9 months ago by orly

  • Status changed from new to closed
  • Resolution set to sistemata

Dopo due anni di utilizzo mono gas della gestione ordini, credo che con l' attuale possibilità di aprire più ordini dello stesso produttore tra più gas (Intergas)ci sia data una reale possibilità di migliorare le relazioni tra gas che possa facilitare la costituzione di aggregati più grandi, o per usare un termine preso a prestito dalla fisica quantistica "domini di coerenza" correlati tra loro che danno vita a domini sempre più vasti che formano organismi più complessi in fase tra loro, che possano supportare come un onda portante, l' economia solidale da modello di economia di nicchia a economia di tutti.

Chiudo quindi questo ticket dandolo per acquisito, se poi i termini della discussione facessero riferimento ad altri concetti non ben esplicitati o da me mal recepiti, potra comunque essere riaperto:)

Note: See TracTickets for help on using tickets.