It's not completely seamless, but it should work adequately well. The
workbook (aka client) inserts the workbook version into the http request
body. The server code compares that version number against its minimum
supported client version.
If the client is too old, an error message is sent back to the client.
When the client receives the "Obsolete" error message, it launches the
https://<server>:<port>/template URL in the default browser, which
enables the user to save the downloaded new workbook file.
Two things were wrong with this code:
1. The exchange rate conversion was backward. Since we work in USD, I
removed the conversion and used value_usd instead.
2. The calculation of pscale.factor was incorrect. If the old value is
1000, and we need to get to 1020, the record to be inserted must have
a value of 20, thus the value for factor needs to be:
(1020 - 1000) / 1000 = (1020 / 1000) - 1 = 0.02
0.02 * 1000 = 20, which is inserted in the new record.
The subtraction was missing before, which of course caused WAY wrong
numbers that should have been caught a long time ago. It was doing:
1020 / 1000 = 1.02
1.02 * 1000 = 1020 was inserted, doubling the intended adjustment.
There were too many other locations that needed to be found and changed,
that it was easier to just do:
update osm_pool set iter='plan' to iter='baseline'
and be done with it. I also informed Jim to make the same change in his
baseline creation scripts.
The Range.Value function does not consistently return a 2-D array. If
the range is a single cell, it returns just the value in that cell. When
initializing a Userform listbox, it needs to be an array, so this
function was born.
I got DSM list from ubm.rlarp.osm_pool, not CMSInterfaceIn.lgdat.CODE.
Made the list of Tags contain just "Volume".
Added "baseline" to the Basis and Baseline lists.
This was causing a double dipping of value changes. Along with this
change was a manual purge of the changes that mistakenly were made.
Luckily they were easy to find:
l.doc->>'type' = 'scale_vp'
iter = 'adj price'
This happens on the Monthly view, and it's possible to get multiple
error messages, even among other successful month adjustments. There was
no way of knowing which month was the offending one or if any had
succeeded when an error was shown.
This change collects all the error messages into one message with the
period so that it's more intuitive and less obtrusive.
