In the original design of Tariffs and Rates, we included a field Rate.maxValue, which was to be a hard upper limit of the hourly rate. However, the current implementation neither requires a non-fixed Rate to have a maxValue, nor does it check HourlyCharge instances to ensure that they are lower than maxValue. This is clearly a defect, and it has been exploited.
We would like to fix it (see Issues #624 and #625); before we do, I want to ask the community whether you would like to see the fix immediately, before we run more tournament games, or sometime later. It will be an easy fix in the server, but it will cause Rates and HourlyCharges to be rejected if they do not comply, so it may break some broker logic.
Please let me know your preferences in this matter. I will not implement this fix until I hear your opinions.
I have just deployed updates to common and accounting that add new rules for validity of variable-rate tariffs. Here are the rules:
- A non-fixed Rate must specify all three values (minValue, maxValue, expectedMean), and they must bear proper relationships with each other. In other words, for a CONSUMPTION tariff, maxValue must be more negative than minValue, and expectedMean must be between the max and min values.
- new HourlyCharge values must be between minValue and maxValue or they will be rejected.
Note that the default charge for a variable-rate tariff is the expectedMean. So if there is an hour during which no HourlyCharge applies, customers will pay the expectedMean.
If you rebuild your brokers with the updated common module, you can call the validity-testing methods yourself before sending an update. The easiest way to do this is to compose your TariffSpecification, add the Rates, then call tariffSpec.isValid(). If it returns false, the log file should tell you what's wrong.
Please let me know if you encounter trouble with this feature.