Sean and Shari O. were on the morning meeting over GoToMeeting. They were going over clients and who is doing what and what needs are being expressed and acknowledged. They are doing a great job. Shari O. is doing a bunch of client one-on-one help and training. Sean was reporting on a demo from last week. There is a difference between frontend and backend expectations, as far as requirements and system needs and wants. In this case, the frontend guys are the ones doing the daily interactions (primary users or customer facing users) and the backend folks are more managers, accounting, and owners (secondary users or more specific users for certain tasks or internal facing users).

Shari O. and Sean were talking about internal reporting and setting up flex attributes and custom data fields. Along with that, it is hard to enforce specific standards, best practices, and other ways to help normalize the data. The more I watch, from the background, I can see a need for maintenance on data, practices, and training. Maintenance is a huge deal. The end goal is to make it all uniform and be able to get it in, get it out, and make it useful. Actually doing that can be a tricky move.

I was doing emails, listening, and scribbling down some notes. I had to jump off at 9:30 am to join a different meeting. I left and both Sean and Shari O. were still on the meeting.

On a Zoom meeting with Kelly, Cory, Steve and I. We were going over a number of different topics. We started out on expense/receipts and logic on limited expense types per vendor. Kelly was saying that we should only limit things if we know enough information to actually limit things. There was an error where a vendor had been assigned to a single expense type, but then that expense type got made inactive. She couldn't get into the expense/receipt. We had her go to the vendor and remove the limit by expense type value and everything worked fine.

We then switched over to talking about sub inventory and sub inventory attributes (sub attributes). We spent tons of time and I took a bunch of notes. Here are my notes:

- Kelly went through things to find the gaps

- Parents and children are so separate - you have to know what goes where

- She started on the grouped inventory report (just shows counts from the parents).

-- She was hoping that those quantities and costs would be able to show the same values.

-- Investigating and auditing - Going deep

- Cost of sold adjustments - 2 sides on an invoice... one positive and one negative. ICC - internal cost corrections (future project) - cleaning up the dust - bulk tools are needed.

- On big reports, we need to look at the size, and maybe do backend data pulling and then showing data.

- She has to go to the usage on each one to look at what is going on.

- Accurate inventory values - this is a big lift

- She needs an extended cost per - cost * qty = extended. We just show the cost and the quantity, not the extended cost.

- Clients are saying that their reporting is way off.

- Disconnects between PO line items - parents and subs

- She was using Excel pivot tables to get super close details to what we were showing.

- Cost changes, rounding errors, some parents and some subs, negatives, etc.

- In order to find all of the possible problems, you have to get so deep in the usage and details.

- How do you help clients fix items, quantities, costs, and usage, etc.

- When auditing subs... it would really help to show which ones have which costs

- Part status - active and allow sub only - could be both.

- The knowledge level to do an audit.

- Multiple tabs open and pulling data at one time.

- Level of trust... - I could pull more data but is it even what I'm looking for?

- Pagination of the data - say 40 pages - I need it all summed up - with what was what... in/outs, cost changes, etc.

- In Excel, she had to do find and replace, build special comparisons, standardize the data, etc.

- She had to figure out what was off and then go in deeper. Basically, she would love to see the known issues or sub sets of the data. Maybe even comparing things and helping them find the issues.

- Some of the dates... in the past - you can't even fix something - How do you fix it without adjusting things going forward.

- It would be nice if there were alerts, notices, or somehow finding those problem children.

- It becomes so complicated that they skip it. It is very manual on the fully deep audit.

- Locking things down - ice-down dates - being able to lock/hide things. We need this on all of the main players.

- If there is a difference between po line items and subs, we could show the problems... all at once. Similar to the bank balance helper report.

- Read them and weep numbers - too bold

- Our basic user's comprehension is not very deep.

- There is a need for oversight, maintenance, etc.

- Helping all our users to know what the problems are. It seems like it is coming down to known issues and disconnects.

- The cost field is so important... we allow that to be changed. Kelly was saying, the cost runs downhill.

- We talked about the balance sheet homepage and that it should run a number of checks before it does it stuff, and/or we need to let people know that there is a possible problem (or problems).

- Talking about some other check fields (aggregated values) that could be held on the main to show problems, disconnects, or whatever.

- On E/R's and deposits, we allow posting and locking. Most of our PO's and invoices can lock lines, but never get to the posted level.

- We rely so much on PO's. We don't have a ton of control over them.

- People are looking for the easy button - things keep evolving and users are expecting the system to help them along that journey.

- More guardrails

- Huge need for aggregates, counts, sums, averages, maxes, mins, and other values. This is a huge need. Bigger than we can say... We are very good at getting all of the data (transactional level). We need the aggerate levels. We have so much data. We need to get it summed up and other aggerate levels.

- Controls - at all levels

- We have seen users create more issues trying to correct other issues... Tons of cause-and-effect relationships.

- Inventory that goes into the negative. Ideally, this shouldn't happen. If it does, we need to show it.

- Visibility - start here - helping our users see what is going on.

- Parent/child issues - looking for disconnects.

/////////////////////////

Switching over to sub attributes

- Kelly has a client that has sub inventory and existing categories and wants to re-categorize the inventory. Category to category moves, in sub inventory. This totally creates a disconnect.

- People want to consolidate their categories or break things into smaller categories. We didn't know that people would be flipping the categories. That's a higher level of flipping but it has cause and effect drop-down effect.

- Currently, all sub attributes are tracked on (or off of) the column number (not the sort order or name, literally just the column number), not the id number. This can make things go off the rails.

- Is there a quick solution? Personally, I think this is going to take some time.

- One of the biggest problems is - we can't get the reporting out that we are needed. Because of this, they start altering things to solve their need. That can cascade potential problems. They want quick reports, quick exports, etc.

- We need to be able to cross over categories.

- We think that we need a master list for sub templates. In Kelly's words, maybe build above it. Along with that, we may need to build on both sides, build above it (master list) or build below it (custom cross category mapping).

- Build and break - build and break - part of the cycle

- Steve was talking... what about the next version of sub inventory. What would this look like?

- What about bulk tools?

- Kelly's goal was to show the different sides of what we are learning.

- Software has to evolve! What is the next step?

- From Steve - It keeps feeling like our users are wanting the software to go to the AI (artificial intelligence) level.

Steve, Cory, and I stayed on the Zoom session after Kelly left. We were talking about the evolving nature of software and how it seems like it keeps heading towards a form of AI (artificial intelligence). We were talking about developers, projects, and project management stuff. We really want to get that datasource project done (bus to motorcycles or world building project). We spent a lot of time talking about funding. We are pushing as hard as we can, we need some gas money. Big requirements and a tiny budget. It takes time and resources. Our product and our users keep evolving. Project management and quotes with Cory after Steve left.

- It may be good to do a pros and cons analysis of attributes - parent attributes, sub attributes, flex attributes, flex grid tie-ins, and other in-line database extensions. Speed, bulk, capabilities, searchability, show/hide on all or certain templates or views, etc. Where are we headed next or how can we tighten things up to make it even better?

- We first have to get the data into the database. They we have to be able to get it out. Next, what happens if anything changes? We need to think through all aspects of lifecycle of the data.

- We really need a plan - detailed out - commit to it - then really do it.

- More and more of a need for bulk tools (data coming in, data going out, and updating and changing things).

- Charging for what we are doing. We, as a company, are missing out.

- The value of our user/client base as a testing group. We couldn't pay for what they are doing.

- Cory and I were talking about requirements for industry specific software. Expectations of our clients. We have a standard package and then we customize on top of that. It's really tough to do everything, well.

GoToMeeting session with Shari O. and Sean. Going over emails and client communication channels. Hoping to get with Wayne a bit. Shari O. had a quick question about merchant processing and some settings there. Light talk about some wish list stuff.

Reviewing time and scheduling stuff with Bryan. He is working on showing subs of time in a horizontal view. Going over a small list of bugs. Talking about how loose or tight to make things. Talking about flow, drill-downs, options, and search filters. We got into talking about experiments and learning by trial and error. Eventually, we would like to come up with all kinds of scenarios and then check to make sure we are hitting the mark.

Along those lines, we need to keep asking ourselves, what about this and that? The more questions and answers, the better. Also, there is a value of working in the system as a real user, not just a developer. If we are in there enough, we tend to find ways to speed things up and smooth out the corners (user vs just a developer). Good meeting and making progress.

Recording notes from the day (5/15/23).