SAP cannot import readings, it complains that my readings are negative?

This was a reclock error.
Basically, there are 3 inherent reclock schemes.
1) Meter reclock scheme (e.g. on 10000)
2) No reclock scheme for billing etc. (PNPSCADA DB)
3) SAP reclock scheme (format given by SAP per register)


We convert between 1) and 2) when the meter is read and the data put in the database.
We convert between 2) and 3) when the reading is given back to SAP.




When we do step 1); we check whether the register value is equal to or more than the sum of the profile from installation to that date (with TOU scheme applied if relevant). If it is, then fine, it fits into reclock scheme 2) - indicating a non zero start reading. (e.g. when the meter was installed before the AMR system)


If, however, we see we have too much profile to account for a lower register reading, we assume that the meter register has overclocked according to scheme 1); and we add enough on to the register reading, in multiples of the meter reclock value (e.g. +10000); to ensure that the recalculated start reading of the register according to scheme 2) would not be less than zero.




When SAP does a reading, we for instance look at any known readings, then calculate according to profile to the time when the reading is asked for, unapply the billing multiplier, and give this reading to SAP. E.g., for an earlier reading, we would SUBTRACT the profile from the register value to get the required value. IF THIS IS NEGATIVE, SAP gives an error.


Now, if the conversion from 1) to 2) has been done properly, it should never be negative.




The way this can be broken, is to import data from a flat file into the meter later, since before the profile that was read into the meter, and then ask for a SAP reading in that time. For instance, if the meter was reprogrammed and all profile wiped and registers reset to zero. Now SAP will try to return a negative value, and fail.
(Sometimes it would pick it up as reclocked at the time of conversion from 1) to 2); because of reasons like artificial spikes at startup or the difference in resolution of profile and total registers in the same meter, but that cannot be relied upon to always cause a 'reclocked' condition)



The way to reliably fix a broken case like above, you would have to delete the 'non-reclocked' register values put into the DB scheme 2); and read the meter registers again (hopefully still in meter memory) with the old profile already imported. That would then more reliably detect register values as reclocked, and increase the scheme 2) register values accordingly, so that if SAP should ask for older register values, it would still get non negative values.




As for the generic energy total registers, both scheme 1) and scheme 2) are displayed on the Edit->MeterTotals screen: the ones on the right are unmultiplied and with reclocking still on, in other words what the meter actually says; the ones on the left are multiplied by the Billing factor and there is no reclocking there - the values just keep going up, which means we can more easily do calculations and queries. You can also maintain the totals on there, including to actually delete the total entry, or recalculate the scheme 2) value from profile, e.g. when you changed the physical CT at some point and want to bring the values used for reports in line with the actual energy use.



Now, for the Time-of-Use registers, the scheme 1) values can be seen in the View->MeterRegisters screen.
These values can then potentially translate into Time-of-Use Billing registers according to scheme 2); using the recognition parameters set up in the TOU Calendar, screen Edit->CalendarRegisters.
These you can see and maintain in the TOU Billing Registers screen (Edit->TOU Billing Registers). Here you can delete them, and also choose to delete the corresponding Meter Register entry.