The Next Chapter

After getting certified to integrate with Metrc, I built a multi-tenant service which allowed me to explore a variety of issues faced by Cannabis companies.

All of the tools and apps were based on real world problems, gleaned from conversations and interactions with people working in Marijuana businesses. Some of these ended up being useful, and others ended up having limited value. Since the entire endeavor provided an endless stream of challenges and puzzles to solve, it was a huge success.

While I have every intent to continue writing software in my spare time, I want to experiment with new architectures and technologies. Migrating the current server and all of it's functionality is a possibility, but would take a lot of effort and time. Since this is my hobby, and something I do for fun rather than profit, I'd prefer bypassing the heavy lifting and getting right to the fun stuff.

So, I've wound down the service. Everything was written so it can run on-premise, or on a company-specific hosted account. There may still be some maintenance work to do, but I'm trying to find alternative solutions for any businesses still needing functionality.

Again, this does not mean an end to writing software to solve Cannabis related problems. It means the freedom to try something new. I've learned I don't want to run my own company. But I do want to continue solving problems and creating solutions. So, I'm not sure what I'll build next, but as long as it's challenging, I'm up for it!

CA evaluation completed

I just completed the CA evaluation for Metrc. While I had hoped the third time would be a charm, and things would go smoothly, it was not to be. I probably spent a total of 4 hours getting through this . . . ouch! I’ll share some of the challenges I ran into, if for no other reason, so that I can learn from it.

To find usable tags, you need to parse several files. However, it’s not obvious what licensee type is represented by each file. This has tripped me up before. The solution here is to use facilities/v1/ to list all license numbers and types.

I initially thought there was nothing populated in the db. After all, last year the sandbox was reset, and there wasn’t enough data to be able to do anything. Without any starting inventory, the API can be really hard to use.

But the problem this time is "API Program Bulletin 17". Since you only get back items which have changed in the past 24 hours by default, initially finding inventory via curl calls makes the system seem empty. I suppose that makes it less likely you’ll stomp on someone else’s data.

Trying to do anything with rooms/v1/ resulted in a “401 Unauthorized” error regardless of which

licensee I tried. I ended up emailing metrc to find “they have been working on some problems” related to rooms. Fortunately, I was given a license number that worked. However, this would bite me later!

I temporarily stumbled over “changegrowthphase” vs “changegrowthphases”. This is not the first time I’ve been bit by this, and it's not a big deal. But still, it was a head scratcher until I realized what was wrong.

The next hurdle was discovering one of the Grower accounts had only 4 plant tags left. Of course, I had used this account to set up strains and items. But without tags, I wasn’t going to get much done. This is where the bulk of my time was spent: first in haphazardly guessing which tags were available, and ultimately in some code to automate finding free tags.

Once I could better analyze tag usage, I switched to another grower license which had many tags available. However, I would soon discover this new licensee was affected by the Rooms issue I ran into earlier. So now I had tags, but no rooms. I tried guessing some room names so I could move product around, but ended up having to ask metrc for a list of room names I could use.

I made a mistake (again) in not reading what should be included in each response. I recorded tags and/or ids as I went, but before I could submit, I had to revisit most of the sections to get other information. For example, some sections require name, date or licensee number. It wasn’t difficult to backfill the data, but would have been more efficient had I captured it right off the bat.

At the end of the evaluation, I had a shiny new tool that lets me check a list of Plant or Package tags and see which are already used. While I’ve built this before (at least for Packages), that was before Bulletin 17, when it was possible to get “allPackages” at once. So I’ve rewritten the tool to work with both types of tags, and to check each individually. This should make life easier during the next evaluation . . . which will likely be for Michigan.

What's the Metrc API good for?

I've been asked repeatedly whether the Metrc API can be used to do various things. It seems reasonable that a "seed to sale" system would provide the ability to track inventory and provide information useful for a number of reporting functions. Unfortunately, I invariably end up being the bearer of bad news.

The Metrc API is a mechanism to report some compliance data to the State. That's it! If you want to use it for anything else, that's your prerogative, but don't be surprised if your project fails. Would you use a screwdriver to drive nails? Cook your Thanksgiving turkey with a bunsen burner? Commute to work on a Big Wheel? You get the idea.

At first glance, you might think the API is poorly designed. Posting data returns a 200, but absolutely nothing else. Fetching data returns only records which have changed in the past 24 hours. The documentation shows a single sample request payload, with no additional information. Terms such as Tag and Label are synonymous, but not interchangeable. Rooms represent an arbitrary area rather than a space which is separated from the rest of the building. And while you can "delete" Items and Strains, you "post" to destroy Plants and Packages.

But if you remember what the API is designed to do, you realize these features are actually benefits. While most API's return at least the identifier of the object created with a "post", this forces your system to hold the response in memory, and then parse it. So, by not returning a payload on success, Metrc is keeping your system light and nimble.

Since you'll need that identifier later, as soon as your "post" completes, you'll need to do a "get" in order to find the new record you've just created. Metrc makes this easier by returning records sorted by "last modified" date, so your record is probably one of the first. Not only does Metrc make it easy to find your new record, by getting the record you can rest assured other threads will now be able to retrieve the record as well. And by limiting the "get" response to only records that have changed in the past 24 hours, your system doesn't have to deal with an abundance of records.

Again, if you decide to use the API for things it was not designed for, you'll end up causing yourself pain. If you want to see all of the Plants or Package a licensee has, you'll need to page through all of the records, again sorted by "last modified" date. Since you only get a 24 hour period for each "get", you'll need to make 30 calls to see anything that's changed in the past month. If the licensee has anything in inventory that hasn't been modified in longer than a month, you'll need to go back farther. If you're trying to get the inventory of a licensee who's been in business for a year, you'll need to make 365 calls, or risk not getting all the relevant data.

The documentation indicates you get records back based on the last modified date. However, there's no information about defaults or what happens if you provide incorrect values. But that's why vendors must be certified! Anyone authorized to use the API must go through training, so the documentation can be more of a "refresher" rather than a "how to" helper. The training also makes things like inconsistent naming, nonintuitive concepts and oddly assembled endpoints a non-issue.

As long as you use the Metrc API for what it's intended to provide, and only what it's intended to provide, you'll be a happy camper. You can think of the Metrc API as a one way door where data goes in. However, once it's in there, don't expect or try to get it back out. You've been warned.

Nevada certification obtained; Open Source library released

Over the past few months, I've had very little time to do any programming that wasn't directly related to my day job. However, with the upcoming holidays, and the Q4 priorities at work coming to completion, I've finally been able to have some fun.

Up until now, I've had no reason to get certified to use the Metrc API anywhere outside of Oregon. 

However, I have some friends in Michigan who are going through the licensing process and want to leverage the API, so I plan on helping them get through certification (whenever training and evaluations are available). Partially to refresh my memory on what's involved in getting certified, partially because one of the local processors I work with has expanded, and partially because I couldn't think of a reason NOT to, I decided to go through testing for Nevada. At the same time, I started the process for California too.

Fortunately, Nevada doesn't require going through training for vendors who have already completed it in other states. California does require it (at least right now). Michigan is still concentrating on getting licensees up and running, so it's unclear on what will be required for third party integrators. I'm sure they'll all require passing the evaluation test, regardless of certification status in other states.

The Nevada evaluation was done in the Colorado sandbox. I ran into some issues with sales endpoints which may have been differences between Nevada and Colorado feature sets, but after contacting Metrc, I was provided with a workaround which let me complete that section. So, now I'm certified in Oregon and Nevada. Besides California and Michigan, I don't really have plans to get certified in other states, but I may change those plans in time.

As I wait for additional testing to be available, I've decided to revisit some of the code I've written for the Cannabis industry and share it. One of the biggest surprises developers discover when first working with the Metrc API is the responses for POST calls. When you create something, you might expect the API to return the newly created object. Or at least the id of the object. But sadly, that's not what you get. A response code of 200 and an "OK" signals success, but doesn't really help you produce a meaningful user experience. So, after posting, you end up having to GET the active objects and fishing for what you just created.

Every vendor has had to reinvent this POST/GET dance, and while they may want to keep theirs tightly guarded, I've decided to share mine. I believe it's the first open source library for the Metrc API. Covering mostly Processor related functionality, I'll build out other parts as time allows. Since it's open source, it's absolutely free for anyone to use, copy, change, sell . . . whatever. Of course, without Metrc API production and user keys it's useless, but licensees and third party integrators can use the project to jump start their own creations.

Being different is making Washington State look bad

Colorado and Washington were first, and each took their own unique paths when developing regulations. When Oregon legalized recreational Marijuana, the program was more like CO than WA. WA just seemed to do things "differently".

When Washington decided to change their CTS (Cannabis Tracking System) from BioTrackTHC, again they decided to ignore what other states were doing. They did not like the idea of requiring specific RFID tags or labels. While I understand not wanting to dictate how licensees run their businesses, I don't understand how you expect to have true traceability if you don't enforce how product is tracked. The first rule of data is: garbage in, garbage out. Instead of telling licensees how to track Cannabis, you leave them to their own devises, which is bound to result in inconsistencies and inaccurate reporting.

The demand to leave tagging an open ended affair forced Franwell to pull their proposal (even though Metrc was originally selected as the CTS replacement). So instead of Metrc, Washington State ended up going with MJFreeway. MJFreeway was the first seed-to-sale tracking system I learned about, but since that time, issues have plagued the company. To top it off, the BioTrackTHC contract has expired, but MJFreeway isn't ready. So now there is no traceability system in Washington State for the time being. I guess inconsistencies and inaccurate data are no big deal . . . especially when you're running with NO data.

Love it or hate it, Metrc is the standard for state traceability systems at the moment. Colorado, Oregon, Alaska, Maryland, Nevada, Michigan . . . and now California . . . the grand price of legalized recreational Marijuana! Sure there's some downside: a user interface that feels like it was built a decade ago, an API with many missing capabilities, RFID tag requirements, and on and on. But the system is relatively stable, and they have experience to not only provide a platform, but to help states build compliance programs with a baseline, workable system.

I feel sorry for all the Washington State licensees who are struggling right now. The state did you no favors by avoiding the need to tag your Marijuana!

Why won't I commit to working in the Cannabis industry?

As I've said, I'm not willing to give up my day job to pursue working in the Cannabis industry full time. During the day, I'm leading the effort to build our "number one priority". Despite a recent wave of coworker departures, crazy aggressive deadlines, ever shifting scope, and conflicting directives, it's an almost impossible goal I feel compelled to win. While it's extremely fulfilling work, it leaves me little time to write code for the Cannabis industry.

Recently, I spent some of that free time to participate in the Metrc API Advisory Group. The group will meet regularly with a goal of making recommendations regarding training, verification and support of API users. A separate group recommends improvements to the overall Metrc system, however the API users were not shy about sharing their desire for API changes. It was reassuring to hear how many others would like the ability to post transfer data, get response data instead of just a 200, access package history, and similar issues I've long said were missing from the API. It was also interesting to meet people who have taken the leap into full time Cannabis software work.

There's a bit of an internal struggle happening in my head. If others are able to write software full time for Marijuana related businesses, why can't I? Is it fear? Is it laziness?

I don't think so. It's that I want to write code. Sure, for my day job I still have to write documentation, design new features, architect systems, train/mentor junior developers, and more, but all of that is centered about building working software. I don't have to worry whether I'm building the right thing, only that I'm building it in the right way. The decisions of what to build, how to market, who to sell it to, and so on, is someone else's problem. They just pay me to deliver "the thing". That's freaking awesome!

Though I've really enjoyed working with Cannabis companies so far, I've come to realize I'm doing a lot more than just building software. I've had no trouble finding people who want solutions, so I haven't had to do any marketing or advertising. And since I don't charge anyone¹, there's no accounting to do. So it would seems all that's left to do is build software.

But that's not the case. Very few businesses I've had contact with have a clear cut idea of what they want built. Those that do generally describe systems which may seem modest, but in reality are massive in scope and complexity. While these are the systems I want to build, the people who can envision these solutions have businesses to run, and can not "drive the bus". That means I'm left to figure out the actual problem they're trying to solve, and discover ways to alleviate the pain in the quickest, lowest effort approach possible. That's a lot of work to do in order to find software to build; especially because there can be non-software solutions which are better suited to solving the problem.

Does this mean I'm going to stop looking for software to write for the Cannabis industry? Heck no! I'm currently building a workflow solution that tracks and analyzes processing activities, both as an inventory control system, and a system to identify opportunities in increase efficiency and decrease waste. Now, instead of trying to design a marketable product, I'm going to build it because it's a fun project that could actually help people run their pot businesses. No promises and no pressure. And no more trying to figure out how I can turn this into something to replace work that I love.

Who knows. Maybe some day I'll run into a Marijuana entrepreneur who has been dreaming of building an ERP or Automation system for Cannabis Processors. Maybe one of the brave souls who have already taken the leap into the industry full time will one day have a position available that suits me. But until then, I'm going to stick with doing full time software development, and spending my free time building software because I like to build software, not because I want to build a business.


¹ though I have accepted a couple of small donations to get a server up and running

Some of the tools I've written to interact with Metrc

As is usually the case, I haven't had nearly as much time as I'd like to write software for the Cannabis industry. Challenges at work have been meaty and sticky enough to require some real thought, which is both a blessing and a curse. It's great to get paid to solve programming puzzles for a living, but that doesn't always leave a lot of gas left over for the really fun stuff.

It's been just over half a year since I got certified to use the Metrc API. In that time, I've found time to write some interesting tools. And since I'm treating my work for Marijuana businesses as a hobby rather than a side hustle, I figured I'd share some information on what I've created up to this point.

While I have a lot of bits and pieces, there are two tools that are complete enough to have some production value. Both of these communicate with Metrc in real time and use Metrc as the only storage mechanism (look Ma, no database!). They're both essentially "pretty wrappers" for data entry tasks that are tedious to do in the Metrc UI. They also serve as examples of how custom forms can be created to expedite and reduce errors while entering compliance data.

The first tool is a Strain and Item Manager. As you might expect, this tool provides the ability to add, update and delete Strains and Items. But it also provides information on relationships between Strains and Items. And it shows inventory of each individual Item.

Upon opening, the licensees Strains are provided in a scrolling selector (which is a little Jquery plugin I put on my github page: https://github.com/toddrun/JqueryScrollSelector). Scrolling to a Strain opens another scroller with all the children Items. Scrolling to an Item opens a table of all the Packages for that Item, including conversions of the total weight into a variety of units of measurement.

The second tool is a Package Manager. The intent is to allow splitting, combining or just repackaging any existing Package. This was originally three separate tools, but I eventually decided to make a single interface for all three activities.

No matter what you want to do with the tool, you'll start with one or more existing Packages. You'll also need one or more unused Packages (which at this point, will just be unused Metrc RFID tag/labels). Upon opening, you're presented with a way to move part or all of one Package into another:

While you'll have to enter the "New Package" Metrc Tag value, the rest of lets you pick from your live Metrc data:

This makes it easy to take part of a Package and put it into another Package. But, what if you want to take three Packages, extract concentrate, and label the new Package of concentrate? Or, what if you want to split the Package into several smaller Packages, like converting the concentrate into batches of brownies? There are handy "+ Add" and "- Minus" buttons for this purpose.

Note the buttons won't let you have multiple Existing Packages AND multiple New Packages at the same time. This is intentional, and is designed to reduce errors. Likewise, until you have the minimum information required, there is no way to submit the form. Of course, once you can submit the form, the data goes directly to Metrc. Compliance done!

Again, these are just a couple of the tools I've put together since getting certified. I make them available for free to any licensee who wants to use them. And this is just the start. I look forward to building much more in the future. But for now . . . back to my real job!