entrouvert
/
lingo
15
0
Fork 0
Code Issues Pull Requests 8 Releases Wiki Activity

facturation: générer un avoir à la clôture d'une facture, si elle est négative (#89810) #188

Merged
lguerin merged 11 commits from wip/89810-invoicing-credit into main 2024-04-30 09:05:00 +02:00
Conversation 3 Commits 11 Files Changed 21 +1176 -182
lguerin commented 2024-04-23 13:35:30 +02:00
Owner
Copy Link
No description provided.
lguerin added 11 commits 2024-04-23 13:35:30 +02:00
lguerin changed title from WIP: facturation: générer un avoir à la clôture d'une facture, si elle est négative (#89810) to facturation: générer un avoir à la clôture d'une facture, si elle est négative (#89810) 2024-04-23 13:41:26 +02:00
pmarillonnet requested review from pmarillonnet 2024-04-23 14:35:18 +02:00
pmarillonnet commented 2024-04-23 14:35:32 +02:00
Owner
Copy Link

Je commence à relire.

Je commence à relire.
pmarillonnet reviewed 2024-04-24 16:33:52 +02:00
pmarillonnet left a comment
Owner
Copy Link

Quelques trucs vus au passage et une interrogation de ma part.

Du détail, mais je changerais le message de 0007 (73f2cafd40) pour

invoicing: add credit cancellation fields (#89810)

ce qui ferait que ce ne serait plus le seul message de commit sans verbe de la série (d’autant plus que “credit” c’est aussi un verbe et donc ça porte un peu à confusion en l’état).

Quelques trucs vus au passage et une interrogation de ma part. Du détail, mais je changerais le message de 0007 (73f2cafd407) pour ``` invoicing: add credit cancellation fields (#89810) ``` ce qui ferait que ce ne serait plus le seul message de commit sans verbe de la série (d’autant plus que “credit” c’est aussi un verbe et donc ça porte un peu à confusion en l’état).
lingo/api/serializers.py Outdated
@ -404,2 +405,3 @@
try:
credit = Credit.objects.get(uuid=value, regie=self.regie)
credit = Credit.objects.get(
Q(pool__isnull=True) | Q(pool__campaign__finalized=True),
pmarillonnet commented 2024-04-24 15:48:29 +02:00
Owner
Copy Link

J’ai du mal à me représenter ce qui signifie cette contrainte de ne chercher que parmi les crédits soit rattachés à aucun pool, soit les crédits rattachés à un pool dont la campagne de paiement est terminée.

J’ai du mal à me représenter ce qui signifie cette contrainte de ne chercher que parmi les crédits soit rattachés à aucun pool, soit les crédits rattachés à un pool dont la campagne de paiement est terminée.
lguerin commented 2024-04-25 17:45:30 +02:00
Author
Owner
Copy Link

On a trois types d'avoirs:

  • ceux qui seront générés lors de campagne (cette PR rend ce cas possible, mais ça sera systématisé avec un prochain ticket, campagne de type post-facturation, avec remboursement de réservations payées par panier mais l'enfant était absent pour un motif valable nécessitant un remboursement)
  • ceux qui sont générés via le panier
  • ceux qui sont générés via API, en clôture d'une facture négative (nouveauté de cette PR)

Pour les cas 2 et 3, les avoirs sont détachés des campagnes, autonomes, et sont consommables dès leur émission.

Pour le cas 1, les avoirs sont générés à une étape "finalisation" de la campagne, comme les factures définitives, mais sont encore annulables, par annulation du pool définitif. Puis le régisseur peut re-finaliser la campagne et re-générer factures et avoirs.
Il ne faut pas que les avoirs soient consommés, ni publiés, alors qu'ils sont dans cet état transitoire: attachés à une campagne non terminée.

On a trois types d'avoirs: - ceux qui seront générés lors de campagne (cette PR rend ce cas possible, mais ça sera systématisé avec un prochain ticket, campagne de type post-facturation, avec remboursement de réservations payées par panier mais l'enfant était absent pour un motif valable nécessitant un remboursement) - ceux qui sont générés via le panier - ceux qui sont générés via API, en clôture d'une facture négative (nouveauté de cette PR) Pour les cas 2 et 3, les avoirs sont détachés des campagnes, autonomes, et sont consommables dès leur émission. Pour le cas 1, les avoirs sont générés à une étape "finalisation" de la campagne, comme les factures définitives, mais sont encore annulables, par annulation du pool définitif. Puis le régisseur peut re-finaliser la campagne et re-générer factures et avoirs. Il ne faut pas que les avoirs soient consommés, ni publiés, alors qu'ils sont dans cet état transitoire: attachés à une campagne non terminée.
pmarillonnet commented 2024-04-29 15:16:00 +02:00
Owner
Copy Link

Hmm ok c’est plus clair pour moi, merci pour l’explication.

Hmm ok c’est plus clair pour moi, merci pour l’explication.
tests/api/test_invoicing.py Outdated
@ -2259,0 +2277,4 @@
assert credit.payer_address == invoice.payer_address
assert credit.total_amount == -invoice.total_amount == 3
assert credit.number == 1
assert credit.formatted_number == 'A%02d-%s-0000001' % (regie.pk, today.strftime('%y-%m'))
pmarillonnet commented 2024-04-24 15:12:06 +02:00
Owner
Copy Link

Hmm, il n’y a pas des cas où la différence de tz-awareness entre datetime et django.utils.timezonefait que la comparaison du jour risque de casser dans les tests ?

Hmm, il n’y a pas des cas où la différence de tz-awareness entre `datetime` et `django.utils.timezone`fait que la comparaison du jour risque de casser dans les tests ?
lguerin commented 2024-04-25 17:47:46 +02:00
Author
Owner
Copy Link

yes, sans doute, mais il y a du datetime.date.today déjà un peu partout dans les tests, je vais faire un ticket pour corriger ça de manière plus globale, ok ?

yes, sans doute, mais il y a du datetime.date.today déjà un peu partout dans les tests, je vais faire un ticket pour corriger ça de manière plus globale, ok ?
pmarillonnet commented 2024-04-29 15:13:57 +02:00
Owner
Copy Link

Ouai peut-être à l’occasion si ça casse des tests (?)

Ouai peut-être à l’occasion si ça casse des tests (?)
pmarillonnet commented 2024-04-29 15:30:06 +02:00
Owner
Copy Link

(Ah, c’est #90048, déjà codé et déjà validé par ailleurs, top !)

(Ah, c’est #90048, déjà codé et déjà validé par ailleurs, top !)
tests/epayment/test_payment.py Outdated
@ -329,2 +350,4 @@
unit_amount=1,
)
other_credit = Credit.objects.create(
date_publication=datetime.date.today() + datetime.timedelta(days=1), # not publicated
pmarillonnet commented 2024-04-24 15:58:55 +02:00
Owner
Copy Link

(Du détail mais si tu as le courage de s/not publicated/not published/ sur les quatre occurrences dans cette PR, ce premier étant une forme archaïque dont on risque de ne pas se rappeler si on recherche ce commentaire dans les tests.)

(Du détail mais si tu as le courage de `s/not publicated/not published/` sur les quatre occurrences dans cette PR, ce premier étant une forme archaïque dont on risque de ne pas se rappeler si on recherche ce commentaire dans les tests.)
lguerin commented 2024-04-25 17:49:34 +02:00
Author
Owner
Copy Link

ok :)

ok :)
lguerin commented 2024-04-25 17:53:26 +02:00
Author
Owner
Copy Link

(corrigé sans fixup)

(corrigé sans fixup)
pmarillonnet commented 2024-04-29 15:13:34 +02:00
Owner
Copy Link

Yes, merci !

Yes, merci !
lguerin force-pushed wip/89810-invoicing-credit from 3b3dcf1c7f to 363c2bade0 2024-04-25 17:53:15 +02:00 Compare
lguerin commented 2024-04-25 17:53:36 +02:00
Author
Owner
Copy Link

Du détail, mais je changerais le message de 0007 (73f2cafd40) pour

Fait

> Du détail, mais je changerais le message de 0007 (73f2cafd40) pour Fait
pmarillonnet commented 2024-04-29 15:13:19 +02:00
Owner
Copy Link

Du détail, mais je changerais le message de 0007 (73f2cafd40) pour

Fait

Vu, merci.

> > Du détail, mais je changerais le message de 0007 (73f2cafd40) pour > > Fait Vu, merci.
pmarillonnet approved these changes 2024-04-29 15:16:13 +02:00
pmarillonnet left a comment
Owner
Copy Link

Ack.

Ack.
lguerin changed target branch from wip/89732-invoicing-delete-pool to main 2024-04-30 08:53:44 +02:00
lguerin force-pushed wip/89810-invoicing-credit from 363c2bade0 to 976a33a5ef 2024-04-30 08:55:20 +02:00 Compare
lguerin merged commit 976a33a5ef into main 2024-04-30 09:05:00 +02:00
lguerin deleted branch wip/89810-invoicing-credit 2024-04-30 09:05:00 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
pmarillonnet
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/lingo#188
No description provided.
Delete Branch "wip/89810-invoicing-credit"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?