@aspangaro-Inovea je peux la lier manuellement aussi, mais il y en a énormément et c’est fastidieux, de ton côté la liaison est automatique ? sur quel code comptable ?
mon install a été créé sur une V6 (ou V5) à l’origine, et upgradée depuis, si jamais ca peut avoir une influence.
après essais complémentaires, ca fonctionne correctement avec l’API également (problème de cache sur le serveur).
Donc pour résumer l’utilisation de FACTURES_DEPOSITS_ARE_JUST_PAYMENTS permet de faire en sorte que la ventilation comptable soit automatique, ce qui peut résoudre mon problème actuellement.
reste le « problème » de ventilation des (DEPOSIT) qui n’est pas automatique ches moi et que @aspangaro-Inovea n’arrive pas à reproduire. Je veux bien mettre mon instance en accès pour une vérification par un spécialiste si ca peut aider à débuger.
Cette variable FACTURES_DEPOSITS_ARE_JUST_PAYMENTS n’est en effet surement pas prise en compte par le web service, comme elle ne l’est pas non plus par le module compta) car elle n’est pas supportée (abandonné depuis de nombreuses années car qucun cas d’utilisation connu conforme avec les bonnes pratiques comptables ne semble justifier son utilisation).
Hello @eldy,
Non, c’est faux, le module compta prend en compte cette variable et de ce fait, les factures d’acomptes ne sont pas liés en compta car elles sont justes des paiements donc la réflexion est bonne et doit servir dans certains pays comme c’était le cas par le passée en France avant qu’on préconise aujourd’hui de faire des factures pour les acomptes.
Après pour les lignes deposit non ventilé automatiquement, c’est car il s’agit d’une liste de ligne libre et il n’y a pas de type particulier pour identifier cette ligne, il faudrait déjà qu’on voit ça car dans le meilleur des mondes, il faudrait que ça parte en 419 pour identifier l’avancement des projets au moment de la clôture comptable.
« les factures d’acomptes ne sont pas liés en compta car elles sont justes des paiements »
En effet, elle ne sont pas ventilés dans le journal de vente puisque ce sont des paiements, mais, sont elles ventilés dans le journal de banque comme paiement ? Il me semble pas non plus. C’est ce que je voulais dire en disant qu’elle n’est pas géré par le module compta. Me trompe-je sur ce point ?
bonjour @eldy , je confirme que la ventilation en banque est effectuée, je vous joint des screenshots pour une facture payée en partie par un acompte (depuis l’API)
la facture d’acompte
la facture finale
dans le journal de vente on ne voit que la facture finale
dans le journal de banque on a bien les deux règlements
et je retrouve ces écritures dans le grand livre .
Donc vu d’ici ca semble bien fonctionner, et ce que je demande surtout c’est si cette fonctionnalité sera supportée dans les évolutions de versions ou pas.
1 « J'aime »
Il faudra donc compter sur des contributions pour prendre en charge l’option sur les api.
Par contre, quand a dire qu’elle sera toujours supportés, il est difficile de dire oui, puisque déja, elle ne l’est pas encore (outre les api, elle n’est pas non plus incluse dans les test unitaires).
après avoir regardé de plus près dans l’api, il y a un hic final c’est que [GET]/invoices/{id}/payments] ne retoune rien pour les avoir et les acomptes saisis en paiement… mais on s’éloigne du sujet d’origine, je vais voir si je peux me pencher sur ce sujet et faire une PR.
bilan comptablement ca tient la solution peut fonctionner, mais ca ne résoud pas le problème d’origine des lignes (DEPOSIT) qui n’ont pas de code comptables lorsqu’elles sont sur les factures.
Alexandre, @aspangaro-Inovea dis-moi s’il est préférable d’ouvrir un ticket sur github et on pourra clore cette discussion (pour le moment).
Hello @jerash, merci pour le PR.
Pour l’affectation automatique des comptes, j’avais prévu un correctif, il a été modifié dans la 10.0.5. L’affectation automatique fonctionne même pour les acomptes (lignes libres) mais il faudra cocher la case du bout de la ligne alors que j’avais prévu qu’elle soit cochée par défaut.
Pour en discuter, tu peux ouvrir un ticket sur github et je te laisse m’affecter le ticket.
Bonne journée,
Bonjour,
Je suis nouveau sur ce forum bien que j’utilise Dolibarr depuis fin 2018.
En passant avec la réservation en ligne, j’utilise désormais intensivement les factures d’acomptes et je suis tombé sur le même problème que @jerash pour la ventilation automatique des DEPOSIT.
J’ai la version 9.0.0 de Dolibarr.
Que conseillez-vous, d’utiliser la variable FACTURES_DEPOSITS_ARE_JUST_PAYMENTS, ou bien d’ajouter le correctif modifié dans la 10.0.5 ? Si c’est la 2ème solution, comment faut-il s’y prendre ?
je vous remercie, et encore bravo pour tout ce travail open-source,
Bonne journée
Réponse très tardive…
Ne serait-il pas mieux de monter de version ?
J’ai constaté récemment un autre problème lié à cette option de configuration.
J’ai dû faire un avoir sur la facture d’acompte parce que le paiement finalement devait intervenir sur un autre tiers. Mais si la facture d’acompte n’est pas en compta, l’avoir l’est, ce qui est parfaitement illogique 
Surtout ne jamais utiliser la variable FACTURES_DEPOSITS_ARE_JUST_PAYMENTS.
Il a plein de probleme avec cette ancienne option cachée non officielle, elle est abandonnée depuis des années.
Son développement est incomplet et son usage non compatible avec les pratiques de comptabilité préconisée actuelle. Activer cette option déprécié, c’est mettre son dolibarr en état instable et s’exposer a des problemes fiscaux.
Bonjour @eldy ,
En quoi la variable FACTURES_DEPOSITS_ARE_JUST_PAYMENTS n’est pas compatible avec les pratiques de comptabilité préconisées actuelles ?
Quelles seraient les bonnes pratiques ?
Merci du retour,
Cordialement.
Bonjour
Je reviens sur cette question car j’ai le même problème. J’utilisais auparavant ACTURES_DEPOSITS_ARE_JUST_PAYMENTS que j’ai retiré il y a une bonne année.
J’ai un facture client créée par la suite en tant que facture d’acompte. A réception du paiement, j’ai noté payée et passé en crédit disponible.
J’ai affecté ce crédit à la facture finale qui est noté comme « DEPOSIT »
Dans la partie comptabilité, la ligne n’est pas liée et n’est pas proposée de code comptable, j’hésite à la forcer en 4191
Merci
Bonjour,
désolé de ne pas avoir de réponse à la question précédente, mais je viens de tomber sur ce fil de discussion en cherchant des infos concernant les factures d’acompte.
Au moins en Allemagne et en Autriche, les acomptes pour les factures (payés via une facture d’acompte incluant la TVA) NE DOIVENT PAS être comptés dans le chiffre d’affaires mais doivent être comptabilisés sur un compte spécial de paiement d’acomptes jusqu’à l’émission de la facture finale. Sur la facture finale, l’acompte est déduit du total initial comme une sorte de paiement spécial. Cela semble être un peu le cas inverse de la France.
La variable FACTURES_DEPOSITS_ARE_JUST_PAYMENTS semble donc être presque la bonne. Il faut juste ajouter une déclaration de la partie TVA du paiement de l’acompte reçu (nous avons donc besoin du montant total, de la TVA totale, du montant de l’acompte, de la TVA sur l’acompte et du montant restant à payer).
Ce fil de discussion et le commentaire de @eldy m’ont appris que cette variable est quelque peu dépréciée. Je comprends qu’elle ne doit pas être utilisée en France, mais serait-il possible, d’un point de vue technique, d’activer et d’utiliser cette fonctionnalité dans des pays ayant des législations différentes ou est-elle déjà dépréciée au point de causer des problèmes à l’avenir ?
Merci pour toute information et désolé pour la traduction automatique et le saut dans ce fil, mais je pense que c’est le meilleur endroit pour discuter de cette question.
La traduction automatique est juste parfaite !
L’option FACTURES_DEPOSITS_ARE_JUST_PAYMENTS agit surtout sur la manière de stocker l’info en base et de la présenter. Elle n’a pas été prise en compte partout dans les rapports (donc elle est buggué actuellement). Il y a bien 2 modes de fonctionnement (Mode A: acompte en ligne de facture ou B: en ligne de paiement). Cette option va poser problème à l’avenir car
Si active, les données sont stockée d’une manière qu’on peux difficilement faire de rapports ou de la ventilation comptable dans le mode B)
Alors que si l’option n’est pas active, on peut facilement ventiler en comptabilité selon le mode A ou B (meme si actuellement on ne fait que le A).
On a voulu changer la manière de représenter et comptabiliser les info différemment en changeant la manière de le stocker. Ce qui était selon moi une erreur car le code est doublé partout et la compréhension de la manière de stocker dure à comprendre. Il doit y avoir 1 seule manière de stocker ls données (et on a choisi celle qui est la plus compatible avec les 2 modes, en l’occurrence celle où FACTURES_DEPOSITS_ARE_JUST_PAYMENTS n’est pas définie). Et ce sont les écrans ou exports qui doivent ensuite s’adapter selon le mode A ou B via une option, mais je préférerais une autre option que FACTURES_DEPOSITS_ARE_JUST_PAYMENTS.
Par exemple, pour la ventilation en comptabilité, as-tu regardé l’option
« Compte comptable pour les acomptes » dans la page de configuration de comptabilité double partie des « comptes par défauts » (option ACCOUNTING_ACCOUNT_CUSTOMER_DEPOSIT).
Je pense que cela correspond à ton « compte spécial ». Si non défini, c’est une ventilation de facture comme les autres. Si défini, cela va dans un compte spécial. Ton retour pour savoir si cela répond à ton problème pour l’Allemagne sera précieux…
Merci beaucoup pour vos explications détaillées. Il semble maintenant clair de ne plus utiliser les FACTURES_DEPOSITS_ARE_JUST_PAYMENTS (et pourquoi) mais d’opter pour le futur mode B des factures de dépôt.
Décider entre le mode A (considéré comme revenu) et le mode B (considéré comme paiement) sur la base de la présence du compte comptable de dépôt est une excellente proposition.
Je regarderai ce qu’il faut faire pour la mettre en œuvre - à la fois, la sortie correcte sur la facture et l’intégration avec la comptabilité. Je suis assez optimiste quant à la possibilité de satisfaire aux exigences réglementaires de l’Allemagne et de l’Autriche et peut-être d’autres pays.
