Phone call with Josh. He wants some help doing developer work for potential clients. They, Josh, Cory, Steve, and Eric have been doing some fun projects. Lots of look and feel, email campaigns, and new ecommerce skins. He has some potential clients lined up, just needs to fix certain things. He was asking me where I'm at with things. I'm off the side of the bus (not with everybody else). He wants me to work with Steve and the crew on development projects that need to be done. I'm trying to do some planning and working with ChatGPT (AI) to help line out the master plan stuff. We have never had that, meaning a master plan. I'm not trying to get it, the master plan, too detailed, but we need it. I feel that it is very important. We will always have more projects and development work. To me, it's just another checkbox and/or request. We have tons of those, meaning checkboxes, done and pushed out. Just for fun, here is a link to a 50-page document, just with features inside of adilas.

It's not just planning, I'm circling back around, finishing things up, reinforcing the foundation, and refining things. I'm trying to simplify things, make it easier to understand, explore new avenues, use AI to help us get rid of the rub and/or friction. Tons of things. In sales we talk about features, advantages, and benefits. We have the feature part down... We need to circle back around and make sure that we can show the advantages and the benefits. Some of that is look and feel and some of that is flow and simplicity. Just as a sample, here is an element of time entry that shows some of what we are doing and how we can harvest these AI conversations to help show the simplicity of what we are really trying to do. See EOT # 12793 in the shop. This entry has four new documents that are super easy to read, yet tell a huge amount of what we do and offer. We are working on graphics, help files, documentation, etc. We tend to go so quickly, that we don't put the finish on it.

One of the biggest things that people complain about is what it looks like (look and feel of the UI). We have great tech and functionality. We need to circle around and put that finish on our product that people are looking for. I love it, and I totally see it. There is nothing wrong with what he, Josh, is asking. I also know that it takes major resources to do all of that. I really want to see if we can get some investors to help us with some gas money, help us along the path. We have put every extra cent into this project that we could and/or can. That is awesome, but it is also taxing.

Josh recommended that I call Steve and see what he needs help with. I just know if I do that, I'm back in the mix of going a million miles an hour without a plan. We joke about it, but there is some reality to the situation, we are hanging on the car or train as it is going down the road and/or train tracks. We are working on it while it is going, making corners, going up/down hills, etc. In real life, the plan is - just follow the money, but then it never ends and you don't know where you are going. It starts getting complicated. Everything has to keep going and connect to tell the story. I really feel like me not being on the train is important right now. I don't know the timing of everything. We'll get it all figured out.

After we got done talking, it took me a couple of hours to get back on level ground. I think that I have some mental anxiety about where things are at right now and where things are going. I've been in this battle (the adilas project) for 20+ years. I've been burned out and reanimated a number of times. It's a repeating cycle. It has been pretty stressful. I really want to see it succeed, but the current demands are saying, jump right back in at full speed. I need to be on the outside right now, if for nothing else, for my mental wellbeing. I'm working on other parts of the system. There will be great ROI (return on investment) of what I am doing, it just may not be super visible right now. I know that it is going to help.

The other part of the adilas glossary (A-J) is on element of time # 4030 in the adilas university site. Web link - time_web_gallery.cfm?corp=371&id=4030

K

• Keep - This is usually some sort of an action where you are maintaining or keeping something for later use. It could also involve something that you do continuously - for instance keep clicking on this, keep drilling down, keep refreshing, keep checking back, etc. Saying either save that or continue on that path. 
• Kill - This is a general term usually meaning to delete, destroy, make inactive, hide, etc. It is a general term that means to get rid of something. Other times you might talk about if it is going to kill the system meaning too heavy of a load, too intense, too many sub details, etc. 
• Knock knock - Who's there? It could be a joke but actually we use it in computer speaking when we are trying to gain access to API sockets. You play knock knock with the server. The server responds who are you? What do you want? Then you have to respond that those questions/requests. It is kind of a back and forth protocol.
• Knox Report - Special sales report for invoices and payments made. It has the ability to show quick stats, counts, and other math totals. You can also run comparisons on different date ranges if wanted. The original report, and all of the columns and/or numbers, were requested by an operations manager named Phillip Knox, out of Canada. Thus the name. It's really just an awesome sales report.
• KPI or Key Performance Indicators - These are a set of values (totals, counts, averages, sums, etc.) that are used to determine how things (people, processes, or campaigns) are doing. Some of these KPI's are used on reports, dashboards, and in other areas. Basically, someone setups up a rule and and benchmark goal. Then things are evaluated based on those key performance indicators.
• Kush Cart - This is a version of the internal shopping cart. The three main versions are the classic cart, the Kush cart, and the mini scan cart.

L

• Labels - Can be printed via browser settings from multiple locations in the database. Item labels can be used to add items to the shopping cart, item labels can be printed from within the shopping cart for certain industries, labels can be printed for plants from the cultivation homepage.
• Label Builder - Special application and/or functionality to help with custom labels. Inside the system, there are various label builders. Some are very basic (auto linked from specific pages to the label generator) and other allow for all kinds of drawing, graphics, dynamic text, colors, rotation, barcodes, QR codes, custom naming, saving, etc. Multiple versions, based on needs.
• Liabilities - Financial obligations of a company. Tracked on the balance sheet.
• Line Items - "Meat and potatoes of a form." Can be inventory items on a PO, expenses on an expense receipt, and invoice sales on a deposit.
• Link - A link could be an actual web link where you go from page to page. These are often used in navigation or drill-downs. A link could also be things that get connected or tied in. Such as an invoice might be linked with a customer or an item is linked with a PO. Another definition for link is an item within a chain of a process. What are the links that it needs to go through?
• Locations - Way to sort inventory, allocate sales tax rates, organize operations in the database. Completely dynamic.
• Lock - A lock usually means that something becomes more secure. It could be locking people out, locking things down, it could be advancing something so that people with lower permissions cannot access or see it. Another example could be a system being put or going on lock down - like the system or a database table. A lock is used to inhibit access. 
• Logout - Function that allows a user to leave the database. Once logged out, another user can log in from that computer. Note.. logging out does not clock out the user.
• Logs - Associated with customers/clients. Area where notes may be kept for historical reference.
• Look and Feel - Basically this deals with what you see. Your interface colors, your color choices, your navigation buttons, your interface layout design, your defaults, your style, etc. The software system allows for all kinds of dynamic colors, fonts, watermarks, graphics, logos, and styling to help with your look and feel. 
• Look Back Date - Usually this means that we are going back in time to look at data or content. Very common for inventory levels, sales, and balance sheet items.
• Loyalty Points - This is the process of assigning points and values (dollars) to a customer or client who purchases from you. These loyalty points can have ratios (how many points for how many dollars spent), date rules, redemption rules, etc. Inside the system, you have to turn it on, but the system will automate this process for you (checkout, accumulation, redemption, etc.). The bigger section is called special accounts and deals with things like loyalty points, gift cards, vendor credits, in-store credits, etc. The use of loyalty points, in the system if built-in, once turned on at no extra charge.
• LPI (Lines Per Inch) - This is a printing term that deals with resolution. Another common one for this is DPI which is dots per inch. Often computer screens and printers deal with DPI where LPI is for professional print shops.

M

• Main - The software application uses the term main in multiple different ways. It could be main homepage, main navigation, main or core logic. The word main might also refer to sub homepages such as main customer homepage, main invoice homepage, main deposit homepage. Going deeper the word main could also mean the starting of the object. Anything that can hold subs is a main. For instance the main invoice details or main element of time. We end up adding sub details, such as line items and payments, to a main bucket, item, or container. It is very common within the application to see the words edit main. This deals with going directly to edit the details required to start or initiate a new object within the system. 
• Make/Model - This is tied to serialized or stock/unit inventory. The make is usually similar to a brand name. Then the model is usually some sort of a sub division within that, that has some known attributes or pieces. In the system we allow you to define the makes/models and the underlying presets that go along with those. These are set up into one to many relationships where one make can have an unlimited number of models.  
• Manager's Time Clock - This is a permission/section that allows a user to oversee time clock records for departments that have been assigned to that manager. Time clocks have three different levels. You have the user level which is easy to add but you cannot edit anything. Then manager's time clock which allows you to add and edit but only at a certain level. Then admin time clock that allows for corporation wide adds, edits, and reports. 
• Mark-up - This usually deals with a pricing model where you take a value and you multiple it by a cost to arrive at a new price. Depending on if you are doing widget (small, bulk) type inventory or serialized (stock/unit) inventory there may be multiple levels of mark-up. Another way that mark-up is used is sometimes on coding language. A mark-up language is where certain things have tags, attributes, and parameters. 
• Media Content - Technically media/content is any kind of file, which could be spreadsheets, text documents, PDFs, graphics, photos, scans, audio files, video files, etc. that may be added to the system. Inside of the application we allow media/content to be added to any of the 12 main items, any of the 12 main player groups, or just generically to the system as a whole. Basically this is your paperless office function. 
• Merchant Processing - This is a general term used to talk about credit card transactions, authorizations, and processing. The system acts as the client side or software piece. It sends transactions over to a gateway which authorizes, confirms, and holds secure data. The merchant part of it deals with converting that data into real monies that will get pushed into the company's bank account.
• Meta Data - This is data about the data. Usually used for database or describing things. Say you have a PDF document. The meta data might be things like the title, the category, the feature it explains or is part of, who created it, the date, the last date modified, the page length, etc. This is just one sample. It is basically any side data that describes or helps categorize the main data. It is used in web technologies all the time. Meta data helps the browsers and search engines know what the page either contains or is for.
• Metrc - This is a state compliance agency that tracks regulated items through the chain of custody and uses their own RFID tags and subsequent system to help in that tracking and training process. Metrc is pronounced "metric", like the measurement standard.
• Mini Conversions - A conversion is where something gets converted into something else. Usually it deals with units of measure. For example gallons of water, liters of water, cups of water, drops of water, etc. The reason we use the word mini conversions is that we are trying to track a semblance of what is happening instead of a full conversion that might be unalterable. These mini conversions are simulating the breakdown or conversion into smaller or bigger groupings.
• Mini Scan Cart - This is a version of the main internal shopping cart. The three main versions are the classic cart, the Kush cart, and the mini scan cart. The mini scan cart is the most flexible and customizable of all of the shopping carts. It has a number of toggle on/off settings, you can rename buttons and even show/hide different possible functionality add-ons. This shopping cart also has a number of touch screen specific options and settings.
• Mix - This could be the mix that you have on your sales floor (what inventory items you have in-stock - example: what's your mix or let me show you my mix) or it could be the act of blending one or more pieces together. Often the word mix is used to mean some sort of combination or process to get a result. Inside of adilas, we often are mixing and blending different business functions or technologies together. The goal is something different than what or where you started.
• Mobile - This could mean mobile as in on a mobile device where the sizing or layout changes based on screen size. It could also mean the ability to carry, transport, or move around. It may also mean the ability to transfer pieces between things - the data can become mobile. The ability of the data to transfer between places such as to different corps, other software, different places in the application, etc. Often you might hear the words mobile app or mobile ready - that usually means a software system that runs natively on android or iOS devices.
• Modal - This is a special popup window that is used in or on a web page. It appears to be a new window, but actually, it is just a layer that sits on top of the other browser window. Without getting super technical, a modal helps show/hide additional information so that the page can remain less cluttered.
• Money Types - Options for making and receiving payments.
• Money Type Settings - List that shows all existing options for making and receiving payments. Boxes may be selected or deselected to customize payment options based on form (Invoice, Shopping Cart, Deposit, Expense)
• More Options - Button provides access to links that are associated with the page in use. At the top of most pages.
• My Cart Favorites - Custom preset buttons that determine how items assigned to those buttons are sold.
• My Settings - This deals with access to user level settings within the software application. This could be anything from password and profile information to default cart types, expense types, Flash buttons, etc.

N

• Ctrl N - This is a keyboard shortcut on windows for creating a new tab in your browser window. Often you can do the same thing by right clicking a tab and clicking new or duplicate, etc. 
• News & Updates - Updates and how to's are posted here to alert users of new functionality within the system.
• Normal Parts/Items - The word "parts" is used to mean any item that is tracked as a group (including labor and services). It is also important to note that the words "parts" and "part number" are editable on a per corporation basis from the corp-wide settings. Specific items are called units or stock numbers (serialized units) and are handled through a different section (usually bigger ticket items). Sometimes the word normal parts applies itself to how things are tracked meaning tracking things in and out.
• Nxtlinq - AI technologies company. The Nxtlinq group helped to make the adilas.biz AI agent "Adi". They are a 3rd party solution in the AI technology space.

O

• One to Many - This is a database concept and usually deals with some main element that may have subs, children, add-ons, additions, or some unlimited number of connections. Some examples could be one customer has multiple invoices or each invoice has multiple line items. We use the concept of one to many to talk way beyond just database things but that is where it came from. 
• One to One - This is also a database concept and usually what it means is a direct relationship. It's the opposite of a one to many. Often a one to one indicates a switch, a toggle, an additional value that may be conditional, an option of being turned on or invoked. 
• Online Bill Pay - This is where a customer would actually get a button, a link, or an email where they could go pay for a statement online using a credit card. 
• Open/Opened - This is a common term that we use to talk about being engaged, active, selected, etc. An example might be open this package, meaning make it active or current. Or open the invoice homepage, meaning go to that page and open it. Or you may hear someone say tell me what tabs you have opened, meaning what do you have showing. 

P

• Ctrl P - This is a keyboard shortcut on windows for printing a certain page.
• Packages - This is used in a number of different ways. Often it deals with batches for sub inventory. Sometimes they are called packages or child packages where you get into parent or child relationship. Packages could get into shipping. Packages could also be used for a certain set of features. For example if you were in a certain industry and wanted to buy the extended package that would be a set of extended features. Sometimes it is also used in the recipe/build area if you are creating certain recipes to create a package, or a kit, or some sort of group. 
• Page Settings - These settings deal with what happens on a single page. As a note there are corporation or world-level settings. There are group level settings such as invoices or PO settings. There are individual settings, there are also these page settings which deal with just how certain pages act, interact, show/hide, react, etc. 
• Parent - This usually refers to inventory and kind of a parent-child relationship. The parent is usually the main element or place holder. We then refer to the parent as the main item and the subsequent children are those related to that parent.  
• Parent Attributes - These are optional but these are classifications and categories that can be associated with different inventory items. These are ways to group and flag your inventories. This can help with sales and filtering of items/products. These are unlimited and often help in categorizing or searching or sub-filtering pieces together. As an example, say you bought outdoor equipment from a wholesaler but you really wanted to make sure that things were known for their brand. Not necessarily the vendor you purchased them from but the brand. This could be one example of a parent attribute but there are unlimited possibilities.
• Parent/Child or Parent - Child - This is a relationship for inventory items. The parent is the main item. If there are differences or a need to track sub data, special descriptions, changing costs, alternate prices, and other attributes, we use child or sub inventory. Super flexible and powerful but does require some additional steps as compared to normal or parent inventory tracking. Not required.
• Parent Inventory - Inventory items. May be sold as is (status active) or may be set up not to be sold (allow subs only) but to act as name holders for sub inventory (see sub inventory). May also be set to inactive if no longer needed for sales.
• Parts - Items or services that are sold. The name 'part' can be changed to reflect the 'widget' inventory and or services. 
• Part Category/Categories - Organizes items into a subset. Technically a part category helps in searches, in your reports, and on your financials. It also helps if you are going to be setting up any sub inventory attributes. Most of your sales reports are done by category at the top level and then by item. 
• Parts Homepage - Main inventory homepage. May search for inventory by vendor, category, or item. Printable views also accessed from this homepage, as well as a multitude of advanced searches.
• Patient - System default is customer- patient is an example of a choice for renaming 
• Payee - Refers to individual or business being paid, either vendor or employee.
• Payments Not Yet Deposited - As invoices are created, payments are applied. This verbiage stands for the state of these payments. They are 'waiting' to be included on a deposit.
• PDF-Portable Document Format - a file format that is used to share data. Many pages in the system may be exported to PDF through the click of a button.
• Percentage Calculator - This is a feature that allows you to calculate a percentage based off of either the cart total or a line total. Once the percentage is calculated, you have an option to alter or change any verbiage that is needed before adding the item to the cart. Often this is done to help cover credit card fees or some other percentage calculation. Normally used as part of the POS (point of sale) interface. Only companies that use this feature need to know about it. Normal retail actions don't use this special calculator.
• Permissions - Over 150 rules that allow or block access to functions within the database.
• Plant Tags - This is a term meaning an RFID tag for monitored items. Usually used in cultivation and harvesting processes.
• PNG Image - Portable Network Graphic- type of image file that is accepted for upload under the Media/Content link located on most forms in the database.
• PO's - This abbreviation stands for both Purchase Order, used to receive inventory and Production Order, used to record and track light manufactured items.
• Post - A post has a couple different things that it could be. One, any time a form is submitted it is called a post in technical terms. A post in accounting usually means let's lock it down and make it tight, also meaning lock it down from lower permission users. A post could also mean when you take smaller details and combine them into a summed entry, this entry can also be called a post. If you are talking about fences, it's the big tall thing. :)
• Presentation Gallery - This is a small web-site devoted to quick sales and marketing slides. The full set is around 50 sides that cover main topics of what we do at adilas. There are sections for essential business functions, application player groups, and core concepts. https://news.adilas.biz/sales-gallery/adilas-advert-index.html
• Printable - View of data that is condensed in order to print more succinctly. Editing is unavailable in the printable view.
• Printer Friendly - This is a term for certain pages and reports. Printer friendly means that minimal navigation or header/footer values exists. Usually, you have to go to that page, say an invoice or quote, and then click a button that says printer friendly. There are printer friendly options for multiple areas within the site.

Q

• Quick Search - This function appears on each page and allows one to quickly search for any element.
• Quote - The step prior to creating an invoice. Can be skipped if desired or created and turned into an invoice.
• QR Code - A two dimensional barcode that holds more data than a one dimensional barcode. 
  
  

R

• Raster Image - This is also sometimes called a bitmap image. Usually what this means is that there are little blocks of color to make the image. If it is blown up to big it can become pixelated. For example, people who work in PhotoShop deal with raster images all the time. The opposite of a raster image is what is called a vector image, which deals with smooth mathematical lines, arcs, and curves. Vector images scale very well because they are mathematically based. 
• Recipe/Builds - Method of selling items grouped together into a 'kit' or 'recipe'. Pulls inventory onto the invoice in set quantities.
• Reflexive Flex Grid - This is a piece of flex grid or flex grid tie-in that goes in the opposite direction. A normal piece of flex grid connects a single record to a source (say one of the main 12 application player groups). A reflexive piece of flex grid does a reverse connection from sub to main vs main to sub. Here is a quick example: Say you have a customer that needs a refund, you could go from the expense to the customer or from the customer to the expense. Either way. The goal is that the items are connected or have a relationship. If you use reflexive flex grid, you only have to make one connection, and the system will do both directions for you. You are trying to tell the story of what happened. Time saver.
• Refresh Queue - A queue is basically a digital line. This could be used for projects, people waiting, people who need to be served, etc. Refreshing the queue typically just means what is the current status or order of these people or things waiting. Some of the pages actually have settings so that the queue will refresh itself at an interval the company has selected.
• Refund - This is the act of returning or giving back an amount for something that was purchased. Inside the system, if you need to issue a refund, you will do a negative quantity (I'm getting something back). Not all refunds deal with items. Sometimes is just money trading hands. Depending on the side of the equation you are on, a refund could be monies going out (someone is asking for a refund) or you could be asking for monies coming in (I was a refund).
• REI's - This is short for a reimbursement. A reimbursement is money that was paid out of a person's pocket that needs to be paid back directly to that person. These are very common in the expense/receipt side of the application. For example, say I was out and bought a new broom and wanted to have the company reimburse me for buying the broom. On a technical side reimbursements in the system must be paid back in full. There is something called a split in the system that you can chip away at an expense and make payments to it but a reimbursement must be paid in full. There are tools in the systems to combine or pay reimbursements in bulk. 
• Reoccurring Elements of Time - Often you will have things that you want to reoccur over and over again such as company meetings, a set/reoccurring due date, even a person's schedule - things that happen over and over again. Inside the system you have to create one primary element of time that exists by itself, then you can tell it to reoccur or choose how to reoccurs. The master needs to be created first and then you can duplicate that master to create the further elements for reoccurring. 
• Reoccurring Expense Receipts - This is some sort of a bill or expense that happens over and over again. This is very common for rent, insurance, draws, auto-transfers from banks, etc. You set up the master and then you can tell it when to duplicate itself and advance it's dates for creating the additional expense/receipts. 
• Reoccurring Invoices - This is charging a customer over and over again in some kind of a reoccurring subscription, or repetitive purchases, etc. Once a single invoice is setup it could be set to reoccurring if there is some sort of constant, regular billing. If the invoice amount changes you may not want to go this route. This is best used for the same items/services and amount reoccurring on a regular interval. Once again you have to have a master invoice and then it knows what to copy. This section inside of the system can do it both automatically and as a manual reminder in case things need to change. 
• Request PO - This PO type is used for ordering, requesting, or getting quotes from vendors. This PO type records all of the main PO info without taking it to the next step (receiving). The PO request may easily be turned into a "Basic Live" PO by switching the PO type. When this happens, the request will hold all of it's original info and becomes received (actual or live). At this point, it will function just as a basic live PO would (inventory counts and payables). This PO type is vendor specific. See corp-wide settings for custom naming.
• Responsive - This has a couple of general meanings. One of the most modern ones is called a responsive webpage, meaning it sizes well for different devices. The layout will change depending on the size of the screen, that is called responsive. Another use of the word responsive is talking about clients getting back with you, vendors, or even the server - such as the server is not responsive meaning that it is not responding to requests presently which could mean it may be asleep or dead for a bit.
• Restore to Cart - This means you are taking something, usually a quote, and putting it back into the flexible shopping cart mode where you can add, edit, change, and use the bulk tools in the shopping cart. As a note, restore to cart is from quotes but there is also an option to duplicate to cart which is taking a completed invoice and restoring it to the cart. 
• Results - This is also a general term. It could mean a goal - what are you desired results. It could mean results of a query - what came back from a search. It could also deal with testing results for something such as new code. Results are also trying to find what you are looking for. What do you get out of this thing that you are looking for.
• Retail - The term retail usually means something along the lines of sales or selling something. Inside the system, retail could be a name of a certain interface or dashboard - retail dashboard, retail homepage, retail interface (POS interface), retail sales report, etc. Retail usually means taxes, where wholesale means non taxed, at the current time of the transaction.
• RFID - Radio frequency identifiers - Used in the cannabis industry to track all inventory and plants. Unique number associated with inventory items.
• Rounding - Rounding deals with the level of accuracy, usually with number. This could be decimals to decimals or decimals to integers. It is also important to know that the deeper you split something apart there might be virtual saw dust or shavings which is referred to as rounding error - trying to get it split apart or broken down as close as you can. Rounding is often used in taxes, discounts, and eventually needs to be equated into money if you are dealing with dollars and cents. Sometimes inside of the system we allow things to be flexible up to 5 decimal points - the term we use for this in the application is the dewy decimal system - this is not related to libraries.   

S

• Sales And Profit - This is a term to show what has been sold (sales) and what the profit or difference between the price and cost are. Sometimes, this is used as a term to mean, how did we do? Inside the system, there are special invoice-based sales report that show this information. The P&L (profit and loss or income statement) also show this kind of information. Sometime the sales are called revenue and the profit is calculated based off of a salesprice minus the cost of goods sold (COGS). Discounts may or may not be included, depending on what you are looking for. Often taxes are left out of this calculation.
• Sales Tax Settings - All settings are dynamic and can be entered on the location homepage. 
• Server (what server are you on?) - All corps are assigned a server that houses all their data. Server number is visible in URL ie. https://data4.adilas.biz
• Settings - Settings are usually some sort of user preferences or default values to help a page or a function configure itself. Inside of the system there are four main types of settings. We have corporation or world level settings. We have group or system player settings - for example invoices, parts, customers, etc. We also have what are called page settings which deal with a specific page function, flow, or process. The lastly we also have a thing called individual or user settings - this is where an individual or user gets to set some preferences such as default types, navigation, other presets and defaults. 
• Shopping Cart - Where sales happen in the database (see also Cart).  The shopping cart is how you sell your stuff. It is the interface between your customers and the entire rest of the system. The shopping cart eventually helps you to create your invoices and quotes. It is literally tied to almost everything in the system. If you took out this piece of the puzzle, not much would be happening. This is the "interface" piece.
• Show/Hide Search Criteria - This is usually a button or a link that helps you collapse or expand search forms. Often pages or reports needs user inputs or filters but showing that right off the bat takes up valuable real estate on the page. So the show/hide search criteria allows you to expand or collapse that when you need to interact with the input, filter, and searching section.  
• Signature or E-Signature - This usually deals with a sales receipt or invoice. A signature is a special written name or approval. An e-signature usually means some sort of digital signature or approval. There are a number of signature settings for invoices, inside the system, including e-signature options.
• Smart Group - Basically, a smart group button is a my cart favorite button that contains all of the functionality of the normal cart favorite buttons plus it allows for pre-set pricing structures (quantities, weights, and prices) to be assigned or connected to one or more inventory items. Smart group buttons allow for both assignments (who gets to play) and rules (how things interact or play) to be set up.
• Snow Owl - This is a look and feel theme or motif. Snow Owl is a series of header, footers, options, settings, and styling for the pages. Originally developed by Russell Moore in 2017. Additional changes have been made. This theme currently has the most modern features, access to tools, functions, settings, and more. Sometimes we talk about Snow Owl in a general sense but this encompasses hundreds of settings, features, and options that are part of running Snow Owl. 
• Software - This is a term meaning any kind of code or program that is installed on a machine. Often software deals with licenses, updates, versioning, etc. Some of it's family members are hardware, firmware, freeware, shareware, and even sometimes vaporware. Even though the system is a web application it is sometimes generically called software. 
• Special Accounts - These are things inside of the system that take on the role of a miniature account of sorts. We use the term special accounts for things like loyalty points, gift cards, gift certificates, vendor credits, in-store credits, punch cards, account balances, etc.
• Special Line Items - These deal with the hardcoded part numbers or "special line items" that are used within the application. Many of them have special uses and special code that is built in to the main application. These are things such as labor, fee, discount, verbiage, other, shipping, trade-ins, and more. Basically these are special parts or items that can be attached to an invoice or PO and some of them even have special treatment on how they are tracked financially on the P&L and Balance Sheet.  
• Special Live PO - PO used to bring in inventory from multiple vendors. This PO type allows the main vendor to be set as the payable (who will get paid), and the line items may contain bulk, generic, or non-vendor specific items. These PO types are used by companies that buy the same item from multiple vendors and don't want certain items to be tracked on a per vendor basis. The items become a bulk or general usage item and are usually maintained under a special internal vendor. 
• Special Parts - This can be two different things, it can refer to unlimited items that don't track quantity such as labor or services, or it can refer to the special built-in application items.
• Special Request - This is the request side of the special live PO's. Very similar to a basic request except it allows multi and mixed vendors. See description of special live PO's above for more info. Once received, all special request PO's will need to be flipped over to the special live PO status in order to show up and become real or live. 
• Specific - Specific basically limits the scope. We use it as a general term and it could mean specific in reference to talking about a specific item or a specific relationship. We also use it when referring to things like corp specific, vendor specific, location specific, user specific etc. Once again it takes that general topic and narrows it down to that scope. 
• Split Cart - Feature that allows user to view shopping cart and my cart favorite buttons on the same screen simultaneously (see M for My cart favorite).
• Split/Splits - This has a number of different features associated with the word splits. This could be split payments - which is typically dealing with multiple locations where you may have to split or divide payments. A general term called splits in the system is a term used for payments that are on account. This is used when you need to pay a vendor and you may owe a larger sum than you can pay right then. You can attribute whatever monies you would like to that vendor's account and it will pay off or satisfy those expenses. Sometimes split can refer to split screen functionality that diverges or splits. If you are dividing revenue sharing you might create some sort of a split.
• Spread - This could mean a spread of what you have (like inventory items or options) or it could be the act of distributing something across multiple areas. The term areas could mean whatever, bills, invoices, payments, security, outreach, etc.
• Start New Cart - Function that allows user to begin a sale.
• Statements - a time stamped report or "snapshot" of who owes you what.
• Status - This term could me a number of things. A status is usually a state of being of some sort. Often, inside the system, a status is either active (use/show) or inactive (don't use/delete/hide). Sometimes the term status could also mean a state of readiness.
• Stock/Unit Cust - A restricted view of serialized inventory. The view is 'customer' friendly, hence the name 'Cust.'
• Stock/Unit Full - A full view of serialized inventory. Includes cost and other info that should be hidden from customers.
• Students - Technically a student is a person who learns. There is a corp wide setting that you can use for your customers and if you happen to be engaged with people who are called students you may change your customer name to student. This can also deal with people who are learning from your media files or procedures. 
• Sub Attributes - Unique information associated with a sub inventory item. This information is driven by sub inventory templates that are created based on the tracking needs of the business (see sub attribute templates).
• Sub Attribute Templates - Templates that carry the unique data assigned to sub inventory items. These are assigned by the business based on tracking needs.
• Sub Inventory - Items in the database that can be sold. Connected to a parent item (parent inventory) which carries the name and some information. Sub inventory is unique and can carry much more unique information (see also Child).
• Switch Corp - If a business has more than one corp they can switch between them without logging out.
• System Assets - Contains all company assets. Deposits, Accounts Receivable, Invoices etc.
• System Basics - Basic permissions and links to preform calculations.
• System Liabilities - Contains all company liabilities. In general all payables that your company owes.
• System-Maintained BSI - Item on the balance sheet that are automatically generated and updated by the database.
• System Maintenance - Section that contains homepages that allow the user to maintain different functions.
• System Management - High security level that allows the user to maintain corp-wide settings and user permissions.
• System Reports - General reports to help you know and understand the company finances, inventory levels and historical data.
• System Time & Requests - Inter company calendar. Used to schedule any 'element of time.'

T

• Templates - Templates are typically grouped settings or presets. It could be a number of settings or permissions that are configured or options that are toggled on and off. Sometimes we use templates in things like sub inventory attributes, elements of time templates (master time templates), we also could potentially use templates to set up corporations on a more global scale - like setting presets for certain industries or jobs, etc. 
• Themes - A theme is similar to a template except it deals with look and feel or what we call a theme. A theme is something that has a reoccurring or overarching premises to it. We do often use this with look and feel and you can see a patter with this, some of these are the classic theme, geometry, Snow Owl, etc.
• Threshold - A threshold is a limit either on the top or bottom of an amount. For example: Say you sell a certain widget item, you may set a max threshold of 50 and minimum threshold of 10. The goal is to stay within your boundaries or thresholds.
• Tiered Pricing - This is the act of automatically applying a price break as the quantity goes up. Inside the system, there are tiered pricing options in the my cart favorite buttons (smart groups) or inside of the parent attributes applied to items for ecommerce sales. Often tiered pricing deals with rules and assignments to different items (assignments) and price breaks (rules).
• Time - Refers to an 'Element of Time.' The object that tracks any data related to time. These are the basis of the calendar and scheduling.
• Time Clock - Time clocks have three different levels. You have the user level which is easy to add but you cannot edit anything. Then manager's time clock which allows you to add and edit but only at a certain level. Then admin time clock that allows for corporation wide adds, edits, and reports. 
• Time Templates - The time templates or master time templates control what the time elements are called. They also control what they allow as far as subs, add-on's, default settings, and functions of time. Think of a time template as a cookie cutter for the actual elements of time. 
• Touch or Touch Screen - Touch can mean a number of different things. It could be an action - who touched my customer log notes? Often, there are system histories to show who touched what parts, pieces, and/or records. It could also mean touch or the act of using a touch screen. This is very common in the POS (point of sale) interface. Certain settings are specifically setup to allow for easier touch options (big buttons or finger related interfaces).
• Transfer - This is another general term. One of the most common usages is what we call an invoice transfer where you are moving product from location to location. Internally we call that a transfer invoice. Another use for transfer is when we talk about a bank transfer - moving money from one account to another account. There may be other uses for the word transfer like transfer of ownership or documents. It generally means something is in movement or there is a change in ownership.
• Transition Invoice - A transition means something that is in-between things. For general purposes a transition invoice is between a quote and a real invoice. We actually allow you to name it whatever you would like. Some common ones might be work in progress, work order, layaway, prepaid invoice, etc. Basically it is something that may not fully be done or finished but we already need to start contributing inventory and payments to the order. On transition invoices some of your normal financial pieces are deferred until it gets changed to an actual customer invoice.
• Try Storming - Similar to brainstorming but with the knowledge that you will be circling back around. You still plan things out, do whatever you are going to do, make your best effort, and then you - on purpose - circle back around. Keep repeating until you have what you want.
• Type - This is a very general term. It is basically a way to organize or flag certain data. A couple of examples might be invoice types, PO types, customer types, etc. We also use virtual chart of account buckets called deposit types and expense types. It is all for categorizing and organizing your data. Another common term for a type is either a category or grouping. Sometimes these can all be used interchangeably and indicate some sort of organization or flagging. 

U

• Universe - Universe inside of the system usually deals with all of the different servers, the different corporations or worlds, and all of the different entities that play together under this larger umbrella. Along this line sometimes we also use the word universal which can mean globally/generally accepted and adapted across the system. 
• Units of Measure - A unit of measure is some sort of a standard way of noting a measurement, a weight, or a length. Common ones might be something like ounces, grams, tons, liters, gallons, dozens, boxes, each, etc. A unit of measurement is assigned to every inventory item. This controls how the items are reduced from inventory and how price is determined in the shopping cart. Units of measure may be broken down further into what are called mini conversions. This is where you have a certain amount of one measurement that creates or equals a certain amount of another measurement. 
• Unlimited Parts/Items - Each inventory item may be specified as either normal, where we count quantities in and out. Or unlimited where we allow it to sell as many as we want, such as services where we don't limit it to an actual inventory value. 
• Update - Update is a general term. Usually it deals with some sort of a database type change where a record gets edited or updated. It is also very possible to update things that are held in memory without hitting the database but usually update refers to some sort of a change, or something new being presented, a feature being updated, or some news and updates letting you know about current or upcoming functionality. 
• Update Cart - Allows user to push new information into the shopping cart during a sale.
• Update Inventory - Function that allows user to update entire inventory via one purchase order (see Update PO).
• Update PO - PO used to update inventory regardless of vendor (see Update Inventory).
• Upload - This is an action. Usually this means a push from one computer to another computer or server. Uploading usually deals with files, images, media/content, or even potential lists of data. 
• URL - A URL is another name for the web address. A web address is usually in the top of your browser and is used for hyperlinks, form submission, and general web navigation. Technically it stands for a Uniform Resource Locator but it is basically just a web address. 
• USAePay - Available merchant processing gateway for internal shopping carts, online bill pay, and ecommerce transactions.
• User-Maintained BSI - Item on the balance sheet that is created by the user and maintained by the user (not automatically updated by the database).
• User Settings - These are settings that are changeable on a per user basis. These could be things like default location, default homepage, a specific invoice type you like to use, if you are paying expenses it could be a certain payment type you typically use, a default shopping cart, etc. Basically they are setting that are changeable to make your user flow more customized and helpful for the user. The number of user settings continues to increase and there are also places that you can setup your own custom navigation, links, buttons, and more to come.  

V

• Ctrl V - This is a keyboard shortcut on windows for pasting a certain selection held in memory. Either Ctrl C or Ctrl X are the ways of copying something to memory. 
• Validation - This usually means that certain data meets or matches certain criteria before being accepted. The system actually uses a number of forms of validation. You can have local validation which happens before anything even gets submitted. You also have server side validation where things get checked on the server before they are able to be used, advanced, or edited. There are also things called validation routines which means multiple steps of validation to help walk through a process. 
• Vendor Catalog - This is a term that is used at an enterprise level. Meaning, a list of vendors that may be added or go up/down the chain for multiple locations, entities, or corporation. It is basically a library of vendor information that exists at a high level and then may be pushed down to sub entities.
• Vendor Credit - This is an amount that a vendor allows as a discount or value that does not need to be paid. For example: Say you bought some things and the items weren't quite right. The vendor may issue you a credit or vendor credit. That means that the next bill or things that you pay for will be less money due to the vendor credit (an I owe you from the vendor). Inside the system, these are tracked as subs of the special accounts functionality.
• Vendors - Any person, business or entity that your company purchases services or items from.
• Verify - Verify usually means a second approval. Dealing with banks on expense and deposits, verifying means that the bank shows that same value. There are tools that allow for what we call bulk verify/verification, posting, etc. A lot of this deals with ways of advancing the ball (data) and saying that it is still good and can move on to the next step. ,    
• View Cart - Shows user current shopping cart information. If a shopping cart exists it will be held in memory and often we use the term view cart to get back to that process. Carts are just saved in memory until you actually submit the cart and create an invoice or a quote. There is usually some sort of button or icon in your header that will help you get back to the cart if it actually exists. 
• View Only - This is a state or status of what is being viewed or shown. The view only status or state means you may look but not touch. Inside the system, there are a number of silver permissions (specialty permission) that allow users to search and view things but not add or edit them.
• View Register - Shows user  current bank information.
• VIN/Serial Num - The unique number/letter id of a serialized item.
• Void Options (all the options) - The act of voiding means you negate or return everything to an original state or a state of zeros. The four main places that things are voided are on invoice, deposits, expenses, and PO's. Once things are voided all of those inventory items or payments are reverted back as if they never happened. Almost every other thing in the system has a status, such as active or inactive, which can virtually be like voiding it or making it go away as well to make something inactive. 

W

• Wholesale - This is normally a sale to another retailer or distributor where tax is not part of this transaction. Tax is attributed on later transactions to the actual customer. Wholesale also sometimes deals in bulk. It has its own special rules and regulations. Sometimes wholesale could also mean a reduction in price or selling things lower than a standard retail environment. 
• Widget - A widget is a general term. Widget could mean a small computer application such as a Flash widget, an HTML widget, a mobile widget, etc. This is also a general term used to talk about general inventory items or non-classified items. For example, you might need to update your widget inventory to show the new prices. 
• With Tax Included - This is a tax setting where the company sets a fixed price out the door and then the system back figures what the tax should be to make the price plus the taxes that out the door pricing. The brother to this setting is called normal taxable and that takes the item price plus the tax which then comes up with a new total. 
• World - This is a general term. Often it denotes some sort of sphere or area that has certain characteristics. Another synonymous term is something like land where we might say eCommerce land, invoice land, or invoice world - denoting when you are in separate areas. Another definition for a world is a corporation or an entity. Often we use this when talking about world building. When we talk about your world it is your business entity. 
• World Building - World building is the act of gathering all of the different pieces and putting them into play in a system that simulates your world. Disclaimer: the term world building is used by authors and those in film to build a world with characters, cause and effect relationships, some sort of trouble or problems, and some sort of a goal that ties these things together. This creates a symbiotic relationship. 

X

• Ctrl X - This is a keyboard shortcut on windows for cutting a certain selection and putting it on the clipboard for future use. Ctrl V is used to paste.
• X-axis - Part of a 3D model. Time is the x axis (bottom or horizontal side to side). Time goes in both known directions (forward and backward).
• X-out - This is usually a quick way to say X out of that, X that, close that, kill that, remove that, etc.  

Y

• Ctrl Y - This is a keyboard shortcut on windows for redoing something that has been undone. It's brother command is Ctrl Z or undo.
• Y-axis - Part of a 3D model. Money is the y axis (vertical or up and down). The y axis may also be referred to as resources. Not all resources are money but they do go up and down as things happen and business flows. 
• Yearly/Year - This is a term denoting the time period of a fiscal year (accounting) or a physical year (general time period).

Z

• Ctrl Z - This is a keyboard shortcut on windows for undoing a previous action. It's brother command is Ctrl Y or redo.  
• Z-axis - Part of a 3D model. Space is the z axis (depth, front to back and/or layering). This axis deals with additional details. What is happening? Are things moving? Are these things part of some other piece? What are the additional details that give more depth and understanding, that make it a rich story.

Adilas Key Contributors:

Steve Berkenkotter - Main owner and business partner - original ideas, concepts, and training - sales, relationships, dreamer, visionary, custom code, coordinator, builder of the first industry specific skin, and the list goes on. Huge player in the adilas story and timeline. One of the original owners in Moring Star Automotive - where the system came from. There are three known Steve's in the system notes. Most of them are this Steve (99 out of 100 times). He won't admit it, but adilas was his brainchild.

David Berkenkotter - Steve's brother and business partner in Morning Star Automotive. David was a system user and helped us create the adilas quick search. He liked using that feature, the quick search, but it only existed on one page originally. He wanted us to put it on every page. That ended up being in the header. He was also one of the original partners in adilas. Power user in the system. Sadly, he passed away due to cancer.

Shari Olin - Commonly known as "Shari O.". She worked in the accounting department back in the Morning Star days. She has been somewhat of a mother hen to help all of us crazy chickens keep going. She helps with customer support, training, payroll, bill collection, and tons of backend office functions. Major power user. Just being silly, but she can have the mouth of a sailor but the heart of an angel. Part of the adilas admin team and a great friend.

Craig Leitner - Also part of the original Morning Star team. Craig was the automotive floorplan and bank guy. He is a power user in the system and does a lot of bank reconciliation and other tasks. He currently works with Steve and asks as the adilas controller (money flow guy).

Cory Warden - Originally an adilas rep and consultant. Cory become part of the team after being a rep for quite some time. She helps with customer care, client support, project management, and keeping the team on track. She also does all of the news and updates and other training material. Cory does tons of oversight type services for our clients. Power user and part of the admin team.

Sean Carlton - Sean was a manager at a Cannabis dispensary in Colorado that used adilas for years and years until they sold. Steve recruited Sean to help with sales, deployment, and training. Sean brings lots of usage experience. Often, he is one of the helpers if we need to send someone onsite to help with a deployment or training session. Power user.

Brandon Moore - I'm one of the guys that writes most of the developer's notebook entries. Originally, I was hired by Morning Star, the automotive dealership, to help with data entry, accounting, and website stuff. I ended up being one of the main adilas developers and architects. I build content, write code, help other developers and team members, and help with training. Helped start the project back in 2001 under the Morning Star name.

Chris Dunsey - One of the first adilas interns (developers). Helped with a number of projects. Ended up being somewhat of a consultant later on.

Shawn Curtis - Kinda a funny story. He was taking a developer's class at Bridgerland. He knew my brother Russell. He asked to join our developer class and became one of the first interns along with Chris Dunsey. Shawn ended up helping with payroll and other projects. Some of the photo galleries in the system came from Shawn's help. He also worked on the media/content (file upload) pieces. Later on, he did more payroll work and acted as a buddy to Brandon and did some consulting work. We worked together for years and years.

Russell Moore - Russell is my younger brother. Originally, he was added to the group because of his graphic skills. He ended up being a great backend developer and project manager. He has also acted as a trainer and mentor for Brandon along the way. Much of the current system came from projects and efforts that Russell was involved with. He has also been Brandon's AI tutor in recent years. Great help to the system. Huge contribution.

Chris Johnnie - He is an entrepreneur who teamed up with Russell to help create a company called "Adilas For Business" or "AFB". Eventually, both Russell and Chris sold their pieces back to adilas. They were honestly the first ones to really try to run as a white label of adilas. This was back in 2015 and 2016. Chris really helped to push the product to the next level along with Russell's help.

Danny Shuford - Longtime friend of Steve's. Danny helped with some website design, sales, and videos for adilas. He even got into creating custom PDF labels for clients. Light development work.

Marisa Shaw - She is Danny's daughter. Danny brought her to an adilas training event in Denver, CO. Marisa was the star student. She ended up helping with some graphics, flyers, marketing material, teaching, instruction, and planning. Power user. Very helpful.

Shannon Scoffield - Shannon is Brandon and Russell's sister. Her maiden name is Shannon Moore. Huge help and virtual assistant to Brandon. She has helped with training, project management, and content creation. Most of the major content sessions were or have been with Brandon and Shannon working together. When they, Brandon and Shannon, were traveling, Shannon was one of the primary adilas instructors. If she was teaching Brandon was taking notes. If Brandon was teaching, Shannon was taking notes. Power user.

Cheryl Moore - Cheryl is my mom. What an asset. She owns a small business and has owed a few different ones. When we were doing training sessions, she came to every one of them. She asked wonderful questions and was a great supporter. Sometime, I would use her as a test subject - can my mom do this? If yes, we are good. If not, we may need to keep tweaking it. Thanks mom!

Wayne Moore - Wayne is my dad. He was my hiking buddy and more than willing to talk about ideas and concepts on our walks and hikes. He helped out with video stuff and was a great coordinator for making other connections. He worked at Bridgerland (technical college) and helped us get setup with classrooms, computer labs, and other great connections. Huge cheerleader! There is another Wayne, Wayne Andersen, he is a backend developer, systems guy, and database guy.

Wayne Andersen - This Wayne lives in Portugal and helps with all of the backend security, server, and code testing. Major skills, writes code, helps push all of us to new technologies, partially retired but loves to play with tech stuff. If you search for Wayne and it deals with concepts and coordination stuff, that's my dad, Wayne Moore. If you search for Wayne and it sounds like a master backend guy, that's Wayne Andersen.

Alan Williams - One of the lead developer's at adilas.biz. Alan joined us in 2015 and quickly came up through the ranks. Trainer, CTO, team lead, master developer, prototyper, and system architect. Alan has helped with many projects and features over the years. He also helped Brandon with some of the prep work for the adilas lite (fracture) plans and project. Sometimes called "Dr. Alan" by the other developers. Example: This might be a project for Dr. Alan.

Bryan Dayton - Bryan has been one of the most versatile guys on our team. Originally, he joined a development class out of curiosity. He and Brandon live in the same town and know each other from church. Bryan has done more custom code or small system projects than almost any other developer. He also joined the team in 2015. He helps with sales, custom projects, pushing on projects that he thinks will yield a return. Lots of work on the adilas lite and fracture project. Very hard working and versatile.

Dustin Siegel - Developer who helped with numerous cannabis and cultivation type projects. He worked directly under Steve to help with that business vertical. Many of the original pages that Steve built were taken over and remade by Dustin.

Eric Tauer - Developer and custom code guy. Originally, Eric knew Steve and lived in Salida, CO. As a note, adilas is Salida spelled backwards. Eric has a background in database work and data warehousing. Eric has done tons of custom systems for clients. Often, Eric would pioneer certain features or logic, as custom code, and then we would bring those features into the main adilas application.

Garrett Kirschbaum - Adilas intern and then full developer back in 2015. Stressful time of building and expansion. He and others helped run the adilas shop with Brandon's help. Garrett was a great developer and helped us standardize a number of tools and features. He was the first developer to work on sub inventory, back in the day. He also did other projects and helped with some developer management stuff.

Charles or "Chuck" Swann - Charles was an instructor at Bridgerland for web development. He builds custom websites, does amazing mock-ups, prototypes, and is a CSS master (styling a website using code). Chuck worked with Russell to help with redesign work, projects, and vision. Chuck worked fulltime for a number of years and now works and coordinates work done by a small hand-picked design and development team. Anything that needs some design loving gets passed over the Chuck and his small team.

Steve McNew - Friend of Steve Berkenkotter's. This Steve helped prep some whitepaper documents to help with getting adilas standardized and some internal audit type stuff. Mostly white papers and putting things down on paper. He ended up getting hired by the local school district and wasn't able to finish the process, but he got it started. He asked some great questions, and we had some good conversations.

Abby Elkins - Abby is Brandon's daughter. Her maiden name was Abby Moore. Abby, when she was little (10-12 years old) helped with some of the original concept artwork for adilas. Later on, she helped with content for the presentation gallery and then the adilas lite plans (fracture). Currently, she is working graphic artwork for different adilas pages. She's now in her mid 20's and has some awesome art and content skills.

Aspen Moore - Aspen is Abby's younger sister and Brandon's daughter. Aspen helped Brandon with some planning and counseling (mental help). Aspen also did some general business consulting with her dad Brandon.

John Maestas - Developer, backend server guys, and designer. John came to us through Dustin. John was uses as a jack of all trades on the backend and frontend. He did numerous projects, documentation, payroll, and page redesign projects. John was also very help to Brandon in working on the notes and comments on the SWOT analysis document. Many other projects as well. Good vision of the future.

Kiva Berkenkotter - Steve's wife. She helped Steve with various projects and planning sessions. At one point, she was in charge of paying commissions and collecting monthly reoccurring payments. Huge supporter to Steve!

Heather Moore - Heather is Brandon's wife. What a trooper. Cheerleader, support, ideas, and consulting. Huge asset to Brandon (me). Thanks Heather!

Jonathan Wells - Designer and mock-up guy. He helped to map out the system and created a number of deep mock-ups for adilas lite (fracture) projects. Great job catching the vision and putting those pieces into a visual representation. We still refer to his work when talking about fracture (future project for adilas).

Jonathan Johnson - Business consultant from Epic Enterprises. Met with Brandon and Steve in end of 2019 into 2020. Really helped us see some needs and opportunities. Later, helped Brandon with some other consulting when trying to define the fracture plan.

Calvin Chipman - Windows software developer. Calvin also did a bunch of web-based work, database stuff, label printing, and API socket stuff. Calvin was the first developer to use the adilas API's to create a native mobile app for a client. He also built a number of special developer tools used by some of our team to speed things up. He's the tool guy!

Cody Apedaile - Bryan Dayton's cousin, Cody helped with a bunch of JavaScript code and changes. He also spent some time working on the UML diagram for the adilas database. We didn't get things finished, but he was working on a new build your own interface (custom to you) for adilas. We ran out of funding. We want to get back to that project at some point.

Dave Forbis - Dave was the official "high tech gofer". He did a bunch of things. Graphics, project management, brainstorming, planning, sales, and helped with managing developers for the adilas shop. He was another great student. He came to a number of training courses and brought so much to the courses. He was also a big support to Brandon during some rough times.

Josh - There are three Josh's. Josh Wheeler, Brandon's friend and developer. Josh Sagert, developer and adilas user (worked tons on the discount engine), and Josh White, Steve's friend from California. Josh White has brought us a number of bigger leads and bigger players, like franchises, and other higher-end clients. Anything recent is Josh White, from California. He helps with networking, sales, and dreaming of new things.

Suzi Distelberg - Sales, training, and deployment. She also worked with some custom projects and doing step-by-step user guides. She has helped with all kinds of projects and even gone onsite for setups and training. Great asset!

Kelly Whyman - Kelly is Dustin's wife. Kelly was single handedly the best independent sales rep that adilas had. She did training, consulting, and sponsored a number of custom projects. Kelly helped Steve and Brandon with reports, functionality, and other things. She got so good at things, state contracts snagged her up to work at state and multi-state level stuff.

Molly Hennessy - Molly was another independent sales rep and consultant. She had numerous clients and got into doing SOP's (standard operating procedures) and other high-end documentation and training. Molly was an entrepreneur and even started creating some of her own product and services. If you search adilas on google, some of the other results are from Molly. Super creative and a great consultant.

Hamid Karbasi - Developer - He has worked with Brandon doing small websites, training, and small tasks. He currently is a manager at a retail store and brings some managerial type skills to the table. Willing to talk about concepts and how they apply to retail and other environments. He is also lightly helping with some planning for fracture.

Gene Spaulding - Friend, entrepreneur, and businessman. Gene is an old college friend. We had a number of friends in common. He has been a small mentor to me over the years. Way back, before adilas, he helped me get my first business loan for a project that I was working on.

Sharik Peck - Friend, entrepreneur, public speaker, physical therapist, and businessman. Good influence and mentor in ways. Sharik and I used to exercise together back in the day. Many of fun walk, run, and weightlifting session. Learning some conference and training skills from him and his wife. They have done really well pushing their product lines and doing some marketing. Trying to get some ideas.

Bridgerland Technical College - Use to be Bridgerland Applied Technology College. Not a person, but a huge help. This is a local technical college in the Logan, UT, area. Brandon's dad, Wayne, worked there. Tons of assets. They provided classrooms, training options, computers, and even an small incubation spot (starter office space) for the adilas shop during the startup phase. Huge asset!

McCorvey's Pro Shop - Also known as Bowling World. Client that had multiple locations. The started out with around 30 and grew up to the 90+ location level, all using adilas. Long time client.

Emerald Fields - They were the first client that wanted their own fully dedicated box and server. They had multiple locations and requested some custom code, reports, and features.

Beaver Mountain Ski School - Client that we helped them track their ski school (snow sport) lessons. Students, instructors, classes, and schedules. Custom interface dealing with elements of time and flex grid.

Bear 100 - This was the first event or annual event client that we did. They used the system for about a week each year. They had 350+ runners and their families that would be on the site for multiple days straight. It was a 100 mile running race with 13 aid stations and a small social portal for the family and friends to watch their runners. This one was special as it had custom input options to upload CSV files to populate the database vs normal HTML form field entries. Records were sent in batches from remote places to adilas for storage and race progress.

High Valley Bike Shuttle - Online ecommerce and scheduling client. They also have a cafe and small retail store. Fun online scheduling and bulk flex grid projects.

Herbo - Mike Roundtree, owner of Herbo, was the first company to do a small white label of adilas. Mike has been a great asset to Steve and the two of them have worked on projects, plans, and dreams. Herbo also has a custom payment solution that they are trying to market and get rolling. Mike has been a great supporter for years. He is also a certified CPA and that credential helps us and him. We would like to get other CPA's on board as well. Thanks Mike!

Nxtlinq AI - AI assistant. These guys really pushed us to get an AI agent inside of adilas. Tons of development took place and lots of prep stuff. We wanted to do a 3-part plan for integrating AI. 1. Teach it how to navigate using the AI quick search (check - done), 2. Teach it all things adilas. and 3. Teach it how to be clear up at the consultant type level. We only got the first phase done. Lots of other plans and such, but we ran out of funding.

Grok AI - Steve loves using Grok. He has built a number of image generation options inside of adilas. He is also working with Grok to feed it data to help with analytics and AI insight. This is not finished yet, but we may end up using Grok as an AI assistant inside of adilas. We have simple and emerging connections available right now but need to really polish things up before going live with the AI assistant options.

ChatGPT AI - We have started using ChatGPT to help with code, explanations, explore resources, planning, and help with training and flow for people and other AI bots. Currently, Brandon, Steve, Bryan, Alan, Josh, Russell, Chuck, and Wayne are using AI in either ChatGPT chat sessions or some other form of AI. We have some using Copilot, Gemini, Claude, etc. AI is actually helping in many ways. ChatGPT is a big one for use. Anyways, they are earning their place in the adilas key contributors list.

There are so many more that I can't list. Developers, users, power users, reps, consultants, trainers, clients, accountants, friends, family, and even critics. They have all helped out the idea farming process and progression. Good stuff! We couldn't have done this alone. It takes a community to do what we are doing.

Lunch meeting with Bryan. Talking about goals, direction, and what we are seeing. Some of our conversations were talking about our team, the next vertical, and what are our plans to get there. Where do we want to be in a month, two months, a year, etc.? Great conversations. I gathered that Bryan has been out selling this thing (adilas software) for the past couple of years here and there. Not fulltime, but he has been hitting the streets. He has some good information and things that I could glean from his experience.

As a side note, what if our next business vertical is selling our kick butt business engines to entrepreneurs or outside parties and helping them skin it and market it. That is right in line with our value add-on core model. Let's do that. We have a generic business tool, on purpose. Now let's start putting the industry specific skins on it. Build out the API, build out the ways to do the custom skins, etc. Go in that direction. Keep finishing up the MVP (minimal viable product) for a full-on business engine. Go sell the engine.

As a follow up - as I was driving home, I had a few thoughts. I sent Bryan a text saying that our next business vertical could be selling our business engine to other parties. He wrote back and asked, who would be our competitors? What language would they write it in? Are you thinking open source or something different? Great questions. I wrote back and said... I'm not sure. On the language question, if we build it, we will code it, using the languages that we use, and then put it on our servers. If they used an API, they could host it and use any language that they want. Some good questions, we might want to look into this a little bit deeper. Fun lunch meeting and fun to think about ideas and options.

Working on some more global CSS changes for snow owl pages (adilas CSS theme). Mostly working on form fields and formatting for text, numeric, text areas (bigger notes fields), selects (drop-down menus), and other form fields. Pushed up new code.

Emails, paying bills, reviewing notes from over the weekend. Planning for a meeting with Steve. Reread some great poems that have a great message. Click this link to see the poems (on a different entry from a couple of years ago). Pushing up videos to a new folder inside of google drive.

Translating from post-it notes on 1/11/26

- Sunday morning - I was shaving, getting ready for church. I had a flood of ideas come into my head.

- We go for it on 4th down (football analogy)

- Reinforce the team - goal 1

- Goal 2 - We make sure that keeps working (meaning goal 1)

- Morning meeting at 9:30 am (get some communication stuff going on)

- Let people (our team) run... minimal on the micromanagement

- We focus on people... there will always be more projects and features

- CSS on forms for classic looking forms in the snow owl theme

- Look and feel to snow owl - help fix internal and existing pages look good

- Training - could be internal training, AI training, or external training

- Presentation Gallery - Keep pushing on that project

- Images for the adilas lite plan and the investment opportunities

- Abby - Talk to Steve about getting her involved

- Work with the design team - Chuck, Piper, Sarah

- Move key videos to Google Drive vs on the content server. It just can't serve them up quick enough.

- On the AI Agent - Use what we have - Set it up so that it tells people "I'm good at nav" - Polish the 350 existing prompts and tools.

- Suzi - Step-by-steps - small documents with information and instructions. She is really good at that.

- Sean and Cory - General Training

- Prepare for 100+ new accounts - What would that take?

- Open things up!!!

- If needed, we have others who can help - Dustin, Eric, and John. There are others as well.

- Shannon - She has been such a great helper to me

- Let Alan lead out - Help him succeed. He can do so much more than code.

- Get out of the way

- Leverage debt - put all of the adilas shop or adilas lite stuff into adilas as real payables - bring it out of hiding - true costs and costing

- Co-owner Advocate - possible new title, if needed

- Mini bank accounts for each person and/or department - help the team feel safe, supported, and funded

- Be in someone's corner - believe in them

- Overcoming fear - Satan wants us to run and hide

- Simple 1-pagers (one-pagers) - at a glance

Working with Bryan to look at some future development for a school that tracks native american students and some of their goals and progress. Going over plans and talking about ways to setup the one-to-many relationships that they need. We briefly went over some document management (custom documents and assignments) and connecting to custom paperwork options. We also talked about stepping away from the computer to do some planning. Sometimes that really helps. Otherwise, you get distracted.

These were some notes that I was using and working on. It was somewhat of a tick list of things that I wanted to do and/or add. There are a lot of square brackets in the entry. If you see [] (two square brackets - back to back), this is where you would enter the correct variable or dynamic prompt of a name, a value, a numeric id, etc.

------ start - ai options and prompts -----

done - build a function to pull out sub filters - pass in the whole string and what we are looking for. return the trimmed value.

- make a new help file with everything all listed out... help ai know what to do.

- url help... search_action.cfm?aiSearch=[prompt]

- mini api help - web/adilas_mini_api_calls.cfm?useCorpKeyId=[corp key]&mode=[mode]&aiQuickSearch=[value]

- samples - expand as needed

- calls and actions to the url's - double thread, simple response, stupid simple - maybe out in web or public, predictive level, show subs, mini async calls, predictive material to work with, show all categories, show all items under that category, same with customers

- cart stuff...

- items by vendor [name] ai quick search and mini api

- items by category [name] ai quick search and mini api

- my cart favorites - expand when ready

- edit cart line [cart line id], adv edit cart line [cart line id] - when looking up, remember line sorting and lines with 0 qty (skip)

- invoice mini [555], invoice mini last, invoice mini max

- invoice max

- invoice edit main [invoice num]

- invoice edit lines [invoice num]

- customer log [customer id]

- credit card checkout (checkout credit), cc checkout, external cc checkout, maybe spell it out as well

- on account or payment on account

- loyalty points

- gift cards

- cart groupings (sorting things)

- cart stuff - remove line [cart line id], change qty [cart line id], cash with change due, adv checkout, start cart for 5555

- classic cart settings, mini scan cart settings, view classic cart, view kush cart, view mini scan cart, deliver options, split cart, bulk edit line items, save cart, save quote, save as new quote, refresh cart, choose subs, add sub inventory with a quantity, auto open next sub package, cart as a whole discount, show discounts, other special cart functions... look them up and add items

- help all, help [search], help -title:[title filter], help -main:[main filter]

- back, back [number of pages], forward, forward [number of pages]

- bank home, bank running, bank reconcile, bank bulk verify

- developers notebook [search string] - expand when ready

- my home or just home

- gps core

- interactive map

- items by vendor [name] - ai quick search and mini api

- items by category [name] - ai quick search and mini api

- mini calendar

- ecommerce settings

- email settings

- media content [search filter] - - expand when ready

- news and updates

- my settings, my profile, my password, change password

- homepages [homepage name] - expand when ready - this could be a big section

- a/r's, a/p's, payroll, fulfillment, settings, cultivation, production, back orders, special accounts, adv exports, reoccurring invoices, go through permissions and pages - expand

- chooser

- corp admin, corp wide settings, admin corp wide settings, corp look and feel, corp stats

- history home, history [date]

- switch corp, switch corp [corp name]

- my favorites

- p&l, p and l, profit and loss, income statement, adv income statement

- page level actions... submit, select, select option, tab, shift-tab

- public shortcuts (corp id 7 simple prompt) - not sure what this means... it was part of my notes. maybe think on this a bit.

- bulk tools - expand as needed - define as needed

- labels - expand

- existing normal quick search options - see search action or help file

- edit main, edit lines, verify, history, add photos, add media content, add payment, edit payment, printable, etc... normal actions per section

- duplicate time, working with time, add sub, add flex grid, add limited flex grid

- for me - if they are already on an existing main player... maybe remember the type and the id... then the other edit main, edit line items, history, etc. will play through better. help it remember where it is or what it is dealing with...

- for me - change the options and prompts to an accordion style page - printable list - translate or interpret language - also make a new help file that is public facing

- take time to record what is possible... help train users and ai agents - think the value of education

- add links to the ai quick search from the main headers and chooser page

- last [count] - for example: customer last 10 or invoice last 25 or po last 5

- stats - use this to get basic stats for a section - for example: customer stats, invoice stats, po stats, item stats - maybe even some keywords... today, yesterday, this week, last week, two weeks ago, tomorrow, next week, this quarter, this year, last year, etc. maybe allow for day, month, year, range.

- special reports - daily weekly, closeout, knox report, grouped, etc. think of special options and reports that are used all of the time.

- logout

- images and media searches - general, specific main player groups (customer images, item images, expense images, etc.) - maybe some small filters like -from_date:[date], -to_date:[date], -caption:[caption filter], -user:[payee/user id], etc. media could be similar...

- organize all of the ai quick search pieces according to the main business functions. that will help show what we can do. don't get stuck on the number 12. it could be whatever... - link to the presentation gallery - business functions

- show [], show prompts, show homepages, show pos options, show crm options, show payroll options, etc.

- what about creating some more quick search permissions... things like help, ai, images, media/content, navigation (nav), etc. That would be cool and would create some great crossover between the older quick search and the newer quick text options and prompts.

------ end - ai options and prompts -----

Meeting with Bryan to go over some new requests for the Benning golf tournament. They sent us a whole email with a list of things that they wanted to tweak and change. Bryan and I were going through requests and looking at options. We added a new generic customer to help skip login and make the flow easier.

Working with Shannon. Spent time working on describing the industry specific skin section of the adilas value add-on core model. See below for some of the content that we came up with.

Industry Specific Skins Level - White Labeling

The next, or second, layer above the core is what we call the industry specific skins. Imagine taking the generic adilas business tool, the adilas core, and then building software specifically for a business vertical. The new software package has exactly what they need, looks like what they want, and caters to their specific business practices or processes.

All of the other pieces are hidden and/or behind the scenes. With an industry specific skin, you can toggle on and off almost anything that you want. Change any of the verbiage, language, steps, and even the flow process. It becomes fully custom.

Every business has such diverse needs, wants, and even flow. For example: Say you were a car or trailer dealership. You would be dealing with stock/units (serialized inventory), floorplans, commissions, paperwork, etc. If you were simple retail, you would be dealing with barcodes, touchscreens, tons of different widget inventory, quick counter sales, and different payment options. A service industry may need scheduling, reoccurring billing, and a focus on customer care or support. You get the idea.

Building industry specific skins help us, as a company, cater to the exact needs of those business verticals. This also helps our clients feel like they have industry specific software that was built just for them. The true secret is the powerful underlying core. That's what allows all of this to really take place per business vertical and allow unlimited possibilities.

The white label option deals with a company wanting to brand and sell one or more of these custom industry specific skins. Each white label will, or could, have a completely different brand, feel, or flavor. For example: Say a specific skin for bowling pro shops, ice cream shops, pet grooming, quick retail, health and wellness, hobby shops, etc. Lots of potential! If you want to learn more about our plans for the white label options, see this page that has some adilas investment opportunities. The white label content is number 4 in the last section, ways to invest in adilas.

Meeting with Cody. Going over the PDF reader code that he wrote (parsing and stripping out data values for tax withholdings). We then jumped over and started looking for a new project for Cody. He ran a global find and replace for the list contains vs the list find functions. I need to check that out and get it all merged into the system or the master branch.

After that, we switched over and he will be working on the total time for sub dates and times. I showed him some existing payroll stuff and we spent a bit of time looking around and finding the different pieces of the puzzle. His project will be in the sub dates and time, not in payroll, but they are similar (calculating total time). We also did some just in time project management (our specialty) and planning. This project was started by Steve and Eric last March of 2024, and it is already 3/4 of the way done but it needs some light detail work. I'm hoping that Cody will be able to follow things along and help make it just a little bit tighter, which will allow us to fully use it better.

Meeting over Google meet with some of the guys from SymLiv (https://symliv.com/). SymLiv is short for Simultaneous Living. They cater to gated communities, HOA's (homeowner associations), and other important security access venues.

My friend, Gene Spaulding, former banker and private equity investor, help to setup the meeting. The goal was to see if there were any common ground between what adilas does and what SymLiv does. Great meeting. There were four of us on the virtual meeting. We all live in the same area, in Northern Utah, and will most likely get together in person in the next couple of weeks. Here are some of my notes.

- Those where there: Taylor James from SymLiv, Tim Greenfield from SymLiv, Gene Spaulding, and myself.

- We talked about startups and accruing technical debt (old or unorganized code - anything like that).

- We went over what SymLiv does and where they are heading. See link above to view their website. They are very focused on a specific vertical and have big plans and more phases to do in the future. They were giving me some good advice as well.

- They had questions about adilas and what we do and where we came from. I gave them a small history overview and we chatted about all kinds of things. That was really fun for me. (history and investment options for adilas - small summary - see different sections on this page)

- We talked about SaaS (software as a service) and how that reoccurring revenue model is going and working. They highly recommended that we look into the transactional reoccurring revenue model as well. Something along the lines of payments, processing, small percentages of sales, per transaction fees, etc. This is what Tim said - "We are seeing that the transactional model is potentially bigger than the actual SaaS model." They were talking about multiples (raw numbers times a multiplier). I thought that was pretty cool.

- They were recommending that we either focus on making adilas a lifestyle business or change the focus and put an exit strategy in place. Basically, if we keep going, the way we are, we will have to keep working for years and years to come. That becomes a lifestyle, even if we don't have to do as much work. We basically maintain control and just grow things slowly over time (natural or organic growth). If the focus is more on exiting or getting bought out, then you play the game differently. Just some talks back and forth.

- All of the guys chimed in and asked questions and good dialog. I really enjoyed some of Tim's questions. They were deep and he wanted to know about certain aspects of things both technically and logistically. I thought that it was fun.

- Gene asked Tim, "What are your thoughts?" - I won't quote him, but Tim was basically like - If someone came to me, with a big dream, a plan and was saying the things that I was saying (just about adilas and what we are doing), he's not sure if he would believe it. Mixing operations and accounting and doing all of the things that we do is lot. That is super complex and may sound good on paper, but he just wasn't sure if he would believe it. He then said, if you were on the other side of that huge divide (meaning having done and/or doing everything that you had pitched or proposed) then that would change everything.

- We've put in the hours... We started back in 2001 and put in time, money (millions and millions), and have built it out. We have a working proof of concept, a working prototype, and have proved the model. Not only have we proved the model, but we've also made millions of dollars along the way. Way more than just a dream or vaporware. That's pretty cool!

- They recommended that we find a niche and follow that all the way. I told them that we are a general business package or generic on purpose and that our future goals include both white labeling options and industry specific skins (on top of the main adilas core). We would do that directly and/or allow for API socket usage and adaptation. Tons of options.

- How to make our customers "sticky"? I mentioned that we use the same term and sometimes do custom code to help those customers become more sticky (wanting to stay with us or stay around, while using our products and features). We played with some fun ideas, back and forth.

- Lots of talk about custom code and how to manage some of that. We ended up talking a lot about permissions and settings (some of the foundation pieces).

- They wanted to know the ratio between SaaS reoccurring revenue and other professional services (data entry, setup, training, marketing, custom code, design, consulting, etc.). I told them that currently, we are 70% SaaS model and the other 30% is other professional services. This brought on more conversations about multipliers and either focusing on SaaS multipliers or transactional multipliers.

- The more we talked, the more my head was going towards API sockets, API integrations, white labels, and other possible industry specific levels. That would help with marketing, development, training, etc. I love it!

- One thing that caught my ear was that they, SymLiv, are hardware agnostic (not tied to specific hardware). They also tout that they can interface with any other existing hardware, used in their industry, based on their current model. I would love to see what they have and/or are doing. We, at adilas, could really use that. We just barely got done with a very painful attempt to use some super old proprietary hardware for a company doing POS (point of sale) stuff. It would be super cool if we had a middleware type thing (some sort of software) that we could put on an older device and then be able to make a web, middleware, hardware bridge of sorts. We would really love that.

After the meeting, Gene gave me a call and we chatted for a bit. I recorded some notes and sent out some texts. I really enjoyed the meeting. It was fun.

Meeting prep. As the meeting got started, we had Sean, Cory, Alan, Steve, and I on the meeting. Here are some of my notes: Kinda all over the place.

- Sean has set up the logins for the new users up in Canada.

- Looking at what it will take to come up with an MVP (minimal viable product).

- Steve bought some new hardware. He will be playing with it and getting it all wired up and configured.

- How do we keep pushing the ball down the road?

- Setting up limits. We want to play but don't want to get ran over.

- Going over a list of to do items.

- Steve really chimed in on where he thinks that we are at. He really took the ball and ran with it today.

- Risk vs Reward - We spent quite a bit of time going over options.

- Steve is excited about the number of items that the Canada company has. It's really pretty small.

- Number of locations - lots of potential there

- Steve was talking about a book - "The Art of War." - Making deals and business stuff.

- Show what we have done - clover integration - $23K, features, advantages, and benefits, list out an MVP, show a percentage of what we have to still do, things that are not on the list... wishes, future desires, tablets - online orders and delivery, website, ecommerce, we do the POS software. We can help with hardware but that's not our specialty.

- We have some depth - adilas - operations and accounting

- Look at what we can help them with...

- Mission statement - help your business succeed

- Could be some scale problems as we go along

- Promises made and expectations

- Deployments - it can get dicey (interesting)

- We have... list it out - we have a solution

- Get them talking and thinking about something else - distract them what they are worried about - sometimes, what someone is worried about, they are not as big of thing as you think. However, if all you ever do is just think about that one thing, it can change your focus. You aren't taking in the whole picture. Get them seeing the whole or bigger picture.

- Hardware - pros and cons - come up with a valid solution and then allow them to choose, buy, or configure their own system

- We can see our way through a bunch of things - looking down the road

- We can setup corps... we haven't really done much mirroring of corps and settings

- Alan - Sunk costs, new costs, and building going forward

- Alan - Getting direction (where are we going as a company?) - He likes where we are going

- Cory - He (Aaron - owner) needs to invest in us. Money and time - how long will it take and what do we need to still build out?

- Steve and Cory going back and forth - nice little volley back and forth - risk and reward stuff.

- We want Eric to ask for his other stores to be on adilas. Eric is a store owner.

- Alan - Once they are up and running, they may not need more right away

- Steve - We can build anything... there is a line or an end zone - a goal is in sight

- Goal - What will it take to get this thing to launch?

- Alan - Questions about customer support and server up time

- Alan - Other possible services - customer support, training, etc.

- Alan - They are trying to see how serious we are? Almost a test on us

- Alan - We get our hardware stuff up and running and we show that we have a solution

- Steve - Give us a list and we'll cross it off

- Steve - Like a game of football - How much time is left in the game and what are our plans?

- Steve - Pushing this company further down the road

- Steve - This could be our golden ticket - Let's punch it!

- Alan - If we don't do this, then what? Let's use our current team and get it done.

- Alan - this is not vaporware... this is right here in front of us

- Steve - They could be the last client that we ever need

- Helping them see the future and wanting to stay with us

- Steve - What about global ecommerce stuff and then locations where people could pick things up

- Steve - They, are looking for us... they hate some of the competition

- Cory - We may need to fake it (customers, gift cards, and loyalty points) - We have all of those pieces, they are just at the corp and cross-corp levels. Not at the enterprise level yet. If needed, we could just have them run per corp until we get the other pieces. That's our fall back.

- Alan - Just noting that we only have some data (not all of the locations). If needed, we could do it per location

- Cory - Wanting to setup some action items

- Steve - Wants to start a list, send it around, tout our horn, and show who is doing what

- Steve - Assume the sale

- This is a test

- If you are going to fake it until you make it, you need to pretend that it really works and it already exists - smoke and mirrors. We've been at this for over 20 years. There really is a lot there.

- Alan - We can't over promise - stick to the basics

- Steve - We are working on... Steve-hardware, Alan-enterprise, and Brandon-reporting

- Communication - short and sweet but keep it moving

- Steve - Asking about customers... direct vs enterprise

- Sean - On new customers, they just need a few fields... such as: first name, last name, email, cell phone

- Alan - Let's do the customers and gift cards at the corp level - We'll clean-up later

- Steve - He is planning on using one printer to handle both receipts and cup labels - sticky receipt paper

- Steve will work with josh a bit to help with direction

- Alan - Enterprise is a value add-on piece. We need to figure out the pricing structure there.

- Alan - We will gain some momentum as we keep doing the enterprise stuff - this is where we are heading.

- Alan - We add a lot to adilas but we never up our prices - We need to manage that better to recoup or get ROI - Dynamic billing

- Steve - no Metrc (statewide compliance system), under 100 items, not even tracking inventory yet - Let's do this thing!

- Sean - On ecommerce, they aren't really tracking inventory, they just need to use their menu and go for it.

- Steve - simple on what they need, scale on the reporting and needs - here we go

- We are figuring out where we are going... Okay, let's go!

Yogen Fruz Projects:

Completed:

1. Ability for the Browser on the FranPOS to access the adilas SAAS. (Suzi)
2. Setup test system with all items and buttons. (Suzi)
3. Reconfigure and add settings to POS environment. (Brandon)
4. Beverage and inventory labels (Stephen)
5. Research on Menu Boards (Stephen)
6. Setup e-commerce (Suzi)
7. Live test transactions in Canada for 2 days (Suzi)
8. Clover processing integration (Alan)
9. Live pilot in Canada (Sean and Brandon)
10. Icon Report for Eric's store(s) (Stephen)
11. Gift and Loyalty (Brandon)

In Progress

1. Gift and Loyalty (Brandon) - done
2. New hardware testing (Stephen)
3. Website discussion (Dustin)
4. Enterprise scaling (Alan)
5. Small update to the Icon App Report (Charles)

Future Projects (Included or Co-Funded)

1. Menu Board (Stephen)
2. Website (Charles / Dustin)
3. Delivery API (Alan)
4. Additional Reporting (Brandon)
5. Canadian nomenclature, such as State being called Providence, and Zip Code being changed to Postal Code (Settings)

Up helping with the Yogen Fruz deployment with Sean up in Tronto, Canada.

Here are some notes and recap:

Sunday - 10/27/24 - Drove to Colorado. Needed to get a passport and Utah didn't have a passport agency place.

Monday - 10/28/24 - Spent the day in Denver getting my passport. Had to go back to the passport agency a couple of times. One for the initial appointment and another time to pick it up and verify information. While waiting, did some research on my cart favorite buttons, smart groups, tiered pricing and rules and assignments for the smart group buttons. Met up with my brother for dinner.

Tuesday - 10/29/24 - Went to the Denver temple in the morning. Spent some time playing around with Affinity Designer and learning how to control color and saturation levels. Graphic stuff. Drove to Salida, CO. Met up with Steve at his house. We chatted about some upcoming projects and challenges. I really liked his house. He had redone some rooms, cabinets, counters, rest rooms, and such. Super cool! Craig came over and gave me a bunch of adilas checks. We talked about goals and ideas for the Canada trip and venture. After that, I met up with Mrs. Shari O. up in Buena Vista, Colorado and we had dinner together. Great time and fun chatting. I then got to go see Shari O.'s house and dogs. Super cute. Visited my friend Andy Maupin and then drove up to Denver.

Wednesday - 10/30/24 - Slept in my car in the airport parking garage - fun! Flew up to Canada and Sean picked me up in Tronto. We went to the hotel, got settled in and got some dinner. After dinner, we went and found a store to get some snacks and other food for the week.

Thursday - 10/31/24 - Trick or treat... We got tricked... :) We went to headquarters and met with some of their team. We got there at 9:30 am in the morning. We didn't leave until after 12:30 am, that night. Super long and stressful day. Tons of hardware issues. They wanted us to fully configure the old FranPOS units (7 year old Android tables with a locked software system installed). We were attempting to run adilas (web-based system on that unit). The browser part worked great (normal adilas stuff). The ability to interface with the peripherals and hardware were crazy tough. We couldn't get anything to work. Totally beating our heads against the wall. Trying all kinds of stuff. We did have some help from one of their team members (Harsha) and that was about it. At one point, it looked like that was the end... The main boss on their team was saying, it doesn't look like we will be able to deploy this software. Sean and I asked for leave to go to the computer store and purchase some things that we knew would work (new hardware). We were also somewhat waiting on another one of their team members who hadn't come in yet. He was a tech savvy guy who had been able to hack the locked code on the FranPOS on the last visit from Suzi from the adilas team. Without going into crazy details. We got some new hardware and started setting it up. We were also blessed and the other IT guy (George) from their company came and was able to get some things going through on the older hardware. Pretty stressful day.

Friday - 11/1/24 - Went to the mall (Square One mall in Tronto) to help get the system up live for the client. We were needing some help from the IT guy. He was a little bit late, we had it mostly running before he came. He put the icing on the cake and made it work. In the meantime, I ended up recoding some of the my cart favorite buttons, making them bigger, and styling the mini invoice (customer receipt) format. Sean was doing some training and by mid way through the day, it was going super smooth. If it wasn't for the hardware issues, we could have been in and out in just a few hours. Anyways, good day and they seemed to like the system. Answering random questions here and there. By the end of the day, they had done over 150 invoices (sales tickets) through the system.

Saturday - 11/2/24 - Went back to the store (Square One) to help out and see if they had any questions. Had lunch with the owner (Eric), great guy. I spent most of the day fixing small little things to help with flow and settings. Fixed a few information messages and added a new setting to control the auto print option for the mini invoice. Good day.

Sunday - 11/3/24 - Woke up early to update all of the time zones on the servers (daylight savings stuff). Sean and I went to church and then did some site seeing (Niagra Falls and such).

Monday - 11/4/24 - Back to headquarters. Worked on uploading customers. Sean was helping and doing some training. We spent some time and put together a small email with a list of to do items. We then had a meeting with some of their team to go over the email and to do list. That was really good. I met with a couple of people and setup some new accounts for some of the accounting people. Towards the end of the day, I got a chance to chat with the main operations boss (Phillip). I enjoyed that. Trying to show him what we do and how we do things. He has a lot of things going on.

Tuesday - 11/5/24 - Sean dropped me off at headquarters and I worked there all day. He took the rental car back and flew home. I spent most of the morning working on loyalty points and getting data entered into the system. Various questions, different sessions, etc. Towards the end of the day, I did some group training for four of the main people (Phillip, Rex, George, and Harsha). I thought it went good, hopefully they enjoyed it. There is a lot to cover. At the end of the day, I found a good spot to stop and did some light planning. One of the guys gave me a ride home (Rex). He was pretty cool! Just being silly but I got back to the hotel and said, "I'm alive!". I was super happy. We still have some things flapping in the wind but nothing that we can't tie up and/or fix. All in all, I was pretty happy.

Wednesday - 11/6/24 - Took a cab to the airport and got all checked in. I spent some time going over emails and what not. I hadn't checked them too much for the past week or so. Somewhat behind. Flew home and drove from Denver to Grand Junction, Colorado.

Thursday - 11/7/24 - Drove home from Grand Junction, Colorado to Logan, Utah. Stopped along the way and had a 2 hour phone call meeting with the adilas team (Steve, Alan, Cory, Sean, and I). Had a little car trouble but got home safe. What a trip!

Meeting with Steve and Alan. Going over budgets, pay offs, timing, talking about the approach, don't talk about positions, pitch the sale ($150 internal vs $75/hour - using some of our guys directly). Steve was and has been selling pieces of custom code to our clients. He would like help there and have the guys pitch their own services.

We spent some time talking about our identity and who and what we want to be. Taht is coming along. Here are some other general notes from our conversations (multiple topics):

- Help protect our clients...

- Set some caps on how much our developers can charge

- Communication back to the clients - weekly reports and billing

- Billing - weekly

- We can't let our developers rough up our clients

- Helping our guys succeed - plans, billing, communication, oversite, etc.

- Possible kickback - commission to adilas

- It takes so much time to crunch things up - sales or custom code - the reality of what it takes

- Can't keep pushing things over to the balance sheet (code or projects for Kelly) - it costs of too much. We pay the developers and we owe money back to Kelly.

- Consultation document or a checklist type doc

- We are generic on purpose - if you want it custom... you've got to pay to optimize it

- Setting up boundaries and being firm on that

- An add-on cost for custom work - they need to pay for it - they may need to keep paying for it (reoccurring) - maintenance

- Selling what we have

- Our development and sales focus is as a general business tool

- Elevator pitch - web based, SaaS (software as a service), we focus on operations and accounting, we have a base model, and we allow custom

- We want to be generic. We want to cover a number of industries. We want to be a great companion software for any business.

- This is who we are - defining ourselves and what we do

- Plans for our upcoming meeting with the developers - take care of business and setup another meeting where we have some plans all made up.

- The developers may have some ideas on how to make things work

- How can we get some of the cool stuff exposed to the public? Selling what we have. - sales - nobody is pushing it, our tools and features, as a product.

- Alan had the idea of using an outside marketing firm - when ready

- There is a need for marketing, education, etc.

- YouTube influencers - quick, short, and powerful mini messages - short and to the point

- Podcasts - how to run your business, tips, tricks, and best practices

- Piece work - we have tons of stuff - what if someone could harvest that kind of stuff? - YouTube, Facebook blogs, podcasts, etc.

- Alan would like to talk about the future - looking short term, medium term, long term, etc. - talking to Steve, Brandon, Shari o., Wayne, Cory, etc.

Working with Eric. Going over some AJAX Json parsing errors. Lots of back and forth and trying different things. Couldn't find the error or figure out if the page was refreshing itself or somehow routing differently. Kind of a weird error. He may need to get with Alan (other developer) to see if they could figure things out. I helped where I could and was a second set of eyes, but it was kinda getting over my head.

Meeting with Steve. Responding to the problems and requests, that's what we do (just in time problem solving). Steve jumped off and I started working on implementing the new deli style barcode (complex barcodes) stuff into the mini scan cart. Before I did that, I spent some time and beefed up the sample deli style barcode tool. I also checked in with Bank of America about some funding options. Reviewing some documents from Cory on deployment practices and light budget numbers.

Meeting with Steve. Going over new settings. We have or there is a small communication gap, even within our own team - who is doing what and what is either live or in progress? Crazy how quick things go and change.

We spent some time going over notes from different client meetings... Liberty Machine Works (stock/unit stuff), Lucky Puppy (time and scheduling and texting), etc. Lots of moving pieces.

Went over the new label builder progress. Talking about next steps for American Made (more sub inventory rules and controls, faster PO ordering process, and speeding up steps). We also looked at their deli barcode labels (standalone complex barcode). The scale was purchased from a different vendor, and they just want to use it and have us interpret it (what the barcode means). Talking about building complex labels.

Meeting with the Lucky Puppy or Puppy Palace folks (dog nails and grooming service). They are looking for a multi-relational pets to owners, pets to techs, color based key, and tons of other things. I showed a small demo of the backend code and where we are at with things. They wanted to know where we are heading moving forward. They are a potential client and we are looking for ways to help them out and solve some of their problems. Suzi recorded the last half of the meeting when they were showing us some of their needs. These are some of my notes:

- As a disclaimer... I went back through the video and refined my notes. Original meeting was on 8/22. I rewatched the video on 8/26 and added a few more notes on 8/27/24. We already have a ton of these pieces. This meeting was to show us what they are wanting and needing and how we will need to put it all together. Just guessing, but I'd say we have 85% of all of these things right now. We just need to tweak a few things out, make some plans, add some new settings, and alter the flow a little bit here and there. That's awesome!

- Choose a customer, choose a pet, choose a service(s), choose a color, choose other assistants, check in/out, create a cart, manage the tips (split tips - they really want this... this was huge). Be able to copy the booking and rebook it (docking and rebooking). Email and text message back to the client. That's kind of a summary of sorts.

- Be able to edit the cart and add discounts during checkout

- 100 appointments a day - phone calls, changes, super-fast paced

- Show cancelations - what was there - They like to see what has changed, moved, or been canceled

- Adding a new client and making it quick - currently, they are using first name, last name, cell phone, email, and zip code. Be able to add more if needed. We have tons of settings there already.

- Notes on pets ... name, type (breed), age, size, up to date on vaccine, does it bite? etc. - thinking about flex grid tie-ins or a custom table there. On the notes and records for the dogs, maybe group things and then allow a subset to be shown. Go from simple groups (say per pet name) to more complex, everything tied to that pet.

- Each service has a time (block of time) associated with the service - there are some pros and cons to that approach. Anyways, just making a list of things that they were showing us and asking for.

*** Fast... they love drag and drop - They would love to be able to easily drag and drop and edit a time slot (length of the appointment - longer or shorter) all done through drag and drop.

- Making the appointments, changing the appointments, etc. - planning for the next step

- Major color code key - they are using multiple colors - each one means something - allow them to set up their own keys and values and colors.

- Tie-in the monies a little bit tighter - they would love to see it more or better - currently they are using multiple systems and then running the cards on the side. They would love to see it all tied in together better. Ideally, they are wanting a mix of an integrated scheduling software package, CRM (customer and pet relationship management), full POS (point of sale), ability to mix both products and services, and manage the money part of the puzzle. Sounds like our kind of game.

*** Tip splitting is huge... keep track of things... tight - reporting the tips split by person (by tech). Help automate this for them. Currently, they have to do it manually. This feature is big enough that it is a make-or-break level feature.

- They are having a problem with tracking their dogs... and having to read the notes for each one, over and over. They need the multi-relational database between owners and pets. We want to really help make this nice. I was originally thinking flex grid tie-ins... We may want to look into a way of doing sub queries or special grouping to make it smoother. We could also do some sort of custom table or custom joiner table.

- Being able to see the whole picture... they need techs, time slots, rooms, services, and needs (client and pet needs). All tracked in one place. Fully customizable - show simple to more complex.

- Alerts on the appointments - little flags - possibly even color-coded tags and flags

- A 3D view of the techs, the rooms, the appointments, the needs, the conflicts, the crossovers, etc. - that would be super cool - just an idea

*** Email and text messaging - app messaging - they really want normal text messaging including conversations back and forth. Here are a few other things related to text messaging needs: - Send message when booking the appointment, send reminders - multiple, send appointment confirmations - auto and manual, send booking reminders - some of their appointments are booked out 4-6 weeks in advance. There was also some talks about sending out auto emails for different actions or steps. Those would need to be defined.

- Switched to a different software package - They started showing us "Rosy" (used for 8 years - lots of data and history) - this is a human salon based software package. Part way through, the switched and showed us a dog or pet care solution called "GrooMore". They, the client, currently used Rosy in one location and the GrooMore software in another location. They are looking to get the best of both worlds. Ideally, we, adilas can come up with a mix and blend of both and become/be used as a newer or custom software option.

- They would like customizable enterprise - multi-location controls and flow of data, pricing, processes, reporting, etc.

- There are going to be transition strategies that need to be involved as our relationship develops. They want to keep going, with minimal issues, get back data, and make it all smooth. At some point, depending on what we can show them, we may need some transition strategies.

- There are too many appointments - a glitch could really be a problem - high volume

- They would like the option of seeing the last service, if known, per client/pet

- They want the appointment to hold all services and all assistants vs each service being its own appointment and each helper being its own mini appointment. More relational database connections.

- Their customer and service look-ups were really fast - asynchronous calls - like ajax or dynamic select or predictive text searches

- Be able to set settings for future interactions - what they normally get - be able to save that (speed things up by saving choices per customer and per pet)

- They need both owner names and pet names to show up on the view - They also want to see both names, client and pet(s), along with all services (cart line items), as well as other assigned flags per appointment. These would show up on the rollover or mouse hover action (aka the popup or rollover popup).

- They are constantly checking the schedule (visual display) to make sure all is well - help them out - simple look and feel with all of the details under the covers.

- Simple to add the other assistants - some appointments require 2-4 extra techs - make that quick. As a side note, the main appointment may be for a certain time and the assistant may be for a subset of that time. All tied to the correct pet.

- Showing conflicts - on the fly - both from calendar view and through a setup flow

- Showing the scheduling for any other assistants. Along with that, booking multi-staff appointments and then making sure that things stay tied together.

- Simple process (how long - in minutes) - add the drag and drop (super cool). Allow for both manual changes or drag and drop changes.

- Docking - saving or moving things - everything that is attached (all attached) - be able to move or put in the holding queue (session or memory) and then pull that back out when ready. Even having multiple things in the memory queue if needed. That would be cool. If needed, we could reuse quotes as a template of sorts. We could also allow for multiple things to be put in the queue. Kinda like a multi copy and paste board of sorts. You just get to manage it (really simply).

- Confirmed or unconfirmed appointments - checked in/out, paid, etc. - different flags and colors per appointment

- Colors - new dogs, bite risk, etc.

- Be able to book multiple staff members at the same time

- Multi-level sliding modals to add things - pretty slick

- Birthdays - it is nice to be able to just put in years and months and back figure the birthdate (help them out). Allow for either a real birthday or back figure based on the approximant (years and months combo).

- Being able to add tags for clients and tags for dogs - each their own tags and flags. Each tag gets a name/title and a color.

- Medical issues and comments - be able to add/edit

- Vaccination records - tracking that info

- Vet info - doctor info and such

- Dashboards

- Conversational text messages and using a huge texting tool

- Intake forms - QR codes or links - they add their own documents or forms (confirm and accept forms) - let the clients put in their own details. These client intake forms would be handled through the ecommerce or client portal section of the application.

- Quick jump from day to day, week to week, and month to month

- Notes - intake notes, appointment notes, ongoing list of notes. Being able to search and filter notes as needed.

- Be able to add/edit the tags per person or per pet

- Being able to search clients or pets by the tags. Thinking flex attributes for this.

- They are doing some mobile on-site appointments. They want to pull up clients in that area to say we are in the area. They like to tag their client's general location (area) to help with targeted marketing efforts.

- Bulk text messaging based on filters or tags - batch send out things based on applied filters of the larger record set.

- Searching by pet name and then finding the client based on the dog or pet name

- Deceased dogs - dogs that have passed away - they still want to see it - maybe just flagged vs not fully deleting the pet profile.

- They would love integrated financials - in the end

- Reach out to Jen if I have other questions. Debi and her crew seemed to be pretty busy (booked).

- Just an idea, currently we allow for photos and media/content to be added to the main customer or client records. Up to 100 photos per client. Do we want to open that up and allow for sub groupings withing the photos for the specific dogs? We do allow things like this to take place for parts and general inventory items (photos and media/content for subs). Anyways, this could come later as well, if needed. Just an idea.

- Empower them on the setup and layout... Let them drive it - block sizes, what to show on the title per appointment, what to show on the hover (rollover popup), color keys, flags, etc.

*** vertical time view (a design has been built by Chuck - branch CAS-93)

- For me - claim some time - make time for it - review the video and make a plan... make sure that we have access to the correct demo site and make things flow there. Thinking about settings and putting the power in their hands - put them in the driver's seat. Wow - great meeting!

1/13/25 Bryan and Brandon meeting 

To outline what it would take in time/money to complete this project.  Then take the information to Steve and Suzi to decide if we are moving forward or putting it on hold. 

A ball park estimate without outlining each project would be at least 200-250 hours ($20,000-$25,000).  At 20 hours per week (which Bryan has available) it would take 3 months.  This project would be utilized in similar pet grooming and salon type businesses.  Currently Puppy Palace would utilize this.  At $300/month the ROI would be 5 years.

1. Vertical time view. (20-40hr project)

    a. Populate Charles' layout

    b. Already have a time slot view.

2. Add drag and drop. (done fairly quickly because time slots already exist - Javascript edit).

    a. outsource this to Cody (20-30hr)

3. Tip splitting. (20hrs)

    a. tips field exists (Eric) on the main invoices if using CC.

    b. open up so that any cart can utilize it.

    c. create a tips page.

4. Texting/email API. (30-40 hrs)

    a. Garrett/Calvin created apis with Twillio.

    b. General filtering (no "cannabis", other reserved words).

    c. They pay 3rd party directly, or pay through Adilas? Monitor and record that.

5. Flagging and Tagging tweaks (15-20 hrs).

6. Pet specific needs. Owner to pet, pet to vet, etc.

*** could be used for multiple Adilas projects.

Working with Eric on tips and tip amounts. Looking at a number of dev pages (special pages that have normal code plus dumps and aborts - stops). We made a bunch of changes and then pushed them up. Nothing major to report. The math seems good, not sure why it is being funny and sometimes showing correctly, and other times showing a flag or disconnect. Tricky stuff.

Working with Cody on the label builder app. He was working on images and being able to make those more dynamic. We talked about ColdFusion stuff and how to use the debugger as your fiend (secret little hacks and tips). We also went over how to invoke functions and methods using ColdFusion. Along with that, we spent some time looking at how we use dynamics to search multiple fields based off of app types and generic filters (both numeric or alpha characters). Lastly, we talked about flagging code with small "todo" list items to help us move forward. Basically, hardcode things and then circle back around to make it more dynamic.

Emails and recording notes.

Working with Bryan. Going over the QuickBooks API. Checking on data types and validation. Quick phone call with Eric to go over some ecommerce settings and checking on a rounding error. Back on the QuickBooks API stuff. Lots of chaining of independent logic and nesting the dependent pieces and flow. Trying to make it tighter. Doing some live testing with Bryan for our client. Small tweaks as needed.

New payment type for EBT (electronic benefit transfer - modern-day government food stamps). Added it to data 0 and then cascaded it to other servers. Meeting with Eric to help with ecommerce gift card payments and other money types (payment types). We did some local testing and resolved a code conflict. After working with Eric, went back to updating servers with new money types. Let Sean and Cory know that the new payment type was up and live.

Meeting with Eric. We looked at some code and did a small merge to help him upload gift card data for a client in bulk. That went pretty smooth. We then looked at some code to use gift cards out in ecommerce. We had to refactor that a bit, add some security, and redo a little bit of the look and feel stuff (CSS). Got that code merged in and checked as well.

Reading over the code on the old discount engine page. Small changes to the JavaScript selectors and logic to use new values (strings - days of the week) vs older numerics (1-7). The old code use to just allow for a single day of the week. Prepping things so that we can have multiple days of the week tied to each discount, if needed. It sounds easy but the old code was imbedded pretty deep. Towards the end of the work session, started looking into the action page where things get set in the database.

Meeting with Eric. Checking on merchant processing stuff for a client. We spent some time talking about transactions that have upstream and downstream dependent relationships. We then flipped over and did some work on voiding out special account transactions. Checked some code and merged it into the master branch. New changes will roll out tomorrow morning.

Merging in code for Eric. It was a quick USAePay gateway fix. Recording notes from 6/17/24 to 6/19/24.

Working with Wayne - server-side tech support - checking into some random files on the data 0 box. Working with both Wayne and Alan and trying to check out logs and access points. A few different meetings over Google meet. Wayne decided to save a copy, then nuke the files, and then redeploy a new image. Eric joined and we talked about merchant processing, tips, and surcharges. Wayne and I were talking about upgrading security and updating Adobe ColdFusion to newer levels. No fun to be on a security call but it was good to touch base with some of the guys.

General stuff. 20 minute phone call with Bryan going over direction on marking parts as main items for auto numbering and grouping. That is his current project. 5 minute call with Eric to talk about USAePay transactions and automated payments. Printing out a check for Shannon. See EOT # 11048 in the shop.

New cart updates. Small spelling change and doing some split cart button clean-up. Added a new up button for the my cart favorite buttons. This allows a user in the split cart to go up the button chain (groups and button stacking). Phone call with Eric to help him get a USAePay sandbox setup for his local environment. Back working throughout the day on the up button. Merged in new code and tested on data 0.

Recording notes. Got on a meeting with Eric. He had an issue with a DAO (database access object) for elements of time and it not returning the correct record set. We could run the exact same query using raw SQL prompts or inside code but not as part of a component that runs things through the DAO. We did what we could. He may need to consult with Wayne, for a deeper database master to take a look at it. Recording notes from the week thus far (6/3/24 to 6/6/24).

Meeting with Eric and going over using gift cards out in ecommerce. He wanted to know where to put things and what pages did what. We touched based on some key pages and logic areas. We looked at code, recorded a few notes, and got him going in a good direction.

Phone call with Eric. Texts back and forth with Steve (small update). Merged in some code for Chuck and his snow owl changes for the add/edit payee and permissions pages. Switching branches and pushing up some database updates for Eric. Ran updates on all servers for cross-corp gift card rules. Recording some notes from the day.

Fixing an API socket for getting parent attributes. Parent attributes can have multiple different data types (what they do or what they hold). Originally, the API socket was only able to get numeric data back. The new changes allow for text, select, number, toggle, number select, dates.

Phone call with Steve to go over things. He gave me an update on some of his meetings and new developments. Lot of stuff is happening. It is amazing how fast things change and shift. Very dynamic environment. We are just trying to manage things and keep the wagon going. It gets super busy. We also talked about other changes that are being requested by clients, priorities and who is paying for what. Lots of stuff is getting done (progress) but we are currently taking it all on the chin (paying for it internally). That is great, but we are not sure how long that can keep going without some outside funding or help. We chatted about that (funding options) for a bit as well.

Phone call and then jumping on a GoToMeeting with Eric. Mostly talking about media/content and image or photo type questions. Looking at code and working on both virtual and actual paths (local vs live). Locally, we only have one development server. Live, we have multiples servers and they all have to interact and play a part. Light debugging and some back and forth talks. Crazy stuff and having to flip paths and variables between test and live and between dockers setups and more normal classic local server setups. We ended up pushing up some files, doing some live testing and debugging, and then coming up with a plan.

Phone calls with both Eric and Bryan. Back working on the cart and line item level groupings. Added a quick page to help flip between customer invoices and counter sales (no customer assigned - quick cash ticket). Just chipping away at things.

Two different phone calls with Eric. Talking about photos, media/content, image manipulation.

Meeting with Russell. I showed him what we are working on in the cart. We decided that we would make part of it into some AJAX and JQuery stuff to help it out. Spent the rest of the time talking about plans and prepping the files. We didn't get to work on any of it, but we have a plan and it's all prepped for next time.

Back on the mini scan cart customer search for an hour. Finished up things and did some testing.

Quick meeting with Bryan. Showed him where we are at on my stuff. Talked about next steps. We will meet up tomorrow morning and work together. I have an assignment to look up how to sort arrays and output the arrays.

Looking over Abby's history doc. Got a call from Eric and helping him merge in a code branch. Making plans with Abby to harvest some older resources (old site and photo gallery).

Merged new code branch into master for the mini customer search changes.

Meeting with Eric. He had me look up what he is doing on my phone. Trying to make it look like a native phone app. He is trying to use as much existing logic and code, just changing the flow a bit. He was showing me some flow and going over questions such as: logging, history, permissions, hardcoded pieces, etc. Talking about uploading images or media/content. I showed him some code from the bear 100 runner portal web app.

Recording notes from yesterday (4/16/24). Meeting with Eric. He was expressing a need for SQL (database) access to real server data. That really helps with debugging things (at least a view only option of looking at the data). Also, as we were talking, he was wishing that we had a full data dictionary (what fields in the database tables mean and/or do). We spent some time and went over payroll time clocks and project time clocks.

Working with Eric. We looked at a database update, ran it locally, and then merged in some code into master. We pushed new code up to data 0 and ran the database updates on all servers.

Meeting with eric. He was showing me some of the time tracker stuff. It gets kinda complicated mixing payroll timecards and project clock in/outs - all mixed together. We talked about some database updates. I ran them locally and then we tried them on the live servers. We ended up deciding to wait and push on the tie-ins and processes a little bit more before pushing things up.

Meeting with Eric. Going over query of queries errors. Tried a number of things with casting the date/time formats from made up values. Going over a number of scenarios but unsuccessful with casting dates and what not. We may end up flipping to numerics vs date/time objects.

Meeting with Eric. He is working on a mobile clock in/out (payroll) and project clock in/out (time tracking on projects) combo project. Eric is calling it a time tracker app. We were talking about relationships between timecards and projects and how to create that special relationships (new joiner table).Steve joined us on the meeting for a bit. Talking through ideas and going over flow processes.

Meeting with Bryan. Working on some demo flow options. Tons of stuff for the golf club demo site. We went over new carts, ways to track tables (say like in a restaurant), custom buttons, and other topics. Here are a couple of topics that need their own line.

- We would like to set it up to be able to setup and/or pass through flex grid items from the shopping cart to either customers, invoices, quotes, or elements of time. That would be so cool. Currently, you have to get out of the shopping cart before you can deal with flex grid tie ins (custom fields or custom one-to-many relationships). We talked about ways to do this and make it happen. Brainstorming.

- Putting multiple people on a single element of time. We already do this for places like Beaver Mountain (ski school lessons) and High Valley Bike (bike shuttle services). We just need ways to make it easier to do for other companies. You can already set it up, but you kinda have to know what to do and how to do it to make it really work. Also, some of those other businesses, we've helped them out by creating a custom set of buttons to jump into their specific flows. That really makes it easy for them. Basically, ways to speed things up and make it not so custom but a generic, yet configurable, toolset. Behind the scenes, we use a thing called limited flex grid to make the forms look super simple and easy to use.

- Bryan and I went over lots of options for splitting tickets or bills. Here's the scenario. Say a guy wants to set up a tee time (golfing) for he and three other friends. We need to schedule the tee time (calendar event or element of time). We also need to bill each person or put it on their tab. We can do that right now but we would have to do one of the following. 1. Create four invoices, one for each person and put it on account (they will pay later or their tab). Or 2. We make one invoice for the full amount and then let them, each person, make a payment towards the full ticket. You can do that right now but it doesn't put it on account for each one. It would just be an invoice with multiple payments. Anyways, we talked about some bulk tools for the shopping cart or ways of saying... duplicate this invoice for these people (bulk tools). Then it, the system, goes out and does it.

Just some ideas and discussion topics. Good stuff! Bryan is doing a great job asking questions and what not. Lots of fun ideas and getting him some training on the system.

Email to Wayne about ways to improve or fix the tables for storing sub inventory attributes and parent attributes. See attached for a copy of the email. It has some light plans on how we could change the columns on the custom_text table (and other custom attribute storage tables - numeric, text, date, and json).

Fixed the error messages and moved the unique id/error code to lower on the error message. Trying to make it look better. Wayne just added the unique id/error code a couple of days ago.

Started to work on an advanced search page that shows parent items, parent attributes, and sub inventory attributes, all on the same report. Bryan originally made the report. Just going over things and lightly cleaning things up. Refining some of the logic.

Going over the federal tax and payroll withholdings in the calculate payroll page. Ended up on a quick phone call with Eric to help him merge in some code to check on a live server. He needs to show someone the new page tomorrow morning.

Back on the payroll withholdings. As I got deeper into the mix, I found that they, the federal government, had changed how they did their withholding lookups. I had to alter some table values. Originally, I had done the wrong look-up tables out of the Pub-15 document (offical tax table document - 70 ish pages). They, the federal government, took off the pay frequency for the automated payroll systems. Previously, we have always added tables that had the pay frequencies built into the tables (daily, weekly, bi-weekly, semi-monthly, monthly, quarterly, semi-annual, and annual). The new tables that we were supposed to use didn't have that. I had to do some light tweaking of our code.

Anyways, got everything in and done and push up new code. Merged in the branch with master and ran some database updates. The new code will go out tomorrow morning with the auto deploy.

Meeting with Russell. Going over all kinds of stuff. Here are some of my notes:

- Notion (software) and setting up his own performance metrics.

- Experiencing all sides of it (meaning programming, managing, admin, planning, design, DevOps, etc.).

- Russell likes the frontend to the backend vs backend to the frontend.

- Talking about different roles, within a company

- Tech lead and/or managing over developer teams mixed with project management

- Make the developers plan it out and then run it through you

- High cognitive loads all day saps or drains your energy

- Talking about the working genius - took the evaluation/exam - https://www.workinggenius.com/

- Talking with Russell about some of the working genius concepts.

- We got my eval back and looked over it. Light back and forth talking about it.

We then jumped into Adobe XD to start working on a new mock-up (our little baby project). Starting with generic boxes and basic layouts (in XD). We had a rough drawing that we were working off of. We then started to mock-up and create placeholders for all of the pieces. Russell was putting info and details off to the side of the different places and/or placeholders. The design was really clean, the details were on the canvas (off to the side). Explaining what each thing does or needs, without putting any details on the actual design.

Russell was doing research to look-up what he wanted invoices to look like (google image search). Basically, look up ideas on the internet and detailing it out (what do we really need or want?). He also used the canvas area (in XD) to put other ideas and then even make choices/options. Dream big... then pull it back (budget scope). Lightly labeling the layout as it got more define. List of requirements. How does this work, what do I want, etc. - for me - see the snipping tool mock-up from adobe XD, just the concept.

Bunch of random stuff. New branch and patch from Wayne dealing with a local without an SSL and port number. Helping Drew from high valley bike and Eric with tips and change due stuff. Eric would like to keep working with adilas. He and I were talking about how Eric talks to other businesses and what angle he takes. He asks them if they could help him with development efforts by telling him what they like or don't like about their current systems.

I then spent some time looking over some adilas financials to help Eric see where things were at. Small history... Eric started out building the shopper app for a client. We talked about old code, in-line code, and adding things right into the main pages. We then did some light black box code. He knows that he is needed. He would really like to be a part of the team. Talking about managing the situation (growth or maintaining or shrinking). Sometimes shrinking is actually a valuable move to get things in or back in control. Going over growing pains (lots of them). We are both working odd hours based on family stuff.

Working with Eric and doing database updates. Pushed up some new code and ran updates on all systems. Talking about chart of accounts reports.

Working with Eric and Cory and trying to merge and push code. Merge conflicts between Wayne and Eric's code.

Meeting with Cory. Fixed a few elements of time to help close them up. On retention (potential adilas department - upcoming), Cory and I were joking around on who is going to take what. Going over other projects and rehashing to do lists for Eric, Bryan, and myself. We spent a lot of time talking about the chart of accounts project for Kelly. I was pitching a certain thing, and we were trying to see if it would meet her needs.

Working with Eric on the chart of accounts project. Light history about how and why we built what we built. Proposing a tabular view for the P&L and the balance sheet.

Jumped on a meeting with Eric. Debugging some code and running some tests for stock/units and wholesale carts for his tip project. As we were working, it was amazing how many places (code pages) that this little project hit. Over 48 pages that needed changes. That is just adding tips to invoices. Cause and effect to statements, deposits, accounts receivable, accounts payable, balance sheets, tons of different invoice versions (pdf, mini, printable, add/edit pages), reports, searches, logic, etc.

Lots of moving parts.

Three different meetings. First, I jumped on a meeting with Eric to look over some tip stuff. We ran an update on data 11. We also looked at a CFC (code and database queries) and I made some suggestions. Something was erroring out with invoices and combined tip amounts.

----------

Met with Cory for a bit to go over a new quote for Kelly. She really wants a new report format for both the balance sheet and the P&L (income statement). Her end goal is to get us closer to a consolidated report that she could mix and blend corporations and financials. She is calling it a chart of accounts report. That's kinda what it is, but we'll just go with it for now. We went over a video that Cory and Kelly recorded a few days ago. I took some notes. It was a pretty good video and really explained well what she was looking for. Her main goal was visibility and exportability.

Here are my notes: The video does a great job but Cory has that.

- kelly wants all existing columns in a full grid...

- combined view system generated and user-maintained items

- going clear back to the top level groupings

- they want to see destination, groupings, types, accounts, etc.

- visibility

- all three parts (bsi, p&l, expense types, deposit types, bsi types)

- destination, category, group, sub group, account/type (item name), system generated or user-maintained, drill-down - show everything

- they want chart of account numbers

- need balance sheet numbers

- show active and inactive

- show sort order

- working toward a consolidated report - multi corp - enterprise

- corp id and corp name

-----------

At the end of the day, I was helping Bryan with some code. He needed something merged and pushed up to a server. We did and then tested. We ended up rolling it back. He will look deeper and we'll push it up later on. It was for a custom report and needed to be tested with actual live data.

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

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

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

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

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

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

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

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

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

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

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

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

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

Emails and then jumping back on the yearend payroll updates. Working on 1099's. We have to do three different versions of the 1099 form. We have to do 1099-Misc (miscellaneous), 1099-NEC (non-employee compensation), and 1099-Int (interest).

Got a quick phone call from Bryan asking for direction on the next steps and next projects. Pointed him to elements of time and new settings that we wanted to work on - See element of time # 8004 in the shop. Also, we have a need to help write some code to help with syncing up certain tables between servers. We could automate a lot of that stuff. Currently, if we sync up database tables, we have to log into 20 different serves and pull down master files or database records. We could really speed that up by doing a push on asynchronous type actions and even automating the submission or pushing from the main server out to other satellite servers. We could also gain a lot by adding in a last modified date on the different tables. That could limit the size of our data requests and make things faster.

Phone call with Eric to go over credit card checkout processes and need for some new settings with multiple devices and multiple locations. We talked through a number of scenarios and Eric is going to formulate a plan and pitch it back to us. It sounded good, what I heard. We'll go from there.

Reviewing code with Eric on his tip collection branch. Making plans. We rolled out a small invoice homepage fix.

Work session with Eric. We ran some new database updates on all servers. We then jumped into a small code review session. We also talked about being able to add tips to multi-payments (one payment for multiple invoices) and payments that are made after the fact.

Quick touch base with Eric. We setup a time to re-meet on Wednesday. Small code review session.

Small work session with Eric. We were looking at his new code for the tips and collecting and showing tip information. We were pulling down code, running local tests, making small changes, and then retesting. Most of our work today was dealing with changes made to statements and accounts receivable logic. We will meet up later today to do some more work on this project after Eric makes a few more changes.

Code review for Will on the history homepage. Sent him some feedback on some observations and choices and small change requests. It's looking pretty good. Phone call with Eric to go over tips and how to show those on statements (summary of invoices, amounts due, and payments made). We talked through a small plan. We'll make a few changes and go from there.

Recording notes from 12/3/23. Working with Eric on his tip integration project. We were testing locally and talking about options. We are trying to roll this project out in stages. We also talked about opening things up to allow for normal tips, checking for double tips (cash tips vs EMV chip reader tips), etc. We got into carts, restoring quotes, duplicating invoices, printable invoices, statements, and accounts receivable stuff. We also checked some ecommerce stuff. Making progress and found a few things that Eric will fix and we'll retest in a couple of days.

Got a text from Cory to help look at a database issue on data 4. Jumped on a Zoom meeting and was working on debugging things. Eric joined us as well. With his help, we were able to find and fix the error. I was in the right area but was super focused on one particular part of the problem. I kept trying to fix a certain value to see if that is what the problem was. With Eric's help, we widened our view and were able to find the problem. The problem ended up being a lone parentheses that was in the wrong place.

Working with Eric to get everything ready to merge into our main repository. This is just a part of the branch (piece of a project) that will get entered into the master code branch. We are trying to deploy this bigger branch by breaking it up into pieces. We spent our time going over pages, code review, and going page by page, looking at things. I thought that we did a pretty good job! Merged the branch into master.

After I got done with Eric, I did some code review for Will on a new change that we talked about earlier today. We ended up moving a remote API socket function out of an older file and put it on its own. That solved the problem.

Work session with Eric. We were going over his new changes on his tip integration project. We did some light debugging. Added some better error handling on the database update script and talked about next steps. We planned a meeting for later today to push the next steps. That gave Eric some time to make a few new changes and check some things off of the to do list.

Tech support for our guys. Checking branches for Will. Phone call with Eric going over plans and updates. Switched over to the bulk clear customer loyalty points project. Fixing the page to work with both the classic theme and the snow owl theme (look and feel stuff). Merged in some code for Will and pushed it live on all serves. Emails.

Meeting with Eric to go over plans and developments in the tip integration project. Looking over files, making changes, and then retesting on my local. Eric was making the changes, I would pull them down and then run the tests again. Good work session.

Going over tips, rollout plan, and code review session with Eric on his tips project. We checked on some database transactions and database updates. We then pulled down his code branch to my computer and started doing some testing with me driving and Eric watching and telling me where to go. We found a few things to fix and I showed him some other places that he did not know about that tie into the accounting for the tips. We spent some time going over flow and user expectations. Making progress.

Going over the tip rollout plan with Eric. Talking about dependencies, plans, stages, and steps. We ended up running the first round of database updates. We then merged in some code and ran the updates on all servers. We may need Alan's expertise to help us push stuff to the next the level. We'll do what we can and then circle around.

Working with Eric. Going over a rollout plan for his tip stuff. His branch has 24 files, 2 current conflicts, and 15 cfc's (ColdFusion components). Lots of dependencies and internal changes. Tips sound pretty easy on the surface. It is going to get deep. It affects reports, invoices, math, deposits, payouts, balance sheet items, accounts receivable, etc.

We also talked quite a bit about USAePay (merchant gateway that we use). We have a need for some of our guys to have the actual hardware devices in their hands. We have some simulators, but the actual accounts and products are only available in a live environment. That adds a challenge. We talked about the need to better equip our developers with the correct hardware to help them in their coding and debugging processes. There is a cost to some of that. There is also a cost on the not having those pieces (more development time and even some guess work).

Anyways, we spent a little bit of time going over some ideas to help us out with R&D (research and development) type projects. We may look at getting our guys better hardware to test on and actual full or paid accounts vs just test accounts and simulators. It depends on the project. Anyways, at least having conversations about the needs there.

Meeting with Bryan. Made a few small changes to fix a bug. Spent the rest of the time looking at data and trying to figure out why or what is going on for a data disconnect for a corp on data 8. We ran lots of behind the scenes queries to check po/invoice lines, parts, time sub inventory, and fiddled with different joins and filters.

After our work session, I was on a phone call with Eric talking about tips and a new data flow process that is coming down the pipeline. We went over a few questions and talked about some of the cause and effect trickle down as we change things. We made some plans to reconnect and work on it on Monday.

Spent half an hour combing data and looking at live data for a client. They sent us a CSV file with customer info and loyalty points on it. The data is kinda messy. We'll have to do some major gymnastics to really make it work. Light prep work.

Two different sessions with Eric, going over tips, payments, and use cases and scenarios. Our first session was in the morning from 9:30-10 am. I had to bail out to meet with Cory and Shari O. We met up again at 11 and did some more talking and discussing. The main goal was tips, flow, and keeping financials in balance and in good shape. We also talked about either creating and/or using some mappings for new expense types and/or deposit types. We talked alot about EMV/chip readers, tips, and how to handle those credit card type transactions. We also talked about cash/check scenarios and how that is sometimes treated differently for tips and repayment.

Each corporation does their own stuff and handles tips in their own way. Some treat it as cash and cash out every night. Others hold it, track it, and pay it back out with payroll, taxes, and a rolling payment method. Lots of companies in between, including some companies that don't allow or don't even deal with tips. Lots of possible scenarios.

Some of our discussions got off into the weeds a bit. Adilas is so flexible, we allow our clients to sort of make up their own rules. That is great, but we may also need a way to help steer them in a good direction and/or help them enforce their own rules. If we create something, we can't just take that away. We have to leave it alone so that it can play through any past transactions or user history actions. That complicates things a bit.

We talked about a dedicated tip screen on the checkout process. That would help us gather the correct information and even provide us with enough information to process things how we need to, to keep everything inline.

Meeting with Eric to merge and push up some new code to help with certain merchants (our customers) who need to switch between a manual card entry, a swipe card entry, or a EMV/Chip card entry. We chatted, pushed things up, and ran some tests. Eric is going to call a customer and make sure that they know what to do differently. Trying to make things easier.

Finished up the code for the CSV customer loyalty points upload page. This allows us to take a CSV file, match it with existing customers in the database, and record manual entries for customer loyalty points coming from an outside source or outside system. Ran the code live and merged in the page with the master branch. Uploaded over 3,400+ entries with customer loyalty points for a client. Let both Eric and Cory know and gave them an update.

Working on the CSV customer loyalty points upload page for a client. Working on the logic portion of the code. Quick phone call with Eric to go over progress and ask a few questions. Getting close. Ran out of time.

Code review for Eric on his EMV/Chip and swipe/manual entry for credit card transactions. Made a few small changes. Called and talked with Eric. I got a call from John and we chatted and touched base on some projects. Spent some time recording notes from the past couple of days. It's been one thing, right into the next thing.

Emails and looking over some code that Eric was working on. His code was dealing with USAePay (merchant gateway) and showing options for switching between EMV/Chip readers and swipe/manual entry on credit cards. We have needs for both of those avenues.

Got a text from Cory asking me to jump on a Zoom meeting. We ended up adding in some special history logging on part category and sub inventory settings. We looked around for any bulk or global tools that may have affected our clients sub inventory template settings. We added the new code, tested, and pushed up code.

Meeting with Bryan for about half an hour. Going over progress bar stuff. He is still working on it. After that, I met up with Will Hudson who used to work with us back in 2015-2017 ish. He is circling back around and we were working on getting his local development environment all setup and going. We ended up doing some light debugging. After that, we went over some ideas for basic or generic website pages for our clients. I tried to show him the goal or vision of where it will end up. He'll start making steps towards that and we'll refine it as we go. Eventually, we will tie the new pages into simple settings, ecommerce, and the public customer portal that we offer to our clients.

Working with Bryan on saving large files as CSV files. We were talking about session variables inside of the CFC's (ColdFusion components) and best practices. Bryan is going to rework some stuff and get back with me.

On the phone with Eric. We were going over 2 main topics. One was his new code for both EMV/Chip reader credit card transactions and normal swipe or manual entry credit card transactions. He has a branch that he wants me to look over. The other major topic was dealing with an import for a client that had customer info and customer loyalty points from a different system.

After working with Eric, I tried to track down a possible bug with scanning a sub inventory package or sub inventory number. It ended up being a setting that prompts for a specific sub weight. I turned it off and the sub barcode scanning worked great. We wanted it to skip that extra step. Just had to flip the right setting. No code changes took place. I reported back to Steve, Cory, and Dustin.

Quick 20 minute meeting with Cory to go over projects and priorities. I then got on a phone call with Steve. We were going over general stuff, sales, demos, meetings, and new shopping cart stuff. Steve requested that I keep pushing on stuff and also help out with Dustin, Eric, Bryan, and Will. I wrote a few things down in my notes to follow-up on with the guys.

Quick phone call with Eric going over USAePay stuff and merchant processing options. At some future point, we may need better documentation and/or a hardware specialist on our team.

Meeting with Dustin to go over things. We started out on GoToMeeting and then switched over to Zoom. He had a list of questions. We jumped in and helped him setup his own new shopping cart. We may alter the name, but it will be called something like the integrated side menu cart. It's kinda custom but may be used by other people later on. I'm hoping that our little session will end up saving him tons of time so that he can hit his deadline. Good stuff!

After we got all of his new cart stuff under control, we switched over and talked about FTP (file transfer protocol) stuff. I showed him around, got him info, and we did some light training. He's going to work with Wayne and our hosting company to get everything else all setup. Good session.

Diverse day. Just got back from a multi-day Adobe ColdFusion conference. Lots of catch-up, phone calls, meetings, and small code changes. Here is a rough overview.

- Spent a little over an hour with Cory, on a Zoom meeting. We were going over to do list items and prorities. We went over a number of smaller needs and upcoming/current projects. General project management type stuff.

- Phone calls with Eric, Steve, and Shari O. - These were all separate calls with differnet topics.

- Added users, permissions, and sent out emails to help get Eric setup with system admin options on the data 11 server.

- Going over emails. While doing emails, got a few small code change requests. Made the changes and pushed up the new code. Some of it was internal and some of it was a request from the Bear 100 data team. Created a public facing test CSV file uploader page, specific to the Bear 100 and their runner data files. No database activity is done from this page. It only looks at the uploaded CSV files and spits back parsed data (it runs through the backend logic but no database changes are made - inserts or updates).

- Paying bills and recording receipts from Bryan and I's trip to the ColdFusion conference.

Checking on some Bear 100 runner counts. It looked like there was a problem. It ended up being that some of the data team (HAM radio folks) changed some records after the race started. Here is what happened. There were a number of people who didn't show up on time to start the race. They were marked as DNS (did not start). Later, at some time, they showed up and wanted to still run. They allowed them to start running with the original group start time. I had already seen the counts, so I had a specific number in my mind. When I checked some of the reports the numbers were different. We got it all figured out.

Phone call with Eric going over the pros and cons of sub/child inventory and parent inventory. We talked for quite a while about the needs, wants, and ins and outs of both options. I put in a plug for the ICC or internal cost correction project that would help allow us to use parent inventory (when needed and there are specific instances where that is better). Anyways, we had a good chat. It comes down to what is best for the situation and for the users. As an analogy, not everyone likes class V (class 5) rapids. Sometimes that's a little too hardcore.

Recording notes from the day. I've been bouncing all over the place today. Part of the gig.

Combing data and then doing a new data import for about 1,600 items or products. Sent messages to Cory, Sean, and Eric to have them go in and test things to make sure all was well.

Phone call with Eric going over what it would take to import customer loyalty points from an outside system or source. We went over some details and ideas. Eric is pretty busy, so I will have to build this out. He is going to send me over a file, and we'll go from there. Most likely, we will need to run this import over and over again for the same client. Reason - they are still using their existing system but as they switch, we need to keep the data up to date. We also anticipate that other clients will need the same capabilities.

Back working on some ecommerce changes and helping out High Valley Bike Shuttles with their page request and navigation options. Custom code for where they want to point people on their ecommerce site. They use a lot of our online schedling pieces, out in ecommerce land. 

Bryan gave me a call and we chatted about asynchronous (Ajax) calls and options to help with big reports. I also jumped on a call with Eric talking about EMV chip options and how tips and gratuities play into that. He's making great progress there. We talked about keeping things super generic and then customizing the solution, either through settings, or different payment integrations.

Recording notes from today - busy day (9/19/23).

Eric and I jumped on for a second session going over tips and gratuities, accounting, flow, and exploring that project. Good stuff. Eric was taking the notes today. I scribbled down a few things, not in any order, but here were a few things that we talked about.

This may not make much sense - just quick notes:
Tip flow - deposits, invoice payments, later flow when dealing with paying it out, main invoice amount plus the tip amount and comparing that to the sum of the invoice payments, aggregate data and adding the tips up for history reports and totals and counts. Talking about new expense types and paying those tips out. Reports to show tips earned or tips per person. We also talked about tips on a group level (splitting tips or tips not specific per person). Possible tip payout invoice - or they could just do a negative line on the deposit. Low impact changes.

Great little session with Eric, going over accounting for tips and gratuities. See attached for some of our brainstorming ideas and notes. We also did a bunch of drawings, scenarios, and even used the financial flow calculator to run some scenarios. Good stuff.

Doing a few different things for ship A (main adilas). Light research on CSS, bootstrap, and what cart options we have available to us.

Spent a good 1.5 hours helping out Bryan with code and flow on his new Authorize.net integration. We ended up talking about invoice types. Bryan had added in a whole new invoice type for refunds. We talked about how even though that doesn't seem too big, it cascades into reports, financials, and other cause and effect things.

We got into the differences between refunds and voids and even partial refunds. That got a little bit deep. We ended up having Bryan write some stuff down and he will looking into some of the possible scenarios. We also went over some reflexive flex grid tie-ins and how to code those so that we get links and relationships between the original invoices and the refunds. Overall, a good session.

After Bryan left, I jumped back into doing some more CSS research for a new mini cart. Recording some notes.

Part way through some CSS research, I got a phone call from Eric. He wanted to go over some options for recording tips - credit card stuff, merchant processing, and how all of that flows through accounting. We talked about a number of options, including using special accounts to show the liability and the asset, until cleared out (tips paid out to employees). After I got done with Eric, I jumped back into some CSS and bootstrap research. See attached for some notes. I was playing with things on the w3schools website.

Recording notes for the day.

Looking over data import documents from Eric and a new adilas client. Texts and emails back and forth. Paying bills.

Video prep work on the adilas style guide and some possible look and feel options. Taking ideas from Jonathan Wells and some of his Adobe XD mock-ups.

- Video - Fracture style guide overview - 00:02:08

Also got a call from Eric. He is working on some new functionality for tips on credit card transactions. We talked about a number of options including some possible settings. I was recommending that we somewhat follow the existing code for change due on cart and invoice payments. We talked some accounting and Eric is going to reach out to a few other people and contacts to make sure that we have all of the pieces that we need. Good stuff.

Went back in and did another video showing some of the existing navigation, pieces, and elements. This one is a little bit more raw (showing it in the Adobe XD interface) vs a nice slide or PowerPoint type view.

- Video - Mapping out the system - 00:05:00

Phone call with Eric to go over database triggers and then some emails. Back on the Bear 100 changes that were requested. Working on a leader board page and a DNF (did not finish) page. Spent a bunch of time chasing down a possible error in the code. It ended up being a debugging thing. Once I turned the debugging off, the error went away. that was frustrating. The error was dealing with the relative size of the header and footer. It appeared that the title and filter buttons weren't there and thus I was looking for the error. I ended up finding them, but way off the page to the right side. The debugging code was not responsive and had a bigger forced width. Thus the page was adjusting to that width, even though I was trying to view it on a smaller screen.

Phone call with Eric going over database triggers, inventory snapshots, and aggregates. Those are all projects that Eric has been working on in the past few months. Light overview and touching base on where things are at. I'd say we have 75-90% done on all of them.

Meeting with Eric to go over a time zone offset fix for a client. After we got that done, we switched over to a different project. We were talking about changes in the aggregates based on the line status values. Finding all of the places where things change (at the system or database level). Going over database trigger code and updates.

Eric and I were looking at the auto deposit gift card payments update. Merged and pushed up new code. Ran the update on all servers. The new code will handle all auto deposits going forward.

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!

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.

After hours meeting with Wayne, Alan, John, Bryan, and I. Wayne pretty much drove and I took notes. It went for three hours. We have the first two hours recorded (see attached). The last hour, we thought that we were done and it kept going with ideas and more clarification stuff. It may be a lot to read, but I've got 5 pages of notes, all dealing with fracture and where we are heading with adilas lite. Some of these topics are deep, backend, and server and database related. Good meeting.

I have no problem saying this... I was definitely not the smartest person in the room. I've been doing this kind of stuff for over 20+ years and I was impressed. That makes me excited.

Once again, if you want to review the notes, there are a bunch of good things in there for our upcoming fracture or adilas lite project.

These are a few of my takeaways:

- We need to communicate and get some standards setup. This could be what we call things, what code to use and how it looks and acts, and other style guide level stuff.

- Our plan is to build the whole new parts and pieces into an open API socket connection level application. We could then use API sockets as well as let outside developers use the same API sockets. We talked a lot about this. This is where we want to head. The new adilas lite platform will be mostly run on API sockets.

- Rules and assignments - the concept of building the rules and then assigning who plays with those rules was a big part of the discussion. Follow a story-based design for logic, testing, etc. Make all of this data driven.

- Think generic - what is available - what do you want or need? Make everything configurable. Multiple levels of configuration. See notes.

- We will be building a very robust data dictionary and then using that in the rules, validation routines, etc. This is basically a database that shows columns, names, values, rules, defaults, and other information about those columns and/or fields. This is huge and will help us use a more data driven approach vs hardcoding all of the rules, values, and validation per column. We will have a generic set and then let each corp, location, and user tweak a copy, if they want to get that deep. If not, we will use the main master data dictionary list information. Only change and copy what is needed.

- Events and turning everything into small bite sized pieces. Very minimalistic approach. Make as much of this application asynchronous (nonlinear) as possible.

- Let's do the aggregates (data warehousing stuff) right off the bat and get those values in place and being used. We are very good at transactional data and data storage. Let's really make an effort to break into the aggregated or business intelligence (BI) levels. That is a huge goal of ours.

Met with Eric to look at some code. We chatted about some time zone offset questions and date/time stamps that a 3rd party was asking about. We then got into a small discussion about better data modeling (see below). Eric has worked with numerous companies that have built and destroyed whole systems. We talked about some pros and cons and where we are heading for fracture as well as ship A and ship B stuff. We then flipped over to the enterprise vendor catalog changes that Eric was working on. We did a small code review, light clean-up, and merged in some code.

Eric and I – talking about the data model (database stuff)

- Problem with the unique id's – too much reliance on the existing primary keys – switch it to combo primary keys

- Any time you repeat things, you may want to look at the data model

- Cross-corp issues – for example – cross-corp loyalty points

- Po/Invoice lines – database table – breaking large datasets into corp-specific tables – that's how we solved the performance issues – there may be a better way to do that

- Better DB conventions vs table naming for corp-specific tables

- Enterprise level – aggregates and query data

- Shareable data models – associated tables

- Problems with text-based fields that combine records – for example: customer phone numbers

- Lots of talk about associations and setting up those relationships – master lists and who has access to that data, association, and/or relationships

- Refactoring things as we are in there working on things – smaller nibbles – iteration process – keeping chipping away at it along the way

- If we have a multi-page flow - make sure we use a common standard vs every page being different. A list of set standards.

- ETL - extract, transform, load - This is part of data warehousing and we would love to do it along the way vs just at the very end. Let's plan it into the fracture or adilas lite project.

Working on the daily sales and profit reports. We had a client who wanted to see all invoice payments per day, even if they didn't sell anything that day but just got some payments from invoices that were on account. We have a number or reports that already show that data. The client wanted that data to show up on a special report. The existing report only showed data based on the main invoices that happened for a specific date range. It's ok for main invoices, invoice line items, and invoice payment to have different dates. That's how we track accounts receivable (A/R's).

So, we went in and opened it up a bit more. Also added in some notes on the error messages to show any other details that were needed to help the users. Pushed up the new code and let Cory know.

Great internal training event. John was running the show today. We had Brandon, John, Danny, Eric, Alan, Dustin, and Bryan on the meeting with us. We were going over the adilas docs (online style guide and code snippets), light review, going over conventions, components, and other style guide stuff. John was encouraging the developers to use the docs and play around with things. As a side note, John has also started some adilas server docs (major backend stuff) as well.

Lots of good discussions. Topics ranged from docker stuff, older code, bootstrap versions, and sign-off guides for development and frontend GUI stuff (GUI is for graphical user interfaces or UI/UX user interfaces and user experiences). We had some good practice sessions and John had prepped some code with some flags where he wanted us to work and change things.

It was great for all of the guys to be on the meeting. I did snap a screenshot of some of the webcams (see attached). We talked about using data 0 as the starting point or standard for a number of things. Especially if we wanted to duplicate and/or use the same things over and over again. The conversation then led over to talking about the future and where we are heading. We spent some time talking about the new framework and being able to swap out dependencies and what not.

One of the last things for the normal training session was a discussion about requests for future training and crossover training. Here is the quick list, not in any specific order.

Future Training Session Ideas
- Cfscript
- Javascript/JQuery
- Back End (Models, Services, DAOs)
- API's - Internal API sockets and external API sockets
- Ajax
- Testing
- Custom CSS & Print CSS

After everybody else left, John and I did a small review of the training session. We were chatting about options and feedback. John and I may start with some CSS and theme stuff (planning for the future). See attached for 3 different videos that we did from the training session. Great event.

Eric joined the server meeting and we were talking about the sales tax aggregates and what kind of love is needed there. It's up, working, and just needs a little bit to really be fully functional. We talked about getting that code outside of the database triggers and being able to do manual or force updates. We spent 40 minutes going over pros and cons of automated database triggers, manual switches, scheduled tasks, and how best to tackle the aggregate counts, totals, and sums. We only have a few things aggregated right now, but a ton more options are on the horizon.

We then switched to the backend and frontend frameworks that we are looking into. We got into a conversation about technical debt (older or legacy code) and where we are headed. We really want to move more into an MVC (model, view, controller) type framework and application. We would like to change the main structure and underlying conventions that we are built upon. This brought up conversations about breaking the link between view pages, model pages, and controller pages.

Cory was saying that we beat the odds of how long we have lasted on our older code set, and lifecycle as a software company. We are really good at building new things. We would like to get better at planning and strategically doing maintenance and upgrades to the core and/or foundation. Ideally, we want to take some of our older, bigger, monolith code and break it up into smaller and smaller pieces. Things like helper files, microservices, MVC models, and restful API sockets. We already do a bunch of that, but the whole thing is not yet fully there.

Our guys (developers) keep running into things that are slightly off and/or could be changed. Sometimes, that makes them slowdown and either figure out what was done and/or them wanting to fix it, to make it smoother or better. There is a maintenance cost associated with training and learning. Sometimes you only learn by dinking around and playing with things (experiments and trystorming).

We may need to get some funding in place, even to help make the plan. This has been one of the things that has been missing all along (lack of funding). Sometimes, it also feels like we need some fresh blood (new energy or new talent). We are all getting a little bit older and have been pulling this load for quite some time now. That ends up wearing on you, even if that wasn't the intent. As long as we are talking about some ideals, we would love for our code to be more robust, less fragile, and easier to make global changes. There are a lot of intricate and moving pieces. As an idea, maybe we trim our team down and keep a smaller, highly talented, but nimble developer team. We are not sure where to go. It's always a balance.

Steve was asking Wayne some great questions. We are trying to figure out a plan for making the plan. It gets deep quickly. Steve was also asking about the datasource project and where that stands (looking for a progress report).

Eric popped in and we went over gift cards. He had made some small changes. We merged and tested some the pieces. I also talked to Eric about some needs coming down the pipeline for aggregates and deeper business intelligence (BI) levels. Eric was requesting deeper access to real database and SQL prompts on the test server. We talked about scheduled events, creating a manual trigger, and ways of getting at server logs and database logs. We talked about possible workarounds and getting things done.

After Eric left, John and I looked at his GUI page for testing results for page re-works. Small code review session and merged in and pushed up the code to data 0. John went in and did some live testing. This is a new tool to track code review, page sign-off, and who tested what on the new pages. It's a graphical tool to show progress on code/page sign-off. Looks good.

Eric jumped on and we looked at gift card logic. Apparently, a little bit of code changed. We were pretty tight a couple of days ago and then got a note yesterday that a client found an error (only if selling two or more gift cards on a single invoice). We were checking things out and retracing some of the steps and logic. Lots of good back and forth - dialogue. Eric was able to get the same error on his local box so he will take a look at it. After that, John and I were going over some layout stuff.

Light research on a possible disconnect between transactional dates (effectual dates or when it shows up for roll call) and historical dates (when it really happened). Sent an email to Eric with some questions. Listed the issue on the known issues page. This is a running list of things that we know that we need to watch out for. At some point, we'll have to fix all of those things, but at least we are recording what we know and are learning. That's part of the game.

On the server meeting with Wayne, John, Cory, and myself. Sean and Eric popped in for a bit as well. We were talking about email servers, merging in code, and making plans for pushing up new pages. Eric joined and Wayne merged in his code for the global item catalog - enterprise stuff. Once that happened, I pulled the branch down on my local box and was clicking around to see if there were any errors. Looked good.

Small code merge for Dustin. Then working with Wayne on his ColdBox framework stuff. We talked about users, payees, vendors, multiple corps, and memory and session management stuff. Small Q&A with Wayne and John about the framework, plans, and how we will handle certain pieces of the puzzle. Light plans for the future (wish list stuff). After that, John and I spent a little bit of time talking about internal education and training for our developers.

Phone call with Shari O. touching base on budgets, tech support questions, and a new project for a client. The client has reached out to both Shari O. and Cory - trying to double dip and push their project through.

Great morning meeting. Eric and Sean started out and were touching base and coordinating on a big demo and a big feature release. They were planning release times, testing times, and fall back plans if needed. I thought that it was really good. They were also talking about different servers and plans per server, based on the demo and the extra functionality. For the demo, they may script it and use an outline (direct links) and/or screenshots of the two different pieces, in case we don't get everything all merged together before the demo.

Sean and I switched gears and were talking about SG&A costs and using expense/receipts (E/R's) vs PO's and capitalized inventory. Sean kept waking up last night and wrote down a number of ideas on a Word document (see attached). We went over the Word doc and drew pictures, made notes, and talked about options. It was just Sean and I, but we beat it up pretty good. See attached for some of the notes.

Here are a few of the notes, beyond what Sean had pitched (once again, see attached).

- E/R's is where it all starts. Maybe just keep it there vs going clear out to PO and capitalized inventory levels.

- E/R's already have a normal date and a due date. The difference between the two is already a built in date range - how long to track the life cycle of each E/R.

- In Sean's notes, he was talking about to the exact minute, second, etc. We will be sticking with a daily value to keep it more simple. Most likely, it will be scheduled at a certain time so that we get consistent results, it can handle weekends, holidays, and becomes a built-in procedure.

- I liked his idea of flagging each SG&A vendor with a special flag. That will help us treat expenses from that vendor in a different way.

- If we run it through the E/R side of things, it will be very minimal effort and input from the user. Most of it will be done and distributed behind the scenes.

- Inventory still in place, keeps get hanger costs. Once it sales, that hanger cost stops and it gets recorded. Otherwise, it is sort of in a state of flux.

- If we get to the tightest level that we are thinking, it will add value for owners and managers to see what it costs over time to keep bigger on hand inventories. Being able to see past what is on the shelf and what that costs. Pros and cons to different inventory stocking models.

- If we hang (add hanger costs) to an E/R, we could reference (key word reference) the PO, invoice, item, sub item (sub inventory), etc. It doesn't add any weight to the current flow, it would just be a reference to those other pieces and/or items.

//////////

After Sean left, John and I were talking about some server stuff. I mentioned to John about getting him a higher percentage of adilas (as a co-owner) than what he currently has. He's playing an important role and doing server stuff, backend code, as well as frontend design stuff. I think that he is doing a good job. We will just keep refining things and playing well with others.

We ended up talking about servers, moving hardware to a new section within the Hostek environment. We also talked about internal developer training that is coming up, subjects, topics, and ideas. We really want the developers to virtually own or have ownership of and for their projects.

Phone call with Cory to go over plans and logistics. Emails, checking on the Herbo server, texts and emails, and working on a database update for Eric - pulling out a dependency in the code.

Looking into running a database update for Eric to help prep for a new feature roll out. Looked into it, couldn't do it because there were too many dependencies. We would have to rework it a bit. Emails back and forth.

Server meeting with Wayne, John, and Cory. We started out by talking about code that just sits on the shelf. We've got to get things finished up and pushed forward. We have to make some global changes and then make sure everybody knows about it. One of our goals is standardizing things across the board. We were also planning which branches are going live and who is on call for changes that are needed.

We have a big product upgrade coming out over the next couple of days. The big push is getting the enterprise level item catalog live on all servers. Making plans and assignments.

Wayne, John, and Shari O. had a meeting with Hostek. Good progress there. They were reporting about all kinds of stuff. We talked about disaster recovery stuff, plans, schedules, and contacts. It sounds like Hostek is going to try to work directly with our server admin team.

We talked about new email servers, flip flopping branches around on the testing server, and figuring out plans for all of those pieces. We then spent some time talking about changes to the look and feel. Getting approvals and other people to test and sign-off on things. Trying to coordinate efforts.

Eric joined the meeting to help us plan some stuff. As a side note, it is really hard to plan for every possible scenario. At some point, we need to move away from the classic theme (old look and feel). It is starting to cause issues because we still support it, but no new development is being done on that code set. It is also intermixing with other pages that are just on the new more modern snow owl theme (newer look and feel). It's causing more maintenance and larger pages due to keeping up with multiple sets of code (virtual supported versions).

At some point, we would like to automate some of the database updates to get rid of any dependencies when deploying new code and new functionality. John had some questions and we chatted for a bit after the main meeting.

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

-------

Older website text

-------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Recording notes and working on a list of known issues. See top_secret/secure/known_issues.cfm for more information.

For fun, here is a list of some of the items listed on that page. This list originally was started in 2009. Small list of what are known problems. Some of these things are real problems and some are just warnings. Lots of things have changed since then. It may need to be updated, added to, and some of the items removed, that have been patched, fixed, and/or finished.

1. Invoice pmts on account with something different than 0.00 value.


2. Receipt pmts on account with something different than 0.00 value.


3. Reimbursements (rei's) with a bank assigned on the receipt pmt.


4. Invoices with mismatch between main and line items.


5. Deposits with mismatch between main and line items.


6. Receipts with mismatch between main and line items.


7. PO's with mismatch between main and line items.


8. Non verified payments (outstanding deposits and checks).


9. Duplicates ???


10. Dates prior to the corp start date or prior to the bank start date. See bank_balance_helper.cfm page.


11. Dates in the future. see bank_balance_helper.cfm page.


12. Internal invoices that are not marked as paid.


13. Receipt payments that are verified but the main is not verified.


14. Difference between invoices and stock numbers. Created a number of flags to show disconnect.


15. When paying back splits and rei's - what about both (main and subs) being assigned to income statement expense types? This could double things up on the income statement. Defaulted special multi build (rei and splits) to b.s. items for expense types. Still possible problem on original e/r that may get assigned to the balance sheet.


16. Update PO's not tied to a balance sheet item (say a loss account or something).


17. Lien payoff line items on invoice with a 0 cost. The cost and the price should be the same otherwise it puffs up the profit. Did run a report at one time to fix this. Also added code to the cart to match cost and price for lien payoff stuff.


18. PO payments that have the wrong date and thus the po_paid date is wrong. The system was using the current date as the payment date even if the payment was actually made in the past. Small disconnect between actual payment date (e/r payment date and PO paid date).


19. Check auto dates that are actually used in I.S. reports or B.S. reports. Need a way to manually change the auto dates if really being used. Check the unit payments, PO payments, other system made payments. The system seems to be ok, the problem is with dates and being able to either set the date when using or edit the date if defaulted to today's date.


20. Blank expense/receipts (payee_id = 1).


21. Voided items but part of it is still in play or not fully voided. Need to get to a voided list quickly.


22. Denied check requests on payables page.


23. Sales tax problem with work in progress invoices. They don't show up on sales tax reports until they get flipped back to a customer invoice. The problem is that the date (main invoice date - if not moved forward) will not show up on the next month’s tax reports. If this happens, the invoice will fall through the cracks and not be counted for sales tax. Possible option for sales tax, Steve thought that it might be cool to have a point and click interface that we physically pay taxes on certain invoices. That way, they never fall through the cracks and we only pay taxes once we collect the monies. This would also help with a system-maintained b.s. item for accrued sales tax. As an update, Eric was working on a sales tax aggregate project to automate this.


24. Along with sales tax problems, how do we show this on the balance sheet? We need to show collected, paid, and owed values. Once again, Eric has been working on this in his sales tax aggerate project.


25. Payroll has similar problems with regards to what has been paid on, what is still needed, and how do we show this info on the financials.


26. See idea in note book about showing all daily transactions. This is different than a history transaction record. This is what really hit in and out on this day in time according to the system. This is not a known issue but may help with finding issues. Daily monitoring of each account per location, per day, per account or category. This would be awesome.


27. Check for master/slave relationships between date changes. For instance main invoice date compared with invoice line items dates. PO main date with PO line items date.


28. Known issue with PO dates. Do we run off the main PO date or the PO received date? Need to standardize. Leaning towards PO received date.


29. Known issue with location based payables. Both expense/receipts and deposits have the location on the line items not the main. This means that monies could potentially get split between stores which would alter bank balances if only part of the money went in/out of the bank. Known problem here. Solution might be that banks are what they are (full monies in/out) and all sub lines and types are location specific. This could give a false indication as to how much money was available for each location.


30. What about transition invoices that have the main invoice date overlapping the transition (wip/qti) invoice date range. They don't show up anywhere other than on the main invoice homepage which doesn't tie to anything. Added a small fix on view_transition_dates.cfm page. Still need to check for possible mismatches.


31. Disconnect between sold date on units and invoice date. This is a disconnect that is unmonitored and will only show up if pulling a sold report (units) and an invoice report for the same time frame.


32. When backing up the main bank start date, there is a problem with expense payments and deposits that have a date before the main start date and a verified date after the main date. The payment or deposit date is not counted but the verified date is. I had the same problem with Leanna in Poncha and with Drew Middlemiss doing his first bank statement. What a pain. See the bank_balance_helper.cfm report (5/16/09) for small fix. Still a known problem with a starting bank balance not being 0.00.


33. Advanced pmt on invoices (pre-paid). They hit the bank because they were deposited but they also need to show up as a liability to offset the deposit or cash going up. This should be a system maintained item.


34. What about deposit types of other income that are assigned to invoices (double counted)? The default is an invoice hits the p&l and only deposit line items that are under other income and revenue adjustments hit or the p&l.


35. What about bad debt? Do we want to create a system maintained items for this?


36. What about deposits that are made before pmts are posted to invoices. This is not backward compatible.


37. Know disconnect between PO dates. The main PO date is currently used as the main search date. The PO received date is the main b.s. date. We are thinking that the main date may become somewhat of a request date or a age player only. The main date will become the received date with the received flag.


38. If a check request gets approved and assigned to a bank but never written out (bank never sees it), there seems to be a problem. There is also a problem with older check requests and the dates that are set in the background. They are uneditable once the request changes into a normal e/r.


39. Known issue with i.s. (income statement) deposit types. If used, without an invoice, they don't show up on the income statement. They may also be double booked if on an invoice and also recorded as other income or revenue adjustment.


40. What about payments made on a PO before it was received. This could happen with a request PO or a basic PO that has not yet been received.


41. What about inactive (status) on parts and subs. If we have details (activity) but something is inactive, that could cause problems.


42. Levels of inventory - this could deal with parents, subs, and usage details. We may need to check costs, quantities, dates, etc. Sub inventory was added way after 2009 (original date of this report). We may want to spend a whole session just going over sub inventory levels and possible pit falls.


43. Steve, Kelly, Molly, and others have lists of balance sheet challenges and other known issues. Check with them and get their lists.


44. Ecommerce and what plays into the real mix from there - invoices, taxes, costs, prices, discounts, payments, quantities, elements of time, etc. Good questions? Some of this is already figured out, it just needs a little bit of loving.


45. What about aggregates (somewhat new for us and just barely getting rolled out) and making sure things match up. Category (could be whatever), by day, by location - are there update processes that may be ran to keep things up to date. Manual updates, API sockets, watchers and feeders.


46. What about backorders? Steve did a whole section on backorders but I'm not sure if we tied in everything to the balance sheet and P&L. Anyways, may need to circle back around.


47. What about banks that get turned on/off (active/inactive). If we go back in time, we need to know if they were playing.


48. Same is turn with location. If they get turned on/off (active/inactive), we need to know when they were playing. We may need a start and end date and then be able to pull things accordingly, even if the current state or status is inactive.


49. What about cost of goods sold on unlimited or special line items? They should be a $0.00 cost because they are unlimited (like a labor or a service). If a cost is needed, it needs to be allocated through an expense to the COGS section or distributed in a thing called SG&A costs. SG&A (selling, general and administrative expenses - aka accounting for general costs by attributing them to a single unit and thus incorporating the true costs into an item). Basically, you take a normal expense like the electric bill or rent and build it into the individual cost of each unit by unitizing the expenses and virtually spreading a bigger general cost to smaller pieces. Sometimes that type of process (SG&A) is required for certain manufacturing and/or production type products. Basically, they (the IRS) don't allow you to expense off the whole expense (rent, insurance, waste, electric, etc.) as a bulk item. It has to be distributed to each smaller piece. If you do real SG&A, it helps assimilate those costs in smaller percentages and thus passing on a truer look at real costs of goods sold.


50. Anything that is currently marked inactive but may have played a role at some point. This could be locations, banks, part categories, items, vendors, customers, etc. Often, if we make them inactive, they don't get pulled (but maybe we need them at some time in the past).


51. Other special account options such as in-store credits, vendor credits, punch cards, etc. We already have loyalty points and gift cards that use special accounts. Maybe expand on this and allow for custom options or other digital payment accounts or payment solutions.


52. I'd love to map out all of the existing balance sheet and P&L values. Make it more widely known and really put it out there. Right now, it all happens behind the scenes and is kinda like a magic box. I'd love to get it all mapped out and presented to the public. We'll get feedback, refinement, and maybe even some other really good ideas. That's my vote, let's get it all out there in the public eye and public realm.

Cory and Eric were talking about enterprise level stuff and the new item catalog that they are working on. We then switched over and were talking about a 3rd party API socket connection that has been in place for a couple of years. They had some questions and want us to do some research. We feel like they should pay for it (new maintenance and new development). We looked around in our code repository a bit to see if we could find any changes that happened on our side of the fence.

Wayne joined the meeting and reported on some mandatory Adobe ColdFusion updates (patches) that had to be applied to all production server (security risk stuff). We talked about getting server documentation and helping to transfer that server and backend knowledge to the other developers or whomever might be taking over, once Wayne retires. Wayne has been making some notes and doing some screen recording or screen capture videos.

We then rolled into a discussion on a dedicated testing server. I'll cover more of that in a minute. At the end of the meeting, John was reporting on progress on CSS and look and feel changes. He is working on printable deposits and printable expense/receipts. He is also making some small tweaks to the layouts and where certain dollar figure data is located. Good stuff. Cory and John were talking about plans on the discount engine and making plans.

Going back to the dedicated testing server - We went over a proposal to get a real testing server up and going. We currently have a number of testing bottlenecks. We talked about reverse merging in master code to the working branches, to help keep them up to date. We have had problems when a project takes weeks or months and it has not been kept up with the master code branch. When we go to merge it, sometimes there are huge differences, conflicts, and some of the underlying application structure has changed. That merge process then takes a while to sort out and make sure that everything gets fully tested and verified again. Anyways, it is an issue that we deal with.

////////

We then had a small discussion about pros and cons for getting or having a dedicated testing server. This was all recorded on a google doc, but I'll paste it here for searchability. Here are some of our notes from today:

Group discussion notes

Cory - We’ve tried this before - what would be different this time?

John - No FTP access to the testing server - there are pros and cons to that

Wayne - We need to test one branch at a time

John - He would like to see it (use of the testing server) go in a line (testing schedule or queue) - I’m next, you’re after me, etc.

Wayne - If we need to, we wipe it clean and then start over again. That’s the process and the beauty of it. We test on it, beat it up, and then wipe it clean for the next round.

John - We can get a full copy of a client’s database and then kick the crap out of it. When done, we just flush it. We never mess with live data. We just make a copy and then test and push against that. Much better look (at live data - copied) then our own fake development data.

Wayne - We need a way to turn off outside 3rd party API’s - either mocking it (pretending) or muting it (silent send outs).

Cory - Sometimes we have big issues with Metrc and other outside parties and doing testing that flows into outside 3rd party API sockets and feeds.

Cory - Currently we are using the Herbo server for some testing. We have been having problems with that. What is going on?

Wayne was commenting on the Herbo server - We are mixing branches, there is still FTP access, it is pointed to a non-master branch, and we have certain things that we can’t change for demos or other needs. Basically, we are using a live server, we have live clients on it, and we are trying to test on it. Too many mix and blend variables... Hard to manage.

Wayne - Would like to see some project scheduling - project A on this day, project B on this day, etc. Keep it tight (ish).

Cory - Con of having just Wayne and John having access to the testing servers. The scenario is, if we find an error, we can fix it right away (whoever the developer or testers are) but then we have to contact either John or Wayne to help that new code get pushed up and deployed. That becomes another bottleneck.

Wayne - We could change the timeframe or auto deploy time cycle to make it faster.

Cory - What about data 5? That is an option, but we would have to make a full copy of the database and all of the corp specific files (images, PDF’s, csv files, etc.). We could then order a new hard drive or put those files somewhere on the current hard drive that we could get back to if needed.

John - Talking about paying bills (meaning our clients)… If a client doesn’t pay, we should be able to just shut them off.

Cory - Question - How much does it cost to put things in cold storage? How much does it cost to bring it back up live?

John and Cory - Talking about costs. John was saying that we need to build in this cost ($400-$600 per month) as an operating cost. We are a software company. We kind of need this. Just like being a foundation company and not having access to a cement truck. It creates a problem.

There are ways to lower the cost, if needed. We could lower CPU’s, RAM, etc. We could also spin things up/down as needed.

Wayne - Rough cost to spin up a server is 2+ hours (somewhere in that neighborhood)

Cory - Really liked the video idea of Wayne recording what he does as future training things and visual assets. Good idea. We just need to be careful of who gets those… This is the whole backend access zone stuff. We just need to keep it tight.

John - He has some server docs and would like to get that put into a private repo that only has access to Wayne, Brandon, and John. Small group.

Cory - Figuring out a way to force some of these clients to pay for cold storage and reanimation or redeployment of the servers. It comes down to if you don’t pay your bills, we get full control of what happens. We need to do what we said that we will do. Forcing the hand by making them pay for the backup data.

John - We just need to have our plans and procedures in place. We need something to stand on.

Brandon - We could do some cold storage on the same servers. Either with a different drive or a partitioned area where we could store things. As a group, we were talking about other possible storage options within the same box. We could make copies of ColdFusion files, client files, and SQL data dumps. Put them all out of reach but on the same server. Then if needed, we could restore things as needed.

John and Cory - If we need to reanimate or redeploy - here are the params and timelines and costs - Part of the plan. Some of these values may change in the future as well.

John - If the crap hits the fan… He doesn’t want to be in the spray zone of that fan. We need to protect ourselves.

Talking with Sean about making a tighter game plan for credit card payments and which merchant account types we will allow and support. Currently, we are super open which is nice, but it also introduces too many variables. We have done integrations with a number of different companies and vendors, but not all. It gets really tricky when new hardware is introduced and chip or EMV requirements are needed. Anyways, we'll work on refining our options and how we approach custom solutions.

Eric joined the meeting and had a few questions. He let me know that there was a problem with the Herbo server (most likely a test branch of code). We also chatted briefly about some other MVP special account options that we would like to get to. We talked about in-store credit, round two on gift cards, coupons, and promotion codes. We also mentioned that we may need to do a full review of what we call our standard merchant processing setup and credit card payment options.

Emails, reviewing some videos on a time formatting bug/complaint on employee timecards. We used to leave it very open and allowed users to enter times as they see fit (for example: 5 pm, 5:30 pm, or 5:30:00 pm). The new time pickers require a certain format and some of our clients have been complaining about the requirements. We had time-pickers for hours and minutes, as well as one that required hours, minutes, and seconds. Basically, they want it back open where they can just quickly slam in a time vs having to comply with specific formats.

Recording notes from 3/7 to 3/12. Phone call with Eric going over some quick questions about forms and JavaScript.

As I was recording notes from last week, I really am feeling the need to make a few new graphics. I really want to create a graphic that shows the adilas value add-on core model. This will have the transactional core and then then the other layers or value add-on's. This is part of our plan and where we want to take things. Along those same lines, I would like to add the graphic for progression of things, Star Wars Death Star (work in progress), rose petal analogy (building one idea on top of another), and the value add-on core model to the teaching gallery or image gallery that I use for showing the guys certain ideas and concepts.

Emails, phone call with Eric about bulk tools, enterprise item catalog features, and storing user selections in the session scope. Merged in some code for Dustin. Reviewed some documentation from Bryan on the Digitech payment solution. Paid some bills.

Both a pro and a con - there are so many custom integrations that we have done, nobody knows all of them. Sean and spent 45 minutes going over credit card gateway problems, issues, and options. This could be how credit cards get entered into the system (manual keyed, swiped, or chip reader and other hardware options) or how each gateway acts or reacts (different variables, paths, and requirements).

I'm going to request some documentation from Eric, Alan, and Bryan. They have all worked on different merchant processing integrations within adilas. We need to help and gather some of that documentation up for tech support and our sales team. That is much needed information. Otherwise, we are somewhat blind as each integration is so different.

Dustin jumped on the meeting, and I helped him get pointed in the right direction on a required file for doing QR codes. Cory had an icon app email issue and we looked into it for a bit. There seems to be a duplicate number in the email settings. We also chatted with John about the chooser and choose more interfaces. John and Cory were going over changes to the chooser. Lots of different opinions - some like numbered, others like alphabetical, and some want to be able to search.

Once again, nobody knows all of the pieces. That creates a mystery of sorts. Also, it is hard to pick things up (projects) after the fact. Without the knowledge of what was going on and what was requested, some of the pieces, by themselves, don't make much sense. It's all part of a bigger puzzle.

Notes from meeting with HG, KW and SB on 3.7.23:

Has some redirects that aren’t user friendly. 

1. When you sign in, take to the main order or have shop home more prevalent. ** Put a setting to skip the first page. Take you right to the category page. **You have successfully signed in.
   
2. Add item to the cart, should allow you to keep shopping instead of taking you to the cart. 

*** look at what Will Hudson did on the above *** EOT 2413

   3. Setting to show/hide the display mode. Don’t need to show it.

   4. Can’t sort and prioritize by the item. ie. HG first, then Green Dot as it is alpha-numeric.

**Steve talked about icon app for phone. Michael is interested in this. Will need to add the email templates to HG.

**Steve talked about tiered selections. Ex. Sell burrito, choose what cheese they want to add.
Talked about Leafly integration. There will be some changes in how tiered pricing is set up.  We will need to make sure HG’s settings are all good when the new code comes into place.

You’ll be able to have 10 tiers and name it what you want. It can have a variety of amounts ie 1.3 grams, for example.

Kelly mentioned suggested products… lead customer to an equivalent item or suggestion.

Steve talked about related items (that is more like a cord needed for a product that you purchase)

**Predictive… you may want this as well. Algorithm.  Build in a default so something shows up

Showed Mike Message modal: 

Would be helpful to be able to choose people to message in other ways besides customer type.

Schedule recurring messaging off of birthdates. 

Eric can help with bubble that would show up on your icon app.

Another thing would be to have the customer to reply back.

**Not ready yet: Transitional invoice= instead of doing a quote, you can do this so it holds inventory/reserved. Assures inventory is held.

Working on the quick search help file. Added new code for the quick search to pull a full balance sheet by using a date in the quick search field. This was a request from Kelly. Spent the rest of the time going over videos that Shannon made for the adilas university training. I watched the videos on PO's, vendor-specific inventory, generic inventory, quotes, vendors, and users and permissions. Good stuff.

- Shannon was showing multiple step processes, reviewing info, prep work, and helping to organize things. She was bringing out standard features, patterns, and helping to show that the tools are as flexible as you want them to be. Good information at the beginner level. I was wanting a little bit more, but that will come. Good stuff!

Steve and Sean were talking about how quickly you could setup a company and just sell and redeem gift cards. We may end up pushing this a little bit further. This could be a quick way to get our foot in the door with a company. We did some playing inside of the demo site and even made a few buttons, setup some quick settings and defaults, and ran a few things through the process.

As a note, we have a number of other quick standalone features that our clients can use that don't require a ton of other pieces. Things like the customer queue (even generic placeholders), timeclocks and timecards, quick calendar events, project tracking, ecommerce, etc. As you get into more and more things, the complexity level does go up, but some of those things could almost be sold or marketed as standalone products or pieces. Of course, they are all there (included), they are just smaller pieces of the whole that may be used independently or with minimal training or other setup.

Steve was asking about a possible option for showing buttons (my cart favorite buttons) with choices (like options on a menu - what options or side do you want with that?). We spent a little bit of time talking about how the buttons could include choices or whatever. At some point, we would like to do some buttons that tie right into time and scheduling as well (time buttons). The button is nothing special. The big advantage there is that it can hold the rules and assignments or special selections or settings. Basically, backend code and/or choices or presets get assigned to each button. That's what makes the button so useful.

After Steve left, to jump on a call with Mike, Sean was asking about quick setup options for things that we do all of the time. I mentioned that we could easily setup prep scripts or special code to help do certain things and/or configuration steps. Say you have a process that would require you to do a certain number of steps (say 10 or 50 or whatever). If you created a quick prep script, you could click one button and then have the system do all of those steps (5, 10, 50, 100 steps) all in the background. Especially if it is the same thing over and over again. It could really speed some things up. This would be a great addition for our fracture project, going forward. Quick settings, quick setups, quick default, and industry specific prep scripts. That would be really cool.

At the end of the meeting, John and I spent some time looking over a page to help split an expense/receipt between locations. This is something like an insurance bill or a bill that needs to be split by percentages between locations. John is working on taking older pages and updating the look and feel. It's looking good. He has permission to merge that page into the master code branch.

Multi-hour server meeting. Wayne, John, and I were on the meeting. Our first topic was email servers and options. I pitched 4 options. Wayne came up with a fifth option. Here they are - in general:

1. Stay with Newtek on the same server and try to update code to help make it more stable. Currently on a shared server for email functionality.
2. Stay with Newtek and just upgrade the shared ColdFusion server to a newer version. Basically, request a plan change and switch boxes (upgrade servers).
3. Switch over to Hostek and use their email services either as a shared server or a VPS for SmarterMail.
4. Full custom and we setup the server, the services, and the API socket connections. There are a number of unknowns here.
5. Switch over to Google workspace and use that as our email server. This was Wayne's idea. We chatted about ideas, options, pricing and what not. He is going to run some experiments using one of our other domain names that we have to do some testing.

After we got done talking about possible email options, we started talking about the datasource project and options that we have there. This discussion took quite a bit of time and felt like we weren't making much progress until towards the end of the discussion. We were talking about tough situations like payees and users being bridged between corporations. We went over the need for GUID's or globally unique id numbers. We also talked about tables like customers and part categories where we use the auto generated id as the main primary field. We also talked about other tables where we allow duplicates based on a multiple column primary key. For example: Say deposits or PO's. We let the system create an auto id number that we don't use (auto number for the transactional ids) but then we do a special corp id and main deposit number or corp id and main PO number as the sub combos. Ideally, we'd like to make all of the tables so that they could have that multiple column primary key or key indexes to help keep the data separated.

Lots and lots of talk about tables, options, and details. Toward the end, I think that all of us had a better idea of what we are up against and how to tackle the project. That is awesome. Our next plan is to have Wayne play with some things and see what it would take to update and merge a couple of tables. Basically, we are going to start running some scenarios and testing experiments. We talked quite a bit about UID's (unique identifiers) and even converting them into numeric values to help with indexing, sorting, and such. Most of it came down to adding in an additional layer to the database where needed. It's not needed everywhere, just in certain places and that was good to see. Progress.

As a goal, it would be super cool to get the full database all mapped out and fully documented. Things like data definitions, primary keys, foreign keys, key indexes, combo fields, etc. As a fun side note, if we flip over to a unique id type system, the main work will be on the insert code (putting things into the database). Then making sure that each select, or view query uses that unique id (a real UID or a combo/multi column primary key) in the joins and where clause filters. Once again, good progress on the datasource project. It may end up being a combo of both new datasource names and better unique identifiers to allow us to mix and bled tables, datasources, and data as needed.

Next, we switched over to session variables and session management options. We talked about setting up global session variables, centralized place to manage that, and moving things into more of a session object with methods, classes, and functions. Get it all in one place vs having it in-line code on multiple different pages. All part of standardizing things and maturing code wise.

Wayne reported that he and Eric got the local docker image running on Eric's Mac with no problems. We talked about some image, media/content, and local paths that need some help and loving. Then at the end of the meeting, after Wayne had left, John and I went over a number of new pages that need to be updated with a more modern look and feel. Long, but a good meeting today.

Emails and researching a different bug on gift card payments. I ended up just doing some looking around. Not sure where to go, based on the new stuff and newer flow processes. I know the old way, super well. But some of the new stuff is still kinda fuzzy for me. I may need to get with either Eric or Wayne to get some clarification. I made some other notes for when we meet that will allow me to get back to what I was looking at.

Pretty quiet meeting this morning. I heard over the grapevine that the sales meeting was going to be pushed back to just Fridays. Anyways, both Sean and Shari O. checked in. Light questions. Cory is out on vacation so they had some questions about data migration for clients and how to do some of those tasks. Cory normally does that. I showed them around and gave them some links and instructions on how to use the corp-to-corp migration and special copy tools.

Part of the session, I spent it taking a file that we had found and making it into a more robust so that we could use it as a new migration tool. It was hardcoded, but we turned it into a more dynamic or generic tool. The new tool deals with being able to copy part categories between corporations.

Emails, merging in code from Eric, updating email settings on my local box, and on the phone with tech support talking about email servers and settings. Did an email password reset for Bryan and let him know via text message.

We started out the server meeting. Those who were on the meeting started out by reviewing the last meeting (morning sales meeting). We then jumped in and started going over server-based topics. The first main server topic was email stuff. We are going to be using or trying to use the adilas content server to send it out vs the adilas university site. The old adilas university site is on a shared environment and is an older server. We are going to see if we can get more up time and new features by using one of our fully dedicated servers.

Next we spent some time talking about data 0 and maybe updating or upping the CPU count and RAM memory. We talked about Hostek and the customer support that we are, were, and hope to get. At times, we really need more support. Currently, it hasn't been as good as it used to be. Sometimes we get slammed and need help. We don't need it all of the time, but when we need it, the support is critical. It all deals with server up time and keeping our clients happy.

Touching base on other projects. Wayne is going to be reaching out to Eric and Dustin to see if they need any help. Cory and Wayne got into some technical compliance stuff like SOC 2 reports and other compliance stuff. Lots of talk about risk mitigation and managing risk. While we were talking about risk management, we got into a conversation about accessibility issues and making content available for persons with disabilities. That got pretty deep but this seems to be a section of the web that is expanding, and requirements are being made more for mainstream sites vs just specialty sites. Lots of special tags and flags for screen readers and such. We also talked about the cost of making a fully accessible site. The costs are huge, especially for little guys. Anyways, it seems like there is some legal cases and such that are pushing this agenda further. We may need to keep an eye on it.

We spent some time looking at some of our other servers and database stuff. We then switched subjects and Cory and John were talking about projects and new CSS look and feel stuff. We would like to get more user feedback. We are doing the best that we can. We are constantly improving our code every day. Talking about new settings and dealing with look and feel and personal preferences. We would like to get good feedback and keep trying to connect the backend code with the frontend user interface (UI).

We looked at the calendar and did some scheduling for some of our new projects and rollouts. Right at the end, Cory was reporting to us on a couple of small bugs. We'll have to circle back around. We ran out of time.

Working with Steve on logic for updating and adding parent attribute values in bulk. Steve is working on a few new pages that have some new bulk attribute tools. After that, we flipped over and had to do a small data update for a client on the data 10 server.

Eric joined the meeting and was asking questions about the item catalog and enterprise level systems. He and Alan are working on those pieces. Anyways, he was asking about logic and flow from the main enterprise system out to the transactional corporations. We talked about flow and then got into training and user experiences (UX/UI) and user interfaces. That lead to a discussion about education and even certification for certain aspects of the system. Another option for compliance and good data outcome is a form of oversight or mentoring for our clients. This would be an additional service.

If you keep following the path of the data and the needs. We can see things at the world level (low level), the solar system level (linked corporations or worlds), and on up the chain to the universe level (everybody who plays into the system both directly and indirectly). Eventually things will need to get clear out to the API socket level where anything could talk to anything else. There was even some talk about subscribing to other high level vendor product catalogs. Basically, a way to make the data entry and updates quick and easy.

For fun, we got into some space analogies with universe, clusters, solar systems, worlds, etc. Eric was also using some construction and cooking analogies. Lots of people understand things at that simpler level. Thinking big picture and then being able to pull it back down into the smaller details. Data is king! Having the foresight and vision to see what else if needed and wanted. That's a challenge at times. We were talking about business logic, flow, aggregates, and other data level needs. Our goal is to keep revamping things as we go. Both logic and look and feel. That's about all we can do.

Debugging session with Eric. We were looking into a bug on credit card processing and how that relates to the new gift card code that we pushed up. Looking into the flow and process of our existing merchant processing code. We got on a call with Missy from McCorvey's Pro Shop - bowling world - and chatted with her about for a bit. She gave us some info and we went into the system and looked around. We then ran a number of pages through a code diff (what is different per page) and actually found a small typo error. We fixed it, made the changes, and pushed up new code. Hopefully that will fix the problem as we couldn't duplicate it. We checked a bunch of shopping cart checkout pages and credit card processing pages. Everything else seemed to be working fine.

Eric jumped into and was checking on credit card payments and a possible bug that got reported. Steve and Sean were talking about sales, leads, and follow-ups. Shari O. and Steve have been working on some local businesses and getting things setup for them. I spent some time while they were talking finishing up some of my notes from yesterday.

Alan joined and was asking about parts and item photos. He may make some tweaks to that part of the system. He is working on the global item catalog and being able to flip default thumbnails and images. We were going to watch a demo from Alan on some of his production and manufacturing stuff. Eric popped in and we got pulled away and had to work on some small errors. All of the other guys bailed out over to Zoom and Alan gave his demo there.

Eric and I spent a couple of hours and tried to make some fixes. Small tweaks to the payment structure fix. Learning and figuring things out. As we keep going, we will end up circling back around and making it more efficient. We will keep refactoring things as we go. As part of this process, we kept finding small one-off's and custom code. Also, some of that stuff (custom code) is hard to test. One of our goals is to push as much as possible to data driven vs code driven changes. It takes the whole village to make it happen.

Eric and I working on wave 3 of the gift cards project. We broke a huge project down into 3 smaller waves to help relieve the dependencies that were built into the project. Lot of application-level stuff, session stuff, and cached server objects and views. Testing and reviewing code. We had to fix some merge conflicts. This branch (the new code) was started months and months ago. That sometimes makes for a number of merge conflicts. We also spent some time picking up missed files and rebuilding the needed assets. We had had some code repository issues with this branch. Good work session.

Pretty quite morning. Michael and Eric jumped on briefly to check in. After we chatted for a bit, they bailed out to work on their own stuff. I went back to trying to catch up with recording notes and doing emails.

Eric and I doing some gift card project planning and testing. We were splitting up a code branch to do a second merge and release wave. Testing on my local branch. Lots of back and forth with Eric. Merged in the second branch and then talked about group dynamics and lessons learned. Making progress. Hoping for one more branch tomorrow, and then it will be fully up and deployed on the master branch.

Eric and I working on the gift card project. We had it all ready back around Thanksgiving time but we've had a hard time getting it fully integrated. Lots of variables and things (application level changes) keep happening all around us. We are making progress.

Today, we ended up having to roll back some commits and try to get his code branch back up to date. Somehow it got all mixed up. While Eric was rebooting his computer, John and I talked about an error message and tracking down a bug in the bank transfer code. After Eric's machine was back up, we spent a bunch of time trying to reset his branch. Sort of a salvage type mission and session. Thank goodness for Bit Bucket and the code repository. We had to go through a number of sub commits and try to reconstruct the main gift card branch.

Morning meeting with all of the guys. Everyone was reporting in and giving updates. I gave an update about using the snow owl theme headers and close to 40 custom navigation links that are available to the whole user base, per corporation. We talked about an update on gift cards. Eric and I are working on that project and trying to roll things out in waves.

We switched over to talking about ecommerce and gaining more control via settings and options. Steve was commenting to Danny about tiered pricing out in ecommerce land. There are some new options coming and we'll take the existing pieces and just keep making them better. As the discussion progresses, we were talking about our general approach and how diverse our user base is. Because of that, we have a ton of tools that some clients may never want or use. In that same breath, we can also offer things to our clients that they never would have gotten if they had a specific software package that only did one specific thing.

The guys were talking about problem solving and how we excel at that. Steve was talking about a shed analogy and how you can have a ton of different tools in the shed, but you only pull out what you need for a specific project and/or task. That's adilas, in a nutshell. Just for fun, Danny was talking about the TV show MacGyver or MacGyvering - making it work with what I have. We love the challenge of trying to make the glove fit. We have tons of tools and features that we can mix and blend to make it happen. Good stuff.

Eric and I were pushing up files for wave one of the gift card project. John and Cory are going over the discount engine and talking about ways to do live testing with good data, without hurting anyone's live data. As a wish list, the developers would really like a way to get good clean data (basically a new database or new data) at will. Some of the data that they end up with gets muddy, due to testing, demos, and bug fixes. Sometimes they only complete a part of the process. It sure would be nice to be able to clean that data or database up with a click of a button. Basically, a restore to point x or y (whatever or even an ongoing good and clean data point).

After John and Cory got finished, Eric and pushed up some more code for wave one. The goal was to get some of the dependencies out of the way without leaning on them (using them). That way, when we push up the next wave, those other dependencies will allready be there in place.

Checking on a list of parked domain names. I reported back to the guys about how my Docker server install was going. No problems on my local development environment. We talked about other server level projects such as: inventory snapshots, email formatting, gift cards, dependencies, and sales tax aggregates. We keep making small little tweaks. We also checked on a number of other small projects.

Eric popped in and he and Wayne were talking about triggers and stored procedures. They were looking at the database entries and what not. As part of the meeting, they (Wayne and Eric) were physically looking deep in the database. Eric is going to circle back around and do some more checking on his side of things. They were reviewing the stored procedures.

It was kind of fun to watch them view and refresh some of the aggregate data on the fly. Cory was acting as the user (actually doing something inside of adilas), Eric was orchestrating what to do and look for, and Wayne was doing the backend calls and database SQL statements. It was fun to watch, as a fly on the wall.

Eric is going to run some debugging scripts on the data. They are looking for a cause and effect scenario. They were also looking at servers, monitoring processes, and running pages. From what it looks like, they will need to do some further data research and analysis. They are trying to get to the bottom of the data differences between the transactional records and the aggregated data.

As a note, if we can't get with Wayne, John is the backup database admin person. He has access to all of the different servers.

New code with Eric for gift cards. We also decided that we would add the adilas quick search to the classic homepage in the top header as well as all other pages. That was the only page that has/had a built-in quick search, so we didn't think that we needed it in the header as well. We have had requests to put it on all pages, even if it is already there. Some users use the quick search as a primary navigation tool.

Cory joined us and we went through some scenarios and did more testing.

Phone call with Eric. Making a plan for deploying the gift card project. We have already rolled it out a few times but had to pull it back due to some random errors. Our next deployment will be staged or done in waves to get rid of the system dependencies that exist at the application level and the session level.

Work session between Eric, Cory, and I. We were testing and going over gift cards and trying to see if we could push some things up to data 0 for live testing. We looked over code, made some back-ups, and then did some code review. We ended up pulling the code branch onto my local machine and did some testing instead. We found a few problems.

After Cory left, Eric and I made some plans for moving the project forward in smaller pieces. Currently, there are too many system level dependencies and things that deal with the entire application scope variables and values. We are going to push it up in smaller pieces or waves so that the dependencies become less of an issue. It may take a few days (vs a single quick push) but it will make it smoother. Good plan.

John was reporting on some new updates on the department homepage. Eric, Cory, and I were looking at gift cards and scenarios with different settings. We had an internal email bug reported to us and we started looking into it. John was the lead and doing most of the debugging today. Bryan joined us as we were checking things out. Sort of a grouped effort. We spent quite a bit of time looking at the email stuff. We pushed up some new code and John will get with Wayne later today to finish things up. We did what we could for current time. It will need more attention later.

Installing new software and tools from Calvin. Phone call with Eric to go over inventory snapshot project and how to get certain info back out of the system. I spent some time being stuck on a database problem.

From our meeting this morning - sales technique - is there anything that I haven't shown you that we are missing? Open it up and let them respond.

The guys were going over SG&A (selling, general and administrative expenses) options based on batches. Steve is willing to help with some API integration stuff for certain 3rd party solutions. We also talked about the need for flex grid tie-ins and being able to use those as a pass through in the internal cart or shopping cart. We need to be able to pass customer, invoice, time, and part number (items) information through the cart flex grid options. This doesn't exist yet.

Danny was talking about stock/units and using VIN (serial number) look-up tools and outside services to help verify user inputs. John was reporting on some new changes for the bank homepage. Light talk on layout options and using tabs, cards, and responsive web layouts. Small date format bug fix. Talking more about the flex grid pass through in the cart.

The further we go, the more settings play into the mix. We tend to build generic tools and then reuse those tools over and over again. Custom stuff for individual companies may be required, but we will try to use settings and permissions where possible. Try to make everything as data driven as possible.