Logiciel Pastèque/API/Fix dupes in stocks

= Fix for pasteque server issue #15 =
Issue 15: Doublons appears in inventory
Found on 6.0
Caused by: adding movements with 0 quantities duplicates stockcurrent line with null attributesetinstance_id.
Fix for 7.0: don't save movements with 0 as quantity in StockService
Rebuild a broken STOCKCURRENT table.
Use the following script to rebuild the broken table from STOCKDIARY
MySQL :
 -- Kill the crappy STOCKCURRENT
 TRUNCATE STOCKCURRENT;
 -- Rebuild from STOCKDIARY
 INSERT INTO STOCKCURRENT (LOCATION, PRODUCT, ATTRIBUTESETINSTANCE_ID, UNITS)
 SELECT LOCATION, PRODUCT, ATTRIBUTESETINSTANCE_ID, SUM(UNITS) AS UNITS FROM STOCKDIARY GROUP BY LOCATION, PRODUCT, ATTRIBUTESETINSTANCE_ID;

Logiciel Pastèque/Misc/Calcul TVA
Mode de calcul de la TVA et des arrondis
Résumé du problème
Le calcul des tarifs HT + TVA = TTC pose des problèmes d'arrondis dès lors qu'ils sont sommés.
Voici un cas pour lequel le prix HT plus la TVA n'est pas égal au prix TTC sur le ticket.
 Un produit à 7,12€TTC le kilo, soit 6.748815165876778€ HT le kilo(en base, v7).
 Vente de 1,200Kg à une TVA de 5,5%.
 TTC = 8,54€ (affiché sur le ticket. 7,12 x 1,2 = 8,544)
 HT = 8,10€
 TVA = 0.45€
 HT + TVA = 8,54
Quel que soit l'arrondi lorsque l'on utilise des calculs intermédiaires, il y aura tôt ou tard une erreur d'arrondi qui se propagera.
Par exemple si on se débrouille pour que pour chaque ligne de ticket HT + TVA = TTC, on pourra retrouver sur la somme des bases de TVA une erreur d'arrondi. Idem avec l'application de réductions.
Solution utilisée
Étant donné qu'il est impossible d'avoir l'intégralité des calculs justes, on se contentera uniquement des valeurs affichées sur le ticket pour chaque ligne et on fera les calculs de TVA uniquement sur les totaux.
Le calcul HT + TVA = TTC n'est effectué qu'une seule fois sur les totaux. Toutes les sommes sont arrondies à 2 décimale. De cette manière il est impossible d'obtenir une erreur d'arrondi sur une seule ligne.
Dans tous les cas, les valeurs finales HT + TVA = TTC par taux et le grand TTC sont tous arrondis à 2 décimales.
Mode B2C
Pour le commerce avec des particuliers, c'est la valeur TTC qui est importante, puisque c'est celle qui est affichée sur le ticket et payée. On ne calculera donc pas le HT et la TVA ligne par ligne, mais uniquement sur les totaux.
 Pour chaque ligne de ticket, on ne calcule que la valeur TTC. Elle vaut (PU TTC x quantité) x (1 - taux de remise). TTC x quantité est arrondi à 2 décimales, tout comme le résultat final. Le prix unitaire au poids peut être sur 5 décimales, mais on arrondit toujours à 2 décimales pour le prix en quantité.
 Pour le ticket, on fait la somme des TTC de chaque ligne. Comme toutes les lignes sont arrondies à 2 décimales, le total du ticket est également sur 2 décimales. Ce total avant remise est affiché.
 On fait la même somme par taux de TVA, ceux-ci ne sont pas affichés car non significatifs (on attend la remise).
 On applique ensuite le taux de remise du ticket au total pour obtenir le tarif TTC à payer.
 On applique le taux de remise sur chaque total par TVA, puis on calcule le montant HT et de TVA associés.
On peut obtenir une erreur d'arrondi au pire de (nombre de taxes - 1) centimes, uniquement lorsqu'une remise est appliquée. Deal with it.
En effet, hors remise sur le ticket il n'y a pas de calcul intermédiaire effectué sur les sommes TTC. Comme la remise est affectée au total TTC, il n'est pas possible de répercuter cette remise sur les totaux par taux de TVA sans faire de calcul intermédiaire, sauf à ne pas les arrondir ce qui n'a pas de sens (la compta est sur 2 décimales).
On pourrait trouver des incohérences si on essaie de recalculer le détail HT ligne à ligne, mais on s'en fout en vrai puisque ces valeurs ne sont ni affichées, ni utilisées en compta.
Mode B2B
Pour le commerce entre professionnels, c'est la valeur HT qui est affichée. On se contentera donc de ne pas calculer le tarif TTC pour chaque ligne (puisqu'il n'a pas de sens) et on ne fera le calcul que sur le total pour obtenir le montant à payer.
Cette section présente encore quelques zones floues, parce que cette méthode n'est de toute façon pas encore implémentée.
 Pour chaque ligne de ticket, on ne calcule que la valeur HT. Elle vaut (PU HT x quantité) x (1 - taux de remise). HT x quantité est arrondi à 2 décimales, tout comme le résultat final (ou pas). Le prix unitaire au poids peut être sur 5 décimales.
 Pour le ticket, on fait la somme des HT de chaque ligne. Ce total avant remise est affiché.
 On fait la même somme par taux de TVA, ceux-ci ne sont pas affichés car non significatifs (on attend la remise).
 On applique ensuite le taux de remise du ticket aux totaux par TVA pour obtenir le tarif HT de chaque taux.
 On calcule la TVA associée à chaque taux, pour obtenir un TTC à 2 décimales.
 On fait la somme des TTC pour obtenir le prix TTC final à payer.
On pourra retrouver une incohérence de (nombre de taxes - 1) centimes avec une remise entre la somme des HT par TVA et le HT total. Deal with it aussi.

Logiciel Pastèque/Server/Upgrade 6 to 7
= Upgrading Pasteque v6 to v7 =
Server.
Upgrade database.
Like for every major version, run the upgrade script to update the database.
No conversion is required for the server to work but it can have some surprises with modules.
JWT configuration.
There are two new properties in the config file
 // JWT auth
 $config['jwt_timeout'] = 600; // Validity in seconds of an auth token
 $config['jwt_secret'] = "Change this to a superstrong password";
Put these two new properties in the config file and change the jwt_secret. It is used to sign and verify the auth tokens, don't hesitate to put a 256 character long random string with special characters.
Auth modules.
Openbar was deleted. If your server used it, you are suggested to switch to inifile for a simple configuration or local to put user accounts in a database.
PHP 5.5 is required for Inifile auth module.
Inifile uses password hashing. You can use the following php-cli script to generate the hash property. You may also use an online generator like https://pasteque.pro/user_ini.php
 <?php
 if ($argc < 2) {
 system("stty -echo");
 $password = fread(STDIN, 80);
 $password2 = fread(STDIN, 80);
 system("stty echo");
 if ($password != $password2) {
 file_put_contents("php://stderr", "Password mismatch\n");
 die();
 } else {
 $password = $argv[1];
 echo "password=" . password_hash($password, PASSWORD_DEFAULT);
Logging.
A new layer of loggin has been added in v7 with new configuration properties. With more log output, the server can write the log in a dedicated file along the system log (usefull when you can't have access in real time to the system log):
 // Uncomment to add an other log directory. System log is still enabled.
 //$config['log_dir'] = "/var/log/pasteque";
 // Log level: one of DEBUG, INFO, WARNING, ERROR
 $config['log_level'] = 'WARNING';
The user running the server must have write permission to the targeted directory. A new log file is created every day.
Modules.
The core modules for managing enabled modules were deleted.
Instead, the list of activated modules is set in the APPLICATIONS table. The upgrade script set it by default to all. You may have to change this value from the previous configuration.
Clients.
No special changes required. Just upgrade the clients and let's go.