You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2009/01/29 23:23:42 UTC
Price rule with classifications hierarchy
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
Re: Price rule with classifications hierarchy
Posted by David E Jones <da...@hotwaxmedia.com>.
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" <da...@hotwaxmedia.com>
>>
>> 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
>>>
>>>
>
Re: Price rule with classifications hierarchy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jacques
From: "David E Jones" <da...@hotwaxmedia.com>
>
> 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
>>
>>
>
Re: Price rule with classifications hierarchy
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>
>