Research and checking into some possible bad data on data 10 for a client. Tons and tons of testing and writing queries against the database. We found 25 records from back in 2022 that had some bad data. Not sure how it got there, but we found it. Bryan is going to email the client and rep to get more information and possible answers. It took a while to find the bad data among hundreds of thousands of records. I have a full page of notes and queries to show our findings if needed.

Meeting with Cory and Shari O. on projects. We went over some yearend documents and forms and progress there. We spent quite a bit of time on some new quotes. One was a revamp on a prior quote. We added in some new requirements and needs for histories for flex attributes. Randomly enough, there were other requests for other hidden history records and reports. Some of our clients want us to watch almost every single place and record histories (some visual to the users and some that are hidden and only seen by administrators). I thought that was very interesting and something that we need to be on top of for fracture and adilas lite.

One of the places that they want us to watch was settings and who turns things on/off (like a gram controller for the shopping cart) and other setting changes. We also went over more requests to tie things to elements of time (like PO's and E/R's). We have some clients that are using elements of time for help with production runs and delivery options. Interesting what people need.

The last quote that we worked on was for a better or more standard report or export for the balance sheet, P&L (income statement), and general chart of accounts (deposit types and expense types and balance sheet types). The requests was for a report that showed each segment in a nice grid like fashion. On some of the existing reports, the values are all there, they are just hyphenated, the request was to break each data piece down and export it in a simplified grid, no other formatting. I think that the end goal is to pull it into Microsoft Excel and do some tweaking of the data and values there. Just guessing.

The last thing that I wanted to say was put in another plug for better aggregated data to help provide some better speed and business intelligence (BI). We have this planned as part of the fracture and adilas lite project, it just takes time and resources to get there. There is a whole project called the adilas value add-on core model where we will be working on these layers over and on top of the transactional core. Just for fun, here is a link with other references to the adilas value add-on core model.

Note form Cory about what the meeting was going to be about: Cannapages has been trying to connect to Leafly through our API. We have opened up two API's for them but they are still having issues. Steve suggested a quick meeting with you to help facilitate this.

Here are my notes from the call, conversation, and meeting:

- They, the Cannapages guys, are super into their own vertical. They had some deep questions about things that are very specific to their industry. We use a very general or generic tool that has lots of dynamics. That works great for our clients as they are able to setup whatever key datapoints that they need. That is not very good if you are trying to standardize things and play with economy of scale (lots of people doing the same thing). There is a need for things to be standardized.

- Lots of talk about setting standards for certain 3rd party solutions and integrations. We can allow our users to set them up or we could automate things and either lead them through a valid setup and/or force them to use certain attributes and flows. If things are more standard, it just helps downstream flow and data transfer and sharing. Basically, a way to get normalized data for a specific integration and/or 3rd party solution.

- Our developers have full access to the whole adilas database. Some of the outside developers have to use API sockets and connections to open up specific endpoints. That is great and all but can be very frustrating, if they don't know which endpoints to use (virtual windows and doors into the data and records). Lots of talk about documentation and ease of use, from an outside developer's point of view.

- What is the best or biggest value for our customers or for the people using it? Some of our customers are real clients and some are outside developers. Keep those different parties in mind when developing. They have different needs.

- There are costs to do industry specific hook-ups. There needs to be a plan, settings, requirements, and set standards per integration. Otherwise, the outside developers feel like they are chasing their tails.

- Making things human readable... Many of our API sockets (backend developer endpoints through the API) are coded to id numbers or techy look-ups. Some of these outside developers really want an easy way to get at the data (plain English vs techy id look-ups). We spent some time talking about building different attribute look-ups based on text or names vs id or control number stuff. That led to talks about requirements, possible mapping options, and making settings that help with setup and automation. Otherwise, there are too many variables.

- This 3rd party needs lots of specific and categorized data (called meta data). We talked a lot about meta publishing data and being able to construct the names and associated data values. We need to put the data in the correct columns and in the correct format (standards). That makes it easier for filtering and matching things. Eventually, things will get parsed or broken up into smaller and smaller parts and pieces. This allows for things to be tagged and flagged as certain things. Once again, getting clear down to the meta data level.

- They gave us a few wish lists for the existing API. Cory took some notes there. Basically, was to standardize things and make it go and flow faster for them.

- I didn't know this, but the Cannapages guys are actually building a standalone side project to help some of our clients. Imagine something like this... a bulk tool that takes raw inventory data from adilas, strips out what they need (for their industry), standardizes it, allows for bulk edits and classifications, and then takes the new data (in bulk) and adds it to their database. They then serve up that modified data to an outside 3rd party that does or has a key industry specific website and data filtration process. I didn't really know what they were doing until this meeting. We are not even as close to industry specific as these guys are. It's basically a 3rd party bulk tool to provide data to another 3rd party. Kinda interesting.

- The last major topic was data and views. We have data (what is needed and recorded) and views (what it looks like) for multiple different parties. We have to have views and data for employee/users, data and views for state compliance agencies, and data and views for outside or normal customers, clients, and patients. That's a lot of different data and possible views (what it looks like). All of that, based off of stored data that got stored and entered into the system. Pretty high requirements.

- Some of the above notes may apply to our future fracture and adilas lite build outs. Whether it is dealing with different views, industry specific skins, normalizing data, and making the API sockets and endpoints easier to use and consume (plain English vs techy id/number stuff). Lots of good lessons being learned by being in the trenches.