#85 Replace random invoice numbers with sequential numbers

fix #4

Number generation is functional and number format is « stable », but still some TODO:

• do not change the number on saving
• figure out/check what to do with draft invoices (they are not supposed to have a number)
• document better
• more tests (is it ok when you have A.date > B.date but A.sequence < B.date because of validation date ? NO)
  • WIP if not, maybe the bill date must be the validation date, not the creation date

Updated the PR

• rebased
• fix some TODOs
• some refacto/renaming on pre-existing code
• use a DRAFT-XX invoice number for unvalidated invoices

Not finished, but getting close :-)

• test admin interface

Ooook, ready for test & review !

That's a big change, from a workflow/accountant point-of-view, having 2 person testing it before merging would be cool :-).

This invoice numbering scheme is less permissive than the previous (date & number cannot be choosen/edited by the accountant).

Super ! Merci pour le taff.

Voici mes quelques remarques divisées en "Features Request", "Bugs", et "Autres" quand je ne savais pas où les ranger :)

Features Request :

• Faire l'incrément des 'Quantité' par 1 plutôt que 0.01
• Pouvoir émettre des factures à des non membres (rajouter un champ Nom + adresse)
• Indiquer le montant restant à régler (sois dans la vue de l'objet, soit dans la vue listant les objets)
• Mettre en évidence 'Enregistrer et poursuivre les modifications' plutôt que 'Enregistrer' pour mieux orienter l'utilisateur sur le process de génération de facturep
• Indiquer la date d'échéance du paiement de la facture dans le PDF

Bugs :

• Pas de vérification sur le montant réglé avant de changer le statut de "À payer" à "Réglée"
• Même non nulle, la TVA n'apparait pas sur la facture

Autres :

• Pas de réinitialisation du draft number ?
• Est ce que l'on pourrait indiquer la référence de l'abonnement en plus de la référence de facture dans les indications de paiement par virement dans le PDF ?

Merci @daimrod. Les sections Feature Request et Bugs sont pertinentes mais pas relatives à cette PR ; peut-être peux-tu ouvrir un/des tickets dédiés à l'amélioration des factures ?

Bien séparer en au moins 2 tickets si une partie des changements à apporter est bloquante pour que l'on démarre l'utilisation de coin pour les factures chez faimaison et l'autre non.

Pour les deux autres :

• Pas de réinitialisation du draft number ?

Peux-tu détailler ?

• Est ce que l'on pourrait indiquer la référence de l'abonnement en plus de la référence de facture dans les indications de paiement par virement dans le PDF ?

La mention de la réf d'abonnement me semble éventuellement ok à mettre dans la facture.

Petite parenthèse, pour le fonctionnement de FAImaison (prix libre…), on a aussi besoin de personaliser le texte qui parle du paiement : nous souhaitons qu'apparaisse dans le libellé de virement la référence d'abonnement et non le n° de facture. Du coup je pense que nous (FAImaison) avons carrément besoin d'une template de facture personalisée pour ce genre de choses (mais que ça n'urge pas forcément).

Nous avons déjà un dossier de templates personalisées (dépôt git adminsys de fma), à faire là-dedans donc à mon avis.

Ok pour l'ouverture de tickets. Pour la mention de la réf d'abonnement, je regarderai effectivement avec ma casquette FAImaison, pas d'un point de vue global.

Concernant le draft number. Lorsqu'une facture est créée mais pas encore validée elle apparaît avec le numéro DRAFT-XX. Le numéro XX ne fait qu'augmenter et je me demandais s'il était pertinent de remettre le compteur à zéro lorsqu'il n'y a pas/plus de facture non validée.

Rien de bloquant pour l'utilisation chez FAImaison à mon avis.

Concernant le draft number. Lorsqu'une facture est créée mais pas encore validée elle apparaît avec le numéro DRAFT-XX. Le numéro XX ne fait qu'augmenter et je me demandais s'il était pertinent de remettre le compteur à zéro lorsqu'il n'y a pas/plus de facture non validée.

Boarf, actuellement, ça prend la primary key de la facture et ça l'utilise pour construire le numéro de facture brouillon. Ça permet de faire simplement quelque-chose d'unique.

La solution que tu propose m'a l'air un peu complexe (est-ce que quand je valide DRAFT-1, DRAFT-2 est renommée en DRAFT-1 ?). Bref, je ne dis pas qu'il n'y a aucun intérêt, juste qu'il est à mon avis maigre, et que du coup je ne passerais perso pas de temps à coder ce genre de comportement :-).