dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] patch compteur à masque client et numéro chrono


From: Eldy
Subject: Re: [Dolibarr-dev] patch compteur à masque client et numéro chrono
Date: Fri, 20 Jun 2008 23:13:47 +0200
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

J'ai intégré le patch.

Par contre j'ai simplifié un peu le code pour le même résultat, corrigé un petit bug et remplacé le carac _ par # quand on complète le code client incomplet et j'ai mutualisé le code qui recherche le numéro suivant des modules génériques par une fonction dans le fichier functions2.lib.php.




Raphaël Bertrand (Résultic) a écrit :
Avec celui là ce sera mieux...

*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Raphaël Bertrand (Résultic) a écrit :
Bonjour,

Voici ci-joint le patch demandé.

On peut maintenant utiliser dans tous les compteurs saphir & co les filtres {cccc} et {cccc000} qui n'influencent pas le compteur général, excepté par le fait qu'ils changent la structure du filtre.

Afin d'ignorer les enregistrements pouvant entrer en conflit,
Ces compteurs vérifient maintenant que les enregistrement correspondent au filtre avec un test en Like complet, qui teste la structure du filtre avec sa taille, en ignorant toutefois la correspondance de caractères pour tout ce qui va être remplacé par un filtre (utilisation d'un caractère joker _), ainsi que les caractères spéciaux.


*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Eldy a écrit :
Raphaël Bertrand (Résultic) a écrit :
Merci pour la réponse, je la lirais à nouveau et ferais le patch correspondant à priori pour demain.

Concernant la gestion des codes clients, ok pour un {cccc} qui est remplacé par exactement 4 caractères (les premiers du code client unique complété par *).

Par contre est que c'est ok aussi pour un {cccc0000} fonctionnant sur le même principe mais incluant une numérotation spécifique au client?
Ok, je commence à comprendre. Tu peux effectivement mettre cela en place, par contre tu devras donc faire 2 requetes. - Une pour retrouve le max du numéro {0000} avec les substring pour ne récupérer que le chiffre en position juste. - Une autre requete (uniquement si on a un {cccc0000}) pour retrouver la aussi le max propre au client, mais la encore il faut réaliser la recherche par un select avec substring, chose qui devient possible car tout étant de longueur fixe, on sait combien de carac avant et apres enlevé dans le substring pour retrouver le max.



*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Eldy a écrit :
Peux-tu en replacement de tous les patch fournis précédemment fournir un fichier patch qui intégrerait:

* Pour modifier le test en 'not like' par un test en like qui teste certains caractères du masque pour le rendre moins sensible à la présence de données ne suivant pas ce masque (limite les cas où l'on est obligé d'altérer toute l'ancienne numérotation pour faire fonctionner la nouvelle).
OK

* - Pour faire fonctionner le module de comptage d'intervention arctic, qui n'était actuellement plus fonctionnel, n'allant pas chercher ses numéros dans la bonne table.
OK


* Par contre pour le support du code client, il faut simplifier ton approche.

En effet, tous critères personnalisés de type {xxx} doit avoir une longueur fixe. Ceci évite ainsi des règles complexe comme "ça marche mais il faut pas qu'il y ait ceci après ou avant". Ceci vaut donc pour le code client {cccc}. Il faut donc y placer des * par exemple si le code client est trop court pour avoir une longeur fixe de compteur.. Ceci permet d'avoir la possibilité de mettre {cccc} ou non sans se soucier de quoi que ce soit.
Et cette evol doit aussi être présente dans le module facture.
En effet, ce qui est important dans le module facture c'est que le {00000} qui indique la numérotation soit présente, unique et continu. Rien n'empeche de mettre un prefix {cccc} en plus avant ou après, du moment qu'on a notre compteur continu. Et vu que pour rechercher le numéro suivant on fait une recherche sur substring avec tous les caractères qui ne sont pas le compteur mis à _ et qu'on a QUE des tags de longeurs fixe, le {cccc} peut etre placé où on veut sans souci, au même titre que tous les autres tags. Je pense qu'il faut ne pas essayer de faire des modules de num trop complexes juste dans le but de pouvoir gérer des changement de normes de numérotation car il y aura tjs un cas non géré de toute façon qui ne passera pas.

De plus il n'est pas nécessaire de prévoir autre chose que {cccc} ( donc pas de {cccc+x} ). Si le code client n'est pas défini, ou pas assez de caractères, on y met * pour compléter devant.

Il ne faut pas perdre de vue que Dolibarr doit ensuite être utilisé et compris par des gens qui n'ont pas notre tournure d'esprit farfelue d'informaticien et qu'il faut ensuite répondre aux questions des utilisateurs qui ne comprennent pas comment définir leur module donc gare à ne pas faire trop complexe, car les explication textes par mail ou forum seront alors difficiles. Et un utilisateur qui utilise un logiciel opensource dont on ne peut etre débloqué par une simple explication mail sera un utilisateur qui se dira que ce n'est pas un BON logiciel opensource. Un simple {cccc}, si on décide que le champ substitué sera de longeur fixe égal au nb de c, s'intègre très facilement dans le code des modules de numérotation actuel et cela sans aucune contrainte (comme on le fait pour l'année qui vaut {yyyy}). Et cela reste facile à comprendre. Je ne pense pas qu'on ait besoin de plus.

Seul le numéro de compteur {0000} obligatoire doit offrir des variantes d'offset ou de remise à zero, les autres tags doivent etre de simple "remplacé par".



Raphaël Bertrand (Résultic) a écrit :
Voici le patch qui met à jour les modules saphir, mercure et arctic (propales, commandes, fichinter, factures)

- Pour modifier le test en 'not like' par un test en like qui teste certains caractères du masque pour le rendre moins sensible à la présence de données ne suivant pas ce masque (limite les cas où l'on est obligé d'altérer toute l'ancienne numérotation pour faire fonctionner la nouvelle).

- Pour faire fonctionner le module de comptage d'intervention arctic, qui n'était actuellement plus fonctionnel, n'allant pas chercher ses numéros dans la bonne table.

- Pour ajouter le support du filtre {cccc} qui transforme le compteur général en compteur propre au client, en incluant dans le masque le code client unique, dans la limite des caractères définissant le code client. (NON intégré dans mercure pour respecter la législation qui impose la présence d'un compteur global)

- Pour ajouter le support du filtre {-cccc0000} / {-ccccSEP000+10} décrit dans les mails précédents, et qui permet d'ajouter un suffixe muni d'un compteur propre au client, et comportant les n (n=nombre de c) premières lettres du code client unique (dans la limite de ce qui est défini), et pouvant comporter un préfixe d'une lettre différente de c, ainsi qu'un séparateur de longueur quelconque mais ne comportant ni de c ni de 0. Le compteur client peut être initialisé à une valeur d'offset, et est obligatoirement réinitialisé en même temps que le compteur global. La possibilité d'intégrer ces caractères au sein du filtre s'explique par le fait qu'elle permet d'ajouter ce suffixe sans réinitialiser le compteur préexistant.

*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Raphaël Bertrand (Résultic) a écrit :
Voici maintenant une version modifiée de mon patch pour la numérotation de propales saphir qui permet l'ajout d'un filtre évolué suivant l'expression régulière '\{([^c])?(c+)([^0c]*)(0+)(\+[0-9]+)?\}' Soit 1 caractère de préfixe optionnel (différent de c majuscule ou minuscule), suivi d'un nombre quelconque c (autant de c que le nombre maximum de caractères à récupérer du code client), suivi d'une chaine optionnelle servant de séparateur (ne contenant ni de 0 ni de c majuscule ou minuscule), suivi d'un nombre de zéro correspondant au nombre de chiffres du compteur propre au client, et éventuellement suivi d'un marqueur d'offset.

Le résultat est un suffixe n'interférant pas sur la numérotation standard.

Exemple: pour le masque address@hidden
ayant déjà 7 propositions suivant le masque address@hidden, et 0 suivant ce nouveau masque, le module propose PR0800008-0057 si pas de référence client (l'exemple de numérotation), et PR0800008-CLIE0057
pour un client ayant comme code client CLIENT.
Si on valide cette proposition et l'on en crée aussitôt une autre pour le même client, on obtient PR0800009-CLIE0058

Avec le masque address@hidden
on aurait eu PR0800008-CLIE-0001 puis PR0800009-CLIE-0002
et avec address@hidden, PR0800008CLIE-NUM-0001 puis PR0800008CLIE-NUM-0002


*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Raphaël Bertrand (Résultic) a écrit :
Bonjour,

Sauf erreur de ma part, c'est justement de ce code client unique dont je me sers. La seule chose qu'il peut se passer, c'est que si l'on choisit moins de lettres dans le masque que le nombre de lettre que font les codes clients, il peut y avoir des codes clients distincts qui se retrouvent avec le même masque. Mais rien n'empêche de mettre suffisamment de c pour que cela ne se produise pas (si il y a plus de c que de lettres pour les codes clients, on se contente de retourner l'intégralité du code client).

La seule restriction qui demeure, c'est qu'il ne faut pas que les codes clients se terminent par un 0 si ils sont utilisés juste avant le compteur (sans séparation), car alors ils rentrent en conflit avec lui comme c'est le cas actuellement si l'on met un 0 dans son masque juste avant le compteur.

Pour l'idée du compteur propre au client avec mention du code client et utilisé en suffixe, venant se surajouter au compteur global, je vais voir comment cela peut se faire.

*Raphaël Bertrand*
Résultic - Management & Informatique
Siège : 11 rue Tronchet - 69006 LYON
Bureaux : 11 pl Maréchal Lyautey - 69006 LYON
Fixe. 08 74 77 00 70
Fax. 08 25 24 85 02
E-Mail : address@hidden

Rodolphe Quiedeville a écrit :
Raphaël Bertrand (Résultic) a écrit :
En me servant du patch permettant de rendre saphir plus robuste,
j'ai rajouté la prise en compte du code client via le masque {cccc}


Bonjour,

Il existe déjà un code client unique pourquoi ne pas l'utiliser ?

Après pour les facture une sequence :

08-00001-CD54-0001
08-00002-CD54-0002
08-00003-EB54-0001
08-00004-CD54-0003

Avec l'année sur 2 digit, compteur total sur 5 digits, code client, compteur client sera valide auprès des institutions. Il contient bien une séquence unique qui servira de base comptable. Le changement lors de changement d'année est régulièrement accepté ou à la fin de l'exercice.

En fait c'est juste une séquence unique et continue avec un suffix.

A++



_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev


------------------------------------------------------------------------

_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------

_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev



------------------------------------------------------------------------

_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------

_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Author) : http://awstats.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net
Dolibarr (Contributor) : http://www.dolibarr.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]