Facturation: paramétrage des dates d'une campagne (#75561) #44
No reviewers
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/lingo#44
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/75561-campaign-dates"
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?
0001: du nettoyage, la commande était là début pour tester des trucs avant d'avoir une UI
0002: ajout des nouvelles dates dans les models
0003: suppression de date_issue du form "de base" (== configuration de base de la campagne)
0004: ajout d'un form pour les dates, et affichage des dates dans un onglet dédié
0005: à l'update des dates, mettre à jour les dates sur les factures
0006: invalidation de la campagne si update via le form "de base" (parce que si modification des dates de début/fin, des agendas etc, le dernier pool n'est peut-être plus cohérent)
eed9c4b354
tof0456833fa
f0456833fa
to205b6d78ca
Je commence à relire.
Quelques mini remarques attrapées en relisant, dis-moi ce que tu en penses. De mon coté je vais tester en local en copiant dans mon devinst les données d’initialisation de ton
test_edit_campaign_dates
pour voir à quoi ressemble cet écran d’édition de dates.@ -68,0 +96,4 @@
def clean(self):
cleaned_data = super().clean()
if (
Intuitivement on pourrait se dire qu’il faut le même genre de vérification de la cohérence / prévention anachronique sur date_debit en plus de ces trois autres champs, non ?
peut-être, je ne sais pas, ça n'a pas été précisé lors du dernier eoday, contrairement à ces trois dates là. On pourra toujours ajouter une vérif plus tard ?
Ok, on pourra demander lors du prochain eoday oui.
@ -68,0 +116,4 @@
invoice_qs = Invoice.objects.filter(pool__campaign=self.instance)
for qs in [draft_invoice_qs, invoice_qs]:
qs.update(
Pareil ici, pourquoi on exclut date_debit de la mise à jour des queryset ?
c'est fait juste en dessous, uniquement pour les factures en prélèvement auto (pas de date de prélèvement pour une facture qui n'est pas en prélèvement auto)
Oulà oui pardon, fatigue :)
@ -333,1 +337,4 @@
date_publication = models.DateField(_('Publication date'))
date_payment_deadline = models.DateField(_('Payment deadline'))
date_issue = models.DateField(_('Issue date'))
date_debit = models.DateField(_('Debit date'), null=True)
Pas compris dans le code ce qui justifie que seul ce champ de date de débit, et pour le modèle AbstractInvoice seulement, est nullable :(
parce que pas de date de prélèvement si direct_debit = False :)
Ok mais je ne comprends pas fonctionnellement ce que ça veut dire que ce champ est nullable alors que le champ similaire
date_debit
sur une campagne ne l’est pas, et est endefault=now
à la place.Le default sur Campaign c'était surtout pour gérer la migration; dans le formulaire de création d'une campagne, on initialise ces dates à date_end (la date de fin de la campagne qui vient d'être saisie).
date_debit n'est pas nullable sur une campagne car il nous faut définir une valeur à reporter sur les factures en prélèvement auto.
Pour une facture donnée, cette date de débit est vraiment nulle si payer_direct_debit est False: pas de prélèvement auto, donc pas de date de prélèvement.
Je m'étais posée la question de ne pas reporter ces dates sur les factures et plutôt aller les chercher sur la campagne liée. Mais je dois ajouter plus tard de quoi créer des factures hors campagne (cas du parent qui vient au guichet pour réserver le séjour au ski, le paie toute de suite, et repart avec une facture acquittée), donc dans le doute j'ai laissé le report des dates de campagne à facture. En me disant que du code, ça peut se refactorer.
Ok, ça fait sens, je comprends mieux, merci pour l’explication.
@ -0,0 +13,4 @@
{% block breadcrumb %}
{{ block.super }}
<a href="{% url 'lingo-manager-invoicing-campaign-detail' regie.pk object.pk %}">{{ object }}</a>
Niveau UI, sur cette page où on édite des dates, avoir un lien vers la campagne juste présenté avec
{{ object }}
ça va fairelabel (date de début - date de fin)
. J’ai peur que ça fasse trop de dates et qu’on perde des gens en cours de route. Peut-être qu’on pourrait simplement mettre{{ object.label }}
?c'est dans une popup, donc on ne voit pas le breadcrumb (sauf si validation du form+errors), mais tu as raison, je vais modifier ça
D’ac, merci.
Étrange, de mon coté, dans mon shell django je dois rajouter une
date_issue
et unedate_payment_deadline
explicites à l’initialisation de l’objet Campaign de ce test (sans quoi ça me claque une erreur devaleur NULL viole la contrainte NOT NULL de la colonne […]
). Pourtant dans tox le test passe nickel, pas compris.Sinon pour l’écran en lui même c’est bon pour moi, j’ai pu tester, c’est top.
C’est bon pour moi. Merci pour tes explications sur les trucs qui restaient flous pour moi à la relecture.