Ticket UUID: 9c3ea0c6aa8c18405e90b72b8eaf16b253a44612
Title: Création d'écritures dans des comptes vides/inexistants lors d'import
Status: Fixed Type: Code_Defect
Severity: Critical Priority: Immediate
Subsystem: Resolution: Fixed
Last Modified: 2019-05-10 10:47:55
Version Found In: 0.9.2
User Comments:
zou added on 2019-05-08 21:02:58:

Lors d'un import CSV, il est possible de créer des opérations avec une écriture au débit ou au crédit qui ne corresponde pas à un compte existant (càd un compte vide, ex.: « compte_credit = "" »), en ayant un des deux champs vides dans le fichier CSV.

Les lignes suivante me laissent penser que ça aurait pu être volontaire, mais je n'arrive vraiment pas à voir dans quelle circonstance une telle situation devrait être possible. Même avec la compta simplifiée, toutes les catégories affectent un compte en débit et un autre en crédit.

Fichier: include/lib/Garradin/Compta/Import.php, l.162-169 :

if (trim($debit) == '' && trim($credit) != '')
{
	$debit = null;
}
elseif (trim($debit) != '' && trim($credit) == '')
{
	$credit = null;
}

Ça pourrait être corrigé en ayant ceci à la place des affections à null :
throw new UserException('Erreur sur la ligne ' . $line . ' : champs « Compte de débit - numéro » vide.');
Ou dans Journal.php, dans _checkFields, l.280, en ajoutant ce test aux conditions :
... || is_null($data['compte_debit']) || ...

(j'aurais sûrement pu le corriger moi-même mais je sais pas encore me servir de Fossil trop et j'ai peur de faire des bêtises, mais peut-être je m'y pencherais après, quand j'aurais fini mes bidouilles avec mes scripts perso de migrations)
(pardon encore si jamais c'est un truc qui parait évident à côté duquel je passe)


bohwaz added on 2019-05-10 08:47:55:
Jolie trouvaille !

La raison de ce code c'est qu'avant la 0.9 les reports de soldes étaient fait avec le crédit ou débit à NULL vu que je ne savais pas quel compte il fallait utiliser.

Mais maintenant on utilise les comptes 890 et 891, ce qui est la manière correcte de faire.

Ce bug est donc corrigé dans [1e77de77403c1d1c632dcc7617813c995ede5668] merci !