Discussion concernant les factures de situation pour le GIF
GIF - Facture de situation
Les factures de situation peuvent rendre les gens heureux :
7 « J'aime »
Bonjour à tous,
Je n’ai pu participer à la dernière réunion, mais le sujet m’intéresse tout particulièrement.
Si d’autres réunions sont prévues, je suis preneur des dates ou d’une invitation
Je vous fais remonter un échange avec Eldy qui touche au sujet et qui je pense à sa place dans la définition du modèle de données :
Mon mail initial :
Bonjour Laurent,
J’espère que tu vas bien ?
Je suis en train de travailler à améliorer notre module de facture de situation et je voudrais prendre en compte les améliorations apportées sur la V14 et + et sur les demandes des clients
Dans la table llx_facture, nous avons désormais des champs liés à la retenue de garantie. C’est une bonne chose.
De mon côté les clients du BTP me disent qu’ils sont soumis en réalité à au moins 3 types de garantie légales que voici :
- Retenue de garantie, généralement sur le TTC, mais pas toujours (cf autre pays), récupérable 1 an après le décompte général définitif
- Retenue de parfait achèvement, sur le TTC ou le HT, et récupérable à l’expiration de la garantie de parfait achèvement, c’est à dire, 1 an après la réception des travaux
- Garantie de bonne fin de travaux, sur le TTC ou le HT, récupérable à la réception des travaux
Et que les 3 peuvent être cumulés sur des factures.
Mais il pourrait y en avoir d’autres.
Je me demandais donc si il ne serait pas plus judicieux d’ajouter un dictionnaire llx_c_invoice_warranty qui permettrait de gérer les différentes garanties. Ca permettrait, via une table d’échange de sélectionner sur les factures les garanties à utiliser ou non
Qu’en penses-tu ?
Merci d’avance et bonne journée,
Sa réponse :
Cela voudrait dire donc 2 tables en plus.
Une pour le type de retenu de garantie (llx_c_invoice_warranty) et une pour le lien entre la facture et le type de retenu (llx_invoice_warranty).
Comme la table des type génèrera du code spécifique avec des regles de claculs propre à chaque type, une table de type ne sert à rien. Il suffit de convenir les valeurs de codes qui détermine les types de garanties qui seront implémenter dans le code. En effet, cette tabe ne sera pas dynamique. Si on ajouter un 4eme type, il n’y aura pas de code associé. Dans ce cas pas besoin de table dictionnaire.
Mais cela me semble bon d’avoir une gestion des tenus de garanties géré en relation 1,n avec une table llx_invoice_warranty
Pour info, la fonction implémenté actuellement est propre aux factures de situation. Hors la fonction d efacture de situation de dolibarr tel qu’elle est ne sera jamais releasé officiellement sans un réécriture, le modèle physique qui a été choisi étant mauvais est incompatible avec plein d’autres fonction des dolibarr notamment la compta.
donc tu peux tout a fait soumettre une PR pour initier la fonction de gestions des retenues de garantie en relation 1,n qui dans un premier temps ne sera géré que par ton module mais table surlaquelle on pourra s’appuyer lors de la refonte de systeme des factures de situation actuelles qui devrait etre revu.
Merci pour votre travail et à plus tard
1 « J'aime »
Je mets ici le lien vers le post proposé par Eric
1 « J'aime »
Bonjour,
Un client me signale que lorsqu’il utilise la facture de situation, pour un produit vendu sur 3 factures de situation, cet objet est compté 3 fois dans les objets référents et le montant du produit est comptabilisé également plusieurs fois ce qui fausse tous les chiffres.
Merci d’avance de l’intégrer dans les points à traiter
hello @akene
c’est maigre comme description de bug … serait-il possible d’aller à la chasse aux infos ? quelle version de dolibarr, plus précisément comment il fait sa 1ere facture de situation (à partir d’un devis, d’une commande ?) et si c’était possible d’avoir un use-case reproductible ça serait précieux mais ce n’est pas à toi que je vais l’appendre 
J’ai déjà constaté ce comportement. En fait voici ce qu’il se passe pour une ligne de 1000 € HT dans une facture de situation :
- situation 1 : avancement 10% valeur 100€HT
- situation 2 : avancement 30 % valeur 300€HT
- situation 3 : avancement 100% valeur 1000€ HT
- situation 4 : avancement 100% valeur 1000€HT
Donc quand je regarde Dolibarr pour le CA, il fait la somme des lignes et j’ai donc un CA de 2400€ HT pour ces lignes…
Pas conséquent, selon comment les factures de situation avancent, et à quel moment on regarde on trouve effectivement qu’on a fait une bonne année ;)) Ou on se pose des questions.
Cela fait d’ores et déjà parti de la refonte du modèle de données prévue dans le GIF 
@+
Ok si c’est ça on est tous d’accord et c’est ce que @aspangaro-Easya nous a expliqué la dernière fois, pour vérifier ton CA il faut aller en COMPTA et ne pas regarder les totaux des listes de factures qui font effectivement des cumuls.
Je vais ajouter ça dans la doc j’ai oublié en effet de l’indiquer histoire que tout le monde soit raccord !
… sauf que je n’arrive pas à reproduire ce comportement les amis, voilà ce que j’ai sur un dolibarr 17: le total en bas est correct …
Bonjour Messieurs,
Je n’avais pas parlé de l’onglet « Objet référent » d’une fiche produit dans ce que j’avais expliqué mais c’est bien le même problème au même titre que la comptabilité dès que tu travailles avec la table llx_facturedet et les champs total_ht, total_tva_, total_ttc.
Le fonctionnement actuel étant en cumul à partir de la S2, cela fausse totalement les statistiques.
Avancement :
S1 : 30%
S2 : 50% (S1 + 20%)
Statistiques :
S1 : 30%
S2 : 50% (S1 + 20%)
Sur cette dernière partie, il faudrait n’afficher que la partie inhérente au 20% d’avancement de la S2
On en discute mercredi prochain 
Merci @DELTHAIR64
C’est bien ce comportement et c’est bien au niveau des objets référents, pas au niveau de liste de facture
Parfait si c’est prévu d’être modifié.
Je comprends par le message d’Alexandre qu’il y a une réunion mercredi prochain, est-ce que je peux avoir les infos ? Est-ce que les réunions seront systématiquement les mercredis ? (auquel cas je vais avoir du mal à vous rejoindre)
Je croyais que « l’organisateur » t’avais mis dans la boucle des invitations @akene ! je te fais suivre les infos et pour la date nous avons décidés ensemble la dernière fois de la réunion suivante alors c’est sur que c’est pas pratique pour les absents … a voir si on ne relance pas plutôt un framadate pour celle d’apres !
Ok,
histoire d’avoir de quoi faire des tests de « non régression » ou tout au moins « des tests » j’ai documenté ce 2° cas de figure du problème.
Si vous en avez d’autres c’est le moment de le dire histoire que le problème soit le plus documenté possible histoire que ça soit limpide pour tout le monde (et vu le temps que je viens de passer pour produire et documenter ce dernier j’avoue que pour moi ce n’était pas limpide du tout, tout au plus j’avais capté qu’il y avait un « loup » mais sans plus) !
→ wiki à jour GIF - Facture de situation 2022 - Dolibarr ERP CRM Wiki
1 « J'aime »
Bonjour à tous,
Nouvelle réunion ce jour pour valider les 2 premières étapes d’avancement du projet et élaboration de la nouvelle structure pour le future stockage des données pour les factures de situation.
Et ceci toujours dans la bonne humeur : (On dit « Dolibarr »)
Excellente journée à tous,
P.S. : Bon anniversaire Anthony !
5 « J'aime »
Bonjour à tous,
J’en profite pour poser ici le compte rendu d’Aurélien :
CR de la réunion de ce matin :
Le nouveau comportement du fonctionnement "facturedet" proposé semble OK pour les participants.
Il faudrait passer d'un enregistrement de la ligne "total cumulé" à ce qui a été additionné par rapport à la précédente ligne + verouillage de la ligne précédente
C'est sur ce "additionné" que doit se baser le calcul de la TVA
On peut tout de même créer des champs supplémentaires pour enregistrer les totaux
Pour le produit minimum viable, on souhaite embarquer :
Modification du comportement et de la structure de facturedet
Gestion des impacts dans le reste du code Dolibarr
Génération des PDF
Pour les versions suivantes :
Cloture automatique, manuelle, + ou - de 100%, plus ou moins values
Régression (exemple passage de 50% à 45%)
Liaison entre devis, commande et facture
Retenue de garantie
Mise à jour Dolibarr : script pour passer de l'ancien au nouveau système
Actions à suivre :
Par Alexandre OpenDSI : valider le nouveau comportement avec Laurent Destailleur
Par Anthony Progiseize (et Julien Iouston ?) : apporter les modifications + gestion des impacts
Par Eric CAP REL et ?ATM - voir génération des PDF
Par Johan ATP : tests
Un point rapide des échanges lors de la réunion du jour sur les factures de situation :
Création du module de migration des factures de situation :
facture_situation_migration
Dolibarr situation pour les modifications dans le CORE
Points abordés :
-Modèle de données voir la PR ci-dessus
-Sauvegardes des tables notamment llx_facturedet avant la migration
-Déclenchement du script de migration (Migration de la base de la 17 à 18)
-Use_situation_invoice = 2 obligatoire à partir de la 18
-Création des dépôts sur Github
3 « J'aime »
Bonjour,
J’ai enfin pu participer à ce GIF, et je ne regrette vraiment pas ! Si améliorer la facture de situation dans dolibarr vous intéresse, rejoignez-nous lors de la prochaine réunion
→ Sondage - GIF SITUATION - Framadate
Au plaisir de vous y voir !
6 « J'aime »
Compte rendu rapide de la 5ème réunion GIF situation de ce jour :
Présents :
- Anthony Progiseize
- Olivier Progiseize
- Johan ATM
- Nicolas Pragmatech
- Sylvain InfraS
- Nicolas Inovea
- Alexandre OpenDSI
Nouveau participant :
- Julien Iouston (bienvenue !)
Points abordés ce jour :
- Point récapitulatif rapide sur les réunions antérieures notamment sur l’échange du 28/02/2023 où peu de monde était présent qui fait suite au retour de Laurent (Eldy) sur le sujet
- Anthony a travaillé sur la base technique et à montrer le résultat de ces premiers travaux sur un Dolibarr branche develop (v18.0.0-alpha).
Ses travaux ont été publiés sur le git dévolue au GIF Situation : GitHub - progiseize/facture_situation_migration
- Question du financement auprès de Progiseize (Général) : si fonctionnel, un point d’avancement sera réalisé lors de la prochaine réunion du GIF Situation (Voir sondage de date ci-dessous) pour déclencher la facturation auprès de chaque prefered partner rattaché au projet.
- Question du dépôt de garantie (Julien) : sera traité lors d’une prochaine étape du projet
À faire :
- Anthony continue d’avancer sur le sujet de l’intégration dans le core
- Sylvain / (Johan ?) commence à travailler sur les modèles pdfs (InfraS et Sponge_btp) se basant sur les bonnes données d’avancement
- Alexandre corrige la génération des factures de situation en comptabilité (Erreur détectée ce jour)
Liste des modules externes potentiellement touchés par cette nouvelle base : Sous-total, InfraSpack, FacturX
But : Présentation d’une version très avancée lors du devcamp qui aura lieu du 08-11 juin 2023 à Bordeaux
Merci à Alexandre pour le compte rendu !
Bonjour,
Que le temps passe vite !
Il y a eu 3 réunions depuis le dernier compte rendu…
Aujourd’hui, c’était le compte rendu final au Summer devcamp de Bordeaux.
Nous avons présenté une version 18 beta modifiée spécialement pour des tests complets avec un module de migration des données pour corriger les données lorsque les factures de situation (qui est une fonction cachée de base) ont pu être utilisé dans une version où la fonction n’est pas valide.
Il reste deux sujets à finaliser qui sont :
- le pdf
- le log inaltérable
Nous vous tiendrons au courant des derniers travaux et après le but sera d’intégrer ses modifications au sein de la future version 19 de Dolibarr le temps de réaliser des tests conséquents.
Merci à tous les participants du groupe et on continue sur le prochain sujet !
1 « J'aime »
Bonjour à tous,
Un grand merci pour votre travail.
J’utilise les modules factures de situation et sous-total, êtes-vous en mesure de m’indiquer s’ils seront toujours compatibles sur les futures versions ? J’ai pu lire qu’ils pouvaient être impactés. J’avais remonté l’info à @akene concernant le problème de cumul de CA.
En vous remerciant par avance.
