We have two locations where we have a slush machine for selling a juice. We have an internet-connected sensor that will periodically report the pH value and temperature of the juice. We’d like this information to be captured by ERPNext so that when a PoS invoice is generated, the two values appear on the invoice. Each juice shop will submit their own values against their PoS account.
As far as I understand, it’s fairly straight forward to send information to ERPNext via its REST API. However, I’m not clear on how the information will be stored in a
DocType so that it can be pulled in a PoS invoice.
In addition to
DocType, do I need to create something else in order to implement this? Any advice is appreciated.
I think you might have to also create some custom fields in the doc type that you wish to store the information. In your case, this might be the Sales Invoice.
The biggest issue is finding a place to store the sensor data. How you store this will determine how the rest of the operation works. If you only want the data to appear on the Sales Invoice, then there might be a fairly simple solution (as follows):
Add custom fields to the Sales Invoice to hold the sensor data at the time of the sale.
Create a background app that captures the sensor data for your slush machines into a CSV file on the ERPnext server. The file would be replaced at whatever interval you set for the sensors to be polled. This way the data is always fresh.
Create another background app to be triggered when a Sales Invoice is generated that would read the CSV file for the sensor information related to the particular slush machine and populate the new sensor fields in the Sales Invoice.
When the Sales Invoice is submitted, the sensor data is stored forever against the invoice
There is probably only one problem with the scenario I listed above. You would have to use the POS Awesome application in order to get the Sales Invoice created at the actual time of the sale. The current native POS functions would not work because they create temporary invoices that do not get submitted until the end of the shift. If you were using the “Submit” action to trigger grabbing the sensor data, all of the Sales invoices would have the exact same data that would reflect the sensors at the time of submission (the end of the shift).
The POS Awesome app generates Sales Invoices in real time and creates the stock entries in the ledger to keep data as fresh as possible. This is why you would need to use it as your POS application so the rest of the concept works.
More to consider…
If you want some window of historical data on the sensors, then you could have the app that generates the CSV file simply append the file with new data at every sensor polling time and then manage the files size by the amount of historical data you want to have on hand and any given time.
If for some reason you need complete historical sensor data, then it gets a bit more complicated. You would have to create a new doc type and an app to manage it where the time stamped records of sensor readings would need to be stored. This could lead to a rapid growth of the ERPNext database that could become unmanageable in a very short period of time.
However, my guess is that if you already have an internet application that is polling the sensors and able to report the data, then you likely also have the ability withing that application to keep the historical sensor data available. If this is the case then the very first suggested solution might be the optimal fit for your use case.
BTW… this is just one possible idea. I am sure there are others. As you consider all possible paths to your eventual solution, also remember to consider the ease with which you can keep your solution running during all of the EPRNext updates and upgrades (this is why I suggested a CSV file approach). Also look for all other possible ‘ripple’ effects that any new changes could present (lime the rapid database growth).
Hope this helps…
BTW… The possible solution I wrote out above, is not something that I merely blurted out.
I actually use something like this already. At one site, I periodically poll the ERPNext database and generate a list of “Items” with their associated Item Codes, barcodes, and descriptions and overwrite a CSV file every 30 min with this data.
The CSV file supports a third party barcode printing solution that allows a manufacturing client print new labels for any new product that comes out of manufacturing. Once you have the data in the file, you can access it fairly easily to use it almost anywhere.