dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] Règles de prix


From: Cyrille de Lambert
Subject: Re: [Dolibarr-dev] Règles de prix
Date: Tue, 04 Jan 2011 08:50:15 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; fr-FR; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

Ici, on est plutôt sur une demande type gros distributeur qui doit gérer des prix au kilomètre.
Pour les catégories, le besoin est de définir un % qui se calcul par rapport au tarif officiel de vente de chaque produit.
En effet, dans beaucoup de cas, les marges des distributeurs ne sont pas le mêmes suivant les type de produit, donc les remises ne peuvent pas être de même %. Le système de remise permanente n'est pas adapté pour gérer ce type de cas.
De même, il est irréaliste d'aller définir un tarif à la main sur des centaines de produits. Les mises à jours étant trop fastidieuses.
Comme je le disais, ce partenaire (qui devrait développer ceci si personne ne l'a fais), cherche plutôt à mettre en place un système à lundi matin business qu'il a abandonné pour intégrer Dolibarr.
En effet, LMB est prévu à la base pour gérer ce type de commerce de détail. En dehors des règles de prix, il préfère largement Dolibarr.

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

Le 04/01/2011 00:54, Laurent Destailleur (eldy) a écrit :
Il existe en effet déjà la possibilité de définir, pour chaque produit,
des prix différents selon la catégorie client (pour la notion de prix
client).
On peut aussi définir des prix différents selon la quantité pour les
prix fournisseurs.
Par contre, pas de prix par catégorie pour les prix fournisseur (non
requis car les fournisseurs n'ont pas la meme politique de
catégorisation) et pas de prix par quantité pour les prix client (car
ceci se gère par remise).
Les remises permanantes sont également disponibles pour les clients.

Donc finalement ce qui manque c'est:

* Pouvoir mettre un nom sur les catégories de prix (actuellement
appellées 1, 2, 3...)
* La notion de famille de produit pour définir les prix par famille et
non par produit. Mais a-t-on vraiment ce cas de produits qui ont tous
les meme prix ?


On 03/01/2011 18:18, Cyrille de Lambert wrote:
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-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]