dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] Proposition patch pour rendre saphir plus robuste +


From: Raphaël Bertrand (Résultic)
Subject: Re: [Dolibarr-dev] Proposition patch pour rendre saphir plus robuste + idée co mpteur à masque client
Date: Fri, 13 Jun 2008 15:28:56 +0200
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

Une petite erreur est présente dans ce patch, dans le seul cas que je n'avais pas testé (comme quoi...) Il s'est propagé dans l'autre patch pour saphir (propales avec référence client). Cependant, étant en train de finir la nouvelle version de saphir (et arctic), cela ne devrait pas poser de soucis, et il suffit juste d'attendre que je vous la soumette (sous peu de temps).

$maskrefclient_maskLike = str_replace(sanitize_string('{mm}'),'_',$maskrefclient_maskLike);

devrait être :

$maskrefclient_maskLike = str_replace(sanitize_string('{mm}'),'__',$maskrefclient_maskLike);


*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 :
Merci pour ces précisions,
je comprends donc que l'on ne puisse pas utiliser les regexp.
Une autre solution serait de faire des tests avec des substring, comme actuellement, mais le plus simple et moins lourd, bien que moins robuste, est d'utiliser un like avec le masque dont tous les chiffres et caractères spéciaux ont été transformé en wildcard caracter (_).

C'est ce qui est proposé dans ce patch
Si on voudrait être vraiment plus robuste, il faudrait ajouter en plus un test avec substring s'assurant que chaque caractère du compteur est bien un chiffre, mais bon...

*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 :
Donc si on résume, ta solution offre en effet un module de numérotation moins sensibles aux référence hors normes et le module et capable de retrouver le numéro suivant dans plus de cas tordus. Ces derniers pouvant se manifester qu'en cas de changement de num en cours de route. C'est d'ailleurs une solution qu'avait proposé regis dans ces premieres version des modules de num générique. Malheureusement, ceci peut marcher en faisant appel à un critère select where basé sur la commande REGEXP. Hors cette commande n'est pas un standard (exemple oracle utilise la syntaxe WHERE REGEXP_LIKE(champ, 'regex')).

Une regle à respecter est que le respect du standard et le fonctionnement multiplateforme avec une portabilité de 100% est prioritaire sur du code qui permet de palier un pb qui n'est pas sensé arrivé. C'est grace à cela que Dolibarr pourra tourner sur toutes les bases de données du marché. Le driver d'abstraction de la base a été fait dans ce but et qd un driver PDO aura été fait, dolibarr pourra tourner sur toute base, à condition justement de ne pas mettre de code SQL spécifique. Je préfère donc qu'on gère cela grace au gardefou qui évite de se trouver dans cette situation (celle où un module de num ne marche pas car on a changé en cours de route et que le précédent n'était pas compatible). Ce gardefou, c'est la methode canBeActivated qui se trouve dans chaque module de numerotation et qui dit si on peut activer un module ou pas en regardant si y a pas de enregistrements qui generait (ex: terre). Toutefois cette méthode n'est pas encore exploitée.

J'écarte donc le patch. Toutefois un module saphirbis peut tres bien etre fourni en module complémentaire qui serait téléchargeable sur le site: http://www.dolibarr.org/component/option,com_docman/task,cat_view/gid,65/Itemid,36/lang,en/


Raphaël Bertrand (Résultic) a écrit :
Suite au problème rencontré par Lionel (et par d'autres en cas de changement de système de numérotation en cours de route ou de bidouillage), je me suis penché sur le code de saphir pour chercher pourquoi il pouvait ainsi être trompé par la présence de commandes ne respectant pas son masque. Là je me suis aperçu que le module de numérotation se contentait de repérer les débuts et fin logique du compteur pour lui, et de faire ses comparaisons (de même pour le test de date). Or, dans le cas d'une modification manuelle ou d'un changement de standard, des lettres peuvent se trouver en lieu et place des chiffres attendus, ce qui cause alors une ré initialisation du compteur, et du même coup une erreur lors de l'insertion car le numéro existe déjà.

Pour contrer cela, je propose donc dans le patch ci-présent de remplacer le test d'absence de parenthèse (pour les cas des commandes provisoires), par un test d'expression régulière vérifiant que les lettres préfixes et suffixes correspondent, et que les codes spéciaux sont bien remplacés par des chiffres, avant de considérer un enregistrement comme étant créé par le masque et donc avant d'incrémenter le compteur.

Si cela vous intéresse, je peux essayer de le porter sur les autres modules de numérotation.

D'autre part, nous trouverions intéressant de pouvoir effectuer une numérotation tenant compte du code client, afin de disposer une valeur de compteur propre à chaque client, améliorant ainsi le suivi par client. Qu'en pensez vous ?

Post de Lionel:
http://www.dolibarr.fr/component/option,com_fireboard/Itemid,32/func,view/catid,5/id,8910/lang,fr/#8910
Article de la FAQ:
http://www.dolibarr.com/wikidev/index.php/FAQ_D%C3%A9veloppeur#Changer_mon_syst.C3.A8me_de_num.C3.A9rotation_des_factures_en_cours_de_route


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

_______________________________________________
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




reply via email to

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