47d1baffc5
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'
|
||
|---|---|---|
| build | ||
| inquirey | ||
| offline | ||
| route_sql | ||
| VBA | ||
| .env.sample | ||
| .gitignore | ||
| columns.md | ||
| create_certs.sh | ||
| forecast_api.service | ||
| index.js | ||
| LICENSE | ||
| Master Template.xlsm | ||
| msauth.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| sample_request.json | ||
This will not work without exactly the right database schema which is out of scope. this is only the running process part of the forecast.
Setup
- git clone (to //opt for verbatim use of the .service file)
npm install- create certs:
chmod 700 create_certs.sh,./create_certs.sh - clone sample env
cp .env.sample .envand specify 1) database creds 2) working directory 3) listening port - run:
node index.js - navigate to
https://localhost:8080/to valide it's connectable - open the spreadsheet and specify the target connection
additionally, to setup as service
- copy .service file to //etc/systemd/system/ (adjust user/working direct if needed)
sudo systemctl enable forecast_api.service
Initial Forecast
- all SQL depends on unchanged core sales matrix table schema