Euh, y a pas la pièce jointe...
Raphaël Bertrand (Résultic) a écrit :
Merci
Voici par contre un petit patch pour corriger ce qui me semble être un
oubli dans la fonction mutualisée, et pour mettre à jour les
descriptifs des masques
*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 :
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
_______________________________________________
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
