Envoyez vos messages pour la liste Dolibarr-dev à
address@hidden
Pour vous (dés)abonner par le web, consultez
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
ou, par email, envoyez un message avec 'help' dans le corps ou dans le
sujet à
address@hidden
Vous pouvez contacter l'administrateur de la liste à l'adresse
address@hidden
Si vous répondez, n'oubliez pas de changer l'objet du message afin
qu'il soit plus spécifique que "Re: Contenu du digest de
Dolibarr-dev..."
Thèmes du jour :
1. Devis (Cyrille de Lambert)
2. Règles de prix (Cyrille de Lambert)
3. Re: Règles de prix (Régis Houssin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 03 Jan 2011 18:11:42 +0100
From: Cyrille de Lambert <address@hidden>
Subject: [Dolibarr-dev] Devis
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Bonjour,
Quelqu'un aurait-il déjà développé un module permettant de créer de
grouper des ligne et d'indiquer le sous total de chaque groupe ?
Cyrille
------------------------------
Message: 2
Date: Mon, 03 Jan 2011 18:18:08 +0100
From: Cyrille de Lambert <address@hidden>
Subject: [Dolibarr-dev] Règles de prix
To: Discussions sur le developpement de Dolibarr
<address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-15"
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.
-------------- section suivante --------------
contenu de type multipart/related sauté
------------------------------
Message: 3
Date: Mon, 03 Jan 2011 18:28:21 +0100
From: Régis Houssin <address@hidden>
Subject: Re: [Dolibarr-dev] Règles de prix
To: Discussions sur le developpement de Dolibarr
<address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
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-dev
Cordialement,