Produits Entr'ouvert » Publik

Maintenant¶

Les factures distantes¶

Une régie considère qu'elle gére des factures distantes quand une url vers le webservice permettant de les récuperer est définie.
Elle appelle des urls spécifiques du webservice pour récuperer l'historique et les factures en cours.

Lors d'une tentative de paiement d'une facture son identifiant est stocké dans la transaction et le backend de paiement est appelé.
Lors du callback par le backend de paiement l'identifiant de la facture distante est récupéré de la transaction et la régie est chargée de notifier le webservice(via passerelle) du paiement cette facture(Regie.pay_item)

Facture locales (items)¶

Objets django locaux associés à une régie.
Lors du paiement les objets sont liés à la transaction(ManyToMany). Au callback du backend de paiement pour chaque item une notification est envoyé à wcs.

Dans l'avenir¶

Dans l'avenir il faudrait peut-être commencer par revoir l'idée de notification du paiement, eventuellement passer l'url à appeler en parametre de la régie.
La gestion des factures distantes et locales est à revoir aussi.

Et donc, pour résumer par rapport au titre du ticket "Gérer des factures" : c'est à revoir.

(côté imio c'est des paiements, pas des factures, qui sont gérées)

Hmm le fonctionnement à Fontenay ne me parait pas si affreux, finalement. Dans le cas de Fondettes on peut imaginer un nouveau module concerto qui:

• répond au même protocole que celui qu'il y a entre lingo et le module teamnet
• permet d'injecter les CSV au format Concerto
• génère un CSV au format concerto via une vue et une commande en ligne (pour faire des exports réguliers par cron+mail)

Watdouiousink ?

Benjamin Dauvergne a écrit :

Hmm le fonctionnement à Fontenay ne me parait pas si affreux, finalement. Dans le cas de Fondettes on peut imaginer un nouveau module concerto qui:

• répond au même protocole que celui qu'il y a entre lingo et le module teamnet
• permet d'injecter les CSV au format Concerto

En évitant de l'appeler "concerto" mais juste "lowcostregie" (autre idée bienvenue), qui accepte un format de CSV normé par nous, définissant des machins à payer :

code	montant	date debut	date fin	email	autres infos ...
F2015008712	12.33	2015-10-10T00:00:00	2016-01-02T23:59:59	payeur@example.net	...

• génère un CSV au format concerto via une vue et une commande en ligne (pour faire des exports réguliers par cron+mail)

Plutôt le job de lingo, à mon avis, de proposer une vue (protégée) export de ses transactions (par défaut les denières 48h ; avec en querystring la possibilité d'avoir les transactions "des 10 derniers jours" ou "du tant au tant").

Le problème si ce n'est pas le module passerelle qui fait tout c'est qu'on aura pas toutes les informations dans les transactions lingo or là pour Fondettes on nous demande l'ID_FAM, le reste à payer, etc.. en sortie (alors que Lingo n'en a rien à foutre). Alors soit on recopie tout ce qu'on a de Passerelle dans lingo lors d'un paiement mais alors autant tout faire dans Lingo soit on est obligé de faire une jointure entre les informations dans Lingo et celle dans Passerelle pour obtenir le CSV définitif.

Je pencherai pour bien séparer les deux, dans Lingo on a les transactions, dans lowcostregie les factures et leur état, reste à payer (si jamais on permettait les paiements partiels), toute sorte d'identifiants venant de l'application métiers, etc..