Price rule with classifications hierarchy

[Jacques Le Roux]

A client of mine needed to have a price rule on a party classification also working on children of a classification (using parentId)
His use case was
agent
    agent partner
        agent partner fix
        agent partner performer
    agent not partner
...

and he wanted that if he defines a rule on agent it also apply on all children (this generalized at any level of the hierarchy, of course, ie  a rule on agent partner would only apply to agent partner, agent partner fix and agent partner performer)

I created a little recursive method, do you think this could be useful OOTB ?

Jacques

       

[David E Jones-3]

Those sound more like PartyGroups (related using PartyRelationship)  
than PartyClassifications. A party classification is used for usually  
"sensitive" data like race, income, etc and usually for marketing  
purposes.

As for the group hierarchy thing, I think that may already be  
supported for group-based pricing, and I know there is already code to  
walk up relationships to expand a set of group partyIds.

-David


On Jan 29, 2009, at 2:23 PM, Jacques Le Roux wrote:

> A client of mine needed to have a price rule on a party  
> classification also working on children of a classification (using  
> parentId)
> His use case was
> agent
>    agent partner
>        agent partner fix
>        agent partner performer
>    agent not partner
> ...
>
> and he wanted that if he defines a rule on agent it also apply on  
> all children (this generalized at any level of the hierarchy, of  
> course, ie  a rule on agent partner would only apply to agent  
> partner, agent partner fix and agent partner performer)
>
> I created a little recursive method, do you think this could be  
> useful OOTB ?
>
> Jacques
>
>

[Jacques Le Roux]

Jacques

From: "David E Jones" <[hidden email]>
>
> Those sound more like PartyGroups (related using PartyRelationship)
> than PartyClassifications. A party classification is used for usually
> "sensitive" data like race, income, etc and usually for marketing
> purposes.

Yes, that was also my feeling, but you know... client is king...

> As for the group hierarchy thing, I think that may already be
> supported for group-based pricing,

Yes, it is.

>and I know there is already code to
> walk up relationships to expand a set of group partyIds.

Good to be known, anyway it's was not long to create this recursive custom method, the parentId in PartyClassificationGroup was
useful.
I could commit but this woul dimply to have another choice (Recursive Party Classification) and I guess it's a bit specific.

Thanks

Jacques

> -David
>
>
> On Jan 29, 2009, at 2:23 PM, Jacques Le Roux wrote:
>
>> A client of mine needed to have a price rule on a party
>> classification also working on children of a classification (using
>> parentId)
>> His use case was
>> agent
>>    agent partner
>>        agent partner fix
>>        agent partner performer
>>    agent not partner
>> ...
>>
>> and he wanted that if he defines a rule on agent it also apply on
>> all children (this generalized at any level of the hierarchy, of
>> course, ie  a rule on agent partner would only apply to agent
>> partner, agent partner fix and agent partner performer)
>>
>> I created a little recursive method, do you think this could be
>> useful OOTB ?
>>
>> Jacques
>>
>>
>

[David E Jones-3]

Client is King... well, yes, but Kings need advisors.

In this case if they refuse to use call a group a group, and instead  
want to call a group a classification then they cannot use existing  
functionality in OFBiz, and as in this case there is less of a chance  
that whatever is developed for them will make it back into the project.

Often Kings don't realize such things, hence their need for advisors.  
And if they choose not to listen to their advisors (if their advisors  
are good ;) ), they typically pay more and/or fail.

-David


On Jan 30, 2009, at 2:16 PM, Jacques Le Roux wrote:

> Jacques
>
> From: "David E Jones" <[hidden email]>
>>
>> Those sound more like PartyGroups (related using PartyRelationship)
>> than PartyClassifications. A party classification is used for usually
>> "sensitive" data like race, income, etc and usually for marketing
>> purposes.
>
> Yes, that was also my feeling, but you know... client is king...
>
>> As for the group hierarchy thing, I think that may already be
>> supported for group-based pricing,
>
> Yes, it is.
>
>> and I know there is already code to
>> walk up relationships to expand a set of group partyIds.
>
> Good to be known, anyway it's was not long to create this recursive  
> custom method, the parentId in PartyClassificationGroup was useful.
> I could commit but this woul dimply to have another choice  
> (Recursive Party Classification) and I guess it's a bit specific.
>
> Thanks
>
> Jacques
>
>> -David
>>
>>
>> On Jan 29, 2009, at 2:23 PM, Jacques Le Roux wrote:
>>
>>> A client of mine needed to have a price rule on a party
>>> classification also working on children of a classification (using
>>> parentId)
>>> His use case was
>>> agent
>>>   agent partner
>>>       agent partner fix
>>>       agent partner performer
>>>   agent not partner
>>> ...
>>>
>>> and he wanted that if he defines a rule on agent it also apply on
>>> all children (this generalized at any level of the hierarchy, of
>>> course, ie  a rule on agent partner would only apply to agent
>>> partner, agent partner fix and agent partner performer)
>>>
>>> I created a little recursive method, do you think this could be
>>> useful OOTB ?
>>>
>>> Jacques
>>>
>>>
>