Liste de prix : ajouter une hierarchie

[Cyprienp]

Bonjour j'utilise Tryton en tant que framework pour des modules spécifiques depuis quelques temps déjà.
Actuellement je me penche sur les modules standards de l'ERP. Comme évoqué sur irc, j'aurai besoin de pouvoir gérer le cas suivant :

je gère les prix de ventes en fonction de la région du client. Donc je définis une liste de prix pour chaque région que j'affecte ensuite aux clients concernés. jusque-là c'est bon.
Mais certains clients dans ces régions peuvent avoir des prix particuliers sur certains produits et sur le reste du catalogue le prix de la région.
Actuellement ce cas est difficilement réalisable en standard.

la solution serait d'ajouter un champ parent à la liste de prix, et au moment du calcul du prix, si le prix n'est pas trouvé dans la liste on cherche dans la liste parente, récursivement.
On pourrait même ajouter dans le context le prix de la liste parente (parent_unit_price) pour permettre de calculer des remises en cascade.

j'aimerai contribuer à Tryton, pensez-vous que cette fonctionnalité pourrait être utile en standard ?
Si oui pensez-vous qu'il vaut mieux modifier le module product_price_list ou créer un nouveau module ?

[Cédric Krier]

On 2017-03-18 09:19, Cyprienp wrote:
> la solution serait d'ajouter un champ parent à la liste de prix, et au
> moment du calcul du prix, si le prix n'est pas trouvé dans la liste on
> cherche dans la liste parente, récursivement.
> On pourrait même ajouter dans le context le prix de la liste parente
> (parent_unit_price) pour permettre de calculer des remises en cascade.
>
> j'aimerai contribuer à Tryton, pensez-vous que cette fonctionnalité
> pourrait être utile en standard ?
> Si oui pensez-vous qu'il vaut mieux modifier le module product_price_list
> ou créer un nouveau module ?

Je pense que le comportement d'une telle fonctionnalité est plus
complexe que ce qu'on ne pense car le design des listes de prix est
tel qu'elle retourne toujours un prix. Donc le cas ou il faut chercher
dans la liste de prix parente est assez ambiguë.
Par contre, il n'y a aucune difficulté particulière à implémenter un
module qui ajoute un parent et un 'parent_price'. Elles ont été conçues
pour être facilement extensible pour ce genre de case.
Mais je ne pense pas qu'un tel module devrait être de base du fait de
l'ambigüité qu'il ajouterait aux listes de prix.
Si tu compte réaliser un tel module, je t'invite à le publier et
l'annoncer sur http://groups-contrib.tryton.org/

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Cyprienp]

Ok merci pour ta réponse.
Je retrouve souvent le besoin de cette fonctionnalité chez des clients, notamment dans le négoce, où le nombre de références vendues est important (plusieurs milliers)
et où les mises à jour de prix (fréquentes) sont ingérables sans cette fonctionnalité.
Il ont aussi souvent besoin de pouvoir définir un prix par catégorie de produit, mais j'ai vu que ça sera ajouté à la 4.4.

Donc je vais développer un module pour le prendre en charge. J'ai quelques questions, si tu peux m'aiguiller :

- Si on surcharge la méthode compute, sans modifier le standard, il est compliqué de savoir si des lignes ont matché ou pas.
On peut essayer en comparant le unit_price du produit et le retour de compute. Si les 2 valeurs sont égales et qu'il existe une liste parent alors on compute la liste parent:

def compute(self, party, product, unit_price, quantity, uom,
            pattern=None):
   
    price = super(PriceList, cls).compute(party, product, unit_price, quantity,
        uom, pattern)

    parent_unit_price = unit_price
    if self.parent and (price == unit_price):
        if self.parent:
            parent_unit_price = self.parent.compute(party, product, unit_price,
                quantity, uom, pattern)

    return parent_unit_price


- En modifiant le standard, si aucune ligne ne matche et que la liste possède un parent on compute le parent, si elle n'en possède pas on renvoie unit_price du produit :

    def compute(self, party, product, unit_price, quantity, uom,
            pattern=None):
        'Compute price based on price list of party'

        Uom = Pool().get('product.uom')

        if pattern is None:
            pattern = {}

        pattern = pattern.copy()
        if product:
            pattern['categories'] = [c.id for c in product.categories]
            pattern['product'] = product.id
        pattern['quantity'] = Uom.compute_qty(uom, quantity,
            product.default_uom, round=False) if product else quantity

        parent_unit_price = unit_price
        if self.parent:
            parent_unit_price = self.parent.compute(party, product, unit_price,
                quantity, uom, pattern)

        context = self.get_context_formula(
            party, product, unit_price, parent_unit_price, quantity, uom)
        for line in self.lines:
            if line.match(pattern):
                return line.get_unit_price(**context)

        return parent_unit_price

- Une troisième solution serait, comme tu m'as suggéré sur irc, d'ajouter un critère party à PriceListLine.

- la première solution a l'avantage de préserver le standard mais les cas où on doit chercher dans la liste parent restent ambigus(ex: si le prix qui matche dans la liste est égal au unit_price)
- la deuxième solution a l'avantage de supprimer toute ambiguïté (il me semble), de proposer de définir un prix en cascade (parent_unit_price). Mais ça modifie le standard...
- La troisième solution pourrait être envisagée dans le cas où ponctuellement certains tiers ont des prix particuliers, mais lorsque le nombre de tiers et de produits est important ça devient difficilement maintenable.

Quelle méthode me conseilles-tu ? tu vois une meilleure solution ?

[Cédric Krier]

On 2017-03-20 07:03, Cyprienp wrote:
> Quelle méthode me conseilles-tu ? tu vois une meilleure solution ?

Aucune des trois ;-)

Personnellement, j'ajouterais dans le contexte d'évaluation des formules
une variable "parent_price" par exemple. Et je demanderais aux
utilisateurs d'ajouter comme dernière ligne une ligne qui « match » tout
avec comme formule "parent_price".
De cette manière la configuration est explicite et ne requière qu'un
minimum de code.
Il y a peut-être même la possibilité d'ajouter automatiquement cette
dernière ligne quand le parent est sélectionné via "on_change" et/ou
d'ajouter une validation pour s'assurer que la dernière ligne est
correcte.