There were a bunch of guys on this morning with Steve when I got on the meeting. They were chatting and helping each other out with questions and responses. Good stuff. Eventually, Eric, Steve, and I were the only ones left on the meeting. We spent the rest of the meeting talking about sub attributes for customers and how that would look. Lots of talk about real in-line database extensions and how those might be able to play in to the mix.

For a current project, we pitched and threw around 3 different proposals. Option 1 was to leave the core customers table alone and add a new wholesale customers table with options and settings. Option 2 was to expand the main core customers table with some new columns to hold the data. Option 3 was to build out "flex attributes" (aka real in-line database extensions for customers. This would allow our users to add whatever fields they needed to customer with specific data types (text, drop-downs, numerics, decimals, or dates). Great conversation.

Eric, Steve, and I spent a bunch of time writing down ideas, notes, and drawing diagrams of how things would look and/or function. I will attached our notes from the meeting, but the main thing was dealing with how to create a super generic table to hold the sub or flex attributes for customers, PO's, invoices, expense/receipts, elements of time, users, vendor, stock/units, etc. All of the 12 main system players.

Lots of talks about core values vs the new dynamic flex attributes. We also talked about auto creation, auto setup, and mapping to help make these new values work. Exciting stuff.

Both Eric and Wayne popped in. The main topic was going to be going over a new feature called flex attributes (similar to sub inventory or parent attributes, but for all of the main 12 players inside of adilas). However, we started in and both Wayne and Eric were pushing us to go in a more normal, standard, or data normalization type approach. We still may end up coming back to the flex attributes, but for this project, we can do it without getting super deep into the flex attributes and full on in-line database extensions.

Very interesting... there is a progression of how things get developed and how things progress. Some of the guys are trying to help us take smaller bites and bring quick value that gets finished quicker and allows for frequent deliveries that build on the prior pieces. Sometimes we dive deep and take everybody else with us.

Bryan and I met for awhile. Then we brought in Steve to help us make some decisions. Eventually, we want to get things (inside the system) to allow for what we are calling flex attributes (real in-line database extensions) for each of the 12 main player groups. We really want that, but it is still down the road a bit.

Currently, we are using special flex grid fields and columns to get people going with minimal effort on certain projects. We also talked about single one-off type projects, custom black box code, and moving solutions into a more global or custom code on a bigger scale. Each one has its place and respective challenges. Having said that... there is a huge difference between doing custom code for a single client and taking that code out to a bigger audience and doing it for mass production. Often they have different approaches and can be tricky at times.

Going over projects with Bryan. He is working on two projects, somewhat related, but slightly different. One is the show on the web version for the dynamic customer field name settings. The settings are used internal to the system for the normal add/edit customer pages. Basically, the user gets to say show/hide, rename, sort, require, and add any custom verbage and/or instructions. Well, it turns out that they, our users, want the same things to be populated clear out to the web/shop (ecommerce) interface. This subject/project is extending those settings out to the ecommerce or customer facing pages.

Along with the new show on the web settings for the customer field names and defaults, we also need to setup some new defaults for the show/hide on the web portion. If we just add a new table column or field, it doesn't know how to play. We have to go backwards and update all of the pieces that have already gone under the bridge (older data and settings) in order to show every field out in the shop or ecommerce realm.

The other project that Bryan is getting ready to work on is called flex attributes. I sent him a couple of links to help him look up some more info on the subjects. Here are the two research links that I sent him.

Research dealing with flex attributes and research dealing with real in-line database extensions.

Bryan and I met and went over the flex attributes project. He recorded a few different segments. We talked about what we have already got by way of other applications that have similar concepts. We also went over some planning and details. Here are some random notes - no particular order.

- Flex grid tie-ins already have 30 custom fields. They are already built out to play with and handle all 12 main application player groups. Flex grid is pretty cool but it lacks data types and it has grown to be pretty large. All of the custom fields are text or varchar characters vs real data types.

- We are looking for a cross and a hybrid between the power of the flex grid, the dynamics of sub inventory attributes, and make these new real in-line database extensions play throughout the entire application. Cool concept.

- Here are some pages that already have similar type code - places where we could harvest some ideas and code: All of these are in the top_secret/secure folder.
-- sub_inventory_template_home.cfm - Lists out all of the sub inventory attributes per part category. We would want to do something similar but for all 12 main player groups.
-- sub_inventory_templates.cfm - Add/edit page that deals with sub inventory attributes. Our would be for all 12 main player groups.
-- add_edit_flex_titles.cfm - This page lists all 12 main player groups, uses settings and custom naming, and also checks for permissions. We would love to mix this page with the lists from the sub_inventory_template_home.cfm page. Nice hybrid.
-- edit_sub_part.cfm - This page dynamically builds form fields for sub inventory attributes. Eventually, we will need something similar for all 12 main player groups.
-- sub_inventory_view.cfm - This page dynamically shows any extras or sub inventory attributes without the edit capability options.

- Existing tables to look at are: sub_inventory_attributes, app_types, custom_text, custom_numerics, custom_dates, custom_json, parent_attributes.

- As we were talking... we are thinking of a couple new tables... just ideas. One would be called flex_attributes and the other would be called flex_attribute_data - the data table would allow for text, numeric, and date values. Somewhat of a combo table as compared to custom_text, custom_numerics, and custom_dates tables.

- We asked some questions... shared tables or corp-specific tables? Auto populate and build or just in time? New tables vs old tables (add or modify existing)? Think of the number of servers, number of corps per servers, developer instances, etc. All of these deal with scope, maxes, mins, pros, and cons. Design decisions. As a fun side note, I challenged Bryan to spend a couple of hours and plan things out. I also challenged him to use Excel (spreadsheets) and do some mock-up data and get a feel for things that way before any code is written.

- We also talked about the database field settings project vs these real in-line database extensions and flex attributes project. The database fields settings is somewhat similar in the fact that you get to name, sort, add descriptions, create your own aliases, show/hide things, etc. The main difference is, the database field settings are already tied to real live database columns and fields. For example: Say in customer you have a field called terms. You could rename it, require it, and then search it. Even though you did all of that, the database still calls it "terms" as the actual field name. The real in-line database extensions or flex attributes creates a brand new field and gives it an id number. No matter what you call it, all of the new data is tied to that id number with whatever you want to call it. If you want to kill it, you can. It is not really part of the original table. Anyways, we went through some small differences between those projects.

- Lots of drawing and building out samples. One of the topics was special dev flags or special fields just for developers to use - (dev = developer). We talked about how dynamic this table will end up being. We may want to build in some special fields that allow us to flag and tag the data as needed. Basically, thinking beyond our current project to where it will be going.

All in all, a great session. I'm excited to see what Bryan comes up with. As a small side note, we may need to provide an instructions field for flex attributes, we may also need a flag to show/hide on the web. Very similar to the database field settings. I hope we keep building and learning from our current prototypes and experiments. That makes it fun.

Work session with Bryan. We spent quite a bit of time going over the flex attributes project. We were doing some planning, scenarios, research, and discovery type things. We ended up talking a lot about the concept of try storming and being willing to circle back around. The flex attributes project is a cross between four different projects. It has takes us quite a while to get to this point. We are mixing and blending flex grid tie-ins, sub inventory attributes, parent attributes, and custom field names and defaults. When you mix all 4 of those older projects, you get flex attributes. These are what we are doing and going to use for the real in-line database extensions and options. Pretty cool. This is a big project and may take some iterations and looping (on purpose circling back around) to get it done.

Bryan did record some of the meeting and he made some notes dealing with datatypes and other requirements.

Progress is being made on the flex attributes project. Bryan is following the flow from sub inventory attributes for the new flex attributes. The flex attributes will end up being new database columns for all of the 12 main players. It is currently just in prototype mode but looking good (for its level). Bryan and I went over his existing progress and did a light critique. I authorized him to spend another 10 hours and see where we end up.

Working with Bryan on the Hypur ecommerce payment stuff. We already have a form of this custom payment type inside the main system. This one is on the outside and integrated into the ecommerce processes. Going through code and making small tweaks. Light talk about flex attributes and flex extensions (another project that Bryan is on).

Bryan and I worked on flex attributes and lots of dynamic formatting. Today we were working on standalone dates, date/time stamps, decimals, and integers. All of this was based off of findings and assumptions. Basically a lot of if statements to help dynamically format things according to what the user entered or didn't enter. His flex attribute project is going well. As part of our meeting, he wanted to know where the cutoff line was (this project could be huge...). We set some basic requirements and decided that the rest of the wish list could come later. We may need to touch base with the client, but things are looking good. We will for sure have to circle back around, but a great start.

Working with Bryan on the flex attributes project. Reviewing code, cleaning up comments and code from a past copy and paste action (adapted from previous code but not really cleaned up - tight).  Linking to new pages and building in navigation. Other small clean-ups and organization stuff.

Emails and coordinating meetings and action items with the Bear 100 folks. Research on PDF's and merge options.

Meet with Cory and Steve at 2 pm - Going over a project review of flex attributes and where it is heading. We also talked about the use of templates at different levels. If we could setup templates (at different levels) we could really speed things up. Once again, standardizing data inputs and data outputs. Some of the topics were dealing with master catalogs or lists that could help standardize the data that is available. Make it simple, make it standard, and then use it over and over again. The old build once, use many concept.

Some of this stuff, master lists and master catalogs, enterprise or aggregate level systems, are really important as soon as you have multiple locations or multiple systems. If not, it might be cool, but not as required or as needed. Our model keeps going out into more of the medium sized businesses vs the just the mom and pops. We are seeing a pull for this sized businesses and what they are needing. Interesting.

Bryan and I spent some time going over flex attributes. We were reviewing code and working through some formatting and logic flow. We made a small list of things that are still needed, but we are getting close to launching this first round of stuff.

Working with Bryan and doing some clean-up on the flex attribute project. We ended up doing some rewriting of the create database code and small formatting tweaks. We added some indexes and other small database field size changes.

Bryan joined the meeting to help me push the flex attributes project. Steve, Cory, and I were still in our other meeting. So, Bryan left and we ended up talking on the phone for a bit.

Steve, Cory, and I were talking about scheduling and billing for direct time that clients need for deeper support or training needs. Not quick questions, but more in-depth stuff. We are getting booked out there a ways and some of the smaller time blocks are used up by normal day to day stuff. People still need help, but it is getting harder to just fit them in. We need to schedule them and bill for that time. Once again, this is for things just beyond a simple text, email, or quick question. We have to keep coving ourselves.

Bryan circled back around and helped me launch round one of the flex attributes. It is only tied out to customers right now, but that is the first round of what we have done. The new code was pushed up to all servers.

As we keep going, eventually, we want to expose and release flex attributes for all of the main 12 players inside of the system. Some of the main 12 players are things like: customers, invoices, deposits, expense/receipts, vendor, users, parts and general inventory items, stock/units, quotes, elements of time, balance sheet items, and PO's. Exciting. This is part of a bigger project called real in-line database extensions. Step one is up and live as of today.

Test and merge new update for the flex attributes from Bryan. Great job. That project is live and being tested by a select group of clients and users. We know it has a lot more that is needed, but it is coming around.

Phone call with Shari O. to go over servers, users, and accounts receivable stuff.

Meeting with Cory to go over projects. We were talking about developers, schedules, updates, and projects. We detailed out a couple of projects dealing with ecommerce. One was for a new setting to show/hide a customer photo gallery in ecommerce. Allowing customers to upload their own documents and pictures. The other one was dealing with flex attributes and being able show and use those new customer flex attributes out in ecommerce (in-line database extensions). It is fun to see how each section gets built, and then a little bit later on, it gets refined and added to. It just keeps going. Constant refinements and progress.

Work session with Bryan. We covered two different projects. One was dealing with using parent attributes in custom labels and the other was dealing with expo e-checks  and allowing for editing payments. We merged some code and pushed it up to all servers.

Merged and did some code review with Bryan on the flex attributes out on the web for customers and client profiles.

Working with Bryan on flex attributes on the web and through ecommerce. These are custom (special database fields that are needed and added on a per corporation level) fields that get setup to collect extra or special data. You define them, name them, setup the defaults, require yes/no, and even build drop-down lists if needed. Unlimited custom fields. They only exist for customers (clients/patients) but we've prepped things to allow them to be used for all 12 of the main application players. This is part of the real in-line database extensions project. It is coming into being.

Meeting with Bryan to go over eXPO echecks and payments on expense/receipts. We also looked into a possible bug on the flex attributes. We ended up fixing some of the underlying data.

Cory jumped on and we worked on some ideas on reporting and reports based off of the flex attributes (in-line database extensions). We have them implemented for customers, but need to get deeper into being able to search, pull up reports, export, and being able to filter data and recordsets based off of the new flex attribute values.

We also talked about other projects such as aging payables and adding new layouts to mimic what we do for aged receivables. We got into custom wholesale taxes and being able to switch between normal taxes and certain excise taxes. It gets really complicated. We talked about switches, phases, and more complex tax settings.

The last project that we went over was dealing with bulk tools for ecommerce. Show/hide on the web, long web descriptions, specs, reviews, etc. Currently, most of the web or ecommerce settings, you have to do them one item at a time. We are getting more requests to be able to manage things in bulk on the ecommerce side.

Working with Shari O. on barcodes. Then working with Bryan on planning to make a plan for the flex attribute reporting project. He is working on doing some prep work to help with project management tasks. Plans for making a plan.

Bryan and I were exploring ideas and concepts for doing searches on the flex attributes and flex attribute data. We looked at a number of options. Eventually, we did a small scratch file to show some older but proven ways of doing the dynamic searches. Bryan was coding and I was directing him on what to do. This is one of many possible ways of doing it. Just trying to advance the ball.

We built out a query of a query model with lists, arrays, structures, and custom complex data sets. Playing with possible options. I know how to do it the old way, but we may need to keep looking for faster ways of doing it. Research practice session.

Looking over advanced customer search code with Bryan and trying to add in options for searching and showing customer flex attributes in the advanced search. In deep in the code. Multilevel arrays, loops, conditional logic, etc. It's all there. This is part of a project to get better search options for the flex attributes (in-line database extensions).

Work session with Bryan. We are working on adding in flex attributes to the advanced customer search. Bryan is prepping files and then we are going through things line by line to do some detail work. It gets pretty involved. Making good progress. Today we were outputting all of the flex attribute values per customer record. Next time, we'll get into pre-filtering the main records based off of entered search criteria from the flex attributes.

Advanced customer searches and using flex attributes as search fields and search filters with Bryan. We were checking code, doing tests, and outputting and showing the data. We were going through a number of scenarios and doing some tightening up of the processes. Towards the end, we switched and talked about custom labels and some questions and answers.

Helping Bryan with some Git (code repository) issues. Sometimes, if you get off the track, it is hard to get back on and get everything happy again. Lots of back and forth until everything smooths out.

We did some code review and sign-off on the advanced customer search with flex attributes and flex attribute filters. Currently, they are only for customers, but the stage has been prepped for the other 12 main system players.

Merging in code for Bryan and his advanced customer search with flex attributes. Pushed up the file live on all servers. After that, he and I did some checking on some files on the data 7 server. We just needed to make sure that the auto deploy and auto pull from the master code branch was working. All is well.

Pushing up code with Bryan. We fixed a couple of small errors in the flex attribute searches - minor tweaks. Bryan is going to look deeper tomorrow as we ran out of time. It is getting better, we still have one known issue for flex attribute numeric search filters. We'll get it all figured out.

- Talking about some timeout issues - say all of the items at once, or all sales for the year, or all invoice line items per vendor for a time period

- Captcha images - sort of a pain

- Cloudflare - bouncing bad traffic and dealing with caching issues

- Potential 3rd party API traffic and clogging the pipelines

- Timelines for aggregated totals, sums, counts, averages, totals, etc.

- From adilas, our current aggregated report priorities are: 1) Vendor List, 2) Item List, 3) Customers, 4) Sales Data

- As a note, the lists mentioned above will help with data normalization and flow of the data uphill and downhill

- Using the adilas API sockets to pull all of the data and do their own aggregation type totals - Steve Palmer - has some ideas there

- Steve Berkenkotter chimed in and talked about how we have one client who gets all of the data (certain tables) pushed over to a separate server and then they run their data aggregation from that other outside dedicated server. Set it up and push it out daily.

- Once we get some of the aggregation stuff done, it will automatically start going and flowing into enterprise level settings and reports

- Figuring out other possible workarounds to make it happen - within the specified timelines - being creative and pushing and pulling data as needed

- Routing and being creative on the distribution and delivery options that they are coming up with - once again very creative and using some of their own tech guys to build out the solutions - kudos

- Introducing John M. to the Euflora guys - he is local in Denver and is helping Wayne on the servers. Better access to backend tech contacts.

- Talking about servers, resources, monitoring, specs, etc. - allowing our clients to go in and watch and monitor those servers

- Steve B. was talking about some of the new flex attributes for customers. Also sub invoice types for invoices.

- Steve P. is using the invoice history options to help record special customer meta data and delivery options. Creative!

Meeting with Cory and Steve - Working on a super deep inventory report. Looking at aggregating quantities and counts, mins and maxes, reorder options, parent attributes, sub attributes, flex attributes (new), core values, build your own reports (point and click), save and name your own report, setting pages (defaults), template and builder processes, and in-line database extensions. Lots of fun topics.

We talked a lot about "core" attributes (existing database columns and fields - core attributes).

We also talked about building, using, and deleting small aggregation tables for current part quantities. Great little work session.

Working with Shannon on vision statements and general goals for the next 1 year, 5 years, upto 10 years. See attached for our progress. Here is a list of some of our semi-short term goals that we will be adding to our business plan and vision plan:

Without going into too many details here are some elements that will be included in our plan:

- Keep tweaking on the transactional core

- Move client services more internal to Adilas 

- Expand into other verticals

- Allow for custom code where needed

- Get into aggregated and/or business intelligence (BI) type levels

- Grow the platform into an enterprise level app/system

- Along the way there are plans to do a full re-write under the code name “Fracture”

- Revamp the look and feel - improve user experience 

- Create and facilitate the Adilas Café and community

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

We also talked about using the key word "core" for different starting spots or base level options. This could be core transactional systems, core database columns or fields, core or main pieces. An example may be something like: Using the word or phase core values vs parent attributes, sub attributes, flex attributes, etc. Hopefully that makes sense.

Prepping things and doing some pioneering. All part of the game.

At the end of the meeting, I ended up pushing up some code for Danny and his custom labels.

Bryan and I were working on some of the dynamic filters and values for searching customers based on the new flex attributes. The code was already released, a couple of days ago. This was a deeper dive and adding in some more dynamics to help the reports with refining the search and being able to save the custom report settings. Good work session. We pushed the code up at the end of the session.

I've got a project coming up that needs some new settings for elements of time (calendar, scheduling, and events). I woke up this morning and couldn't stop thinking about some ideas for some new settings. I scribbled them down on a 3x5 card (front and back). I was saying a prayer and the ideas kept coming. Kinda fun. Also, the other fun thing was almost being able to see how to do some of these things and the potential that they could unlock. Really fun.

Anyways, here are the ideas. After I got them all scribbled down, I texted Steve to see if he would want to meet for a bit to go over the new settings and ideas. We jumped on a GoToMeeting session and he and I had a good 45 minute chat, with drawings, proposals, pitches, and lots of ideas going back and forth. Good session. Here is an expanded version of some of my little notes and scribbles.

- Dealing with time templates - what if we allowed for a basic mode and an advanced mode? Some people may not want to see all of the pieces. The basic mode would be what currently exits and/or something pared down from that. The new advanced mode would allow for all kinds of other settings, verbage changes, field name aliases, special instructions, sort order (where the fields show up), settings, required options, etc. The time templates page would have a toggle switch to go between the basic mode and the advanced mode. There would also be links directly to the advanced and basic modes from the list of time templates page. Same permission, just a toggle switch between the page modes. As a side note, Chuck recommended that we maybe have a "custom" mode.

- We already do this with customer database field names (allow for field names to be controlled). We want to do the same thing for elements of time. We will use the db_field_settings table to store specific info (field name options) for each time template, if the users wish to. If not, we will use a default set of data stored in the db_field_settings table for basic time_templates. We will use the field called db_table_name to store the value "time_templates" to store the default values assigned to corp 1. Just like the customers stuff. For each time template, we will change the name from "time_templates" to "time_templates_[555]" where the number will be the corp specific time template id number. Tons of sweet options there already. Aliases, defaults, placeholders, build your own drop-downs, required yes/no, max, min, show/hide, sort order, etc. As a side note, we currently let the main time templates handle the show/hide options. Somehow we may need to sync those up and/or figure out which one is the master. For right now, I'm still leaning on the time template being the master and the db_field_settings table holding the naming, aliases, special directions, defaults, etc. I hope that makes sense.

- On the advanced time search page. I would really like to add a master template switch at the top of the page. This would be a drop-down form field that shows all of the time templates. If a time template is selected (or preselected through a URL.template value), at the top, and submitted, then the page would be able to virtually slim down based on the settings, naming, and custom pieces per time template. The current advanced time search has everything plus the kitchen sink. If a template is selected, then the page could only show those pieces that are turned on, the correct naming, the correct filters and search criteria, and hide all unused sub searches as well. The time template settings would also affect the sub time searches and use the correct verbage, info, naming, show/hide, filters, etc. Basically, be able to dynamically convert the advanced time search page into a time template specific search form or page. That would be super cool. Also, if a template is selected, the search results could also translate and show the correct fields, verbage, settings, and make it feel round trip (search, results, and details). Higher in this entry, it is alluded to the fact that we could control the page with a URL value (URL.template) and then we could link to it, store quick buttons, etc. That would be really handy. As a side note, Chuck recommended that we look into a tab or tabs based page for all of the different searches - make it more digestible vs all in-line down the page. We could still have the template switch, but show the different searches in a vertical or horizontal tab display. Great idea.

- On the sub flags and tags, we need some more template settings. You can turn 5 different sections on with this sub (one of the bigger subs). A section within the sub tags and flags, was one that that was added later on (for phase tracking and location moving) it deals with possible sub tie-ins (PO's, invoices, quotes, etc.). Currently, we can't control that piece through settings. It just kinda got added out of necessity vs through the normal development process (planning). All we need to do is go in and add those settings, flip some of the old values (existing data) and make it more straight forward as people set those things up in the future. Along those same lines, the sub flags and tags may need some help on the output and display and the add/edit process. All of those pieces were altered and got the sub tie-in hardcoded to them. We may need to remove or make that more settings based.

- On sub flags and tags, I would like to be able to show the last flag or fag on the main. It holds the data right now, but doesn't show the entry. Light tweak to make it show up on the working with time page and the printable time page. Also, check the searchability of the last known flag or tag on the main, through the advanced search.

- There are two pieces of the main elements of time that we can't control via settings yet... they are the make private and admin only checkboxes. We need to be able to turn those two settings on and off. Currently, every element of time automatically gets those. They are not used that often and need to become settings so that we can show/hide those options. As a side note, those two settings do have some hardcoded text values like "private" or "admin only" that show up on other reports and report types if someone searches for something that is marked as private or admin only. Just a heads up. We may want to limit the verbage on these settings.

- The general amount field on the main elements of time is currently locked to showing dollars. I would love to add some settings to allow that field to be named and formatted. I was thinking of dollars and cents, decimals, plain (no formatting), and integers (remove the decimals). That would make it more useful. For example: I have a time template called mileage and I use the general amount field to hold the number of miles. It holds the correct value but when I pull the report, it always shows the miles in dollars and cents vs just a plain or decimal number. Anyways, I think that could help. Also, along those lines, there are some budget and estimate settings (different settings but still tied to the main element of time)  that could use similar number formatting options. See notes at the bottom for some other mileage ideas.

- What about allowing for the sort order of the fields? This is more complex, but it would be cool. You could put whatever makes sense to you first and move other fields around (up and down or sorted). We may have to circle back around to make sure this is possible.

- Recently we added a thing called flex attributes to the customer section or player group within the system. The flex attributes are virtually real in-line database extensions. We allow for new fields to be configured, added in, able to search, able to show-up, etc. These flex attributes are datatype specific (dates, times, strings, numbers, decimals) vs just plain text fields like the flex grid tie-ins. We eventually want to add these flex attributes to all 12 main system wide player groups (customers - already, invoices, quotes, parts and items, stock/units, elements of time - coming soon, I hope, employee/users, vendors, PO's, expense/receipts, deposits, and balance sheet items). One more thought on this topic of flex attributes. We may need some flex attributes on a global scale (able to cross time templates) and we may need time template specific flex attributes. We may want to do the global ones first, then limit or tighten things down for the time template specific flex attributes after the global flex attributes are added and stable.

- Horizontal grids - show time blocks with main categories or values going down the left and time across the top. We would love to allow for saving settings, allowing for special homepages, and custom buttons, just like my cart favorite buttons. See element of time 6967 for more info on horizontal grids. This is a form of blocking out times and who or what is scheduled, called for, or booked. Ideally, we want to be able to configure these horizontal and vertical time views, so that we could have and use more of them. That would be really cool. Once again, see element of time 6967 to get more details and information on horizontal grids. We used a custom horizontal time view for the Beaver Mountain Ski School. They have been using it for 5-6 years now. We would love to keep building off of that type of a model and make it even more configurable and savable without tons of custom code. Make it a tool for all of our users.

- Visual blocking of time... both horizontal and vertical blocking or showing bars or blocks of time. This is a visual way of showing what is booked and what is not booked or called for. Both directions, horizontal (side to side) and vertical (up and down). We need them both. We currently have the time slot view which is close to vertical blocking, but it still needs to be more bold and handle the blocking in a better way. The logic seems to be there, but it still needs a little visual help to really bock and virtually claim those slots or segments of time. It might be nice to ask for certain visual blocking right from the advanced time search - kinda like a report type. We already have a calendar view, time slot view, grouped view, and detailed view. Maybe add horizontal block view, and vertical block view. That would be cool.

- We would like to add in some dynamic dates. These special dates would allow reports to be saved with the dynamic dates vs a physical date range or custom fixed date rage. The dynamic dates would and could be things like: current day, current week, current month, current quarter, current year,  yesterday (prior day), last week, (prior week), last month (prior month), last quarter (prior quarter), last year (prior year), tomorrow (next day), next week (future week), next month (future month), next quarter (future quarter), next year (future year), etc. These would be really handy, so that saved reports could just pull relative info (based off of the current or today's date value), without having to worry about updating or flipping date ranges. Anyways, I think this will be awesome and we could use it all over the system on other reports and pages. Especially, wherever we are saving reports and pulling up saved data. These dynamic dates may make it super awesome and powerful.

- Be able to use the calendar view and calendar overlay for tons of new reports. Be able to save almost anything in an calendar type view. That would be awesome. Once again, the dynamic dates, mentioned above, would be really cool with this. Maybe even have an advanced search page that could save and filter the data and then show it on a calendar type report view. Great visual for what is happening on what day over time. We could call it the advanced calendar page or report. It would also be super cool if we could point subs of time to some sort of calendar type report or other visual time blocking type report. Currently, most of the subs only show up in detail view (normal tables with rows and columns). Being able to see the subs in other report formats (calendar, time slots, time blocking, horizontal, vertical, groups, etc.) would be sweet.

- On the template settings (techy stuff behind the scenes), currently, when adding and editing a main element of time, you have to pass in the template settings when adding or editing the main element of time. I would like to automate this process. It would make it easier for the developers. This is more of a behind the scenes switch on the methods and method calls. Most of those template settings don't change very often. We should have the methods themselves do the look-ups and make the changes (adds and updates to the fields on the elements of time table). This would really simplify the add and edit main elements of time processes.

- Being able to control the names and settings on the subs is going to be huge. This means what they are called (like sub dates and times, sub comments, sub sign-off's, sub flags and tags, sub payroll, etc.) and what fields they hold. Be able to change that on a per template basis. It also includes the sub fields and what they are called. For example: Say the default sub section is called "Sub Dates & Times". We may want to rename that "Amenities" or "Sub Bookings" or "Project Timecards". We could also control the field names with the sub section. Say the origianl or default field name is "Sub Title or Caption". Say you wanted to change it to "Extra Booking" or "Follow-up Reason" or "Sub Event" or whatever. Being able to change what the main things are called and also what the sub fields, within each sub of time are called and how they act. That will be a game changer. Here is a list of the current subs of time.

- On the working with time page, make the add/edit subs easier. Add in buttons to help with the add new process. The current way is just a simple link. It kind of gets hidden. Make it a little bit more bold and obvious.

- Some of these settings and concepts would be super cool for the fracture project. We really want to hide whatever we can, show what we need to, and allow for the whole thing to be dynamically (through data vs code) controlled and configured. That would be a super cool piece for fracture. See the above entries for some ideas.

- Futuristically, we would love to be able to switch elements of time between time templates. Currently, you get one time template and that is it. We don't allow an element of time to switch templates due to all of the background settings that are being held, monitored, and used.

- We may also need to add in some settings to deal with the general name for elements of time. That is very broad. Each time template can be named individually, but we have had clients that want it called the calendar, scheduling, etc. We may need some bigger corp-wide settings that control the main name and smaller abbreviations. For example: The defaults may be "Elements of Time" and "Time" for short. However, they could be set to Calendar, Lessons, Schedules, Reservations, Rentals, Bookings, Assignments, Tasks, To Do's, etc. The more that people can call it what they want, the less they end up fussing later on. That key piece of speaking their language is huge.

- It's not all code, some of this is just planning and dreaming

- It may be nice to use a spreadsheet to help with some of the planning. We have lots of rows, columns, and complex data that is needed for the planning portion.

- As a side note, it was so tempting to see a need, and then jump and try to fill that need. I on purpose spent some additional time (hours and hours), trying to get ideas and thoughts out of my head and on to paper (virtually) so that all of the pieces became public knowledge. My normal urge was to figure out a portion of it and then just do it vs writing all of these things down for the benefit of others (and myself).

///////

On 8/10/21 added some ideas for advanced job costing.

- Mini P&L per element of time. If we can tell that an invoice or expense or PO was tied to the element of time, have it automatically show up in a mini P&L (profit and loss) statement. This may be done with flex grid tie-ins right now (currently - but somewhat manual). We would love to automate it and build it into the mix. That would be really cool. Maybe do some searching for "job costing" to get other ideas.

///////

On 9/2/21 added some ideas from Chuck Swann

- Chuck read through these ideas and gave Brandon some feedback. Some of the ideas have been listed above with Chuck's name (search above). Here are some of the highlights - What about adding in some custom CSS (cascading style sheets) or custom display options? Maybe think about using a tabs based display for the advanced time search. The word or mode of "custom" may be better than "advanced" - technically, the advanced mode could be the custom mode, it just sounds better and more fitting to what we are really doing - dealing with time templates. Lots of the existing pages need an update to work better with the snow owl theme (style and face lift for pages). Make elements of time easier to use, in general.

///////

On 9/2/21 added ideas and projects from Cory

- Build out the online and customer facing scheduling options - this is a big project, all by itself. There are more details on other pages. We have a bike shuttle company that needs online scheduling (from ecommerce) and there are many others who are looking for this. Any business could use customer facing, online scheduling.

///////

On 8/21/23 added some ideas from a buddy - Josh Hanks

- On mileage. Maybe add a sub of a sub to do mileage. We may also need a standalone option (list way up higher using the general amount field) or adding it to a sub date and time entry. Not all entries would need mileage, thus a one to many off of the subs (sub off of sub dates and times). Imagine template settings under sub dates and times to say something like: Need mileage? If yes, do you want to enter a simple number (x number of miles) or use start/stop odometer readings (then we automate and do the math when submitted). Anyways, I had a great meeting with Josh Hanks on 8/21/23. He's a water master, ditches and irrigation stuff, he has a need for these things mixed together - projects, hours, notes, and mileage. The other benefits would be reports, exports, and math that is done for you. We may also add in photo galleries, document management stuff (media/content), etc. We have all of the pieces, we would just need to mix it together better and make it a small industry specific skin. Eventually, when we build out fracture or adilas lite, we want to include some industry specific skins as part of that project or platform (part of the value add-on core model). This may be a fun little venture into that world.

Merging in code for Dustin and his bulk batch functionality for cultivation pages. Talking about ways of speeding up the deployment process and getting new clients and customers (corporations) up and going quicker and quicker. New systems and doing data imports. We talked about ways of getting things setup quickly and being more and more efficient. We then moved into QR codes and what they can and should do. We went a little deeper on this topic and went over some known uses of QR codes.

We then started talking about projects for Bryan. We would love him to start working on flex attributes for elements of time (in-line database extensions for time and time templates). We also talked about getting Bryan to help clean up the shelf (existing code that hasn't been fully tied in). We know we have projects like sales tax version 5 (v5) project, invoice due date project, and many others.

Steve and Cory were talking about inventory forecasting and usage pages. Watching and monitoring supply and demand of items and such. Inventory planning type functions and options.

Towards the end of the discussion, Steve and Cory were talking about independent reps and consultants and some pros and cons. We have had great results in the past, however, things are changing and we are on purpose trying to bring things more internally to provide those services from inside of adilas. This is a conscious effort. We will continue to work with a few select individuals, but all new accounts will be helped and supported from internal resources. That's the plan.

Talking about new updates to the query params project (security upgrade stuff for SQL injections). We then talked about new time settings and adding in flex attributes to elements of time. That would be huge and would be super cool. I then shared with Bryan some of where I'm headed with new elements of time settings and changes to time templates (tons more time settings).

After that, Bryan wanted me to look at his custom project for a guy who is making some kind of wikipedia type style forum. We looked at some plans, layouts, and talked about storage and logic and flow. Making progress.

8/10/21:$200

7/23/21: $$600

7/2021: Bryan will add flex attributes to EOT's

Bryan is already working on flex attributes for elements of time. This is where you can virtually extend the database and create your own custom fields and data points for elements of time. You can add data and details, show the data, and even search by those custom fields or in-line database extensions. Anyways, it looks like he is halfway through that process already.

Finished up this timeslot doing emails and light tech support.

Meeting with Steve McNew. We started out talking about volunteering and helping in our communities. Invest in the youth. Give, give, give. Good stuff.

He will be giving me some new white papers. Light touches to keep things together. Impact analysis, gather the small nuggets that we gain and find, and keep moving towards some more technical white papers. Steve also stated that he is willing to help us out with technical input and consulting, if we ever want to go in that direction.

After Steve McNew left, Steve Berkenkotter and I chatted over the GoToMeeting session. We can take our product out to custom levels, out of the box, better than some companies can do plain custom. We are built for that, in a way.

We talked about moving towards flex attributes (in-line database extensions) for employees and invoices. The employee stuff could be for HR (human resources) and other internal things. Invoices are so used in our system, allowing flex attributes to those would be huge. Once again, custom options right out the box. Build your own - whatever!

The shelf (code repository or code graveyard) - We would love to get some of the older projects off the shelf and make them part of the big picture (really deploy and launch them). We have some projects like: dynamic sales tax naming and new sales tax buckets, invoice due dates, save reports for stock/units, and tons of others. They are sadly, just sitting on a shelf, getting older and further and further away from the current master branch. It takes time and resources to get in there and revitalize those pieces and make them part of the bigger picture or part of the whole.

We would also love to make things as dynamic as possible from the get go. Build with that mentality in mind.

Steve and I going over ideas and options. Steve was just going off (in a good way) and I was scribbling things down as fast as I could. Fun little session!

- Using adilas to run adilas - so many things are available - discover what is out there that we already have - harvesting elements of time - Steve is working on forward looking inventory planning - demand, work orders, recipes, supply, ending inventory

- We have lots of great developers, maybe tap into them and help us all learn some new skills - JSON, AJAX, Bootstrap, jQuery, etc.

- We have a great team all around - Sales and deployment is getting better and better

- More predictive stuff is coming - What to order, What to get rid of, finding that balance point

- Keep building the foundation

- The value of templates - Steve sees those concepts (templates) being used for invoices and employees - Maybe add template id to the flex attributes table.

- SaaS (software as a service) is developing, people are starting to trust the cloud more and more - Netflix, Google, etc. - They have taken the edge off a bit.

- Predictive loading and just in time events based on settings

- Fracture is already starting to morph (what we think it to be) - Helping users predict what they want - Break it all down into smaller and smaller predictive outcomes

- Simple pages that allow a customer to preset or only use what they need - like an artist pallet - pick and choose and put the pieces that you need, where you want it - All based on settings and permissions.

- We are seeing three (3) levels of users or programmers - They are full backend, middle end users, and frontend users - You will need all three as it gets more complex.

- The reality of the constant state of improvement(s) - It just keeps going! New tech (new technology) and new services are needed and wanted - All the time!

- Helping our clients succeed - That's the main goal!

- Minimal load but allow them to add weight and depth as they need - Helping to match price with what our clients are getting.

- I was showing Steve some screenshots from Chuck's presentation gallery project - super cool stuff. That (the presentation gallery) will be a great sales tool! So much potential!

Working with Bryan. Pitching some of the new time settings and potential to him as part of our meeting. Small show and tell of where we are headed.

Going over some converge connect and EMV chip reader stuff. Pushed up some new Elavon payment pages. Also pushed up flex attributes for elements of time. Talked with Bryan a bit about next steps and where we are headed. Eventually, flex attributes for time templates, employee/users, and invoices - all with flex attributes. Eventually (we know that is a bad word, but...) all 12 application player groups will have and/or need flex attributes. As of today, we already have customers and elements of time.

Steve and I doing a little bit of brainstorming. Mapping flex attributes out and how we could apply those flex attributes to specific time templates (or other templates - in general). We thought that maybe we could have a section, very similar to selecting money types for carts, invoices, expense/receipts, and deposits - allow the users to click and point and choose which flex attribute was applied to what template or list of templates. Basically, a flex attribute would be global for that main player group (12 main application players) and then you could limit it to show up and/or play with only certain templates.

Danny was saying "properties" or "characteristics" for flex attributes. The flex attributes are what we ended up calling the in-line database extensions. Flex attributes seemed to stick better (naming and wording).

Danny is adding some new email templates (5 new ones). Steve had me give Danny a small demo on what we were trying to do and get done for elements of time and new time settings. We also tied in how the flex attributes for elements of time would play into these changes as well.

Bryan popped in for a bit. He wasn't quite ready to push up the code that he is working on. We chatted for a bit and then bailed out of the meeting to work on different projects. I went back to some production settings that I'm working on for Steve. Bryan went back to finishing up some code dealing with refunds, voids, and pre-auth's for merchant processing and payment transactions.

Working on new settings for elements of time and incorporating flex attributes for time into the new settings to help with some recipe/build and production stuff. This is part of Steve's project.

Started off doing emails and recording notes from the earlier appointments and meetings. I then switched back over to Steve's projects for some new production, recipe/build, and elements of time code changes.

Future plans for fracture and maybe even before - we will need session values for recipe/builds and elements of time. These are the first new dynamic settings that are not tied directly into the normal corp-wide settings. They are more of a group or page level setting, but still needed to cascade through the quick search, homepages, verbage, links, buttons, error messages, and other places. This is a slight variation from the normal corp-wide settings, but they still play a similar role.

Pushed up some dynamic quick search and dynamic permission name changes (7 updated files). Let Steve know where I was at on the project. The next step is building in code to use time flex attributes to dynamically build recipe/build links if the correct settings are in place.

Coding the link builder for the recipes and production stuff. This is tied into settings for elements of time and using flex attributes to auto generate recipe/build links for production based off of settings and usage of the flex attributes. This is a project for one of Steve's clients.

On a client Zoom meeting with Kelly and a manufacturing company. They are mixing elements of time (calendar and scheduling) with recipe/builds and manufacturing (production runs). They are really trying to use the scheduling (elements of time) to virtually reserve inventory in the future for their production runs. Interesting stuff. Anyways, we met and I showed them some of the new changes that we have been working on and I was somewhat surprised, they didn't know about them. I could really see the breakdown in communication. I had related the updates to who I thought needed them, but then it never got passed on. Also, I never took the time to physically show the person who needed it (the new updates and information) how to operate the new features. Lots of assuming, on my part. Anyways, we were showing them things, that they had asked for, that had been done for almost a month, and it was totally new to them. Good lesson. Passing on the update and correct information is huge.

Great little meeting. We were dealing with flex attributes, elements of time, settings for time, and other requests. It was also very apparent that they, the client, wanted full control over the page layout, order, display, and full verbage. That is possible, but usually it takes an outside person, like Kelly, to get that information from the client and then translate the wants and needs into instructions for the developers and development team. Once they get it right, how they want it, they also want to cascade the same changes to multiple systems. Not only custom software solutions, but repeatable and duplicatable custom software solutions. It was good to see somewhat of what they were looking for. Kelly and I will meet again to go over things after she does her work, review, and then submits the projects and their requirements.

Steve and I touching base on different things happening over the weekend. Steve and Sean then jumped into some labels, custom invoices, and gram tracking options. Steve is really trying hard to build out more settings to help automate different pieces and processes.

John was showing us some of his work and progress on the discount engine. He gave us a small demo and showed us what is still remaining, things that still need some work.

The conversation switched over to getting things pushed up and out for testing and live usage. We are really trying to focus on doing lots of tiny or micro releases vs big huge releases. Along with this topic, we started talking about possible projects and helping out Wayne with some of his bigger projects. If anyone gets too big of a project, they tend to virtually stall out and lose some productivity. We talked about the datasource project (world building), flex attributes for other system player groups (in-line database extensions), and client facing scheduling stuff.

Steve and Sean were going over sales, options, and new settings. Sean and Steve were than talking about buying percentages of adilas and creating an asset (user-maintained balance sheet item) and how to track the whole purchase of that asset. Emails and reviewing a reseller agreement for merchant processing with USAePay and NMI.

Steve, Sean, and John started talking about LLC's, trusts, MMLLC's and ways of structuring companies and liability shields (virtually). I showed Steve some of the reseller agreement documents and he wanted me to ask a couple of questions. I have a meeting with a guy later today to talk about reseller options. The last thing we talked about this morning was custom forms out in ecommerce to help get and gather data for certain clients. Steve was talking custom options, using flex attributes, and being able to upload scans, images, and other documents. Full custom ecommerce client portal type stuff.

Talking with Steve about limited flex grid, status, and where things are headed. He is excited to expose some of the new tools that we are developing out to the rest of our clients. We are also trying to stay ahead of Chuck and what pages he is redoing and making them look better. That lead us into some discussions on layout and display options such as tabs, accordions, pop-ups, modals, and other modern display and layout styles.

Everything keeps going back to settings. We talked about 4 different level of settings, that we are seeing. They are: 1. Corporation level settings (corp level or world level), 2. Group or player group level settings (12 main players), 3. Page level settings, and 4. User level settings. As a side note, settings are awesome, but they can also make things feel like it is more complicated. You have to play the game of iceberg vs huge mountain. Hide what you can, only show what is needed, but still make it available if needed (like tools in the shed). We see more and more of this type of thing coming as we build out toward fracture and future development.

Another fun thing that we talked about was page views. We happened to be on the time homepage and going over different page views of the same data, but how cool would it be if we could build out reports that show up in calendar view, timeslot view, grouped or aggregated views, or normal details and tabular data type formats. So many options, including charts, graphs, and other layout options. Not to mention, export or save custom report settings. All available, we just need to keep bringing it all together. More stuff for fracture.

The next subject was dealing with getters and setters and how those pieces are so dynamic. Some of our entries have 30-40 fields or choices. We don't want to have to submit all of those pieces, every time, for a simple update. Getters help you get the data in smaller pieces, as needed. Setters help you set or update the data in small bitesize pieces. For example, say you have 30 records of flex grid, each with a possible 40 columns. If you do the math, that one bulk edit page could have over 1,000 fields. What if only 2 pieces of data actually change? Using a simple setter allows you to only alter smaller pieces of the whole without having to carry the whole load. Efficiency!

As we were talking, we can see the value of using small teams to push on projects together. That could really help with resources and giving everybody a buddy to work with. Along those lines, here are some other projects that we may give to Bryan or a small team of developers. Flex attributes for all of the main players (used to be called in-line database extensions), vendor/payee logs (modeled after the customer log section but for vendor/payees), and other projects that already have a small handrail or guide. Anything that has been done before seems to be easier, due to the example or handrail for the developer to follow.

Steve and Sean were going over sales leads and talking about pushing more on bowling pro shops. The conversation got into the need for certain custom tools per industry. Steve and Sean then talked about flex attributes (custom data points) and how those could be configured into industry specific tools (for bowling, it is ball specs and drilling holes and sizes - techy bowling stuff). I chimed in through chat about limited flex grid as well. That is a great tool and allows for one-to-many relationships, out of the box. Lots of options.

Both Steve and Sean had to take off around 9:30 am. I rolled over into recording notes and doing emails.

Sean, Chuck, Cory, Shari O., and I were on a meeting. Shari O. came in a little bit later after the rest of us had started. The goal was to talk about and look at options for creating some industry specific tables and logic to hold bowling ball drilling specs (important pieces for the bowling industry). I was taking notes and the others were chiming in with questions, feedback, and ideas. Good little brainstorming meeting.

Here are a couple of topics of discussion:

- We have some really old screenshots of some bowling specific software that looks like it was developed in the 1980's or 1990's - looks like old windows stuff.

- Talking about options by using flex attributes - (real in-line database extensions). Those are fairly new and are unlimited, but they are only currently developed as a one-to-one relationship (you only get one set of unlimited data points) vs a one-to-many relationship where you could have one customer and they could have many balls or different drill patterns. We would also have to go in and setup these flex attributes per corporation. We went over some other pros and cons there.

- We could use flex grid tie-ins or even limited flex grid tie-ins, but we cap out at 30 custom fields. They can be used as one-to-many relationships and already have a ton of flexibility and features built in. Possible option.

- Currently, one of our bowling customers is using an old school paper type model. They print out a form, fill it in, and then scan and upload and attach it to a specific customer. They can upload as many new images as needed. They could also use PDF, Word docs, Excel files, etc. - using media/content vs photo uploads. These options exist right now at no additional cost, just some training. The downside here is that each photo or scan is not searchable. It exists but you can't search for patterns or combine things.

- We talked about a budget of between $2,000 and $4,000 ish to get a custom project up and running. This would include onsite research, planning, designing, development, and even some reporting. Just guessing without more info at this point.

- We have a number of resources (people in the bowling industry) that could help and guide us. That is huge. We just haven't really tapped into it yet.

- Chuck had some great questions about other service type industries and how they track their repairs and custom jobs - ski shops, bike shops, etc. Maybe look at what it would take to do and/or extend things out to other industries. Good insight.

We closed the meeting and both Cory and Sean are going to poke around with some of our contacts and see what we come up with. As it develops, we may setup other meetings to keep pushing the project forward.

Quick GoToMeeting with Chuck to go over assigning flex attributes to elements of time and how all of that stuff works. Text messages to developers helping and pointing them in a good direction.

Steve and Sean were on the meeting. They were talking about different demos and client needs. They did some work and training on the custom label builder and prepping labels for a demo. They were also talking about building a new report for a customer - hot list (active potential new clients). We added a value to the existing flex attributes and built a report and saved it in the favorites. Done. That was kinda cool.

John and I did some coordinating on the discount engine and talked about some timing options.

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.

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.

Zoom meeting with Cory, Steve, and Kelly. We were talking about sub inventory. Subs are great but do require more work and effort. Getting info in, out, reporting, and bulk updates and bulk tools. When we started, we didn't even know what was needed. As things unroll and unfold, we are beginning to see a bigger picture. That is awesome!

We have mountains and mountains of data. Now what?

As the meeting progresses, we spent some time talking about the challenges to sub inventory. Here are some of my notes:

- Sub inventory attributes and being category specific

- Settings all over the place - configuration

- What about changes, updates, and flipping categories (after the fact)?

- Possible mapping of categories, sub attributes, etc. Talking about mapping by id numbers and not names or column numbers.

- We need a sub inventory history section. Tables are already built, but they have not been tied in.

- Some of our clients want so much control

- Sub attributes, parent attributes, flex attributes, flex grid tie-ins, and other different levels or layers

- Master list of sub attributes and then repurpose those per category. This could be tied in with the mapping options listed up higher. Either start from the top (master list) and go down (what sub attributes are needed per category) or list out each attribute per category (current model) and then tie and/or map them back to a master type list. We may have to go in both directions. Just some thoughts.

- Kelly likes how parent attributes can be bridged over categories. Having said that, we need to be able to search by sub attributes, parent attributes, and flex attributes.

- Certain clients want to pull data without the category specific reliance. Basically, once we catch the data, we have to be able to let it be searched, pulled, filtered, shown, and exported. It's all part of the puzzle. Being able to get at and use the data. That's a huge key. Just being silly - ADILAS - all data is live and searchable

- Maybe upping the permission level to add/edit sub inventory or sub inventory templates or sub attributes. Once again, we need some histories of who is doing what in the system.

- Steve was talking about - 1. Capturing the data. 2. Then being able to get it back out (in any form - CSV, Excel, PDF, printable, web). and 3. Being able to play in bulk and deal with automation options. Those are some of the goals (small summary).

- We have people who are wanting to add certain sub attributes on the fly, as part of a sub process or sub phase. This gets into sub locations, sub phases, and sub processes and/or steps. Currently, we only show the subs at certain steps and make them go back to certain places to add/edit or update that data. There is a lot of manual work involved. How cool would it be if we could help them and let them setup their own processes, phases, and sub processes. Mini concepts of the data assembly line.

- There is a need for bulk update tools, easy flow processes, and being able to setup their own data flow based off of the subs or steps within a process.

- The use of templates to help control other actions, defaults, rules, and assignments. Having that example and/or template really helps answer a number of questions.

- We went back to the main need of being able to pull data out of the system (quickly and easily) - all data is live and searchable - We really need this and keep going with what we already have.

- Kelly and Steve working on advanced reporting and moving beyond a band-aid. What about going back and correcting the plumbing from the get go. Planning for the future.

- Need for more controls, handrails, and ability to scale.

- Build and break, build and break. Well, it's time to fix it again! it's breaking!

- What if we re-imagined it??? What would it look like? What things do we need to consider if we were to rebuild this out?

- Kelly was recommending that we get into a real life system to see the challenges. We made some plans to meet with Kelly again see the tools that she uses, how she uses them, and what is still lacking and/or needed.

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

This is more for me, but what are the next steps in the planning process for new phases, data assembly line stuff, and where do we want this to go? Help lead and guide it! Keep pushing for more bulk tools, bulk options, and bulk tools to add, edit, update, change, pull data in, pull data out, etc. We can do a bunch of things on a one-by-one basis, let's keep pushing that to the next level. Yee haw!

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.

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.

Going over lots of requests for new and enhanced reports. Small errors and fixing a few things. Cory had a small list. Lots of talk about flex attributes and the need to build them out on all 12 main application player groups. Currently, we have them on customers and elements of time. It seems like the next one that is warming up is PO's. We have clients that are wanting to be able to add new and flexible data points to PO's (purchase orders). Of course, once they get added, they for sure want to be able to search by those new flex attributes. They also want them to show up on all the correct spots, forms, searches, reports, and exports. Not a problem, it just takes a goal and some time.

It seems that across the board, our users, on a global level, are wanting more and more control of their reports and exports. This inclues settings, preset and saved favorites, show/hide certain fields or columns, able to rename fields, set and remember the search criteria or filters, and be able to pull down any and all data (reports or exports).

Cory and I were talking about "visibility vs searchability". Our users want "visibility" first, then they want the "searchability". Basically, our users want to see the data and then be able to limit it and/or filter it down from the results that they got. From a coding side, it is easier to filter (control what will show) vs showing everything and then filtering after all of the data is shown and/or pushed out to the user (way more traffic, memory, and bandwidth). On the coding side, we would much rather have you know what you want, then we only have to serve up those records. Sort of a flip flop on who wants what and which way they approach their data and report results.

We have a report that the users want to control multiple parts of an object (say PO's or purchase orders) all from one export and/or report. Granted, the PO has multiple one-to-many relationships, table joins, and records that need to be matched up and presented. Imagine a report search page that has show/hide checkboxes for all of the main PO data (location, vendor, total amounts, PO types, dates, notes, ties to external invoices, etc. - 20 some fields). They then want all of the show/hide checkboxes to show/hide columns for all of the line item details (quantities, costs, prices, items, descriptions, etc. - tons of new fields - 60+ fields). Next, they want any sub inventory information (sub reference id numbers, barcodes, units of measure, special sub attributes, RFID tags, etc. - tons of other fields - another 15-20+ fields). Without going too crazy, they also want any new flex attributes (extra data points or in-line database extensions), parent attributes (inventory level controls for parent items), and other data. I didn't count, but it could be well over 100+ fields that they want to be able to pull, show/hide, filter, and organize. It gets into some advanced settings and big reports with lots of dynamic logic. Not that it is hard to do any of that, it just gets more difficult when you are mixing so many things or parts of the object together.

Cory wants us to start with the "visibility" of the data. As a side note, we may have to off load some of the processing for these bigger reports. I want to be careful about building on possible already tippy code or projects. We have to make sure that everything is stable. After this conversation, Cory and I lightly talked about budgets. We also looked over some code and did some quotes for clients. There are many challenges when trying to mix and bled and mix viewing with searching huge datasets.

Lastly, we talked about fair compensation. We are heavily underpaid and not showing our true value. That gets complicated as well. It's an interesting mix and an interesting game.

Meeting with Bryan to push the flex attributes for PO's. The flex attributes allow for custom data endpoints per main group (12 main player groups). We currently only have flex attributes for customers, elements of time, and now PO's. Eventually, we want to add this same feature for each of the 12 main player groups. As a side note, originally, these flex attributes were going to be called real in-line database extensions and were going to be the big brother of the flex grid tie-ins. When we get everything out to the fracture level, we want to make sure that we have the flex attributes built out for each main player group. The main player groups are: Deposits, invoices, PO's, expense/receipts, balance sheet items, stock/units, customers, vendors, employee/users, parts/items, elements of time, and quotes.

Another thing that is really wanted, and we would like to build for fracture, is a granular level of both visibility and searchability. The clients want to be able to see everything and then be able to filter it down as well. That seems to be a reoccurring theme and request. Currently we have a number of prebuilt reports. That is great and all and needs to continue. However, to make it even better, we need to provide options on the advanced searches that show every field, every connection, allow for toggle on/off (show/hide) fields and columns, filters for each section, and options for both show and export. Once again, full visibility and full searchability. That's the goal. Adilas - all data is live and searchable.

Bryan and I got his code all merged in and pushed up to data 0 for testing.

Woke up this morning with thoughts of a virtual obstacle course going through my mind. I remember seeing a movie and the extras after the movie talked about how they put the digital characters through an obstacle course to test to see how well their modeling and simulations were doing (Pixar - Monsters Inc.). Once they could virtually run the whole obstacle course, without problem, they were able to go to the next step.

If we are building out the next level of adilas, code name fracture or adilas lite, I was thinking that we could come up with a good virtual obstacle course of sorts. I was thinking, simple database stuff, one-to-many relationships, users, permissions, roles, settings, validation (server-side and client side), add/edit options, getters, setters, reports, pagination, API sockets, coded using frameworks, etc. I know that sounds like a lot, but a mini version of the things that we do all the time.

This could include, form fields, toggle on/off switches, checkboxes, radio buttons, drop-downs, selectors or choosers, date picker, time fields, text fields, numeric fields, buttons, navigation, dynamic CSS (look and feel), mobile ready or mobile responsive designs, etc. Modals, dynamic help files, aliases, show/hide features, and the list keeps going.

This is just for fun but what about using customers and customer logs (simple CRM stuff - customer relationship management) for one of our virtual obstacle courses? Once again, just an idea. The features listed below are in no specific order. This is both funny and not so funny... We can already do all of this right now (using the current adilas ship A application). We want to rebuild this using our new ship B - fracture or adilas lite code and frameworks.

- Settings, navigation options, turn things on/off - do I want to use certain features or options
- Settings, what to call things (naming convention) - corp-wide settings or high level group settings
- Show/hide field level settings (toggle on/off, show/hide, aliases, rules, defaults, sort order, etc.) - data level settings
- Add/edit customer types - way of organizing and grouping customers
- Add/edit main customer functions and pages
- View single customer page (similar to the customer log page)
- Simple search, display, and drill-down into individual customer records
- Advanced search, pick and choose fields, filter, sort, export, and save reports
- Add/edit customer logs (notes and follow-ups per customer) - allow HTML - be able to sanitize as needed for display (say you had some bad or mal formatted HTML - still make it look good)
- Add/edit additional contacts
- Add/edit additional vehicle to customer assignments (currently being worked on for ship A)
- Aggregated data - log counts, contact counts, vehicle counts, total customer counts by type, individual customer info such as total invoices, quotes, elements of time, payments made, purchase history, items bought, etc.
- Full history of all actions - add, edit, modify, etc.
- Dynamic help files
- API sockets to do all of the functions listed above. Things like add/edit main, add/edit logs, add/edit additional contacts, add/edit additional vehicle assignments, view or get back data on all pieces (together and individually), search, show reports, even alter settings. The current API has a visual show and tell page, the real socket (live interface), and printable/searchable documentation.
- Rudimentary training per section - pages, sections, functionality
- Integrated unit testing
- Photo management
- Upload media/content (files)
- Gallery page - (images, scans, photos - up to 100 per customer with captions and show/hide settings)
- Remote login (ecommerce level) to allow a customer to login and update info, see histories invoice and quotes, be able to upload images from ecommerce, build your own statements, and view log notes out in ecommerce
- Quick search options
- Show log notes and follow-ups on a calendar type interface or view
- Search log notes
- Search additional contacts
- Flex grid tie-ins and limited flex grid tie-ins
- Customer flex attributes
- Doesn't have to be right now, but customer tie to invoices, quotes, and time (naturally).
- Barcode label options for simple customer information and customer id numbers
- Validation - server-side and client-side on all forms (add/edit forms and report filters). Base this off of a data dictionary type interface.
- Mobile ready and responsive web format and styling
- Customers can be tied to loyalty points, discounts, and gift cards
- Customer queues
- Email reports and special email options (custom email settings using corp email settings)
- More options on the customer homepage - tons of links and nav to other sections. Reports, management options, and core update and bulk tools.
- More options on the customer log page - including options for custom paperwork and numerous drill-downs to customer-specific searches and filtered reports.

Just being silly, but I'd like to record all of these pieces, in the old way and then compare them to what and how the new way works. Kinda a side by side view. Depending, it may end up being an old way, a semi-new way, and the actual new way. I'm not sure how fast we can jump from old to new. We may need an intermediate or middle ground step.

Merging and pushing up code with Eric. After the initial work, we spent some time talking about data modeling. Here are some of my notes.

- Eric would love to do some more data modeling and taking things into consideration and making a plan. He used to do this for other companies that he has worked with and for. Great resource. We could really use his help with adilas lite or fracture. This was like a mini database and data modeling lesson of sorts. I was loving it and scribbling down notes as quickly as I could. Fun stuff.

- We talked about flex grid tie-ins, flex attributes, and parent attributes. Basically, things that he sees that we do that might be built out into more efficient tools and features. Maybe rework some of this and/or combine some of the features.

- What really connects to other things (natural relationships) or what things are forced together (forced or special relationships)? We may want to look at use cases and try to pull out the natural relationships. Then build your application according to those natural relationships. You may still need to allow the forced or special relationships, but those become the edge cases vs the norm.

- If something happens over and over again, this should be part of the core system. Currently, we do use a lot of flex grid tie-ins to help with some of these special cases. As a side note, some of these one-off features are becoming more normal and should have their own logic and tables vs putting everything into the flex grid tie-ins. Great tool for getting things started but eventually, you may need to build out specific tables, logic, and pages. Make it more normalized and more efficient.

- As a note, what does the flex grid do? It allows for one-to-one connections, one-to-many connections, add log notes to anything, tying things together (main id's to sub id's or main id's to other main id's), and it also allows for up to 30 custom fields. Once again, it can be on a one-to-one basis or used and setup as a one-to-many relationship. Here is a help file that has more info on the flex grid tie-ins.

- As a note, the flex grid tie-ins have been the big brother to the things we are trying to build called flex attributes or real in-line database extensions or real in-line extensions for short. Here is a small, older graphic link, of what we are trying to do.

- We talked about the bus to motorcycle project (datasource project or world building project). We are headed to a new model where the corportion id numbers (corp_id) will be left out per database. Each company will have its own database and thus may not need the corp id number. This deals with table names, joins, and data that gets stored in the database.

- Back to the flex attributes and a possible option to build them right into the main entities or high level tables (for the 12 main players or wherever we see fit to put them). This option has some pros and cons. We'll have to work this out. Currently, I'm really leaning towards something similar to what we did for the current flex attributes or parent attributes. Let them build and setup any custom fields that they need. Dynamic relational model. Just for fun, here is the progression - flex grid tie-ins (2009), sub inventory attributes (2015), parent attributes (2016/2017), flex attributes (2020).

- Lots of talk about data modeling and being able to take off the corp_id. Including on the end of corp-specific tables - for example: invoices_53, invoice_payments_53, time_sub_inventory_53, and a slew of others.

- Maybe break the pili or po invoice line items into two different pieces. It was joined together to help with inventory counts over time and across multiple locations. Anyways, we may look at separating those tables into multiple pieces. Super important, make sure to remember and include locations. If just a single location, we could do the architecture differently. However, with multiple locations, it gets a little bit more complicated or tricky. There are tons of other possible options.

- The payee table should be broken up as well. Currently, if a person or entitiy is tied to an expense/receipt, a PO, an inventory item, it lives in the payee table. Payees consist of users, employees, vendors, and special customers that had to get paid out of the system (a copy and convert process). Anyways, we may want to break that table up into users, vendors, and special customers (something like that).

- We talked about a concept called "attribution" and data normalization levels. There are two main types of data models. You have the logical data model and the physical data model. Entities and entities have attributes. Eventually, those entities and attributes get translated into tables, columns, and fields in a database. Often, most attributes become their own database column or field.

- Attributes are different than types.

- We talked about fields like "flag_for_1099", "password", etc. Those are attributes for certain entities. However, does a vendor need a password field, most likely not. Each field or attribute needs to go with the entity that it belongs with. We, at adilas, tend to mix and blend some of the attributes between different entities. In some ways that is fine, but it requires explanations, instructions, and training. It's not as easy to follow without someone to guide you along. Anyways, some good conversations about data normalization stuff. What goes with what and why does it fit like that?

- Make the names readable and logical where possible. We do a pretty good job on that, but there is some randomness in there as well. Along with that, we jumped into talking about a section called special accounts. We are planning on using that for gift cards, loyalty points, in-store credit, vendor credits, punch cards, and other special account transactions where we almost need a bank account style with a rolling number and being able to add/subtract using individual transactions or actions. Anyways, we have a few fields in there called dev_flag_1, dev_flag_2, and dev_flag_3. We use those flexible fields to help with certain parts of the process. In a way, we didn't know what we were going to need, so we added in some flex fields. Well, now, those flex fields have rules and hold certain data that could be its own column or field. However, because we didn't know what would be needed, the fields are somewhat mixed, depending on what is stored there and what kind or type of transaction record is being stored (loyalty points vs gift cards or whatever).

- The conversion trickled over into human reference fields vs computer identifiers, ids, or computer reference fields. They are different and play different roles.

- As you think things out, eventually you have to transform or go through a transformation from logical models to physical models. Eric kept saying that we should be shooting for the third normal form (data modeling and database modeling). Figure out the whole business world (plan it out as best you can) and then build out what you need, based on what you see and/or know.

- We talked about aggregates and data warehousing. I mentioned that I would like to build out tables for yearly per location, quarterly per location, monthly per location, weekly per location, and daily per location. We would also have the underlying transactions or transactional database tables (raw data that holds all of the data). The other tables would be what we transform the transactions into (a form of aggregates or business intelligence).

- Along with aggregates, Eric was saying that sometimes you can watch the database and see what tables, queries, and reports cost the most (data, traffic, or processing time/energy/frequency). You then build out aggregates based on those findings and/or known needs. For us, we've been doing this for long enough, we know a few places that could really help with speed, server load, and provide great BI or business intelligence levels.

- Our system has to go clear out to the full accounting level. That changes how we do certain things. That is awesome! Our sort of end goal is perfect accounting, aggregates, per day, per location, and per category. Some of those (category levels) vary but they have mostly been defined in the current system. That is huge. We have a plan, we have a path. We just want to refine it. Eventually year over year reporting, monthly by month comparisons, real-time data - all data is live and searchable (adilas).

- Snapshots, aggregates, different preset and controlled data levels. We may need current data (tables without any dates - assumption of current counts, values, sums, totals, averages, maxes, mins, etc.) as well as dated or historical data (tables with dates to allow previous or prior lookups and date driven lookbacks).

- What about enterprise mappings and cross-corp stuff? We need to plan that out as well.

- We also need to consider servers, speed, reliability, backups, redundancies, and how deep we going?

- Lastly, Eric could help with a ground up data model. We could pick a topic, break it down, and do a number of smaller sessions vs a big push. That would be too much. Anyways, great meeting and Eric could be a great resource for planning, checking out our decisions, and planning out the best course of action. Good stuff!

Meeting with Shari O. and Cory. Going over plans and priorities. We talked about yearend stuff for payroll and 1099's. I'll be working on that here this week. We also talked about a quote that a client would like. It's joining PO's, flex attributes, and elements of time. We watched a 15-minute video that Cory and Kelly made with the requirements and requests. We may modify it a bit, but it looks like a good project. This one has more of a manufacturing type flavor to it.

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

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

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

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

Working with Bryan to merge in code for assigning elements to time to other main players. Fixed some merge conflicts and did a light code review with Bryan. Pushed up files on data 0 and did some live testing. Flipped over to a zoom meeting to do some more planning. Working on phase 2 of tying things between flex attributes and elements of time. I was drawing and having Bryan take notes on new changes.

Quick meeting with Bryan. Reviewing his progress on tying in PO's and flex attributes to elements of time. Conversation about classic vs snow owl (visual themes inside of adilas).

Switched over to payroll stuff. Working on payroll and pub-15 tax withholdings for 2024. Working on entering withholding tables.

Back meeting with Bryan to go over the auto tie-ins for PO's to elements of time. We spent some time working on the flex attributes and how they are tied in to time (new settings). Small work session. We made a small to do list and started going through the different pieces. I did lots of explaining and drawing to show where we are hoping to go. Plugged a small hole (in the data) and pushed up a small change to permanently plug that hole. Ran a quick update to update any past or older data.

We ended with ideas and instructions on automating the setting of the master time template settings when creating a new element of time. We went over a couple of options. Our main goal is to make the function of creating a new element of time lighter for developers and later potentially for API socket users. Because we are under a budget crunch on this one, we'll tone it back a notch. We may have to revisit it again later. Making progress.

Phone call with Bryan going over questions about support, logging, and how we handle support tickets. We talked about some other questions as well. Quick Zoom meeting with Cory to go over a needed fix for elements of time and tying in PO's based off of flex attributes. She is going to send me more info via email with requirements and a valid login.

Custom code for a client. They have a PO flex attribute that gets tied over to elements of time. Looking into the code, research, review and clean-up. Prep work and looking around. I may have found the problem, but it will take some time to get into it. Looks like a look-up value was hardcoded and also missing some validation. Spent some time starting to rework some of the logic. Recording notes for the day.

Multiple sessions throughout the day working on the logic for the PO flex attributes being tied over to elements of time. Going page by page and testing things and making small changes. Pushed up code changes to the Bitbucket code repo when done for the day.

Multiple sessions throughout the day. Recording notes from yesterday. Switched over to work on the flex attributes being tied into time. Still going page by page to make sure that everything is all tied in and working well. It gets pretty deep. Started doing some testing. Fine tooth combing of the pages. Working on the output for the flex attribute project. Working on the calendar display for the app type and main id links.

Various sessions throughout the day. Mostly working on the new code for tying in PO date/time flex attributes to elements of time. Finished recording some notes from yesterday. Working on calendar output for the flex attributes being tied to elements of time. Did some more testing. Started to look at the PO flex attribute output and showing what is connected to something (better visibility). Made a new way to tie in flex attributes with elements of time (tighter tie-in). Quick meeting with Bryan to look over progress on his project. Back working on PO page level output for tie-ins with time. Looking good. Final clean-up and pushing up files. Live testing and emailed Cory with an update.

On the meeting with Bryan - He showed me where he is at for the cart line item groupings. He is making progress and can show 1-3 groupings. He is still working with the session stuff but it is coming along. I could see great progress from yesterday. We will meet again on Monday to look a little bit deeper.