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 : [EMAIL PROTECTED]
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 : [EMAIL PROTECTED]
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 : [EMAIL PROTECTED]
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 : [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
ayant déjà 7 propositions suivant le masque [EMAIL PROTECTED], 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 [EMAIL PROTECTED]
on aurait eu PR0800008-CLIE-0001 puis PR0800009-CLIE-0002
et avec [EMAIL PROTECTED], 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 : [EMAIL PROTECTED]
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 : [EMAIL PROTECTED]
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
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------------------------------------------------
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Laurent Destailleur.
---------------------------------------------------------------
EMail: [EMAIL PROTECTED]
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
_______________________________________________
Dolibarr-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
