The concern I have is I wish to use it as a constraint for Adding Orders. That infers if I use the {REPORT SQL} Tag in a constraint and hit the Table every time I need to Add/Edit an Order will this become a issue?
It would be nice to have a {:SETTINGVALUE} @emre?
My goal is to ensure once a Price Definition for a Department is in Use - then DO NOT allow prices to be changed vi Happy Hour or other means unless coded by design.
ACTION to be effected is UPDATE ORDER.
[EDIT]
I could set up a workflow using {SETTING:x} - must LOG OUT on Price List Change - do not refresh cache (to retain setting) but workflows typically are born with "holes’ and I am sure a user will find them…
Ok - If a venue for the day decided to hold a Function i.e Wedding then the Terminals will be switched to Price Definition = Function.
Therefore I do not wnt any other Price Levels available. It works using the constraint above and it is quite efficient using it as a Custom Constraint.