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.
Now that we think we know what we're doing, I'm using a more rigorous
approach to defining iterations and tags, and this condition is no
longer necessary, and in fact, may be harmful. This I'm removing it.
The initial load of data will have these values.
iter | tag | purpose
--------|-------------|-------------------------------------------------
plan | baseline | Adjustments will be made to these values only.
actuals | open-orders | Ordered before 2024 season, still open.
actuals | booked | Ordered in 2024 season so far
I removed a bunch of duplication by:
1. Moving `if (!where)` logic into the build_where function - sending
the "No body was sent." message back in the HTTP response object.
2. Putting all file read operations into a dedicated function -
process_route. This takes a callback function that handles the
remaining logic of each route after successfully reading the SQL
file.
This happens when a customer places identical orders and specifies that
they be shipped in different seasons. We end up with one order shipped
in 2023 and one open for 2024. Under our current operating procedures,
open orders are subtracted from shipped orders and are presented as
baseline for the next forecast. The zero that appears in the baseline in
this case was causing all kinds of issues in the SQL scripts for
inserting the adjustments, ranging from finding zero rows to adjust to
division by zero.
Another change required to correct this was updating the iter value of
the open orders from 'actuals' to 'copy':
UPDATE rlarp.osm_pool
SET iter = 'copy'
WHERE tag = 'open-orders'
Lots of cleanup here too, removing large swaths of code that are no
longer needed. Many improvements the Excel workbook, which is kept in
Teams, not git. These changes may or may not have had accompanying VBA
changes.
A lot has changed here, including:
1. Adding pounds to the data available for display in pivot table.
2. Visual improvements
3. Code simplification
4. Hiding / showing sheets as needed. A developer's backdoor allows for
easy toggling for debugging purposes: Ctrl+RightClick on the Forecast
Adjustment form's "Selected Scenario" label.
5. Fixed a bug that happened when deleting rows from the basket. The
definition of the Target variable was lost in some cases.
6. Made use of the Cancel and Default form properties to purge some
unnecessary code.
7. Added a sheet that contains Help text for the users.
8. Replacing more harcoded range reference with range names.
9. Refactor checks for division by zero errors, and improve error
messages for users.
10. Remove manual formatting. It's already done and saved in the
workbook; there's no need to redo it in code.
11. Added more data validation before Save operation proceeds.
12. Added a new IntersectsWith function to simplify If statements.
1. Remove/Hide Swap Part
2. Remove/Hide Swap Customer
3. Improved the location of controls on fpvt form.
4. Make user experience more intuitive on the Month sheet
5. Make more and better use of named ranges in place of hardcoded cell
locations.
6. Added error checking to ensure Tag is entered and at least one month
has a forecast on Month sheet.
WARNING! Do not assume the Excel file in this repo matches the VBA in
the repo. The decision was made to use Teams for managing changes to the
Excel tamplate because Git is ill-suited for binary files. The Excel
file will be updated from time to time, but only when something major
happens with the application as a whole.
1. Use the sheets' codenames to refer to them in code. This prevents
breakage if the user changes the sheet name while working with the
workbook.
2. Give the pivot tables proper, if not descriptive, names.
3. Simplify the code that detects a double-click in the pivot table.
4. Remove Windows_API as it was not being used.
5. Pare down TheBigOne to just the essential functions in Utils.
6. Refer to the data sources for the userforms' listboxes by using the
worksheet.ListObjects collection.
