Voir les détails de l’anomalie
| Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
|---|---|---|---|---|---|
| 0001092 | NOALYSS | Improve Use | public | 2015-04-19 13:47 | 2015-07-02 23:30 |
| Rapporteur | Marca | Affecté à | danydb | ||
| Priorité | normale | Sévérité | mineur | Reproductibilité | toujours |
| État | fermé | Résolution | corrigé | ||
| Version du produit | 6.8.0.0 | ||||
| Résumé | 0001092: Ageing report | ||||
| Description | Ageing 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. | ||||
| Informations complémentaires | Notes 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. | ||||
| Balises | Aucune balise n’est attachée. | ||||
| Extension Noalyss | |||||
|
|
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). |
|
|
Oui, c'est bien correct. Bon travail, BàT. |
|
|
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. |
| Date de modification | Nom d’utilisateur | Champ | Changement |
|---|---|---|---|
| 2015-04-19 13:47 | Marca | Nouvelle anomalie | |
| 2015-04-28 13:01 | danydb | État | nouveau => accepté |
| 2015-04-28 13:01 | danydb | Version ciblée | => Next Release |
| 2015-05-15 18:35 | danydb | État | accepté => affecté |
| 2015-05-15 18:35 | danydb | Affecté à | => danydb |
| 2015-06-03 23:42 | danydb | Note ajoutée: 0002801 | |
| 2015-06-04 08:53 | Marca | Note ajoutée: 0002802 | |
| 2015-06-06 08:46 | danydb | Note ajoutée: 0002804 | |
| 2015-06-07 20:03 | danydb | ||
| 2015-06-07 20:05 | danydb | État | affecté => résolu |
| 2015-06-07 20:05 | danydb | Résolue dans la version | => Next Release |
| 2015-06-07 20:05 | danydb | Résolution | ouvert => corrigé |
| 2015-06-07 20:20 | danydb | ||
| 2015-07-02 23:29 | danydb | Version ciblée | Next Release => 6.8.2.0 |
| 2015-07-02 23:30 | danydb | Résolue dans la version | Next Release => 6.8.2.0 |
| 2015-07-02 23:30 | danydb | État | résolu => fermé |
