This content has been marked as final. Show 8 replies
Wow that spam filter is ridiculous. Diskount it is then.
Rather than hardcoding the diskounts in the rules, you could define an entity called "the customer diskounts" with a separate instance for each diskount.
You can then add a condition to each diskounts that indicates whether that particular diskounts is applicable to the current assessment:
You can then use the various Instance*If() functions to perform any calculations. For example, to sum up the diskounts you could use:
the customer diskounts is applicable if ...the customer name for the customer diskount = the customer name and ...the transaction date >= the customer diskount start date and ...the transaction date <= the customer diskount end date
the transaction diskount = InstanceSumIf(the customer diskounts, the percentage of the customer diskount, the customer diskount is applicable)
Thanks a lot for the quick response. Sounds like we must put this logic in Word. However we have 1000's of records like this and it would be nice if we can use Excle for it. Can we do something similar in Excel?
Can you please tell me whether your solution will work by defining diskount rate table in excel (more than 1000 records) and refer back to excel
My suggestion is not to store the 1000s of records in Excel or Word, but to instead store them as entity instances and pre-populate any requests with the information about what diskounts are available, effectively as reference data.1 person found this helpful
Thanks once again. However I still need more information. Are you suggesting that we store these 1000s of records somewhere else like Oracle table and then while accessing the rule session, create entity instances for diskounts and populate diskount values only for eligible diskounts. Please enlighten me.
Yes that's basically what I'm suggesting.
Of course there's no reason you couldn't store these in, for example, a CSV file (editable by Excel, to fit your initial request) and then prepopulate your request data with this information.
Just to elaborate one possible way to do this. You could have a software engineer create an inferencing listener and implement the beginInferencing() method to ensure the available diskounts are preloaded in every session. The data could be loaded from a CSV file as described above (which allows it to be edited in Excel) and created as entity instances.1 person found this helpful
Refer to the OPA developer help for more information on inferencing listeners - there is no example for this particular situation however it should be feasible. This documentation also explains how to package up the inferencing listener code with the rulebase so that it will automatically load in the regression tester, but note that you need to produce code suitable for the platform you are using (either .NET or Java).
The one difficulty here is loading the CSV from the inferencing listener code. There's no easy way to do locate it from the inferencing listener itself, so you may just have to decide on a reliable place to locate the file. Something we need to improve in a future version!
Another way to do this in OPA 10.2 is to create an extension for Determinations Server that handles the OnMapDataEvent. You can load whatever reference data you need within your handler for that event. There will be a video available that shows how to do this, shortly.