|
From: | Denis Martin |
Subject: | Re: [Dolibarr-dev] Règles de prix |
Date: | Mon, 3 Jan 2011 18:52:42 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 |
En effet. J'avais déjà réfléchi là dessus et je me dis qu'il faudrait
aussi ajouter deux paramètres : "prix" et "price_base_type" en plus de
taux_remise. On pourrait choisir entre un taux de remise en pourcentage
et un prix final. Suivant celui que l'on choisit, l'autre est calculé
automatiquement. Plus facile si on on veut passer d'un prix de base de
3,00 € à un prix de 2,70 € sans vouloir calculer de pourcentage, sans
s'embêter avec des arrondis, toussa. J'ai déjà fait un module "Remise produit" qui permet de d'associer un produit à un client (j'ai une toute petite base de donnée), je peux le mettre a disposition. Bonne idée les catégories pour un plus grand nombre de références. Denis Le 03/01/2011 18:28, Régis Houssin a écrit : non mais ce serait bien :-) Le 03/01/11 18:18, Cyrille de Lambert a écrit :Un partenaire est tombé sur cette problématique et aimerait standardiser ceci dans Dolibarr. Ce système est présent dans LMB Qui aurait déjà travaillé sur cette idée ? Cyrille *Dolibarr – Règles de prix* *Objet *: pouvoir gérer des règles de prix sur des catégories de produits, pour des catégories de clients. *Description générale* *:* en commerce de détail, les prix pratiqués sont fonction : * De la quantité achetée (tarifs dégressifs en fonction de la quantité achetée) * Du statut du client : un même produit aura un prix différent s’il est vendu à un particulier, un professionnel, une entreprise ou une collectivité * De la relation commerciale établie entre le vendeur et son client : un gros client peut par exemple avoir des remises permanentes sur certaines catégories de produits. A l’heure actuelle, Dolibarr gère des prix multiples sur les produits, et chaque client se voit associer une ligne de prix. Ceci est insuffisant dès lors que le nombre de références est trop conséquent, et il importe dans ce cas de disposer de traitements généraux. Ex : le client C appartient à la catégorie de clients CC. Il achète un produit P appartenant à la catégorie de produits CP. Il doit donc payer un prix PX qui sera fonction de CC et CP. *Aspects fonctionnels :* une table de jointure qui relie une catégorie de clients et une catégorie de produits, comportant un attribut supplémentaire « taux de remise ». Ci-dessous un diagramme simplifié modélisant ce principe : Afin de pouvoir établir une gestion de prix individualisée, il est nécessaire de reproduire ce principe en reliant un produit particulier à un client particulier. Ainsi, nous avons donc une seconde jointure de type règle de prix, à vocation plus spécifique. Cette double règle a pour avantage de gérer autant que faire se peut la politique de prix de façon générale, afin de ne pas tout gérer de façon spécifique. En effet, n’utiliser que cette seconde option peut conduire en théorie au cas où chaque instance « client » est liée à toutes les instances « produit » par une règle de prix individuelle. Le nombre d’enregistrement dans la table de jointure sera alors : nbProduits x nbClients. Pour 2000 clients et 3000 références (chiffres plutôt bas pour une boutique de vente au détail), nous avons donc 6 000 000 de lignes dans la table règles de prix. Les double-règles permettent de traiter un maximum de cas de façon générique. Ainsi, nous pouvons donc classer nos 2000 clients dans 20 catégories, et nos 3000 références dans 10 catégories produits (au sens famille tarifaire, plutôt qu’à la catégorie « métier » des produits), notre table des règles de prix générales comportera 200 lignes et les cas non-couverts par ces règles feront l’objet d’une définition spécifique. Nous obtenons donc un volume de données beaucoup plus facilement gérable en pratique. *Sur le plan technique : * Il faut mettre en place les structures de données et les objets métier (« beans » ou « Value Objects ») ainsi que leurs Savers et Validators (Delegation). Il faut mettre en place les IHM adaptées. Il faut adapter la génération de documents pour que les remises figurent sur les devis, bons de commandes et factures. _______________________________________________ Dolibarr-dev mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/dolibarr-devCordialement,_______________________________________________ Dolibarr-dev mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/dolibarr-dev |
Capture-Dolibarr - ProductDiscount - Mozilla Firefox.png
Description: PNG image
[Prev in Thread] | Current Thread | [Next in Thread] |