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