Bonjour à tous !

Première partie de mon post : description de l'évolution

Pour cette nouvelle évolution que je viens de livrer (presque en totalité) pour mes utilisateurs tout est parti du fait que dans notre business on reçoit des chèques mais que l'on ne peut encaisser tout de suite car la négociation a abouti à des règlements échelonnés par exemple sur 6 mois.

Le pb est que l'on a un 'paquet de chèques' dont on veut connaitre à tout moment le total, la ventilation par client, la répartition 'reçu encaissable' et 'reçu pas encore encaissable' et que ces 'réceptions' de chèques apparaissent dans des montants 'non encaissés' ou 'encaissés' même si il ne s'agit plus d'impayés au sens client car ce dernier a donné une 'garantie' de paiement sous forme de chèque (en particulier).

Comment faire ?

Sans modifier le modèle de données et en utilisant au 'maximum' deux dates :

1. Une 'date' non complètement utilisée à sa juste valeur dans la table llx_paiement, 'datec' (=remplie par défaut jusqu'à présent avec la même valeur que la date de 'réception'), qui doit désormais dans tous les cas être remplie par la date à laquelle le règlement est encaissable (date minimale d'encaissement en quelque sorte, sans préjuger du dépôt effectif en banque et encore moins du crédit sur le compte bancaire)

2. En utilisant la seconde date 'datep', toujours dans llx_paiement, déjà utilisée pour indiquer la 'réception' d'un chèque, mais qui désormais peut être vide. Ce 'vide' indique que le chèque n'a pas encore été reçu.

Cela signifie que l'on peut créer, dès le départ (lors de la validation de la facture) et de façon automatique, en fonction des conditions de règlement ('à réception', '30j', ... + des nouvelles conditions du type 'Acompte 40%, Solde 60% à l'installation', 'Echéancier standard : n chèques, à intervalle de 1 mois", ....), TOUS LES REGLEMENTS avec date encaissable et date de réception (vide, ou non si déjà acompte reçu avant même d'avoir fait la facture).

Bien sûr cela entraine le besoin de modifier un règlement (le montant et la date de réception seulement a priori) ce qui était impossible auparavant.


Seconde partie de mon post : questions sur le fonctionnement actuel

Il y a 2 stratégies (ou plus ?) pour gérer les factures et les règlements :

1. On crée 1 seule facture et n règlements (échéances) dont le total est le total de la facture
2. On crée n factures (échéances) dont le total est égal au total de la proposition et n règlements (1 pour chaque facture)


La stratégie actuelle de Dolibarr est assez énigmatique pour moi. En effet il existe 2 tables : llx_paiement (dont la colonne fk_facture est à NULL) qui contient un montant (on va y revenir), les dates, ... et la table llx_paiement_facture qui 'relie' les factures et les montants avec leur rowid (fk_paiement et fk_facture) et un montant également (on va y revenir).

Ce que l'on peut constater si on veut créer un règlement (bouton "Emettre un règlement" dans une facture) on se retrouve dans une page qui donne la possibilité de rentrer 1 ( n?) règlements avec plusieurs montants pour toutes les factures (il y a une liste) associées au client de la facture depuis laquelle on a voulu "Emettre un règlement". Je ne me suis 'aperçu' de cette saisie 'multiple' que très récemment car à force de faire des tests j'obtient plusieurs factures pour un client (alors que normalement j'en ai une seule, parfois 2 si il y a eu une maintenance hors garantie). C'est très troublant je dois avouer car l'action d'émettre un règlement concerne normalement 1 seule facture et pas plusieurs, surtout que l'on est bien parti d'une facture en particulier (sans avoir 'coché' au préalable n factures par exemple).

J'ai regardé dans le code ce qu'il se passait et j'ai été surpris de constater que si on remplit les montants associés à chaque facture pour le 'règlement en cours d'émission' on obtient un montant total stocké dans llx_paiement et les montants partiels dans llx_paiement_facture. On peut donc avoir 1 règlement et n factures, et non pas obligatoirement 1 ou n règlements par facture, ce qui semblerait 'naturel'. Je n'en vois pas l'utilité et cela me rappelle le fonctionnement des banques qui, à la suite d'un envoi/dépôt de plusieurs chèques, ne font apparaitre l'opération sur votre relevé de compte que sur 1 seule ligne avec le montant total et non autant de lignes que de chèques, ce que je trouve inacceptable (surtout en 2010 avec les technologies de gestion des comptes).

Ma question est donc : pourquoi aurait-on besoin de saisir des 'montants de règlements' en 'masse', avec une seule date de 'réception' (pour le 'règlement' dans llx_paiement) mais concernant plusieurs factures du même client (dans llx_paiement_facture) ?

Cela supposerait qu'un client envoie d'un seul coup (ou du moins que l'utilisateur Dolibarr les rentre au même moment) plusieurs règlements pour plusieurs factures. Cela pourrait s'expliquer si la notion d'échéancier de paiement est 'artificiellement' (et incomplètement disponible car pb de date d'encaissement non disponible) possible dans Dolibarr à condition de créer 'à la main' autant de facture que nécessaire (stratégie n°2). C'est ça ?

Romain

J'ai finalisé l'évolution pour la retrouver partout dans Dolibarr, c'est à dire en 'vertical :

--> dans la Tour de Contrôle (Box des Box)
--> dans la liste des factures
--> dans chaque facture
--> dans les règlements
--> dans la liste des chèques
--> dans les bordereaux

La gestion des règlements 'reçus', 'reçus encaissable', 'reçus encaissés' et des chèques en 'attente de date d'échéance' est donc désormais en production.

Romain