Produits Entr'ouvert » Lingo

Quel est la distinction qui est faite ici entre transaction et paiement ? Lingo ne gérant pas le paiement lui même mais ne recevant que les évènement finaux payé/pas payé, d'où vient la différence ?

Ici ce sont juste des endpoints pour pouvoir déclarer un paiement effectué en guichet: le parent a déposé 10 cesu de 10 euros chacun, mais il a 3 factures à régler d'un montant de 40€ chacune: ce dépôt permet de solder complètement les 2 premières factures et une partie de la 3e.
transaction = 100€ en cesu
3 paiements:
paiement 1 facture 1 40€
paiement 2 facture 2 40€
paiement 3 facture 3 20€

Ok bien compris, on retombe sur un concept habituel de transaction comptable entre un compte client et un compte de facturation, une transaction ventilant un paiement de manière automatique en prenant pour chaque facture le reste à payer.

Je pense qu'il faudrait se rapprocher d'un modèle comptable, ça commencerait par avoir un modèle pour le payeur plutôt que de le référencer implicitement via Invoice.payer_external_id. C'est pas que ce soit mal de faire ça mais je trouve bien de toujours matérialiser les objets métiers.

Ensuite je ne matérialiserais pas le solde des factures sur les factures elle même c'est quelque chose qu'on peut recalculer à la volée sans aucune erreur donc pas de Invoice.paid_amount/remaining_amount.

Ensuite j'aurai un objet Payment pour le paiement en lui même qui référencerait le payeur (Payer) et la régie/compte de facturation concerné et des InvoicePayment pour la ventilation et aurait un identifiant de paiement (payement_reference) venant de combo/lingo, ou n'importe quoi qui nous déclare un paiement (formulaire pour déclarer un paiement en espèce/chèque au guichet) pour éviter de compter un paiement deux fois, lingo remontant pas mal de données, il faudrait les ranger dans un payment_data, c'est plus pour du debug qu'autre chose mais c'est bien pratique.

Ça ne change pas grand chose dans make_payment, sauf que sans paid_amount/remaining_amount on devra calculer ainsi la création des InvoicePayment:

invoice_remaining_amount = invoice.payment - sum(invoice_payment.amount for invoice_payment in invoice.payments)
invoice_amount_paid = min(remaining_amount, invoice_remaing_amount)
InvoicePayment.objects.create(invoice=invoice, amount=invoice_amount_paid)
remaing_amount -= invoice_amount_paid

Au final comme dans le code actuel il peut arriver (dans l'absolu) que le montant payé dépasse le montant des factures visés ou soit inférieur, pas bien grave, parce qu'on a la balance du payeur pour faire des ajustements sur de futures factures :

Payer.balance = lambda: sum(invoice.amount for invoice in payer.invoices) - sum(payment.amount for payment in payer.payments)

Account.balance = sum(payment.amount for payment in account.payments) - sum(invoice.amount for invoice in account.invoices)

Avec l'introduction du modèle Payer je serai aussi d'avis de le verrouiller lui plutôt que chaque facture (via .select_for_update()) parce que c'est plus simple pour raisonner, pendant une transaction on s'occupe de toute ce qui concerne un payeur et rien d'autre.

Benjamin Dauvergne a écrit :

Ensuite j'aurai un objet Payment pour le paiement en lui même qui référencerait le payeur (Payer) et la régie/compte de facturation concerné et des InvoicePayment pour la ventilation et aurait un identifiant de paiement (payement_reference) venant de combo/lingo, ou n'importe quoi qui nous déclare un paiement (formulaire pour déclarer un paiement en espèce/chèque au guichet) pour éviter de compter un paiement deux fois, lingo remontant pas mal de données, il faudrait les ranger dans un payment_data, c'est plus pour du debug qu'autre chose mais c'est bien pratique.

Je pense même qu'il faudrait prévoir une ventilation qui descende niveau des lignes de facture, supposons une ligne "Cantine du 01/14 au 30/04 | 20 repas | payé: 0 euros, du: 20 euros ", on facture c'est payé. 1 mois plus tard le pointage est modifié ou le tarif révisé ou le QF change, que sais-je, mais le montant de la dette change, et donc la ligne aurait du être 18 euros, il faut pouvoir régénérer une ligne "payé: 20 euros du: -2 euros".

Automatic expiration