Ticket #114 (new compito)

Opened 3 years ago

Last modified 7 months ago

Gestione degli ordini inter-GAS a livello di modello Django

Reported by: lfranc Owned by:
Priority: minore Milestone: Futuro
Component: sviluppo Keywords: intergas
Cc:

Description


Change History

comment:1 Changed 3 years ago by fero

  • Milestone set to Consegna finale

comment:2 follow-up: ↓ 6 Changed 3 years ago by fero

La proposta (minimalistica) di Dominique, è quella di aggregare letteralmente gli ordini:
aggiungere un campo GUID al modello !GASSupplierOrder che ha semplicemente il compito di raggruppare gli ordini. Tali ordini verranno gestiti simultaneamente su tutti i GAS.

Sarà poi l'interfaccia grafica a gestire appropriatamente "l'aggancio dei vari GAS" (v. ticket #178)

Io credo che possa essere una soluzione adeguata per il raggiungimento dell'obiettivo. Lorenzo?

comment:3 Changed 3 years ago by fero

Per spiegare in poche altre semplici parole.

Il GUID in sostanza rappresenta un "gruppo".

Aggiungi un campo al modello GASSupplierOrder:

  • Gli ordini come li conosciamo ora sono quelli con GUID = NULL
  • Gli ordini di retina saranno quelli con GUID NOT NULL
  • Ogni ordine di retina sarà un gruppo di ordini singoli con lo stesso GUID

Questa implementazione consente anche di agganciare gli ordini già aperti presso un altro GAS.

Come implementazione minimale va già bene perché tutti gli altri elementi (nome dell'ordine, data di chiusura e consegna) si possono derivare con degli algoritmi nostri.

Ad esempio: possiamo dire che l'ordine di retina non è finalizzato fin quando l'ordine di un singolo GAS è aperto.

Ma anche questo è un vezzo. L'importante per noi è poter dire "questi ordini stanno insieme". Non li inviamo al fornitore se non insieme.

Dirò quasi di più: in quest'ottica è l'ordine tradizionale che diventa un caso particolare. Per evitare di gestire casi particolari potremmo anche impostare sempre di default il GUID all'id dell'ordine.

Quell'ordine risulterà "aggregato con nessuno" (ovviamente non mostreremo questa dicitura nell'interfaccia, ma ci risulterà comodo poter evidenziare gli ordini di retina insieme a tutti gli altri ordini con un colore/icona/simbolo diverso).

Fino alla parte del "fare" l'ordine mi sembra che non ci siano problemi.

Credo che anche dal punto di vista economico sia perfettamente coerente gestire con ingressi/uscite nei conti fornitore e singoli gas. Come archivio documentale la fattura, se si vuole archiviare, la possiamo archiviare in tutti i gas che partecipano all'ordine.

comment:4 Changed 3 years ago by dom_thual

Si il GUID è il collante. Adesso potrebbe essere anche un IntegerField?.

Gli ordini aggregati possono anche essere inviati singolarmente al produttore. Se esso si propone di fare i pacchi per famiglia.

Il report aggregato mostrerà solo la parte aggregato dei prodotti e non la parte per famiglia.

"Dirò quasi di più:" Non credo sia utile. dall'eccezione non facciamo nascere una regola.
la pagina per aprire un ordine deve rimanere semplice e focalizzarci sul suo obbiettivo.
Non si deve introdurre concetti InterGAS a questo livello.
Lascerei tranquillamente il campo a NULL.

Ok per le icone

Le pagine dedicate all'InterGAS, che troveremo nella parte DES del gestionale, si occuperà di propagare le azioni a tutti GAS (avvanzamento del Worflow, gestione contabile...)

comment:5 Changed 3 years ago by fero

Non sono d'accordo quando dici "troveremo gli ordini intergas nella parte DES del gestionale". È dall'inizio che lo dici. E dall'inizio che ti dico che dobbiamo pensare al modo più coerente di inserirli.

Nel nostro design pattern abbiamo le risorse. Le risorse sono modelli. L'ordine intergas così gestito è nello stesso modello dell'ordine, e questo intanto è un punto a favore per gestirlo in maniera coerente agli altri ordini.

L'interfaccia grafica della maschera di creazione dell'ordine non viene sporcata perché se l'attributo "is_intergas" (che ho rinominato in "can_be_grouped") che hai a mio avviso giustamente aggiunto nel GASSupplierSolidalPact (a meno di osservazioni che attendiamo da Lorenzo), è abilitato, ci sarà un piccolo bottone che indicherà "associa altri GAS" o, ripeto, come i fieldset "collapsed" di Django, che li vedrei molto bene.

Un attributo che potrebbe mancare è req_invoice per indicare a chi deve andare la fattura in caso la riceva un gas solo, o un sottoinsieme di GAS. Se la riceve sempre uno solo, si potrebbe impostare il group_id degli ordini appartenenti all'ordine di retina, al valore dell' id del master. Credo che l'assenza di questa informazione ci potrebbe portare difficoltà, ma vi chiedo delucidazioni in merito.

comment:6 in reply to: ↑ 2 Changed 3 years ago by lfranc

Replying to fero:

La proposta (minimalistica) di Dominique, è quella di aggregare letteralmente gli ordini:
aggiungere un campo GUID al modello !GASSupplierOrder che ha semplicemente il compito di raggruppare gli ordini. Tali ordini verranno gestiti simultaneamente su tutti i GAS.

Sarà poi l'interfaccia grafica a gestire appropriatamente "l'aggancio dei vari GAS" (v. ticket #178)

Io credo che possa essere una soluzione adeguata per il raggiungimento dell'obiettivo. Lorenzo?

Dopo averci riflettuto un po' (ma non quanto il tema meriterebbe ;-)) mi sento di fare queste considerazioni:

  1. una gestione degli ordini inter-GAS basata sull'aggregazione a posteriori di ordini singoli mi sembra una soluzione accettabile (almeno in questa prima fase dello sviluppo della piattaforma) e soprattutto (relativamente) poco "costosa"; ho qualche riserva sulla gestione delle consegne/ritiri e delle fatture, ma credo che siano problematiche superabili
  2. in un'ottica di più lungo termine, sono convinto che gli ordini inter-GAS vadano implementati e gestiti separatamente (anche a livello di modello dati); questo perché il workflow e le problematiche di questo genere di ordini sono diverse da quelle degli ordini singoli, relativamente ad alcuni aspetti cruciali come:
    • gestione apertura/chiusura
    • gestione consegne/ritiri
    • gestione contabile

comment:7 Changed 7 months ago by orly

  • Keywords intergas added; retina ordine removed
  • Priority changed from importante to minore
  • Milestone changed from Consegna finale to Futuro

Una prima implementazione di alcune delle ipotesi suddette è in questo momemento in fase di test d' uso reale.

Vediamo come impattano e cosa ci suggerisce la realtà d' uso  che notoriamente supera la fantasia e guardiamo al futuro.

Note: See TracTickets for help on using tickets.