Growers and retailers in the Cannabis industry have a wide range of software products from which to choose. Wholesalers and processors have much fewer options!
I've had numerous requests for a Quickbooks to Metrc connector. All of these requests have come from wholesalers and/or processors. Many of these same companies expressed an interest in syncing an eCommerce system to Metrc. Some shared concerns and struggles in terms of inventory tracking. Concepts from enterprise resource planning came up in conversations as well. The bottom line is, wholesalers and processors are experiencing pain that software can likely solve. Why shouldn't I be the one to solve it?
The big question is . . . HOW should it be solved? I've explored a wide variety of approaches. Hidden agent processes running on a back room server could continually probe existing systems and ensure the various data sources stay in sync. A POS approach works for retailers, and how cool would it be to build manufacturing control and monitoring systems with Raspberry Pi's?!?!
In the end, I can't see any reason why a good ol' web app isn't the right way to go.3 Obviously it will need to provide a better experience than using the various other systems individually. So, though I'm more of a back end engineer than a user experience artist, I'm working on a front end prototype to demonstrate how a wholesaling and processing solution might work. I'll look for feedback to determine where to go from there.
If you're interested in getting a look at what I'm working on, let me know you'd like to review the prototype. I'd also love to hear any suggestions or ideas you have on what should be included in a software offering for marijuana wholesalers or processors!
1. I guess this is a good learning opportunity?!?
2. There are many other challenges for wholesalers and processors when it comes to ecommerce. Access must be restricted to other licensees (and possibly only to retailers, especially in competitive markets). You can't just leverage the postal service's api to calculate delivery charges. And though banking options are becoming more available, capturing credit card payments can still be problematic.
3. At least to get started. Even though I'm starting out with a web solution, I'd still love to put together hardware for processing stations. I initially though growing was the only place where Pi's would be useful (http://icodeforfun.com/cannabis), but since processing is essentially manufacturing, there's a lot of potential there too. Give me a Pi, a label printer and a handheld barcode scanner, and I'll show you a packaging station any operator would be happy to oversee.
Saturday, December 3, 2016
Saturday, November 19, 2016
Solving my own pain first
When I started this adventure, I hoped to find problems faced by Marijuana and Hemp businesses. Any pain point represents an opportunity. However, since getting listed as a verified Metrc API integrator, the primary problem I'm hearing about is the amount of work required to perform all the data input requirements. I didn't find this problem . . . it's finding me! So this is likely something I'm going to spend some time addressing.
During my evaluation, I found myself wishing I had a way to "bootstrap a scenario". For example, repackaging exercises require a starting package. I admit to pillaging packages made by other sandbox users, but remember how cool it would be to have a tool that could create a plant or package at any stage in it's lifecycle. Need a plant ready for harvest? Need multiple plants ready for packaging? Need a package ready to be repackaged? Yes, yes and yes please!
For many of these steps, you'll need to provide tags. While in production, you'll know which tags have not been used (or else you've got really big problems), but in a sandbox or test environment, finding unused tags is kind of like throwing darts in the dark. So step one is to make a tag checker. Nothing pretty, but an easy to use "give me a tag and I'll tell you if it's used" kind of thing.
Next, I'll come up with some common scenarios that might be useful. Creating packages with flower fresh from harvest seems a good start. You'd pass in a plant tag, a package tag and perhaps the amount of product you want. It will create entries starting at planting, through flowering, to harvest and finally into a package. Items, rooms and any other needed data will be picked randomly from existing data. Did I mention this is meant for a sandbox or test environment only?!?
So, this isn't really going to solve any of the problems Cannabis companies are facing. But, it will sure make my life easier. By being able to set up scenarios in a repeatable and reliable way, it will save me time, allow me to concentrate on coming up with solutions for real problems.
During my evaluation, I found myself wishing I had a way to "bootstrap a scenario". For example, repackaging exercises require a starting package. I admit to pillaging packages made by other sandbox users, but remember how cool it would be to have a tool that could create a plant or package at any stage in it's lifecycle. Need a plant ready for harvest? Need multiple plants ready for packaging? Need a package ready to be repackaged? Yes, yes and yes please!
For many of these steps, you'll need to provide tags. While in production, you'll know which tags have not been used (or else you've got really big problems), but in a sandbox or test environment, finding unused tags is kind of like throwing darts in the dark. So step one is to make a tag checker. Nothing pretty, but an easy to use "give me a tag and I'll tell you if it's used" kind of thing.
Next, I'll come up with some common scenarios that might be useful. Creating packages with flower fresh from harvest seems a good start. You'd pass in a plant tag, a package tag and perhaps the amount of product you want. It will create entries starting at planting, through flowering, to harvest and finally into a package. Items, rooms and any other needed data will be picked randomly from existing data. Did I mention this is meant for a sandbox or test environment only?!?
So, this isn't really going to solve any of the problems Cannabis companies are facing. But, it will sure make my life easier. By being able to set up scenarios in a repeatable and reliable way, it will save me time, allow me to concentrate on coming up with solutions for real problems.
Friday, November 11, 2016
The trouble with wholesalers
I've had conversations with several soon-to-be wholesalers lately. They are either still building out their infrastructure, or reworking a previous business to accommodate Cannabis products. All of them plan on being more than simple conduits between growers and processors or retailers, though their visions and approaches all differ.
From a software perspective, it's pretty clear wholesalers are underserved. There are lots of programs for growers and retailers, but few options for wholesalers. Even Metrc's API is missing endpoints for transfer functionality, the main feature needed by these businesses.
Though I've yet to really explore it, I'm sure there is existing software to help manage wholesaling operations. I would even bet there are service providers who can modify the software for Marijuana's unique requirements. However, I would not assume these are user friendly, modern or affordable solutions.
Wholesaling is a natural and necessary service in the Cannabis industry. Once interstate commerce becomes a reality, these companies will become even more vital. I look forward to watching how wholesalers leverage technology within their businesses, and to see whether offerings targeting this niche market start to appear.
From a software perspective, it's pretty clear wholesalers are underserved. There are lots of programs for growers and retailers, but few options for wholesalers. Even Metrc's API is missing endpoints for transfer functionality, the main feature needed by these businesses.
Though I've yet to really explore it, I'm sure there is existing software to help manage wholesaling operations. I would even bet there are service providers who can modify the software for Marijuana's unique requirements. However, I would not assume these are user friendly, modern or affordable solutions.
Wholesaling is a natural and necessary service in the Cannabis industry. Once interstate commerce becomes a reality, these companies will become even more vital. I look forward to watching how wholesalers leverage technology within their businesses, and to see whether offerings targeting this niche market start to appear.
Saturday, November 5, 2016
Women Grow Rocks!
Wow! Just Wow!
I learned about Women Grow during an initial meeting with a grower. I was assured, despite the name, men were welcome. So, I attended my first networking event, and I'm so glad I did!
The variety of people I met was very interesting. Some were just investigating the industry, trying to find a suitable role. Others had years of experience (despite a "13 year forced sabbatical" in one case). Conversations ranged from small talk to hard core business. The cost of Oregon's new testing requirements and limited growing space discussions reaffirmed and expanded my understanding of some of the challenges faced by producers and processors.
The event included a panel who discussed medical uses of cannabis. Dr. Rachel Knox introduced me to the endocannabinoid system and made me realize how little the medical community as a whole understands how to use marijuana as medicine, and how real and profound a properly prescribed regiment can benefit patients. "Professor P" dispelled the importance of THC and CBD as indicators of a strains profile, opening my eyes to the variety of cannabinoids and terpenes that give each marijuana strain it's unique characteristics. And of course, the panel discussed the importance of keeping pesticides, poisons and big pharma out of Cannabis.
I'm looking forward to the next Women Grow networking event. If you're in the industry, or want to get involved, I highly recommend attending the next event too! I hope to meet you there.
I learned about Women Grow during an initial meeting with a grower. I was assured, despite the name, men were welcome. So, I attended my first networking event, and I'm so glad I did!
The variety of people I met was very interesting. Some were just investigating the industry, trying to find a suitable role. Others had years of experience (despite a "13 year forced sabbatical" in one case). Conversations ranged from small talk to hard core business. The cost of Oregon's new testing requirements and limited growing space discussions reaffirmed and expanded my understanding of some of the challenges faced by producers and processors.
The event included a panel who discussed medical uses of cannabis. Dr. Rachel Knox introduced me to the endocannabinoid system and made me realize how little the medical community as a whole understands how to use marijuana as medicine, and how real and profound a properly prescribed regiment can benefit patients. "Professor P" dispelled the importance of THC and CBD as indicators of a strains profile, opening my eyes to the variety of cannabinoids and terpenes that give each marijuana strain it's unique characteristics. And of course, the panel discussed the importance of keeping pesticides, poisons and big pharma out of Cannabis.
I'm looking forward to the next Women Grow networking event. If you're in the industry, or want to get involved, I highly recommend attending the next event too! I hope to meet you there.
Tuesday, October 25, 2016
The Big Idea - Cannabis
Last night, I went to an event held by the Oregonian with a panel who discussed the current state of Cannabis in Oregon. It ended up being interesting and informative, with some insights that I hadn't really considered.
Noah Stokes of Cannaguard argued the end of prohibition has lead us not to legalization, but to regulation. And that, Noah argued, is a good thing! Regulation makes product quality, consumer protections and other benefits possible. It also legitimizes the industry, which will eventually help resolve some of the biggest problems facing the industry.
One of the most visible and obvious problems is banking. Forcing marijuana businesses to deal only in cash may be good for Noah's business, but not for the health of the industry. And though there are now a few options, the majority of banks will not work with Cannabis businesses. The panel confirmed many licensees are paying their taxes in cash.
The stigma of pot makes finding space a huge barrier to entry for new licensees. Mortgages are not compatible with weed. The pool of potential landlords is limited to those who own their property free and clear, leaving few opportunities to lease space. Of course, there's always an option to buy . . . but again, the property would need to be bought in full. A couple of questions from the audience made it clear: if you own property outright and are willing to allow your tenants to run a Cannabis business, you'll have a lot of potential renters lining up to talk to you.
Another topic of frustration are the new testing requirements. An audience member explained how his $20 per ounce product is now saddled with an added $14 testing expense, causing him to cease sales. The panel reassured him the entire industry is struggling to absorb the cost of ensuring quality and safety.
Earl Blumenauer, our Oregon congressman and one of the panelists, talked about the "C-change" occurring at the federal level. Recently, a friend and I pondered what changes the end of federal prohibition could bring. While we could forsee several downsides (like Monsanto deciding to get involved), we hadn't considered some of the potential positives. The same friend shared a conversation with a grower concerned Oregon farmers would eventually produce more product than demand could consume. However, the panel suggested the end of federal prohibition will likely make interstate commerce possible. In this scenario, Oregon would be poised to be a major exporter.
While there wasn't any real talk about technological challenges faced by Cannabis businesses, Rob Patridge of OLCC talked about a variety of ways the state is planning to leverage CTS (Cannabis Tracking System) data. The term "seed-to-sale system" came up a number of times.
If there was one message Rob seemed most keen on getting across, it is to visit http://marijuana.oregon.gov for clarification of any of the current, or future, regulations. There was concern by some audience members that several strain names, including some very popular and well known strains, are no longer allowed. While some people might still disagree with the decision, the rational and disallowed strain names are published on the states website.
Though I didn't come away with any major revelations or ideas for "the next big thing", it was a well spent evening. I may not have any additional insight into problems that can be solved by computers, but I definitely have a better understanding of common challenges faced by everyone in the industry.
Noah Stokes of Cannaguard argued the end of prohibition has lead us not to legalization, but to regulation. And that, Noah argued, is a good thing! Regulation makes product quality, consumer protections and other benefits possible. It also legitimizes the industry, which will eventually help resolve some of the biggest problems facing the industry.
One of the most visible and obvious problems is banking. Forcing marijuana businesses to deal only in cash may be good for Noah's business, but not for the health of the industry. And though there are now a few options, the majority of banks will not work with Cannabis businesses. The panel confirmed many licensees are paying their taxes in cash.
The stigma of pot makes finding space a huge barrier to entry for new licensees. Mortgages are not compatible with weed. The pool of potential landlords is limited to those who own their property free and clear, leaving few opportunities to lease space. Of course, there's always an option to buy . . . but again, the property would need to be bought in full. A couple of questions from the audience made it clear: if you own property outright and are willing to allow your tenants to run a Cannabis business, you'll have a lot of potential renters lining up to talk to you.
Another topic of frustration are the new testing requirements. An audience member explained how his $20 per ounce product is now saddled with an added $14 testing expense, causing him to cease sales. The panel reassured him the entire industry is struggling to absorb the cost of ensuring quality and safety.
Earl Blumenauer, our Oregon congressman and one of the panelists, talked about the "C-change" occurring at the federal level. Recently, a friend and I pondered what changes the end of federal prohibition could bring. While we could forsee several downsides (like Monsanto deciding to get involved), we hadn't considered some of the potential positives. The same friend shared a conversation with a grower concerned Oregon farmers would eventually produce more product than demand could consume. However, the panel suggested the end of federal prohibition will likely make interstate commerce possible. In this scenario, Oregon would be poised to be a major exporter.
While there wasn't any real talk about technological challenges faced by Cannabis businesses, Rob Patridge of OLCC talked about a variety of ways the state is planning to leverage CTS (Cannabis Tracking System) data. The term "seed-to-sale system" came up a number of times.
If there was one message Rob seemed most keen on getting across, it is to visit http://marijuana.oregon.gov for clarification of any of the current, or future, regulations. There was concern by some audience members that several strain names, including some very popular and well known strains, are no longer allowed. While some people might still disagree with the decision, the rational and disallowed strain names are published on the states website.
Though I didn't come away with any major revelations or ideas for "the next big thing", it was a well spent evening. I may not have any additional insight into problems that can be solved by computers, but I definitely have a better understanding of common challenges faced by everyone in the industry.
Friday, October 7, 2016
It's official! I'm authorized to build software that leverages the Oregon Metrc API!!
Got my Production Key today! I am a "validated integrator" for Plants, Harvests, Packages, Sales, Locations, Strains, Items and should be listed in their directory soon!
Hmmm. I guess it's time to set another goal . . .
Thursday, September 29, 2016
A rocky start with the Oregon Metrc API
Towards the end of August, I received a "Proficiency Evaluation", which is the final step in getting production keys for the Oregon Metrc API. Because this is essentially a test, I'm not going to share any of the questions (or answers). However, this was my first chance to play with the API, so I will share my impressions.
It took me over a month to complete the evaluation. And it wasn't because I didn't invest the time! The initial set of docs I got were . . . well, wrong. A number of the argument names weren't correct (though a few were easily guessable). A few of the endpoints just flat-out didn't exist. Of course, none of these issues are immediately obvious, so each of them wasted a lot of time.
Feeling defeated, I contacted Metrc to explain the problems I was having in completing the test. I can not over emphasize how helpful and responsive Metrc has been (Michelle is my hero and I could not have gotten to this point without her help!). I was pointed to some updated online docs. Much better!!!
However, it still wasn't smooth sailing from there.
To complete the evaluation, I was granted access to a sandbox. I was sent a list of plant and package tags, for a number of different licensees, and the sandbox has some initial data. It eventually occurred to me, not all (or maybe not any) of the data was created by the good folks at Metrc. The sandbox, the credentials, the list of tags . . . everything was shared with everyone else who was trying to complete the evaluation. This makes for some nasty surprises and confusing moments!
The shared tags made it impossible to know which tags had been used and which could be attached to plants or packages. To find usable tags, I ended up looking them up until I got a non-200 response. As time went on, finding unused tags became harder and harder. I'm pretty sure I ended up using the last plant tag for one of the producer accounts.
It would be nice to believe you can create something, like a plantbatch, and walk it through it's lifecycle. But in a shared environment, especially one in which users have no means of communicating with each other, your data can get stomped at any time. I had data change out from under me. Initially I felt a tinge of guilt when I used other peoples objects. But by the end, I was flagrantly harvesting other peoples plants and selling out of other peoples packages.
Overall, the API makes a lot of sense. As long as you understand the Metrc system, figuring out which endpoints to call is pretty intuitive. I like the RESTful approach, and I think this is a pretty good implementation.
There are some rough edges though. There's some inconsistency in some of the endpoints. For example, in one case you "changegrowthphase" and in the other case you "changegrowthphases". You can "destroy" a plantbatch, but individual plants require "destroyplants". And while you tag new plants using a "StartingTag", you find plants with a "Label" (these are the same thing). The part I like least is the difference between shapes of requests and responses. For example, when you create a plantbatch, you give it the "Strain". But getting a plantbatch returns the "StrainId" and "StrainName".
I found there's very limited access to historical data. So, if you change the growth phase on a plantbatch, and later see the strain is different, or it's been harvested (or both in my case), there's really no way (that I could tell) to figure out what happened to the plants. Of course, if you're in an environment with a single licensee, none of this should happen . . . but if you wanted to show the lifecycle of a plant, you're going to have to jump through some hoops.
I was less than thrilled to find successful POST requests always return empty responses. Non-200 responses include pretty good information, but after making a successful call, you just get a 200. This pretty much doubles the number of calls I ended making . . . create something, then go look it up.
Though there were some frustrating moments, all in all this was a pretty fun challenge. By the end of completing the evaluation, I felt pretty comfortable with the API and look forward to actually building some software that leverages Metrc. I'm secretly hoping some details of the API are still a work in progress, but even if it's fully baked, I can envision building a lot of cool integrations.
It took me over a month to complete the evaluation. And it wasn't because I didn't invest the time! The initial set of docs I got were . . . well, wrong. A number of the argument names weren't correct (though a few were easily guessable). A few of the endpoints just flat-out didn't exist. Of course, none of these issues are immediately obvious, so each of them wasted a lot of time.
Feeling defeated, I contacted Metrc to explain the problems I was having in completing the test. I can not over emphasize how helpful and responsive Metrc has been (Michelle is my hero and I could not have gotten to this point without her help!). I was pointed to some updated online docs. Much better!!!
However, it still wasn't smooth sailing from there.
To complete the evaluation, I was granted access to a sandbox. I was sent a list of plant and package tags, for a number of different licensees, and the sandbox has some initial data. It eventually occurred to me, not all (or maybe not any) of the data was created by the good folks at Metrc. The sandbox, the credentials, the list of tags . . . everything was shared with everyone else who was trying to complete the evaluation. This makes for some nasty surprises and confusing moments!
The shared tags made it impossible to know which tags had been used and which could be attached to plants or packages. To find usable tags, I ended up looking them up until I got a non-200 response. As time went on, finding unused tags became harder and harder. I'm pretty sure I ended up using the last plant tag for one of the producer accounts.
It would be nice to believe you can create something, like a plantbatch, and walk it through it's lifecycle. But in a shared environment, especially one in which users have no means of communicating with each other, your data can get stomped at any time. I had data change out from under me. Initially I felt a tinge of guilt when I used other peoples objects. But by the end, I was flagrantly harvesting other peoples plants and selling out of other peoples packages.
Overall, the API makes a lot of sense. As long as you understand the Metrc system, figuring out which endpoints to call is pretty intuitive. I like the RESTful approach, and I think this is a pretty good implementation.
There are some rough edges though. There's some inconsistency in some of the endpoints. For example, in one case you "changegrowthphase" and in the other case you "changegrowthphases". You can "destroy" a plantbatch, but individual plants require "destroyplants". And while you tag new plants using a "StartingTag", you find plants with a "Label" (these are the same thing). The part I like least is the difference between shapes of requests and responses. For example, when you create a plantbatch, you give it the "Strain". But getting a plantbatch returns the "StrainId" and "StrainName".
I found there's very limited access to historical data. So, if you change the growth phase on a plantbatch, and later see the strain is different, or it's been harvested (or both in my case), there's really no way (that I could tell) to figure out what happened to the plants. Of course, if you're in an environment with a single licensee, none of this should happen . . . but if you wanted to show the lifecycle of a plant, you're going to have to jump through some hoops.
I was less than thrilled to find successful POST requests always return empty responses. Non-200 responses include pretty good information, but after making a successful call, you just get a 200. This pretty much doubles the number of calls I ended making . . . create something, then go look it up.
Though there were some frustrating moments, all in all this was a pretty fun challenge. By the end of completing the evaluation, I felt pretty comfortable with the API and look forward to actually building some software that leverages Metrc. I'm secretly hoping some details of the API are still a work in progress, but even if it's fully baked, I can envision building a lot of cool integrations.
Subscribe to:
Posts (Atom)