Laurent Destailleur (Eldy) a écrit :
Le 22/04/2010 22:34, Cyrille de Lambert a écrit :
Je ne comprend pas la différence entre une version complexe et une
version simple.
La version simple est celle qui serait accessible sans nécessiter de
comprendre un modèle physique ou des notions abstraites comme la
virtualité de produit.
On peu appeler ça un produit de base afin que tous le monde comprenne
facilement.
Mais ce n'est pas une notion complexe.
La version complexe offre plus de fonctionnalité mais et aussi plus
complexe à comprendre pour un utilisateur lambda et surtout plus longue
à développer, avec mise en oeuvre des métamodéles, des notions d'imports
qui requiert des jointures diverses, etc..
Justement, je n'arrive pas à comprendre pourquoi se sera plus lourd à
développer.
Vu qu'on change moins le code existante et qu'on en ajoute un peu pour
gérer la génération de déclinaisons, les listes de produit (pour
modifier légèrement le filtre) ainsi que le fiche produit (pour
visualiser les déclinaisons disponibles). À moins qu'on ne gère pas le
stock avec les déclinaisons simples. Ce qui serait dommage pour les
personnes qui gèrent des magasins car ne pas avoir les stocks d'un
déclinaisons rend impossible une bonne gestion..
Dans le cas contraire, cette version simple peu s'avérer un véritable
usine à gaz comme je l'ai vu dans d'autres applications (dont une
application e-Commerce dernièrement). Ça rend les exports et imports
beaucoup plus complexes à comprendre et à réaliser. De plus le code est
multiplié car il faut ajouter une déclinaison (modification de code) à
la place d'un produit décliné (pas de modification de code) dans le
panier. Ça complexifie également la gestion des codes barre (qu'il faut
prévoir dans la sous table simple), la recherche produits (il faut
chercher la référence dans les sous tables), etc....
En effet, un déclinaison est un produit entier qui doit être vue comme
un produit (achetable, stockable, etc...).
Dans un magasin, c'est bien la déclinaison qu'on achète (la chemise
coton à poids coton), pas la référence de base (la chemise coton).
Seul le produit virtuel (la chemise de base) ne peut-être achetée.
Il faut donc que les déclinaisons soient gérées par comme un produit
standard Dolibarr. Une simple sous table ne donnera pas de vrais
produits. Donc il faut développer du code spécifique pour gérer le
stock, mettre dans le panier, etc....
C'est la version plus lourde, celle que développe Régis ou du moins est
envisagé de développé et qui serait ultra paramétrable.
Ce que nous avons vu avec Régis est le plus simple à gérer à long
terme de part l'expérience que j'ai de ce type de produits sur
différents systèmes.
Le plus simple en apparence n'est pas forcement le plus simple en réalité.
Si on créé un produit virtuel à décliner, il faut certes revoir
l'affichage des liste produits et légèrement la page produit et
empêcher l'achat d'un produit virtuel et c'est tous .
Pas besoin de revoir la commande, le devis, la facture, etc dans son
ensemble. Un simple contrôle pour empêcher d'un insérer un article
virtuel suffit.
Il faut qu'on en reparle
Cyrille
Laurent Destailleur a écrit :
C'est la version "complexe" des déclinaisons qui sera en module externe
(celle envisagée par regis, utilisant plusieurs tables)
Pour la version simple (c'est a dire basé sur une simple sous table de
déclianaison), cela peut etre fait en standard.
Pour les attributs dynamique, il y a les tables pretes (tables
llx_extra...), reste à developper.
Le 21/04/2010 23:38, Cyrille de Lambert a écrit :
Bonjour,
Je reviens sur les discussions que nous avons eu sur les déclinaisons.
Il a été question de rendre ceci modulaire afin de ne pas surcharger
le coeur de Dolibarr.
Ceci pose des difficultés :
* Beaucoup de métiers travaillent par défaut avec des déclinaisons
(vêtements, meubles, etc...). Je trouve donc dommage d'avoir ça
en module externe !!!!
* Ceci a des conséquences pour la synchronisation avec les outils
de eCommerce qui utilisent les déclinaisons. Avoir les
déclinaisons dans le cœur de Dolibarr permet d'avoir un seul
type de synchronisation (si déclinaison d'un coté, alors
déclinaison créé de l'autre).
Un générateur de déclinaisons à le Prestashop sera bienvenu et très
pratique pour les commerçants.
Une autre fonctionnalité qu'il faudra mettre en place sera les
attributs dynamique pour ajouter des éléments sans avoir à développer :
* Sur les produits
* Sur les tiers et contacts
Ces attributs pouvant être utilisés pour les filtres afin de faciliter
les actions marketing.
Cyrille
--
AUGURIA
Cyrille de Lambert
address@hidden
9, rue Alfred Kastler
BP 50752
44307 NANTES CEDEX 3 Tél : +33 (0) 2 51 13 50 12
Mobile :+33 (0) 6 29 41 81 22
Fax : +33 (0) 2 51 13 52 88
http://www.auguria.net
_______________________________________________
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
|