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 |
||
|---|---|---|
| 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