Comme beaucoup ici, je pense avoir compris à tort que le pattern {cccc000} permettait cela, mais finalement non, c’est juste une concaténation du code client {cccc} et d’un compteur de base {000}.
Parallèlement je sais que la numérotation que je donne en exemple provient d’une instance dolibarr (French data Network et/ou aquilenet).
A part un développement perso, il n’y a pas de solution de contournement possible avec un truc qui m’aurait échappé?
Merci d’avances pour vos retours, rien de critique ou bloquant, mais je trouvais ce pattern intéressant. L’unicité est présente et je ne vois, à priori, pas de risque de trous dans la numérotation.
Le numéro de la facture
Il s’agit d’un numéro unique pour chaque facture, qui est basé sur une séquence chronologique et continue, et doit apparaître sans « trou », une facture ne pouvant être supprimée. La numérotation peut éventuellement se faire par séries distinctes (par exemple avec un préfixe par année), si les conditions d’exercice le justifient.
ainsi la numérotation doit forcément avoir un compteur chronologique et continue sans trou … il faudrait donc que votre exemple soit plus complet pour savoir si vous êtes bien dans ce cas ou pas vu que vous n’avez que le tiers « 2201 » … je vous suggérerait plutôt de faire {yyyy}-{mm}-{cccc}-{0000} ainsi le dernier numéro serait le compteur séquentiel unique depuis le début et vous auriez en préfixe l’année le mois et le code client …
Déjà je ne pensais pas que ce soit possible d’avoir ce genre de pattern mais finalement si, c’est bon, et c’est la balise {tttt} qui permet ce type de fonctionnement, qui par conséquent est liée au dictionnaire « type de tiers ».
Je ne vois à priori pas de risques de « trous » car il n’y a pas de remise à zéro mensuelle et cela rejoint plutôt l’idée de séries distinctes comme indiqué dans le passage cité.
En fait au lieu d’une seule série continue de type {yyy}{mm}{0000} regroupant sans distinction tous les tiers, il y aurait donc « x » séries uniques, une par type de tiers avec un pattern qui pourrait donc être {tttt}{yyy}{mm}{0000}.
Très subjectivement je pense que c’est bon, mais c’est aussi pour ça que je poste sur le forum, pour nuancer un peu cette subjectivité facile.
Ce qui est surtout troublant dans la doc, c’est encore une fois le type de formulation :
{cccc000} : code client sur n caractères suivi d’un compteur propre au client. Ce compteur propre au client est remis à zéro en même temps que le compteur général.
En lisant « propre au client », je comprends « une série unique par client » et pas seulement la concaténation du code client avec un compteur global.
{tttt} code du type de tiers sur n caractères (Voir menu Accueil > Configuration > Dictionnaires > Types de tiers). Si vous ajoutez cet élément au masque de numérotation, le compteur sera différent pour chaque type de tiers.
hmmmm je ne pense pas que ça soit acceptable mais encore une fois je me répète il faudrait nous donner un exemple plus complet de votre numérotation
La numérotation peut éventuellement se faire par séries distinctes (par exemple avec un préfixe par année), si les conditions d’exercice le justifient
le éventuellement est à prendre dans le sens « exceptionnellement » or dans votre cas le éventuellement est « systématique »
ce qui me fait dire que ce que je comprends de votre numérotation n’est pas compatible avec l’obligation légale est ça (d’ou ma demande de détail de votre exemple):
client A code AAA
client B code BBB
2025-01-AAA-001 : 1ere facture du client A le 10 janvier 2025
2025-01-AAA-002 : seconde facture du client A le 20 janvier 2025
2025-02-AAA-003 : 1ere facture du client A en février le 10 février 2025, le compteur n’est pas remis à zéro c’est ok
passons au client B, quel serait le numéro de sa 1ere facture du 18 janvier 2025 ?
si votre réponse est 2025-01-BBB-001 je pense vraiment que votre numérotation n’est pas valide et vous suggère de demande une réponse écrite de votre expert comptable ou à minima une demande claire à votre contact sur le site impots.gouv en détaillant vraiment de manière précise votre numérotation avec un exemple sur 3 mois avec 3 clients et une dizaine de numéro de factures
si votre réponse est « pas possible compte tenu qu’une facture pour le client A est déjà faite en février » ça me va, on reprendrait donc en restant dans la chronologie:
2025-01-AAA-001 : 1ere facture du client A le 10 janvier 2025
2025-01-BBB-002 : 1ere facture du client B le 18 janvier 2025
2025-01-AAA-003 : seconde facture du client A le 20 janvier 2025
2025-02-AAA-004 : 1ere facture du client A en février le 10 février 2025
le compteur unique global de numéro de facture est congru, c’est ça que l’administration fiscale attends, enfin c’est ce que j’ai compris de toute cette histoire
Il n’y a actuellement que le code de type de tiers (encore natif dans mon install, soit PRIV, ADMI… pour private et administration avec 4 caractères) qui différencie une facture de l’autre.
J’ai bien une suite logique par tiers comme je l’attendais mais effectivement pas adapté aux factures. J’ai quand même bien avancé dans l’idée de départ qui postulait que ce n’était pas possible en natif. Ça l’est, et l’idée est encore exploitable pour d’autres objets moins critiques de dolibarr (propales, interventions…)
Je reviens sur cette question qui a été abordée ailleurs aussi précédemment.
La solution validée par @KPBLS est un peu trop radicale je trouve car elle prend pour acquis l’idée que l’on ne peut pas utiliser cette sérialisation en France…
Quel bonheur au contraire il me semble, d’avoir cette fonction en natif ! J’ai proposé comme intégrateur, la solution avec deux facturiers comme ici, où les séries représentent éventuellement des usages différenciés de factures proforma (« dropshipping » hors compta) / factures standard (commissions). Il n’y a rien à redire à cet usage parfaitement légal mais j’en vois potentiellement d’autres …comme l’usage d’un Dolibarr pour deux filiales de la même société par exemple. A preuve du contraire? Amicalement. Christo
