Sean and Cory joined the morning meeting. Sean was asking about parent attributes and how to use them out in ecommerce. After that, Cory needed a bulk update for units of measure (converting each to grams on a bulk scale). Alan joined the meeting and Cory was going to have him help with some of the backend data updates and data clean-up.

Cory and I were looking into some errors and needs on the merchant processing side of things. Shari O. jumped in and we talked more about standardizing our merchant processing efforts. See elements of time # 9934 for ideas on standardizing merchant processing by using Datacap as a 3rd party solution. We need a more trusted solution and we are not very good at hardware integration stuff. An outside party to handle that would be awesome!

Recording notes from last Thursday and today (3/30-4/3). Emails and going through things.

Met with Aspen to look over her world building presentation. We ended up getting into this little Q and A session and small virtual interview. It was kind of fun. Aspen took a bunch of notes on a Google doc. I won't share all of the info that we covered but I may pull out a few key pieces.

- Settings and speaking the client's language is a huge part of it - where it starts or where they (the client) gets some buy-in. Once you speak their language, they feel more comfortable.

- System configuration - I like this, I don't like that, can I hide this, can I make this show up here or there, etc.

- Using world building concepts in trainings and demos. Once the clients figure it out and catch the vision, they use world building terminology in describing what they are wanting or what they are hoping to achieve. Basically, if you can get the client to start thinking about the bigger picture, it really gets the juices flowing and the ideas rolling in. Virtually get the wheels spinning.

- Keep building what we know and then deal with other ideas and requests as they come. Custom code vs settings and toggle on/off features. A growing blossoming idea farm.

- We have outgrown a number of different models. For example: We started out with 5 different roles for permissions. Things like sales, mangers, accounting, admin, and backend/web. Now we have over 170 individual permissions that may be applied in any configuration vs the five simple roles that we started with. Also, our first round of corp-wide settings was to build out six corp-wide settings. We had to flip the model when we got up to the 400 ish level. We ran out of room. We ended up building vertically (variable/value pairs) and using custom setting objects (JSON objects and linking similar settings). Tons of ways that things have exploded, changed, and evolved over time. It's been a process. The other big challenge is adding in or taking away new stuff without affecting those who are already in there working (existing clients). You almost have to make the system a chameleon that can change its shape and color on the fly.

- Aspen and I talked about the potential of doing a white label approach. Kind of like the Intel chip inside of a computer. It could be branded however, but the chip is what the whole thing rides on. For example: You could have an HP, Dell, or some other brand of laptop but all of them use the Intel chip as the underlying microchip processor. We would like to do something similar. Whatever brand, powered by adilas.biz on the inside. We don't have to be the main company like HP or Dell or whatever. We could easily just help power those brands using our tech and underlying engine.

- Along the lines of a white label - It would take a potential competitor years and years and millions and millions of dollars to do what we can do right now. If they saw the value of a white label option, they would be smart to go in that direction (saving time and money). Just reskin it and start selling it vs building it from the ground up. There is already a market for what we do (based on our current clients and 20 years in the business and millions and millions in revenue - even though we aren't done yet).

- Aspen asked me about a couple of features that we are using right now and how they relate to world building. I mentioned elements of time and the flex grid tie-ins. Both are hugely customizable and fill gaps and needs, out the door. We talked about selling in bulk but tracking individual items, tracking processes of change (dealing with sub locations, sub phases, or steps of a process). One-to-many relationships, custom fields, preset settings, configuration, and being able to limit what is shown (even though behind the scenes it could be very complex). Tons of samples, examples, prototypes, and working models. We have nuts and bolts companies, bike shuttles, ski schools, and tons of other companies that use these pieces. This is just two pieces of the much bigger puzzle.

- Most of our progress is somewhat limited by outside funding, not ideas or needs. We have huge dreams; it just depends on where the funding for that comes from. This whole thing has been build on a garage type budget. We have ideas and projects that sometimes sit for weeks, months, and years before we can get to them. Our list for an MVP (minimal viable product) keeps revolving and growing. If there is funding, it moves to the top of the list. If not, we chip away at it little by little.

- Lots of analogies between our system (the adilas.biz system) and the body. Often, we start out talking about things like arms, legs, feet, etc. As we get deeper, we get into layers, joints, muscles, system, and clear down to the cellular or molecular levels. People keep wanting to be able to control and/or see the next layer, the next layer, etc. We haven't found the end or bottom yet.

- Aspen was asking what is the difference between world building and fracture? I tried to explain that the fracture project is more of list of lessons learned, ways to speed things up, ways of standardizing things, allowing for customized things, show/hide things, toggle on/off certain settings, full control over flow and display, and controlling things at a smaller detailed level. World building is what we are trying to do and/or accomplish (think bigger picture). We use fracture (aka the next generation of the system or application platform) to get to the bigger world building pieces. We talked about Legos and building blocks of different size, shape, and functionality. Sometimes you need to play in bulk (bigger or preset pieces), medium pieces, and super small pieces.

- We got into talking about the iceberg analogy (or ice berg analogy - different spelling) and how if we could have the whole mountain but only show the iceberg, it would sell better than something seeing the whole big mountain. It makes it look too intimidating (showing the whole mountain). The iceberg looks so much more approachable (be able to configure just what you want to see and use). That's where fracture and some of those ideas come in. You could still have the whole mountain (under the surface) but only have to show what is needed or wanted. Put the rest of the engine under the covers (under water) like the Intel chip inside of a computer. It's all perception and expectations.

- Ideas that don't get exposed (out to the public) can sometimes die in a hole. We talked about if a bigger company was pushing some of the world building concepts or data assembly line concepts, they would sell like hotcakes.

- Towards the end of the meeting, we were getting into costs, growth, and projections - numbers, costs, financials, etc. Fun stuff!

Anyways, a great meeting. Aspen has more notes in her Google doc where she was recording things from the small interview. I enjoyed the chat and the learning session. Sometimes you don't know what you have until you start trying to verbalize it. Good stuff!

Steve and I were going over sub inventory attributes. We got into all kinds of attributes. We talked about sub inventory attributes, parent attributes, and flex attributes. Currently, each section or attribute does a specific thing. There is a growing need for more or better sub attributes and parent attributes. Easier to get things into the database for storage and easier to pull the data back out. I mentioned to Steve that we would really like to add a few fields and values to the current sub inventory attributes. They are things like: part category id, app type id, main id (tied to the part_id), and sub inventory attribute id numbers. We have some of those columns but there has not been a project to standardize things yet. It's still on the wish list.

Quite a bit of talk about new corp-specific tables and data storage. Evolution... everything is evolutionary... look and feel, logic, business flow, and even sales (how we sell our products and services). We will keep working on making it easier and easier to use. SG&A costs (selling general and administrative costs) and going clear out to the financials. To the client, it is just data storage. To us, we have to make it all flow and work together as a system. Sometimes that's a challenge.

As recap - for sub inventory attributes or sub attributes:

1. Add the part category id as a look-up value (this would be a new column)
2. Add the main part id as a look-up value (we could use the column called main_id to hold the part_id - it would work perfect)
3. Add in the correct app type id as a look-up value (we already have this column but don't use it for sub inventory attributes - we just need to use it and tie it in better)
4. Add in the associated sub inventory attribute id number as a look-up value (this would either be a new column and/or repurpose an existing column that is not being used in the custom_text, custom_dates, and custom_numerics tables).
5. If we do change things here, we may want to go through these tables and rename fields and values. It was originally created for a specific project and then used over and over again for other semi related projects. Now that we know what it will be used for... we should take the time to future proof it a bit.

If we could add these fields and/or data points into the sub inventory attributes, it would be so much better for getting the data back out of the system. Currently, things are tied to the sub inventory id or sub reference id. We then look that up to figure out the part id and then use the part id to look-up the part category id. It would duplicate a little bit of data but it would make it so much easier to find things and quickly reference things. Currently, we have to join multiple tables and go virtually up and down the chain to find everything that we need. I would recommend that we do a special project, add the above, do some clean-up and then move forward. That would really help. Just my two cents.

Hostek went down a couple of days ago. Wayne was reporting on what was going on. We talked about communication and disaster recovery processes. Who does what and what are steps and responsibilities. We need to more tech support from our hosting companies. We have like 40 servers there at Hostek. Most times they do great. However, if things go wrong and/or bad, we don't get any preferential treatment. We kinda need that.

Anyways, Wayne was doing his own trouble shooting processes and found a few problems. We have a growing need for more documentation for our processes and procedures. We also need to keep some of them super secure. That makes for an interesting mix. There is also a ongoing need for more communications and keeping everybody in the loop that needs to be there.

At some point, we would like to reclaim some of the WordPress stuff on our main site. Sometimes WordPress is a high level target, with tons of plug-ins, themes, and required sequential updates. Once again, we need to get documentation for all of these pieces. The next subject was a statement that everybody needs to give us documentation and architecture layouts. Some people don't like that, don't think like that, and it's worse then torture for them. We have to figure things out and figure out who is going to do what. Everybody has talents, virtues, strengths, and weaknesses. It is tough to require the exact same things from everyone. It will end up being a moving balance.

As a side note, we may end up needing to help certain people do some of those things like documentation, training, and certain communication skills or tasks. There may be a need for a new role to help the devs and get the info out of their heads and into a consumable format. Eventually we have to get documentation on all internal and external dependencies. There is a big difference between knowing what to do and actually doing it. Sometimes we are pushing so hard, it's hard to slow down and virtually clean-up or sweep the floor.

We talked about having a checklist for our developers. We have an old one that Alan and I worked on years ago, but that's all that we have at this point. Some of the developers just can't do the documentation (and sadly, some of them we don't want them to do it). It seems like the next steps are helping to collect and organize the information and documentation. We have some holes that need to be filled. John was commenting that we need to add this into the budgets and project costs. We need to charge more than just the developer's time. Once again, we may be going too fast or running too hard. We are missing a part of the puzzle.

Next, we went into talking about Adobe ColdFusion uptime on hosted platforms. Wayne was reporting to Cory about a survey that he was reading and what it was saying. Cory wanted the guys (Wayne and John) to call and talk with Hostek to see if we could some things changes (service levels and response times). We need to make sure that we have the access and tools that we need. Some of our clients are 24/7 everyday, even holidays.

The new dedicated testing server was the next major topic. We switched over to talking about the data 5 server, capturing documentation, and walking through the project with both Wayne and John. They are working on both training and documentation and so it is taking a bit longer. Making good progress. John has a project that is done that needs to be tested by some outside parties. He and Wayne are setting up and managing the project queue. Cory is helping to coordinate the actual projects and the testing.

Spent some time talking about look and feel and talking about a new version of the internal shopping cart. We know that there is a need there, we are just not sure how deep to jump. We may end up doing things in a couple of rounds. Round one, just look and feel. Round two new settings to toggle on/off certain fields, sections, columns, and features. There may be another round that gets into a smart cart level (deep cart engine logic). In a nutshell, we want to remove things and make it smarter and easier.

We are looking for feedback. Talking about timing on projects, testing, and pushing things all the way until they are live and in production (and fully documented). Shari O. popped in and was asking about insurance and levels of support from Hostek. Sometimes, the lack of support can be a deal breaker. We've seen this even in sales of our system. It's a part of the puzzle that gets overlooked sometimes.

Working on a data clean-up project for a client. Deep in the logic (loops and conditional statements). John contacted me and we jumped on the GoToMeeting session. He and I ended up talking about sanitation of data, testing servers, and turning off all outside API sockets and 3rd party solutions. I showed him how to clean-up and turn off a few outside dependencies for the new testing server.

Back on the data clean-up project. Actually writing the update code. Finished up all but the subs. Came back later and got all of the sub inventory updates done as well. Two different sessions. One from 5:15 pm to 7:00 pm and the other from 8:30 pm to 9:15 pm. Total of 2.5 hours for these two sessions.

Both Sean and Shari O. popped in on the meeting. they have a client meeting a little bit later today. I spent most of the time working on the data clean-up for a client.

Meeting with Eric over the GoToMeeting session. We were doing a review of the Datacap project and how and what we are hoping to gain from that integration. While we were talking, I was doing lots of drawings and good back and forth conversations, ideas, and suggestions. We are hoping to turn this into an adilas sponsored 3rd party solution and 3rd party interaction.

Ideally, there will be no adilas admin users needed to complete and setup the whole 3rd party integration. We want to put it all in the client's hands. We are also hoping that they will take care of the outside hardware and merchant processing services. The other major goal with this integration is full documentation. We have a bunch of other merchant processing integrations finished and done. However, no one really knows much about them and how to set them up and use them. We are hoping to standardize our offerings and make it good and smooth.

Finished up the data clean-up project and ran the file and script live on the data 6 server. Let a few people know about the project status.

Emails and light tech support. Replying to different emails and questions.

Working on the sub inventory availability filters for advanced item searches and data exports.

Working with Bryan on his KPI (key performance indicators) report and dashboard. I answered a few questions and made some suggestions. It's coming along. It still needs a little bit, but making good progress.

More sub inventory stuff for Kelly. Worked on the advanced sub item searches for PO line items. Lots of work and changes to exports to Excel. Pushed up new code and did some testing. Let both Cory and Kelly know about the changes.

Sean reported on a demo from last week. Sounded like it went well and was well attended on our side and on their side. This was one from Mike Roundtree and one of his contacts. After Sean left, I was doing emails and trying to get my local development environment up and running. It was having issues this morning.

Cory and I going over projects and quotes. We have a client that wants a few new columns on the advanced PO line item search. We talked about a number of possible options. One was dealing with settings and the other was more involved but what we would really like to do if it was just us deciding. We will pitch it to the client and see what they say. Depending on their interest, we may go either way. If they don't bite, we may put it in the schedule and do what we want to do. Where we want to take it is more of a pick and choose what values and/or columns show up (build your own report) vs just a hardcoded report.

Emails, paying bills, and other small to do list stuff.

Meeting with Bryan to go over a custom dashboard project. We merged things in and then did some testing and light tweaking. It is up live on data 20 and will go live on all other servers tomorrow morning. After that, we switched gears and were looking at his online scheduling stuff. That project has a number of possible variables. Once we get it all nailed down, it will be awesome. Until then, it may be a little bit one-sided or messy (not perfect for all scenarios). We talked about a number of options. We may end up meeting up later today or tomorrow to work more on a more robust plan.

Meeting with John. He was going to help me with my docker images and local development environment. Right before the meeting I was able to make a little bit more progress. It was stalled out and I had rebooted my computer a number of times. John and chatted for a bit and touched base on a few different things. He passed me some docker commands through chat that I saved for later reference. He and Wayne are working on some server documentation and system architecture documents. As I was doing the rebuild, it was taking forever so John bailed out and just said to reach out if I had any problems or questions. I was grateful for his help.

Finished paying bills and then recording notes from the last few days (4/3 from last week).

Recording notes from last week. Did the entries for 4/4 in the developer's notebook.

Bryan checking into the morning meeting with a question or two. We will have to get with him later to get it all figured out. It wasn't a simple fix. Michael and Sean were talking sales and gift card stuff. Cory jumped on and we were talking about scenarios on reports for showing new columns. If we just add them, not all of our clients like that. If we don't add them, other clients want them. You almost can't win.

Our solution will end up being a mix between show/hide checkboxes and saved settings where they could set their own defaults and then still be able to change things on the fly if they want something different. Anyways, we may end up with a mix between normal filters and options and pre-saved settings to help speed things up.

This is our bad, but we have a small lack of communication to our clients. Here's the tricky part, even if we put something out there, they usually don't read it. However, if we do something and don't let them know, they get mad at us as well. Cory and Kelly requested some changes, now we are dealing with the backlash. Some like it, some don't. Sounds like we need more settings.

Shari O. had a question about the adilas phones stuff. We looked at the page and there was some code that tried to show a sub or outside website that was not in a secured SSL (https) site. We made some tweaks and pushed up the code. Kind of a temporary quick fix.

Wayne, John, Cory, Shari O., and I were on the meeting. They were talking about a client and their servers needs. They (our client) may be closing some of their locations down but want to keep other ones active. Light back and forth on whether or not any server specs needed to be changed on that server. There was also a conversation about the need for more tech support. Both on our side and on the server side (the hosting company). Often we don't need help, but when we do, it is kind of painful.

Cory had a list and was checking on different projects. Good dialog and good back and forth. Wayne may be moving on and working less in the next few months. He is wanting to be more of a part time or fully retired. We need to get plans in place to figure out who is going to be taking over that role and what documentation and knowledge needs to be transferred over. We talked briefly about Dustin maybe wanting to help with servers and also looking at existing knowledge levels. Do we want to bring up one of our own guys and/or hire it out to someone else with more knowledge? Great questions.

Wayne was talking about options for virtually building a new ship. This has been a discussion and topic for years. Do we keep building and tweaking what we have or do we rewrite things and try to go all new (code, architecture, design, etc.). There are pros and cons to both approaches. Due to current budgets, we have to stay with fixing what we have vs building all new. That can be painful as well and takes a lot of time. Wayne was talking about doing a sample project and seeing what kind of time it might take to move the existing adilas structure over or under a new standard framework. There are a number of unknowns, but worth looking into.

Towards the end, John and Cory were talking about look and feel stuff. Also, Wayne and John will continue to work on some outlines and plans for the system architecture stuff. Making progress on most fonts. We'll take it!

From Shari O. - Get w/Brandon about the Insurance needed for Privacy liability, Data Breach and Electronic Data Liability - Need to get this into place by this week, so I can put this to rest, and get info to Nevada Compliancy Board; as Adilas renewal of app is pending METRC app for Nevada Compliancy Board until proof of insurance is submitted.

Recap of the meeting - Spent half an hour with Shari O. talking about insurance. We were using the analogy of a baby going naked to wearing a diaper (just being funny). We are ok taking on some more costs to a certain level. If more is needed, we'll have to pass on those costs to our clients. At least those who need the extra coverage. The main conversation was dealing with CGL (commercial general liability) insurance and going over a quote that we got from a company. We decided to go for it based on the quote.

Bryan and I making some changes on the KPI (key performance indicators) dashboard. Small work session. Pushed up some new code and dis some live testing on one of the servers.

Kickoff meeting with Datacap. We will be doing an integration with the DC Direct options for card present and card not present. There will be two different integrations. As part of the meeting, they had a number of key players on the meeting and Eric and I were on from the adilas side. They spent some time going over an onboarding questionnaire (in-take kits) and answering some questions. We are looking for one tool to help standardize things.

Like most merchant processors and gateways, they have a number of different terms and things that they were throwing around (even though Eric and I didn't really know what they were). We are excited to get a good one-to-many integration with multiple hardware devices and multiple standard merchant processing gateways. We already have a number of merchant processing gateways and integrations setup, clear since 2009. We are hoping that this one will be our last one and will help us standardize things into something that is more maintainable and easier to work with.

After the call, Eric and I jumped on a quick phone call to do some follow-up and talk between ourselves after the Datacap folks had left the meeting. We just wanted to make sure that we were both on the same page. Making plans and going over the meeting and conversation. They are going to be getting us a quote for some new testing hardware and the certification/testing stuff.

Emails and recording notes from 4/5/23.

Bryan and I working on some of the new online scheduling. Talking a look at what we have and what else is still needed? Looking for the next logical step. We talked about a number of options and did some drawing and planning.

As a side note, after the meeting, I sent him a few text messages with some ideas about setting up the master time templates, then creating a new element of time that could work or server as a fully filled in sample record (a real element of time using existing manual tools). We could then pull data and values from the sample and hold them in the background. We could then collect the new data or things that need to change and use both the new data (just the things that changed) and the old sample data (old existing record) and make a new record from the mix of the old and new data. Anyways, it seemed like a good idea and possible option. We may expand more on this later.

John and I were going over some new requirements for developers. John wants to create a frontend checklist for the developers. I recommended that he check out our web/API documentation section within adilas. We could use his frontend stuff, tied to what we already have. Just an idea.

Cory joined for a bit and was going over some look and feel stuff with John. Small tweaks that are needed on a newer page. After that John and I were looking at a page for code sign-off. We also talked about setting up a date and time to do some internal adilas developer training. We'd like to get them in there using the adilas docs (style guide and code samples). Along with this new training, we'd like to help get them more accountable and following standard procedures. Without going into it super deep, John wants to build in some internal testing, development, and frontend requirements checkboxes that we could fill out and show who did what with dates and times. Basically, a virtual sign-off for different parts of the code, pages, and features.

Bryan and I spent some time looking at the time templates and using elements of time (that have been filled out) as samples or pre-filled events or entries. Basically, taking the concept of the time templates and expanding on it, actually filling out one element of time with all of the correct values and then using that as the model or basis to create other ones (duplicate, clone, or just slightly modify). We also talked about us controlling some of these pieces. We tend to give tons of freedom to our users, which is good. The hard part is then coding with sooooo many variables. We talked about setting things up for online scheduling and us (we as adilas) controlling it a bit tighter. Then as we get that all stable (a good starting spot) we can add in the other dynamics and possible options. Make the whole thing quicker and more turnkey or ready to use without having to tweak it so much.

Switched gears and pushed up some quick changes on the KPI dashboard (key performance indicators) for a client.

Working with John and pushing up some files temporarily for some live testing on one of the servers. We were having issues with the auto deploy only on certain servers. Texts to both Wayne and Eric on different subjects and follow-up. Recording notes in the system for 4/11/23.

John and Sean were checking in. Steve called in from his phone and had some questions about SG&A costs (sales, general and administrative costs). He is working with Mike on some cool ideas. Basically, they are trying to fold in certain expenses into the mixture. Instead of just strait expenses (say a light bill or something like that), you have to capitalize your expenses into the inventory and then show those expenses over time as things are sold and/or held in inventory. In super general terms, you can't just hang an expense on the P&L (financials) and call it cost of goods sold without doing capitalization and utilization (tie the bigger thing into small measurable pieces). This is only true on/in certain business verticals. Sometimes the other, more simple practice is allowed. If a real accountant was reading this entry, they would be rolling their eyes. I'm just talking my language.

Anyways, we were talking about some possible solutions, ideas, and ways to track those smaller aged variable costs per item or per package. Each item or portion within a package may get a different variable, aged, and cost portion/ratio assigned to it. The whole thing gets pretty deep and complicated. That's where we shine. one-to-many-to-many-to-many (or whatever) relationships. Bring it on.

Talks about capitalized inventory levels, smart reports, daily backend processes (auto and/or manual), certain date ranges, lifespans, terms, flags, tags, and automation. Details, histories, drill-downs, reporting, exports, etc. The whole nine yards. We were talking about how certain inventory (that is aging and/or being stored) may be assigned a higher SG&A cost due to how long we hold it before it gets moved and/or sold. Lots of talk about processes that would allow us to load an item with cost, sell it for that new loaded cost, then repeat. We could do this real-time, forward facing (predicting and assumptions), or running a day behind based on what really happened. Lots of possible options. Anyways, we ended up simplifying it and saying load, sell, load, sell, repeat.

This led us to conversations about having a hopper (holding container), loading the hopper, figuring out when and how each new expense should be disseminated or resolved (dates and aging and ratios per day stuff). Steve wants us to start thinking about it and running scenarios through our minds. We'll re-meet up and have a powwow. I recommended that he and Mike play with the financial flow calculator to play with some ideas. We have two different versions of that tool, one if free and public facing (a little older) and one is internal that has an updated look and feel and few other things. Anyways a great tool for teaching, learning, and running scenarios through it.

Shari O. joined the meeting. She and guys were talking about a live event and things that were needed. She had some suggestions on some pages and verbiage changes for some new pages. I'm super grateful for all of the feedback and suggestions, ideas, and requests we get. No way could we figure this whole thing out on our own. We need a village or a community.

Working on new advanced item search settings. Created a new web page id # and started coding the new settings and defaults. These are new settings for different report layouts and show/hide certain columns and fields. We are also adding a few default fixed filters to help speed things up and take less clicks and/or education.

Another session working on the settings for the advanced parts or advanced item search page. Most of my session was defining the new settings and then going in and wrapping each output column or report column with conditional logic to show/hide each possible report section. Mostly a work session. Pushed up code to my branch.

Recording notes from 4/12 to 4/13 in the developer's notebook.

Sean checked in and was telling me about a demo that he did last Friday. He is getting better at prepping things, making an outline, and even having preset URL (web links) ready as they go through the system (quick way of jumping around without having to navigate and/or fill everything in). That's awesome and good to hear.

After Sean left, I was doing emails and other small to do list tasks.

Meeting with Cory. She was checking on projects. We ended up looking at some corp stats for a client. We found a small discrepancy between two different reports. The numbers were the same, but one report had more information, and it would be nice if both had the same values. One is called the history homepage (more values and drill-down links) and the other is called corp stats (no drill-down links and missing things like customers, log entries, customer media/content, employee/user counts, vendor counts, bank counts, etc.). We might need to build that out a bit.

Cory invited Shari O. in and they were helping me to look the data and figure out what is wanted and needed. I did a small data fix for Cory and a client on the data 8 server. It was running kinda slow. Anyways, we got it all fixed and patched up.

Working on the advanced part/item search layout settings and defaults. Spent time wrapping the show/hide settings with conditional logic for the different reports, exports, and columns (headings and data output). I had to pull down a new local SSL certificate in order to do some testing. I ran into some docker (container and virtual image or virtual server setup). I got with John and we rebuilt some of the docker image stuff. We ran into more problems with my local box. That kinda stopped me for the day. Did a few other tasks but decided to hit it tomorrow.

Sean and Michael were meeting and talking about gift cards, demos, and sales. I was cascading updates and settings to other servers. John jumped in and helped me with the Herbo server and with my local docker image stuff. The Herbo server just needed to be restarted (Adobe ColdFusion services). We kept running into problems with the docker image stuff. Some of it would run great and other parts would fail or not work correctly. Wayne jumped in and helped me out as well. No major success before the server meeting started (the next meeting).

We started out in the server meeting talking about an outage we had last week at the hosting level (upstream of us). We talked about what to do about an outage and getting and SOP (standard operating procedure) or process in place for what to do on a disaster recovery type level. Cory was checking on different projects.

Wayne is looking into ColdBox as a ColdFusion framework. We talked quite a bit about his findings and progress. After that, we were figuring out what is next for the data 5 testing server. We've had a few projects that get almost all the way done and then sort of get lost in the sign-off and testing phases. It could be data, time, scenarios, settings, or just not watching it all the way through. That code isn't gone, it's just sort of stalled out or in limbo land. Cory and John were making plans to do some testing on a project.

They were looking at a server and why it is running slow. We need more info from the client as to what they are doing (process or procedures). We really need to know what corp, what page, what time of day, and what process they are doing. Just saying that the server was slow doesn't help us out very much. Once we finished this up, Cory bailed out and left just Wayne and John and I on the meeting to work on my local development environment (docker images, git stuff, and database code).

Both Wayne and John were watching my screen and trying to help me figure out what was going on. We repulled down code, rebuilt images, and did whatever updates we could think about. Tons of command line stuff. I'm not very good at that (hardcore IT and tech stuff). They were very kind to help me for hours and hours. As we worked, we were having some side conversations about different things. Here are some of my notes.

- Aspects, events, announcing (broadcasting states and status), listening for events and announcements, virtual queues, and event handlers.

- We talked about resource collections, private resource collections, and virtual session management options.

- Standards and consistencies across platforms and development environments

- Different modules for security, validation, etc.

- Form validators and bulk issue finding

- The power of mixing rules and assignments

- Virtual flash memory and managing containers for memory objects (just in time memory allocations and storage).

- Thinking in both layers and levels - for almost everything

- Writing less code using a framework

- If we went with a new framework, we would need both training and deeper education.

- We talked about having both commercial products as well as open source products. Mixing the two types together. Some people will buy the commercial product and then contribute to the open source product. Or the other way around - open source to commercial.

- Packages, extensions, modules - making complex decisions

- Looking at clustering options - comparing Lucee and Adobe ColdFusion - including options for clustering and licensing requirements. Adobe ColdFusion is really nice, but you can lose your shorts on the clustering options and prices. It can get painful in the pocketbook (costs).

- If we make some changes, we would have to change our pricing models. If a client or customer wants more dynamic resources, they have to pay for it. The price would based off of usage vs just a fixed or static price.

- We talked about paying for support - both what we offer and what we are requesting from other vendors and web hosts.

- Talking about ways to give back to open source models and projects - help with bug fixes, donations, and keep pushing their product forward. We spent a little bit of time talking about other ways to help businesses and products that we like and want to support. Just conversations at this point but rolling a few things around.

Wayne had to leave (dinner time where he was at) and just John and I kept going. Wayne checked back in a few time but to no avail. We couldn't get my local environment fully back up. Wayne is going to do some testing on his side and we'll hit it again tomorrow. While we were waiting for things to download and install, John and I were talking about computers and different specs. I may need to upgrade my local computer. It's kinda small for what I use it for (spec wise and hardware wise - RAM, motherboard, chips/cores, hard drive, and processor speed).

Bryan and I going over progress on the online scheduling for rentals. We talked about being able to setup a default template. We went over pros and cons of either a manual path or full automation. I sent him a small list of things that will help get us across the finish line. Our goal right now is just to create an MVP and then circle back around and expand the options, settings, and functionality.

Small data fix for Kelly on data 34. Had to fix some sub inventory attributes for a PO that had been voided but had sub inventory on it. We did some back and forth via text message and we got it all figured out.

After that Cory had me look at a custom PO label that needed to be fixed/tweaked for a client. The barcode was missing a small piece and thus not scanning the number that we wanted for the sub inventory package. The number was right, it was just missing the "~" for the sub package or sub id number. For example: Say it was sub id ~34, the barcode was only scanning as 34. On the phone with Cory, made the small fix, and pushed up new code. Also sent the update to John and Steve to push into master. My local box is still kinda broken.

Recording notes from today and yesterday (4/17 and 4/18).

Sean was on the morning meeting. He was using ChatGPT to get some bullet points for adilas as an all-inclusive ERP system. Interesting use of AI (artificial intelligence). Here is what it came up with...

Here are some possible bullet points for an all-in-one ERP system called Adilas:

• Comprehensive Functionality: Adilas offers a wide range of features to support businesses of all sizes and industries, including accounting, inventory management, sales, purchasing, payroll, time tracking, project management, and more.

• Cloud-based Solution: Adilas is a fully cloud-based ERP system, which means that users can access it from anywhere with an internet connection. This makes it easy to collaborate with team members, work remotely, and manage multiple locations.

• Customizable Interface: Adilas provides a highly customizable interface, allowing users to tailor the system to their specific needs and preferences. This includes the ability to create custom fields, labels, reports, and workflows.

• Mobile Accessibility: Adilas is designed to be mobile-friendly, with a responsive design that adapts to different screen sizes. This makes it easy to use on smartphones and tablets, enabling on-the-go access to critical business data.

• Robust Security: Adilas takes security seriously, offering multiple layers of protection to safeguard user data. This includes role-based access controls, encrypted data transmission, and regular security updates.

• Affordable Pricing: Adilas is priced competitively, with affordable subscription plans that scale with the size and complexity of the business. There are no setup fees, and users can choose to pay monthly or annually.

• Excellent Support: Adilas provides comprehensive support to its users, including online documentation, video tutorials, live chat, phone support, and email support. This ensures that users have the resources they need to get the most out of the system.

Kinda fun... Anyways, he will tweak it and make it our own, but that's what the chatbot came up with.

------------------

Wayne joined the meeting and he and I were working on my local machine and box. Somehow my development environment got all messed up. We took things up, down, up, and back down. Trying this and that, rebuilding images, cloning things, etc. We even tried reverting back to an older image to see if that would work. Still had issues. I may need to get a new laptop or computer.

After about 2.5 hours of playing around, I decided to go back to the old non docker image way of doing the local development environment. This includes standalone installations of Adobe ColdFusion, MySQL databases, and other pieces. I was making progress and then got stuck, having to run ton of database updates to get the database up to speed. Ended up stopping and bailing out for lunch. Too much to do all in one sitting.

Running database updates to make sure that my local environment is up and ready to go. Doing updates clear back from 2014 to current. Lots of clicking and checking things. Working through some small bugs and small issues. Ended up running into some setting errors. All of this was just on my local box, all of the production servers are up and doing great.

I joined the morning meeting and Wayne, John, and Sean were on the meeting. Apparently, there was a hack attempt on the data 3 server. Wayne was watching things and putting up blockades. We talked about sanitizing certain variables and keeping things tight (checking for certain mal or bad values). Both Wayne and John were on it.

Wayne was helping me make a few changes to my local computer. Eric popped in and had some questions on vendor stuff. Steve called and I chatted with him on the phone for a bit. Mike wants to meet and talk about SG&A costs and how to virtually load and sell some of those costs as inventory items (moving capitalized expenses into inventory). Anyways, we chatted briefly about that and then jumped on a different meeting.

On a Zoom meeting with Steve, Mike, Sean, and Jen going over SG&A costs (sales, general and administrative costs). I was taking some notes while listening to the guys talk about things. Steve had me show my screen and we did some drawing and discussing of possible options. We ended up going over some small scenarios and what not. Here are some of my notes:

Load and sell – SG&A

- Hang it – relationship – what is hanging on what?

- Expense over date range – say over 30 days or whatever

- Expense by percentage – say 5% per day or whatever

- Expense on one time event – everything hits right now

- Lifecyle events – everything starts, lives (whatever that is), and then everything dies

- Variable – some items will have SG&A and some will not – this needs to be a switch and/or a manual

- Selling it and grabbing all of the hangers

- Roots and branches – backwards and forwards

- Two channels – normal inventory channel and the SG&A channel

- Making a plan and road map – beat it up on paper/presentation level first before we go to code.

- Some expenses are forward facing or rear facing (we get billed for things that will happen or things that have already happened).

- The inbound hopper will be a moving, flowing, entity – once again think lifecycle

- Allocating the SG&A – there may be some that is attached and some of that may be unattached

- Ever second the balance sheet needs to be in balance.

- What do you want... ??? we need some scenarios – bring inventory in, what are the costs, what happens over time, what are the relationships and hanger values?

- Inventory comes in through PO's. We are thinking of maybe using a special E/R (expense/receipt) to handle the SG&A as the second channel.

- Steve was proposing a possible new inbound tool to help with those costs, capitalization, and flow of the data.

- Based on Steve's idea of using the PO and inventory route – we talked about selling x (real inventory) and virtually hanging z (SG&A or other hidden costs) to the same invoice.

- Mike was talking about a possible problem with PO costs and normal E/R costs and mixing them. Steve was talking about putting multiple lines or line items on each expense. Steve was also talking about a quick tool to split things out. Being able to do PO's with inventory and then adding in other costs. We talked about being able to move the AP between the PO or on the expense side. For example: $75 in real inventory and $25 in freight = 2 lines on the expense. One tied to the $75 PO and the other will be for the freight.

Scenarios:

1. 100 items for $10 per : now we have 1,000 in inventory and we owe 1,000

2. Rent for 100 – in 30 days pull it down = 3.33 per day per item divided by 100 items = .33 per on day 1

3. Hopper = 100

4. We talked about dates, calendars, and being able to hang things on different inventory item

5. We didn't really finish... we started drawing and got pulled off on a tangent...

Light brainstorming on ideas and questions for SG&A costs. See notes below:

After the meeting – ideas and questions:

- I think that we need to be one day after the fact. That way we know how much there is to distribute and how much was sold. We could work with real fixed numbers. If you try to do the whole thing real-time, you may end up with too many variables. If it is allowed, going one day back would help solidify that and/or those values (what was sold, from what category, from what sub package, from what parent, etc.).

- Technically, you could do some of this SG&A stuff right now by using PO's to populate virtual SG&A inventory items (subs would be best to control costs and help each bill get whittled down to nothing). Waiting until the day is done (we have firm sales and values). And then going to each invoice and attaching SG&A items (as many as needed) to each invoice. They would be hidden line items with no price, no tax liability, but just costs and quantities.

- If you used $0 price hidden line items, the inventory levels would be exact, each invoice would carry it's own SG&A costs, you could tweak anything that you want (add or subtract), and it would already show-up in all of the existing reports.

- Question – It would be easier to tie it (SG&A costs) to an invoice vs a single item on an invoice. Is that allowed? Or does it have to be tied to individual items specifically?

- If you had a bulk tool that took yesterdays sales, did the math, showed what the system could do automatically, allow for any tweaks (show local math and JavaScript stuff), and then do it – bulk update all invoices for a certain day. That could be pretty cool.

- I'm curious on the math… how do you get the sums and counts, how do you disperse it, track it, and show the full path and/or pattern of what went where and why?

- I honestly don't know how deep we need to go. It would be awesome if we only had to go to the invoice level. If we have to go to the sub level, we may want to create a new one-to-many off of the sub where we can keep track of the aging and SG&A sub costs that happen over time. Think of each sub package as a place to hold certain values over time. If we get a package in and sell out it really quickly, not much if anything will be there. If we hold on to that same package for a long time, it will have a number of sub entries hung or stuck to it.

----------------

After brainstorming a bit, I got back into some other older projects. On a call with Cory. She needed me to un-void a PO for a client on data 9. We normally don't do that. Working on the advanced part/item search layout settings. Started working on the actual settings page and doing some light testing.

Meeting with Hamid. He was showing me the progress on the business zipper website that he is building (small side project). I gave him the URL for our old site and told him to read the bottom portion that talked about the concepts of the business zipper. Here is the link and some of the text (you have to scroll down to the bottom portion of the page to get to this info).

-------

Older website text

-------

Many people over the years have asked us, what do you guys do? Why do you do that? Where are you trying to go? How long does that take? How can you do such and such and others can't? And what makes you so different? Those are some great questions. The answers vary depending on the time someone is willing to listen. :) This is somewhat of an inside joke, but sometimes we feel like saying "Did you pack a lunch?", meaning it can get pretty deep pretty quick.

To answer plain and simply, we are in the business of tracking people's data. We are a virtual data portal. The word "data" means different things to different people. The word "adilas" also means different things to different people. To some it may be CRM functionality (Customer Relationship Management). To others it might be inventory, sales and POS information (Point Of Sale). To others it might be ERP (Enterprise Resource Planning) or backend office functions. To others; general operations tracking, JIT inventory tracking (Just In Time), manufacturing, online expense tracking, business intelligence (BI), paperless office, document management, a CMS (Content Management System), financial data and reports, paperwork, payroll, timecards, scheduling, etc. Because we say we track "data", we need to be as deep and diverse as the term itself.

Our goal is to help you, as a user or a company, get in, get out, and be happy. Along the way, and depending on what you consider to be data, we try to help show you the whole picture of what is going on. If what we have helps you out, great! If not, that's ok. We enjoy sharing what we have learned. The adilas.biz business platform is a huge integrated tool set that allows you to play in multiple different areas. It is very scaleable and caters to custom settings and different permission levels. Your use of the system, depends on you and your needs.

The words "system" or "platform" denote more than one piece working together in harmony. A full system allows you to do things that others can't do, simply because everything may not be there.

One of our biggest strengths is helping you get your data into the system. Once in, it becomes part of the big picture. Data coming in usually means some form of "operations" or the day-to-day business that happens. We love this and have a strong focus on helping on the operation side of the equation. We try very hard to follow a logical or linear model in helping you to get your data in and out of the system as quickly and easily as possible.

We also offer some great backend office tools and accounting features. If truth be known, the reason we are able to offer you accounting-type features is directly related to how we track your data and help you do your operations. We, at adilas.biz, are actively working on a new and more modern model for accounting as compared to the current, somewhat antiquated, double entry accounting system embraced by most companies. We can run your operations regardless if you use adilas for your accounting needs or not. If you are looking for a traditional credits and debits accounting system, we may not be your product other than for your operational needs. However, if you are willing to try a more modern and nontraditional approach to accounting, you will love what we do and where we are headed. Straight up, it is new and different and we are still pioneering on a daily basis.

Here is a little background on the traditional double entry accounting model that dates back to the fifteenth century (500+ years old). Luca Pacioli, an Italian monk (friar) wrote one of the first math text books called "Summa de Arithmetica". In that book he explained about how the Italian merchants kept track of their sales which we now call "double entry accounting". This guy was a genius and a math wizard for his time. Here is the kicker, this text book came out in 1494. Two years prior to that, Christopher Columbus, in 1492 sailed the ocean blue to show people that the world was round. People were just coming out of the dark ages and entering into the age of the Renaissance. The only way that businesses could track their "data" was in giant notebooks called journals and ledgers. They had large rooms with tons of paper copies and went through different processes of recording, adjusting, and posting their data between the different journals and ledgers. Sound familiar?

Basically, they were trying to track different states and statuses of the data. Some of the processes that they used to track these changes and states of the data were called "debits" (negatives) and "credits" (positives). These debits and credits were added to things called "T Accounts". The different T Accounts made up a bigger thing called the "Chart of Accounts". The Chart of Accounts usually had a numeric value and a name associated with it. This is how they tracked things, on paper and in different notebooks. These Chart of Accounts were then added up and used in financial documents called the "Income Statement" (profit and loss statement or P&L) and the "Balance Sheet". The goal was to make sure that everything got recorded and accounted for. In order to make things balance, they had to do one entry on one side and then a matching entry on the other side of the T Accounts. Thus the term "double entry accounting". This standard has been followed for years and is currently the accepted way to do accounting. As a mater of fact, most computer systems that do some form of accounting, have basically computerized the 500 year old model and added their own little tweaks to the process.

So what makes us so different? Well, we spent the first five years working on operations. The original goal had nothing to do with accounting. The goal was to start tracking inventory and other data. We wanted to be able to quickly view things, pull reports, and even be able to show where that data was or what had happened to it over time. Through a step-by-step approach to solving our own business problems, we stumbled upon a new way of doing accounting. Basically, once we had the operations in place (this is a big key), we just kept asking the question, what happens next? We would then build the system out to that level. As we kept going, the path began to be rolled out and we just kept taking the next logical steps. This process took years and years and was only possible because we kept working at it. Concepts that were only a dream or a wish started to be right in front of us and we simply reached out and grabbed them.

Adilas can virtually track objects and data over time without using the old double entry accounting model. We still simulate some of the pieces of that model, but we do not have any journals, legers, T Accounts, Chart of Accounts, and other standard accounting features that are considered traditional requirements. We don't use the words debit or credit and we try to use as few adjustments as possible. We use technology, good data, flags, dates, checkpoints, approvals, permissions, and business mapping to run things in a linear fashion. Every entry or data object has a life-cycle and we simply track it. We are then able to go back in time and virtually ask the objects or items questions. What's your story? Who created you? Where have you been? Where are you headed? Who are your buddies? Where do you belong? When did you finish? What is your value? And the list goes on. We call it "roll call accounting". At the end of the day, we still produce an Income Statement (profit and loss or P&L) and Balance Sheet. We just arrived there through mapping data and running objects over time.

We are still pioneering and developing steps to the roll call accounting process. We've had a blast creating it and we can't wait to share it with you! Although our accounting system is not completely finished (fully automated to the highest level), we have had many companies happily use it for years. We just keep adding new pieces that make it better and better. Remember, our main goal in providing the adilas.biz system or platform is to help you track your data. Adilas can help you with your operations, accounting, or both. The model is open and flexible.

We invite you to check it out. We would be happy to meet with you in person or give you a live online demo. Give us a call TODAY! Call 719.439.1761 and ask for Steve or email us at sales@adilas.biz.

If you want more information, there is a brief history document of the making of adilas at the bottom of the page. It is a short 6 page read that tells the story of what happened when and who was involved. It has been a wonderful journey thus far and we're still going!

Just for fun, we wanted to list a few of the core concepts if you don't want to read the history document. This is just for fun... :)

When we first started, back in 2001, our original goal was inventory tracking. As things progressed, one of our main goals was to figure out a way to help fill the gap or create a "bridge" between operations and accounting. There seemed to be a very large and visible disconnect between what was happening in the field (operations) and what the final output was (accounting and final numbers). In one of our brainstorming meetings, we came up with the analogy of a "zipper". One side of the zipper was operations and the other side was accounting. Our goal was to start bringing them together one cog at a time, like a zipper being pulled upwards until it came together.

We came up with the theory "track every penny in and track every penny out". With this thought in mind, we started to track each penny from start to finish. What we found was that every transaction had a life-cycle that it went through. We decided to enter the items and data as easily as possible on the operations side and then track it through a number of steps until it found itself finished or completed. Along the way, we started time-stamping each step with a flag and a date. Each flag and date combo became what we called a "checkpoint". As each new flag was added, we would lock the prior steps below that based on permissions.

This process of passing data from checkpoint to checkpoint, based on permissions, is how we track your data. A great analogy of this process is if you imagine what it takes for water to turn into ice. This process doesn't happen all at once, it needs to go through different phases, states, or status levels. As your data passes through these different phases, called checkpoints, we simply help you flag and date the data as it runs over time. Just like the ice analogy, the water droplets are very loose at first "operations" and slowly become crystals, then slush, and finally become completely frozen or ice "final numbers and accounting".

We then use a process called "roll call accounting" to virtually map backwards in time to where the data was at a given date or time. Another synonymous term for roll call accounting is data mapping. The reason we use the term roll call accounting is because that is what we ask the computer to do. Imagine data that is flagged and dated as it goes through certain checkpoints. Pretend that the computer is an army General giving out a roll call or a flag/status report. The computer says, "I need all of the invoices that were not fully paid at such and such a date to step forward". Only these invoices would then be counted - based on flags and dates. You could then use the computer to do the math and give you the totals you need. Each time you want more information, you simply tell the computer what criteria to use for the roll call and eventually it will tell you the story of what is going on.

To sum things up "literally", by keeping track of your normal day-to-day operations, we can get very complex results like aging, histories, usage, reports, final numbers, and accounting. Thus the accounting becomes the date sensitive sum of the details. These values are what make up your "Business Intelligence (BI)" or "Big Data" concepts. It all comes back to managing and tracking your data. Because every piece of the puzzle still exists in the database, you are able to virtually go back in time and see what was where and when it moved out of each checkpoint. If the data is correct, let it flow. If a modification is needed, make the correction, lock it down, and let it keep flowing. The accounting becomes more of a check and stamp of approval rather than entering numbers from different journals or locations. When you put it all together, what do you know... All Data Is Live And Searchable.

Emails and light tech support. Spent lots of time working on the new advanced item search layout settings. Working on the actual layout page and lots of checkboxes to show/hide certain columns. Finished up the first round and pushed up new code.

Spent the morning with Steve brainstorming on SG&A costs (sales, general and administrative costs - ways of accounting for expenses as inventory). We decided to start with hidden line items on the invoice level. Playing with the law of deferring to other pieces that have more information. We do that all the time.

Here are some of our notes:

Meeting with Steve

- Mike said that we need to break things down into the smallest pieces (units of 1)

- Steve and I were talking about 5 decimals of accuracy.

- We will need some rounding error buckets.

- Like an item on a shelf, it will collect dust. We just track that dust.

- Vendors, Part Categories, Parent Line Items, Sub Inventory Items, and SG&A costs over time

- Deferring and going back up the chain

- If we go with hidden line items on an invoice. That could get heavy over time.

- We could also just use a whole other table that just references the invoice number. It’s tied to the invoice but not physically hanging on that invoice. Just a sub table that could be traced back to the invoice but doesn’t hurt any other pieces of the existing invoice.

- Folding it in (meaning the costs), and to what level

- Steve and I were talking about some of the math… sales, costs, expenses, etc.

- Steve already has an SG&A homepage. He/we could add some other settings.

- Here is Mike’s formula – monthly sales? Total SG&A? What is still in inventory?

- Steve is thinking about adding in some new settings – maybe total monthly sales, estimated SG&A per month, how many days are you open per month, what is the parent item that we will be adding as a hidden line item? On/off switch for SG&A costs with hidden lines.

- Figure out the fraction or percentage of the total. Use that number.

- There are a number of variables. Eventually, we could pull in that data, but for now, we may want to set some simple fields and fake it a bit.

- We need to build it out and automate it. Add the hidden line item to all invoices behind the scenes. We can’t add SG&A to transfer invoices.

- On adding in subs… we may need some logic to help us roll over between packages.

Cory and I going over different projects. One of the new things that needs to be done is some new code to help with emailing invoices as PDF's. Currently, we send emails with links to web based invoices out in ecommerce. We have a client that has to get their emails as a PDF invoice. Anyways, we talked about needs for that project and being able to automatically email clients who owe us money with the PDF invoice, be able to save it, attach it, and also do a clean-up routine for keeping things tight on the server. We talked about some new settings to make all of that happen.

Along with our conversation, we were talking about being able to do these things asynchronously so that the user doesn't have to wait. Also, as a side note, if we did this, our client would be happy and Shari O. would have an easier time. She does all of our billing stuff.

We flipped over to recipe/builds and a custom report that mixes elements of time, recipe/builds, flex attributes, and inventory planning. We made a small bug fix for the USAePay EMV chip transaction stuff. After that, we spent the rest of our meeting going over custom report requests. It's amazing what people want to search by, group by, and what things they want to mix and blend onto a single report.

As we were talking, Cory had the idea of building a big robust report builder that allowed for all kinds of stuff. Basically, a smorgasbord with options, filters, and such. We then put that power in the hands of our users and let them go at it. In rough terms, it will be let them pick and choose, save it, run it. That would be really cool. We also talked about linking and mapping things internally for sub inventory, kinda like family groups for sub inventory attributes. What are they paired with, how are they related, etc.?

The last subject was dealing with mapping, relationships, groupings, and aggregates. Everybody wants all of the data (details) but they don't want to have to wade through it (sums, counts, maxes, mins, averages, etc.). Those are the aggregates. Everybody wants sales data, inventory, and sub inventory data.

Looking at code with Bryan for rentals. He is making great progress. Small tweaks to the layout and the logic. He is going to get with John for a little help. We should be ready for code review in the next couple of days.

More work on the SG&A costs. Brainstorming on adding them (the costs) into invoices on the fly. I printed things, read over notes, and did some planning. Reviewing emails and documenting flow and samples that Mike sent over to me. Working on paper and scratch paper to get ideas and flow. I want to nail it down on paper before we go to code. Emails and texts with Sean and Steve.

Both John and Sean were on the morning meeting. It was pretty quiet for the first little bit. Then Cory joined and had a few tasks that needed to be completed. Alan joined and they were working on some branch stuff and making sure things were merged into the correct branches. We have some server that are tracking different branches. Most of the meeting was Sean and Alan working on some changes. Alan will get all of that merged into the master branch.

Wayne, John, Cory, and I on the server meeting. Talking about tech support at our hosting company. Wayne gave John some more permissions in the hosting environment. Wayne is working on a side project in ColdBox and testing out a new ColdFusion specific framework. We talked about doing upgrades and upgrading from some of our older code. Ideally, we are moving more to an MVC framework (model, view, controller) with tons of new options. Currently, we are mixing code with some older libraries and dependencies. Our goal is going to be making fully independent pages and pieces.

Constant process of upgrading our stuff. Conversation about upgrading and what technologies we are using. Are we upgrading with older tech or with the newer more modern tech. We are trying to plan for our future clients. Wayne and John were going over options for switching databases. After that, Cory and John were going over data layouts and small requests. They spent some time talking about different projects. Cory and I did some checking on some custom reports and additional requests for more data and more settings.

Recording notes from the end of last week (4/19 - 4/21).

GoToMeeting brainstorming session with Steve to go over ideas and concepts for SG&A costs (sales, general and administrative costs). The whole first hour was talking and going over ideas. We were drawing and going through some fake scenarios. Here are some of my notes:

- Imagine a bucket with a relative fill line partway up the bucket. This would represent the bucket or holding account for SG&A costs that need to be distributed. As new sales happen, we would bleed off that bucket (lower the amount) based on the sales (percentage of average sales per month and what we thought was going to be the average monthly SG&A costs).

- Some of what we are doing would be considered smoke and mirrors. We have some known values and some unknown values. We have to mix and bled both, known and unknown. We also talked about flex and being able to flex at different times (image 1 and 2 how we see flex bubbles or data assembly line concepts).

- We talked about how we move monies for automotive vehicles (managers checkbook) and slush funds. Virtually padding things as needed to help offset costs, basis, and profit.

- We talked about using a fake number as an average and/or a fake burn number. These would be settings for average monthly sales and average monthly SG&A costs. Once we record these as settings, we can then base our math off of those values. If we want to run things harder or faster, we just change those values, which in turn would change the ratios.

- We talked about thinking on an invoice based model not on a daily basis model. That way, each invoice would carry its own weight and only happens as it really happens. For this first round, this was an easier tie-in to make.

- It keeps going, average SG&A and average sales per month. Constant fill and remove, fill and remove of those associated buckets.

- We talked a little bit about time. How many days to drain each tank or bucket? Monthly bills, annually bills, and other time variables.

- Here is the rough formula for our calculations: sg&a cost = invoice sub total * (average monthly SG&A costs / average monthly sales)

- Don't let SG&A go into the negative. We can't spread out or disperse more than we have available to spread. Adjust the buckets as needed. Being able to control the flow (gas and brakes) based on settings.

- We could show them (our users) the rough averages on the SG&A homepage. We could even do some forecasting or showing a "look ahead" view of what it should play out to look like. We could even show what things would look like under different circumstances and conditions. Almost a snapshot and/or predictive model.

- We will format our data in groups, drill-downs, and details. The goal is to seek the IRS's approval for this technique for tracking SG&A costs.

- Steve and I spent some time talking about systems vs trying to marry together multiple independent software packages. That can be a real nightmare. This topic lead to talks and discussions about systems, normalization of data, and even other outside 3rd party solutions using our data to show reports and statistics.

- Interpellation or Interpolation (not sure on the spelling) - good estimate and/or an educated guess

- Putting a white label over the top of our software. This would allow us to play a more build and supporting role vs the main point of contact and training. We may really want to look into this as we build out fracture (future project). We could be the Intel chip inside the computer or laptop vs being the actual computer (analogy with the Intel chip being inside various different computers and laptops). Being the underlying pieces of the system vs the top level or frontend piece.

- Steve was saying - selling what they want and how they want it - that's how you sell and market things.

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

After talking about SG&A costs for the first hour, Steve and I switched over to talking about our guys, hours, projects, and having our guys record their time and progress. I really enjoy the building and brainstorming part of the puzzle. The management portion is less fun. This has been a small pain in our rear. Too much babysitting. Nobody wants to document what they are doing. Steve and I talked about our burn rate (money wise) going forward and what are plans are. We need to be able to finish up projects in a timely manner. Sometimes all we can do is keep chipping away at it. Some of these things just take time and resources. We know that, but still, it's hard to swallow sometimes. We need to add in some levels of accountability. It's an abundant model and there are lots of players who could play along with us. Lots of options. There are some real challenges to running a software company from a distance. We will keep trying to help our guys and gals finish their projects. Sometimes all we can do is keep pushing forward as we are able. Here we go...

Meeting with Bryan to go over his rental stuff (current project for elements of time out in ecommerce land). First, we pushed up some changes on the KPI (key performance indicators) dashboard page. Bryan and I were going over some CSS stuff in the shop folders and making sure that everything looked in sync and part of a system. He was showing me his to do list for this project. He's getting things done and it's looking better and better. We made some plans to do some more code review tomorrow.

Shari O. and I talking about a bunch of different options. She was saying that she likes to give out virtual "hall passes" to our clients and our developers. They can kinda do whatever they want. However, if there becomes a problem, she can take it back and/or revote the virtual hall pass. I thought that it was kinda funny.

John jumped in and we talked about business and general DevOps (mix between software development and IT backend server stuff). We have a good team but it is a little wild and footloose. John would like to see more structure, responsibility, and defined roles. It can be very frustrating at times. I've seen this as well. Sometimes, I just don't know how to fix it or (the real question is) is that the biggest problem (getting pulled on to other fires)? We talked about competitive wages, challenges of multi-tasking, transitions between projects, wearing tons of different hats (roles), and other remote team issues.

We spent time talking about servers, challenges, and struggles of managing a remote team with a number of different skill levels. Switching to code, we were talking about the differences between building new vs converting the older into the new. We talked about scalability, clustering, and normalizing systems across teams, servers, and management styles. The conversation got into talking about knowledge and scope. Who knows just a little bit, who knows a lot, and who see and deals with the whole picture. There is a huge difference. At some point, we'd love to get rid of some of the older dependencies that have been built in. Progression of things.

There is a huge need for documentation and helping the next guy down the road. Looking out for each other. We flipped over to budgets and salary discussions at the end of the session. We talked pros and cons of hourly vs salary-based pay or systems. Anyways, just going over some goals and what not.

Started out the meeting and John and Cory were talking about the adilas docs and making sure that the adilas style guides and dev checklists were all up to date. That's easier said than done. Things keep evolving and changing. We talked about code review, requirements, sign-off procedures, and merging and pushing up code. Lots of moving pieces. There is a huge need for continuing education and keeping our skills sharp.

Cory and I got into discussion about being able to globally copy users, permissions, and settings from corp to corp (universe or world to world transfers - enterprise level stuff). We can bridge a single user between corporations right now, but all of their permissions and settings have to be setup per corp. We could totally automate that. It just needs to become the goal or a project.

John left and Cory and I started looking over code and reports. We talked about options of bypassing certain prebuilt stop-gaps. Many times, we built in certain stop-gaps to help with flow and dipping into sub routines and sub logic (conditional and nested logic). The last topic of the day was talking pros and cons of showing (show/hide) locations on different inventory exports. That could break things into a one-to-many relationship, depending on how they want to see it, especially for multiple items over multiple locations. Anyways, we went over some options there. Cory took some notes and we may revisit this topic later on. Mostly her notes were dealing with grouping, stacking, or defining output columns - various options.

Code review with Bryan. Going over his code for the first round of online rentals and settings for ecommerce and elements of time. Spent some time going over validation, defaults, and flow. Looking over JavaScript and other code assets. Talked about some small database changes. Getting into the shop and ecommerce pages and flow. Looking over the form and URL variables being passed back and forth.

Working on the SG&A costs settings for the shopping cart. Quick phone call with Alan to go over the logic for auto pulling sub inventory behind the scenes. He had worked on a project for transitional invoices that did some of that sub inventory package manipulation stuff.

John and I were talking about a future internal training event. Talking about examples, hands-on training, frontend code and CSS training, as well as some other house cleaning subjects and topics for the developers. Spent the rest of the time doing emails and recording notes.

Meeting with Bryan to go over more of his rental stuff. I had to call tech support for the email server on the Newtek account. After that, back on with Bryan looking at code. Had to do some back and forth emails and tech support stuff while we were working. Merged and pushed up code. Bryan was doing some live testing.

Emails and then working on the logic for the auto apply SG&A costs to invoices. Figuring out what I need and going through notes, excel documents, and doing some prep work and planning. I had multiple code pages open, and I was strategically pulling bits and pieces from multiple pages. Making some good progress on what is needed for SG&A costs. It feels like about halfway through the code for this part of the puzzle (at least for our first-round level).

Working on the SG&A costs - round one. Working on the submit cart logic for attaching hidden line items. The SG&A costs are converted from cart data into an invoice. Finished up the first round of coding. Pushed up new code and sent out a small email to certain key players.