as of 2/18/21 - meeting with steve, brandon, dustin, and john

master cultivation table...

currently using all po tables (purchase_orders, po_invoice_line_items_[?], time_sub_inventory_[?], elements_of_time, time_sub_flags) - big mix with multiple tables

wanting a new master reporting table - even as a double check or cross check

update this table as the process happens

we may need our own trigger, not a db trigger, but a piece of business logic that is visible

they want one source to get all the info from... vs going to tons of differnet places (other tables)

they want to be able to make bulk moves (adjustments, moves, phase changes, deletions, etc.) ... from one spot vs going into all of the sub details to make the same changes

pros and cons of doing this

pros -
make it easier to handle backend coding changes...
load time saving
standardize and simplify - old way was a mix of multiple tables (lots of one-to-many)
make it industry specific vs open and generic
there may be multiple new tables
we've learned alot - let's boil that logic down into what we really need
so much data, we really need to aggregate - displaying toooooooo much data
see less but do more
easier to train and able to get more customers
gen 4 - we already have up to gen 3... that is awesome
clients want the new stuff - fast, easy
if we charge more, we will make more - if we aren't constantly pushing new resources to this
we actively want to build out industry specific skins... even with new tables that are specific to that industry
because this is so complicated, we have an advantage there - customer needs
there is competition on the POS side, we could focus more on this harder or more complicated side of things

cons -
got to have a plan
time to build it - other resources
on the data - is it by plant, by row, by location, by phase, by batch, by rfid, by strain, by ???
minimal maintenance on the old stuff
have to retrain people
cost - time, money, resources
price for the customer will increase
is there a end to what we are seeing? Or is this neverending?
current problems - timeout problems, missing bulk tools (huge numbers), 
metrc - that is a big variable
other parties are having server problems as well
there are lots of 3rd party solutions that we have to play with
state specific requirements and changes - constant
we have to play along with these other regulatory entities
currently, we dip our toes into the cannabis industry but we are not specific to that industry


we have cultivation and production - is there a difference? if so, what?

we want to speed things up. We like what we have but we want it better and better.

value add-on core - 1. transactional core, 2. industry specific, 3. custom, 4. BI level (aggregates), 5. enterprise (multi corp)

we need both things to go faster... transactions and data and the backend reporting side - make a plan and make some decisions

summary from steve - dustin has built some awesome functionality

g1 - simple po's and simple usage
g2 - new look and internal builds
g3 - dustin's magic (pretty sweet)
g4 - bulk tools, aggregation, reporting - speed and fixing the existing challenges

think layers...

Priorities: reporting, aggregation, bulk tools

for the record... no limit on new tables... no limit on new pages... build what you want and/or need

maybe leave all of the details where they are... build a new report that only shows the current plants or current phases, if they need to go back, send them back to the details (where the transaction data lies).

Everything is headed to the BI (business intelligence) level (aka level 4)

it is ok to stack tables on tables - steps up the aggregation prymid