devcode-it
Maggiore precisione nei calcoli
In futuro potrebbe essere utile prevedere l'implementazione di un qualche sistema o libreria dedicato a gestire in modo preciso le operazioni di calcolo sui prezzi.
Infatti, come indicato dalla documentazione ufficiale PHP (http://php.net/manual/en/language.types.float.php), l'utilizzo dei tipi di dato nativi per effettuare calcoli ha una precisione limitata. Questo può portare a malfunzionamenti imprevedibili e considerevoli, in particolare nel confronto tra numeri e nei valori decimali (per esempio, nei calcoli dello Scadenzario, riga 19 del file modules/scadenzario/actions.php).
L'implementazione della funzione sum nella versione 2.3 ha migliorato e unificato il sistema con cui vengono effettuati molti di questi calcoli, ma i tipi nativi di PHP sono ancora utilizzati e il problema rimane.
Alcuni esempi di librerie più o meno avanzate che potrebbero essere candidate per questa soluzione:
- https://github.com/moneyphp/money
- https://github.com/Litipk/php-bignumbers
- https://github.com/brick/math
Questi progetti utilizzano solitamente delle stringhe per gestire i numeri internamente, ma la loro implementazione richiederebbe molto lavoro per sostituire tutti i calcoli interni al gestionale.
Potrebbe inoltre risultare utile controllare la libreria Math PHP (https://github.com/markrogoyski/math-php#finance), che offre alcuni sistemi di calcolo avanzato a livello finanziario.
avendo la precisione a 4 decimali si sono presentate varie volte delle differenze in centesimi nei calcolo, soprattutto con quantità elevate, anche di svariati centesimi, pochissimi casi comunque. il punto cruciale è usare sempre i 2 decimali per i calcoli e fare attenzione a quando si arrotonda.
da valutare quelle librerie
Per ora, sembra che sui decimali non ci siano altri particolari problemi. Gli unici sorti ora erano in fattura, dove veniva usato un sistema di arrotondamento diverso, e nel piano dei conti.
Ad oggi, confermo che i calcoli con i decimali funzionano correttamente. Non so se serve introdurre altre librerie. Il problema principale dei decimali è che, ad esempio nelle fatture, andava sommata l'iva di ogni riga considerandola a 4 decimali, mentre importi e sconti arrotondandoli a 2 (o per il numero di decimali delle impostazioni). Infatti, dividendo per 100 un numero con 2 decimali, inevitabilmente diventa a 4 decimali, per cui l'iva va sempre considerata a 4.
@loviuz La proposta era per rendere più sicuro il sistema di contabilità, proprio perchè i float in PHP non sono precisi. Malgrado per ora non si siano verificati particolari problemi, si tratterebbe di un miglioramento considerevolmente utile a livello di sicurezza dei calcoli.