Supporto degli atti degli uffici (determine e ordinanze)

[scaloni]

Modella atti amministrativi emessi dagli uffici comunali (Office), a firma di una o più cariche amministrative (AdministrationCharge).

La classe Office modella un ufficio, che ha dipendenze gerarchiche con altri uffici, dunque necessita di un campo ParentOffice che lo metta in relazione con un altro Office.

La determina/ordinanza, oltre a quanto ereditato da Act, aggiunge:

• total_commitment: valore dell'impegno di spesa totale che l'atto stabilisce (introdotto a scopo di cache o nel caso non venga popolata la tabella commitment);
• commitment_set: una relazione con zero o più impegni di spesa (commitment)

Un impegno di spesa (commitment) ha i seguenti campi:

• manager: il responsabile del procedimento (di tipo AdministrationCharge)
• amount: l'importo dell'impegno
• payee: il beneficiario (di tipo Company)
• selection: la modalità di selezione (enumerativo: direct, competition, other)

La classe Company modella un beneficiario, che ha il campo idnum utilizzato per il codice fiscale o la partita IVA.

[fspegni]

Aggiornamento:

• l'override del tipo di un campo dichiarato nella classe parent non e' consentito in Django, sembra per ragioni tecniche: http://stackoverflow.com/questions/2344751/in-django-model-inheritance-does-it-allow-you-to-override-a-parent-models-a
• in generale mi sono accorto che la classe Act si lega ad una Institution emittente; gli Office non sono Institution, bensi' dei Body (anche le Institution sono Body). Morale: la classe Act e' stata progettata per modellare in realta' atti di natura politica.Se vogliamo proseguire su quella linea, dovremo prevedere una classe "sorella" che funga da superclasse a tutti gli atti di ufficio (es. OfficeAct). Questo porta a duplicare la definizione di alcuni attributi (che sarebbero comuni sia ad Act che ad OfficeAct). Inoltre quando si faranno query per reperire gli atti, occorreranno query distinte per atti politici e per quelli d'ufficio (che possono essere poi aggregati in fase di visualizzazione).

Prima di scegliere che strada intraprendere, credo sia opportuno sentire l'opinione di @guglielmo

[fspegni]

Suggerimenti per il nome della classe per Determina e Ordinanza? Dovrebbe esistere il termine Ordinance in inglese, ma per Determina ho visto suggerire ManagerResolution oppure ManagerDecision. Da quanto ho letto una "resolution" in genere e' una decisione/regolamento approvato a seguito di voto (cosa che non avviene per le determine, se ho capito bene). Che ne pensate?

[scaloni]

Ammesso che tradurre specifici atti italiani abbia senso, ormai in OM è stato sempre fatto e continuerei.

Ordinanza sembra meglio tradotta in Decree (vedi http://www.wordreference.com/iten/ordinanza), mentre per Determina propenderei per Decision

[fspegni]

Piccola modifica al modell proposto:

• Commitment dovrebbe avere un payee_set (anziche' un payee), cioe' una relazione molti-molti, perche' i beneficiari di un impegno di spesa (potenzialmente) possono essere piu' aziende
• metto tutti i campi di Commitment come opzional, tranne: manager, amount
• la classe Company e' attualmente presente nell'app people, senza l'attributo idnum; lo aggiungo.
• non m'e' chiaro se ha ancora senso avere due classi (Decree e Decision) se alla fine aggiungono i medesimi campi. Al momento se lo facciamo, ci serve solo a modellare il tipo di atto (infatti nealla realta' i due atti sono formalmente diversi, mi risulta). Non vedo nessuna difficolta' in questo, ma vorrei una conferma che lo stiamo facendo solo per questo scopo.

Se siamo d'accordo su questi punti, committo e pusho.

[scaloni]

Premessa sul nome Decision: in realtà intendevo specificare la sua natura non politica, e quindi la chiamerei OfficeDecision.

Un Commitment impegna la spesa per un solo beneficiario, Se una Decree o una OfficeDecision impegna soldi verso destinatari diversi, lo fa con molteplici Commitment. Intendevi comunque questo @fspegni ?

[fspegni]

In realta' no: se l'appalto (il lotto) viene vinto da un gruppo di aziende, dubito che vogliamo modellare il gruppo di aziende come Company, quindi pensavo fosse piu' semplice modellarlo come un legame verso molte Company (le componenti del gruppo vincitore).

Inoltre: immagino che un impegno di spesa possa corrispondere a piu' lotti, e ciascun lotto puo' avere un vincitore (anche diverso dagli altri lotti). In questo caso ci occorre ugualmente legare l'impegno a molte `Company'.

Riguardo Decree e OfficeDecision: cmq confermi che hanno entrambi esattamente gli stessi campi. Giusto?

[scaloni]

Si confermo

[fspegni]

Per la questione del legame con le Company cosa decidiamo? 1-1 o 1-N ?

[scaloni]

L'analisi che hai suggerito mi convince: se l'appalto (il lotto) viene vinto da un gruppo di aziende, serve modellare il gruppo di aziende come molte Company (una per ogni componenti del gruppo vincitore).

[scaloni]

@fspegni pensavo fosse sufficiente un rapporto 1-a-molti tra un atto Decision/Decree e un Commitment, invece vedo che l'attributo commitment_set è definito come ManyToManyField. Puoi chiarire questo aspetto?