Project

General

Profile

Feature #496

Itération prélèvement

Added by Christian Proust over 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Start date:
07/31/2016
Due date:
% Done:

0%


Description

Voir sur:

https://pad.gresille.org/p/oArCSjfnm2-ambre-iteration-prelevements

#Itération prélèvement et relance

##Description

###Prélèvements

1. Sur décision de l'abonné, le paiement d'un abonnement peut être réalisé par prélèvement ordonné par Rézine.
1. Si la période de facturation est mensuelle, le prélèvement par Rézine est obligatoire.
1. Il est possible de générer des prélèvements à partir des factures qui ont comme moyen de paiement le prélèvement.
1. Chaque prélèvement comportera une référence de facture et un status : à envoyer, envoyé, réglé.
1. Il est possible de valider un prélèvement. Le paiement correspondant sera généré.
###Export ledger

1. Il sera possible de générer un ou des fichiers d'écritures (facture \& paiement) au format ledger. La précision de ces fichiers reste à définir (a ton besoin d'un niveau de précision par adhérent ?).
###Relances

1. II est possible d'effectuer des relances à partir de factures non payées
1. Les relance seront envoyées par mail.
1. Elles comporterons les références des factures concernées et des éventuels paiements déjà effectués.

##Commentaires

###Factures

"Lors d'une facturation, si la période n'est pas complète le montant est calculé au prorata."

--> ça devient compliqué pour les VPN, avec des montants possiblement chelous, avec des centimes… à voir si paiement en espèces
--> mais si on a plus à manipuler ces chiffres, c'est plus très grave qu'il y ait des centimes ? Ou sinon, on peut arrondir aussi.

###Paiements ###
###Prélèvements

"Si la période de facturation est mensuelle, le prélèvement par Rézine est obligatoire."

--> pas d'accord, certains membres fonctionnent par virement auto et ça fonctionne très bien (et en plus c'est gratos pour Rézine et pour le membre)
--> Si Rézine a un jour autant d'abonnés que FDN, tu vas tirer la langue :P (cf ce que je met ci-dessous… dans tous les cas, faudra checker)
--> pas d'avis tranché sur la chose. D'autant que ça change pas grand chose (peut être seulement la possibilité de mettre une référence unique vérifiable automatiquement par la suite).
--> Je ne vois pas la nécessité d'imposer un moyen de réglement dans le SI. Si jamais ça nous embête, on peut toujours refuser le réglemement, mais c'est une opération « de vive voix ».

"Il sera possible de générer des prélèvement à partir des factures en prélèvement."

je n'ai pas compris cela. +1
--> en fait, lorsque l'on générère une facture on peut spécifier un moyen de réglement.

Mais du coup, il se passe quoi si le moyen de réglement n'est pas correspondant après l'émission de la facture ?

"Il est possible de valider un prélèvement. Le paiement correspondant sera généré."
--> pas d'acc avec ça. Je pense que les prélèvements doivent être  automatisé à la banque et un pointage de fait à postériori (car dans  tous les cas faudra pointer pour voir si des prélèvements ne sont pas  passés)
--> Oui c'est exactement ça... lors du pointage de la transaction coté la banque, le prélèvement dans le si est validé et le paiement correspondant aussi.
Sur les prélèvements
il manque ici un certain nombre de cas liés aux prélèvements : que se passe-t-il si un prélèvement échoue ? --> pour moi, les prélèvements doivent forcément être validés dans le SI après réussite du prélèvement
> Je parle pas tant du mécano de validation que du statut de l'objet en lui-même. Si un prélèvement échoue, il faut le re-présenter à la banque. Du coup le SI doit savoir gérer ça.
-> pour moi, c'est pas le SI qui gère les prélèvements. Le lien automatique avec la banque, c'est la misère à mon avis. +1 :D
-> Chez FDN, le mécano c'est : le SI génère un batch de prélèvements (un fichier CSV avec un prélèvement par ligne). On le donne à manger à la banque. La banque nous dit les prélèvements qui ne sont pas passés : il faut les pointer (à la main) dans le SI. Les autres sont réputés payés lors de la cloture mensuelle suivante. Ça permet de faire moins de travail à la main, en moyenne. Cela dit le fonctionnement par clotures mensuelles est très spécifique à FDN, pes certain que ce soit reproductible.
-> avec le crédit mut, on n'a pas à faire d'émission de prélèvement à chaque mois. Cela est automatique une fois qu'on a rentré le prélèvement une fois et choisi la redondance.
-> Ah, ok. Du coup, c'est pas du tout automatisable ? :
( Quand Rézine aura grandi, ça sera la merde :-/ > non, je pense qu'on peut faire l'inverse : tiré du crédit mut un listing csv des prélèvements réalisés et le confronter au SI. Faudrait que qqun qui sait faire du python puisse implémenter cela dans weboob ;) Haha :)
> Pour info, FDN est au crédit Mut aussi ;) --> du coup, oui, on peut faire les deux au crédit mut, il suffit de ne pas entrer de rendondance aux prélèvements et donner à manger un fichier de prélèvements chaque mois. C'est un point de vue différent. Je préfère automatiser côté banque et faire la vérif de ce qui est passé ou pas passé.
-> En fait la question de fond, c'est savoir "où" est la vérité. Si tu considères que la source primaire c'est la banque, le SI suit. Si le SI décide de ce qui doit être prélevé, la banque suit. Dans les deux cas Rézine a la main dessus, mais si le SI a pour objectif à long terme de gérer toute la tréso / compta, je trouve que ça a du sens de considérer que ça doit être lui qui tire les ficelles.
-> ok… mais faut agir manuellement chaque mois à une date précise. Perso, j'ai pas envie de ça ;) -> Bin non, pourquoi une date précise ? -> parce que j'ai pas envie de facturer 3 mois d'un coup parce que j'ai pas fait cela pendant 3 mois. Bin, c'est pas lié. Tu peux, le 4 juillet, générer les créances portant sur des services du mois de mars. Ça génère les prélèvements correspondants, que tu mets en paiement à la banque quand ça t'arrange. Et tu fera le mois d'avril quand tu voudras, plus tard. --> ben ouai… du coup, le 4 juillet, te met en paiement des trucs qui ont 3 mois d'age, je trouve pas ca cool. Nan mais c'était pour l'exemple. En pratique, tous les mois tu clos le mois d'avant :) --> ben voilà… c'est ce que je dis, faut penser à le faire et j'ai pas forcément envie de faire comme ça.

La facture ne doit pas être ré-émise, mais la créance reste due. Le SI doit-il re-présenter la créance due le
mois suivant, en plus de la créance liée à la nouvelle facture du mois ? Y a-t-il un seuil de prélèvement max ?
Si ce seuil est atteint, fait-on un prélèvement qui couvre des portions de créances ?
Que faire si l'abonné donne du liquide pour payer son mois d'abonnement, alors que son prélèvement a été
refusé en banque ? --> +1
Peut-on annuler un prélèvement ? Peut-on attacher un autre paiement à la facture
concernée en remplacement d'un prélèvement annulé ? (Il y a sans doute plein d'autres cas <3) --> +1
<==

--> En conclusion pour mon avis, il faut laisser l'automatisation côté banque et pointer à posteriori. Du coup : WEBOOB WEBOOB WEBOOB !!!! :D

--> Bon, je ne suis pas sur de bien comprendre votre discussion. Le SI poura être capable de générer des prélèvements au format CMUT (même si ce n'est pas nécessaire que cela soit utilisé) et il faudra pointer les transactions de la banque et valider chaque prélèvement dans le SI (de manière automatique ou non).

Mon sentiment, sur les prélèvement c'est qu'il faudra peut-être mieux attendre l'itération 4, 5, ... A vouloir en faire trop d'un coup, on risque de ne rien arriver à sortir.
A la limite, si une opération se révèle réccurente et longue, on trouvera alors moyen de l'automatiser (par exemple, en téléchargeant un CSV ou CMUT pour la liste des prélèvements à effectuer, ou en téléversant le CSV contenant la liste des prélèvement effectués).
Mais cette opération ne conditionne pas selon moi le reste de l'itération 3.

Lors d'une facturation, si la période n'est pas complète le montant est calculé au prorata
Je pense qu'il faut aussi créer la notion d'« éléments de facturation ». Un éléments de facturation contient est une raison de facturation (par ex: 1 mois de VPN, ou cotisation annuelle). Une facture peut alors regrouper plusieurs éléments de facturations. Comme ça, on ne facture que les services complets.

Cela me paraît surtout important en cas de contentieux sur un élément à facturer. Dans ce cas-là, on doit pouvoir faire un avoir sur l'élément en question, si besoin.

History

#1 Updated by Christian Proust over 4 years ago

  • Tracker changed from Bug to Feature

#2 Updated by Christian Proust almost 4 years ago

  • Description updated (diff)
  • Target version set to Version future

Also available in: Atom PDF