devcode-it / openstamanager

Il software gestionale open source per l'assistenza tecnica e la fatturazione
https://www.openstamanager.com
GNU General Public License v3.0
110 stars 69 forks source link

Consistenza direzione dei documenti #618

Open beppe9000 opened 5 years ago

beppe9000 commented 5 years ago

Sono poco esperto di contabilità... ma come mai i ddt in entrata hanno direzione 'uscita' e vice versa?

image

Dasc3er commented 5 years ago

Le direzioni inserite a database utilizzando sempre la logica del flusso di denaro:

Similmente per i DDT:

beppe9000 commented 5 years ago

grazie, è stato un dubbio da quando ho iniziato a studiarmi il codice di osm :)

Dasc3er commented 5 years ago

Quando ho inziato a modificare il codice era piuttosto confusionaria come definizione, e acondora è una delle cose che non è completamente documentata 😞

beppe9000 commented 5 years ago

Ne sono uscito pazzo prima di comprendere che per ddt in entrata devo controllare che $dir sia uscita e vice versa ;)

Magari si potrebbero definire come costanti da qualche parte... tipo const DDT_IN_ENTRATA = 'uscita'; Almeno il codice diventa più intuitivo da capire anche senza una documentazione specifica...

Dasc3er commented 5 years ago

Si potrebbe pensare di utilizzare una classe apposita che definisce le costanti, però poi dovrebbe essere utilizzata anche nel database. In alternativa potremmo inserire una tabella, ma non hanno senso altri tipi di flussi di denaro a quanto ne so...

Il metodo più semplice possibile è ampliare la documentazione in questo senso.

@loviuz cosa ne pensi?

loviuz commented 5 years ago

Eh lo so, al tempo era solo per i documenti, poi è stato esteso ai ddt e con il cambio di dicitura nei ddt (ingresso, uscita) è stato il top di confusione 😅 Si potrebbe aggiornare il termine, ma andrebbe cambiato il dir nel db per poter ancora gestire il tutto tramite query. Suggerimenti?

beppe9000 commented 5 years ago

Per come la vedo io per tenere il tutto semplice si può includere un file costanti.php da core.php subito dopo aver incluso config.in.php.

In quel file si possono quindi definire le costanti:

const OSM_DDT_IN_ENTRATA = 'uscita';
const OSM_DDT_IN_USCITA = 'entrata';
// per esempio se gli stessi valori sono usati con significato diverso si definisce il significato
const OSM_DOCUMENTO_IN_USCITA = 'uscita';
const OSM_DOCUMENTO_IN_USCITA = 'entrata';

Una volta definite queste costanti dir nel database non cambia, ma si possono sostituire tutte le stringhe usate direttamente nei select/update/if di PHP, ovvero:

if($dir=='entrata') exit; 

diventa

if($dir==OSM_DDT_IN_ENTRATA) exit; 

Tra l'altro non è nemmeno necessario sostituire tutto perchè alla fine i valori non cambiano, quindi il gestionale continua a funzionare anche senza un aggiornamento completo di ogni occorrenza, quindi si tratta di deprecare l'utilizzo diretto delle stringhe 'entrata' e 'uscita' in favore di costanti con nomi più descrittivi.

Quindi se necessario basta usare il valore della costante per eventuali query da eseguire, ricordandosi di invertire dir rispetto alla direzione reale.

Direi che una soluzione del genere è un buon compromesso, considerando che si tratta di modifiche minime. In pratica si relega la confusione nel file delle costanti. Se uno legge il codice invece dovrebbe risultare più intuitivo perchè nome della direzione e i nomi delle costanti usate per controllare la direzione sono concordi.

Magari si può documentare questa cosa proprio nel PHPDoc delle costanti?

Vi sembra ragionevole?

Dasc3er commented 5 years ago

L'unico difetto di questa logica è che la presenza delle costanti nel codice provoca uno scollegamento dalla logica del database. Per questo proporrei invece una ulteriore modifica: al posto di gestire la direzione come campo apposito, si potrebbe modificare in un flag flusso_debaro_entrante o simile da utilizzare come boolean visto che non sono posso altri flussi.

Dasc3er commented 5 years ago

L'unico difetto di questa logica è che la presenza delle costanti nel codice provoca uno scollegamento dalla logica del database. Per questo proporrei invece una ulteriore modifica: al posto di gestire la direzione come campo apposito, si potrebbe modificare in un flag flusso_debaro_entrante o simile da utilizzare come boolean visto che non sono posso altri flussi.

beppe9000 commented 5 years ago

L'unico difetto di questa logica è che la presenza delle costanti nel codice provoca uno scollegamento dalla logica del database.

Non ti seguo molto... 😖 il database non dovrebbe contenere i dati e basta?

Per questo proporrei invece una ulteriore modifica: al posto di gestire la direzione come campo apposito, si potrebbe modificare in un flag _flusso_debaroentrante o simile da utilizzare come boolean visto che non sono posso altri flussi.

Un flag apposito mi sembra buona come idea, e si può mantenere la retrocompatibilità facilmente sincronizzando il valore di dir in base al valore di quest'ultimo.