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.
