View Issue Details

IDProjectCategoryView StatusLast Update
0001092NOALYSSImprove Usepublic2015-07-02 23:30
ReporterMarca Assigned Todanydb  
PrioritynormaleSeveritymineurReproducibilitytoujours
Status ferméResolutioncorrigé 
Product Version6.8.0.0 
Summary0001092: Ageing report
DescriptionAgeing report
Une facture payée est une facture avec une date de paiement
Date de paiement cette date est ajoutée lors d'un rapprochement avec un paiement ou manuellement
Pour toutes les factures payées , il faut déterminer le nombre de jours entre la date d'échéance (si elle est absente ce sera la date de facture + intervalle par défaut du journal) et le paiement et le répartir dans un tableau <30 , [30,60[, [ 60,90 [ , > 90.
Plus import CSV et choix de la période à considérer.

Additional InformationNotes supplémentaires :
La date d’échéance est un autre problème, idéalement elle devrait pouvoir être indiquée dans la fiche client directement et calculée automatiquement pour chaque facture (avec la possibilité d’écraser la date proposée par une autre, le cas échéant).
Pour moi, si la date n’est pas indiquée, ce devrait être la date de facture par défaut (« au grand comptant », quoi).
Mais en te lisant, je crois qu’on ne se comprend pas bien : la date de départ est la date d’échéance, si elle est indiqué sinon c’est la date de facture, par exemple le 15/01/2015 et nous sommes aujourd’hui, le 6/4
0 - 30 >> 0 car après le 15/02
31 – 60 >> 0 car après le 15/03
61 – 90 >> XXX car avant le 15/04 !
Si c’est la date d’échéance : le client est en retard d’au moins 60 jours. Si c’est la date de facture et que son terme est de 30 jours fin de mois, il est en retard de 30 jours au moins.
C’est une liste qui doit être simple à lire, j’ai mis la meilleure que j’ai eu à utiliser en exemple.
Elle est pratique pour les fournisseurs et les clients, je l’étendrais à toutes les catégories de fiches basées sur les fournisseurs et les clients. À priori, je ne ferais pas de sous-sélection, si la liste peut être récupérée sous format .csv.
Le nec plus ultra est évidemment de permettre une date pivot à partir de laquelle l’échéancier est calculé mais le soucis est évidemment de tenir compte des factures impayées à la date pivot. Donc si un paiement est intervenu après la date-pivot, l’échéancier ne doit pas en tenir compte… mais cela devient compliqué.
Si on utilise la date échéance et la date de paiement pour les opérations vente / achat (la date de paiement est normalement inscrite quand on rapproche avec une opération de paiement), ce sera assez simple. Sinon, comment faire pour ceux qui ont des échéances différentes du style 30 jours fin de mois.
Le plus simple, serait de pouvoir indiquer quand commence la balance, l'intervalle (30 jours, 15 jours...) et d'avoir le solde pour chaque intervalle mais dans ce cas, ce serait moins utile: cela n'indiquerait pas le retard de paiement.
TagsNo tags attached.
Extension Noalyss

Activities

danydb

2015-06-03 23:42

administrator   ~0002801

Pour chaque client / fournisseurs (=tiers) on calcule la somme des factures payées dans un délai de 30,60,90 jours en utilisant la date d'échéance comme point de départ, ou si elle n'existe pas la date de facture.

Sommes-nous bien d'accord ?

Cette tâche doit être divisée en 2 : une pour la balance âgée et l'autre pour le calcul automatique des dates d'échéance (journal ou fiche).

Marca

2015-06-04 08:53

reporter   ~0002802

Oui, c'est bien correct. Bon travail, BàT.

danydb

2015-06-06 08:46

administrator   ~0002804

Oui mais ceux qui paie AVANT l'échéance ont un nombre de jours négatif.

Exemple : échéance d'une facture au 25 mars, payée le 23 mars, la différence est de -2 jours.

Issue History

Date Modified Username Field Change
2015-04-19 13:47 Marca New Issue
2015-04-28 13:01 danydb Status new => acknowledged
2015-04-28 13:01 danydb Target Version => Next Release
2015-05-15 18:35 danydb Status acknowledged => assigned
2015-05-15 18:35 danydb Assigned To => danydb
2015-06-03 23:42 danydb Note Added: 0002801
2015-06-04 08:53 Marca Note Added: 0002802
2015-06-06 08:46 danydb Note Added: 0002804
2015-06-07 20:03 danydb
2015-06-07 20:05 danydb Status assigned => resolved
2015-06-07 20:05 danydb Fixed in Version => Next Release
2015-06-07 20:05 danydb Resolution open => fixed
2015-06-07 20:20 danydb
2015-07-02 23:29 danydb Target Version Next Release => 6.8.2.0
2015-07-02 23:30 danydb Fixed in Version Next Release => 6.8.2.0
2015-07-02 23:30 danydb Status resolved => closed