Hello,
I was wondering what emails Openboxes sends?
E-mails like:
- An email on stockout
- An email on stock requests
- etc.
I ask this because I want to config it correctly.
The short answer, borrowing from Dolores Huerta is “Sí, se puede”.
1. Assign notification roles
At the moment, daily stock and expiry email notifications can be configured for any user by adding a default role for all stock notifications
- All Stock Notifications
or individually using specific notification subscriptions
- Expiry Notifications (includes stock that has expired and will be expiring in the next 60 days)
- Low Stock Notifications (requires product to have inventory level configuration)
- Overstock Notifications (requires product to have inventory level configuration)
- Out of Stock Notifications (requires product to have inventory level configuration)
- Reorder Notifications (requires product to have inventory level configuration)
- (there might be others)
The system should also allow you to configure these roles at the location role level in the case where you want different users to receive the notifications for different locations.
2. Enable notifications
You can enable notifications on a Location Type
or Location
IMPORTANT: Please note that if you override the Location, that location’s Supported Activities are no longer inherited from its Location Type, so you’ll need to uncheck Use Default Settings and manage them on your own. Since there are new features (i.e. supported activities) being added with each new release you’ll need to keep an eye on Release Notes to see whether you need to enable those features manually.
3. Configure outbound SMTP
You must also configure SMTP settings in your runtime configuration file (i.e. openboxes-config.properties or openboxes-config.groovy).
Depending on your server, you may also need to deal with firewall rules and the like, but that’s out of scope for this discussion.
4. Scheduling notifications
While the default schedule is set to daily (midnight UTC) you can change the cron expression used to trigger this Quartz job so that it executes as often or as infrequent as you’d like. As you’ll note, you also get a few other configuration properties (i.e. skip on empty, days until expiry).
// Send stock alerts
openboxes.jobs.sendStockAlertsJob.enabled = true
openboxes.jobs.sendStockAlertsJob.skipOnEmpty = true
openboxes.jobs.sendStockAlertsJob.daysUntilExpiry = 60
openboxes.jobs.sendStockAlertsJob.cronExpression = "0 0 0 * * ?" // every day at midnight
5. Testing
I don’t think anyone has used this feature in a while, so I cannot confirm that it is working properly at the moment. So test it out a bit and let us know what you find.
Ah yes, thnx for the update!
Aside I’m currently designing / prototyping a much more comprehensive event subscription and notification framework that will allow you to subscribe to specific events that occur within the system.
This new framework will allow you to set up a rule “Perform when a condition is met” that will allow you to, for example, “Send email notification when Product X has fallen under reorder quantity Y at location Z”. These event notifications are different in that they would trigger immediately rather than as a daily notification for all products at a location. The latter (daily stock notifications) will continue to work, but this new feature will allow us to add customization hooks so you can better configure what happens when important events occur.
For example, instead of sending an email notification for every Low Stock event, maybe you just want the Low Stock event to generate a Replenishment Order for transferring a quantity (Max Quantity - Current Quantity) from one internal location to another (i.e. Reserve Location to the default Picking location). The Replenishment Order will still need to be completed by a user since I’m not aware of any of our users performing automation via robots yet. But we can dream.
We will also expose a webhook mechanism allowing you to push these event notifications externally to integrate with third-party systems (e.g. let’s say you want to update your accounting system whenever stock leaves the warehouse). This should not replace a proper integration framework as we probably cannot guarantee delivery, recovery, failover, etc, with an internal event system (we would need to use a proper event queue service for that). But it could be used for prototyping your ideas or for less mission-critical workflows.
In case you’re getting really excited about the potential for this feature, let me just highlight two important points to help dampen your mood.
-
This feature does not have formal requirements or funding at the moment, so there’s no timeline for the delivery of the aforementioned feature. However, if there’s interest, I’ll create a GitHub issue and let users provide use cases they’d like to see supported.
-
Changing the nature of event production and consumption within an application like OpenBoxes will likely cause the potential for a huge amount of “noise”. Any supported use cases should consider that certain conditions might be met more frequently than expected and might cause high volumes of valuable resources like money, attention, and sanity. For example, let’s say you have 200 EA of an item in stock, and your Low Stock threshold is set to 150. If you issue 1 EA of an item 100 times in a day, the condition Current Quantity <= Low Quantity will be true 50 times in that day. That means 50 email low-stock email notifications for a single product and location. That kind of noise will get annoying quickly, so we’ll need to ensure events have a time window associated with them to prevent duplicate actions.
As for the Request Notifications, there are no notifications around the Request workflow at the moment, but we have notifications for the Approval and Shipment workflows.
The new Approval workflow provides notifications related to the various approval states (o.e. request for approval, approved, rejected). Check out the Release Notes and/or documentation for more information.
There are also Shipment notifications that are sent for the Shipped, Partially Received, and Received events.
Lastly, there are notifications are sent for the Shipped and Received events if you use the Recipient field at the line item level.
FWIW, we added notifications for the Request workflow for another project, but that feature was implemented in a separate branch that has not been merged into OpenBoxes core. We’ll eventually merge all of those changes (including some important API changes for the mobile application), but there’s no timeline for that yet.