LCB CCRS First Impressions

Yesterday the LCB announced the removal of Akerna/LeafData as a central, real-time, reporting tool for cannabis. It will be replaced by CSV file uploads.

Just gonna riff on some first impressions here...

Nomenclature

It's odd that with this process to revamp their cannabis reporting the agency still holds on to old terms like "Marijuana". They've even stated that they'd be moving away from that to "Cannabis".

Date Fields

We've had some long history with this screw-up in Washington. First, BioTrack only used the integer UNIX-timestamp. When LeafData showed up they required 'm/d/y h:ia' type format, it's USA, it's missing the seconds and there should be no space between the meridian indicator. With these new CSVs the value is now m/d/Y. Has anyone ever heard of ISO 8601 -- I mean, it's only been around since 1988.

But then UpdatedDate is not a date field, it's a 35 character date field. That's likely just a typo -- we've notified them.

CreatedBy

These files now have a CreatedBy requirement, a free-form text field for the name of the user operating on the record. It's maximum is 35 characters. Which is no problem really, who as a name that is longer?

Areas

This stupid idea which is never really used -- and isn't enforced anyway -- has a dedicated file upload. With, of course, only two fields. It's a requirement to upload this before the dependent lot or plant data is uploaded.

A simple work-around is to put everything into a central location called MAIN_SECTION

Variety Data

A dedicated file upload for Strain/Variety data. The documentation says it will reject duplicates. Remember of course there is no way to query the system before hand, so you'll just have to discover duplicates by trial an error.

Oh, and they've added a Strain Type now (something that was not present in Washington before). The permitted values are

Product Type Data

When Washington used BioTrack there was a defined list of Product Types, using integer values. Then LeafData introduced some sorta hericiicial data with type and intermediate_type. But there was no combination type enforcement, so there was all kinds of junk. With CCRS the LCB has, once again, redefined the acceptable product categories and sub-types for reporting.

A frustrating, but predictable outcome is that the documentation provided by the LCB is inconsistent with these terms.

NOTE: we've been keeping a database of Product Types we see from all these different systems.

This process has introduced a new product "Intermediate Product/Concentrate for Inhalation"; previously this was "End Product/Extract for Inhalation". There is currently no definition for "End Product/Concentrate for Inhalation".

CSV Data

We already knew that CSV was a terrible solution so naturally the LCB has doubled down. The CSVs are crafted with special header rows, this is a known anti-pattern (another one!). A naturally, the header rows are not consistent across all the files but, you can see they tried to be.

Data Integrity

Well, CSVs have none so the LCB had to, once again, poorly implement a wheel that everyone else already has operational. Inventory Lot records depend on Area and Variety information to be present in the database. So just remember to upload those CSVs before you upload Inventory records.

B2B Transactions are uploaded by both the sending and receiving party. I'm sure no lot or product data will get mis-matched when folks are manually entering information.