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.