This content has been marked as final. Show 5 replies
When two items are of equal highest value, what's the deciding factor about which one gets multiplied by 90% and which one by 0%? OPA is never going to randomly pick something, it always evaluates according to specified logic. If there is some logic which acts as a tie-breaker (can't think of a furniture analogy off the top of my head) then you can build that additional logic into your rules.
If there is no tie-breaker logic to specify which item gets the 90% and which gets the 0%, then you can still calculate the final price, but you can't 'pick' an entity instance to apply the % to because you haven't written any logic to do so.
BTW, I assume you also need to take account of situations where you have more than two items of equal highest value?
FYI... to anyone else replying to this thread. Avoid the word d-i-s-c-o-u-n-t in your message. When trying to reply before I kept getting a forum message saying “Sorry, this content is not allowed”. It seems that the forum blocks messages with particular keywords, presumably in an effort to reduce spam and fake messages. Turns out that d-i-s-c-o-u-n-t is one of those words!
you got my problem right.
Unfortunately there is no logic that could act as a tie-breaker. I reckon I'll have to find an alternative solution to do so (ask the user which items would be of lowest/highest value when two or more items are concerned).
Yes, I need to consider situations where two items have equal highest values. Even sometimes the lowest value equals the highest value (3 items with the same value).
Thank you very much for helping,
You might be able to do this by assigning unique IDs to each instance and using inferred relationships. I'm not sure if you are using OWD or ODS, as asking the customer to fill in an ID number might not work for your solution... But in terms of "pure rules" you should be able to do this. You would make an inferred relationship between the objects, such as "the similar objects", and perhaps "the similar objects with a lower ID number..."
We implemented something fairly similar with claim days, and having "earlier days"... even if two "days" were on the same date, we could still differentiate between them by having the calling system assingn ID numbers to each one. This worked well but slowed down considerably with high volumes of instances (because of the self-referential relationship). We had an alternative solution which worked much better (temporal cumulative totals) However over low volumes the performance impact of using self-referentials is acceptable.
If you can't assign ID numbers, perhaps you can make unique inferred IDs in some way, and then use those, i.e. object id = Number(timestamp + object value), or something more creative :-) Again, I'm not sure what other data you have available, and whether those 3 objects would be exactly the same in every single way, or not.
Just some thoughts, and an avenue you might want to explore.
Happy to help more if needed.