Morning meeting... got reports from Alan, Steve, and Russell. I was working on some small changes and taking the rounding error off of the mini invoice (3" customer receipt). Other small changes.

Eric will be coming in at 10 am to talk about loyalty points. Eric and I talked for a couple of hours about the special account tracking project. This deals with loyalty points, gift cards, in-store credits, you name it... We did a lot of drawing and even got into some small scenarios. We went full circle... we decided that they all go together and then not all together and then back to all together. Eric was tasked with looking into things a little bit deeper to see what we can do and what plans we can make.

Shawn came over and was working on state payroll stuff.

Checking in on the morning meeting. I have been out of the office most of the week. Steve and I chatted this morning about the need for new independent developers and getting people into the mix and into the family. There is a real need there. We then merged in some code from his branches and pushed up files to all servers.

Looking over ideas for loyalty points. Lots of good info on element of time # 3778 in the adilas shop.

What is a liability? What are the differences between real and phantom values? We need the values recorded for both real and phantom, the difference is how firm and/or fixed the liability is. Steve mentioned a term called a "shadow account" (that exists, but may not be fully tangible). We also talked about how it is the actual company that is creating these phantom and/or shadow type liabilities. That kinda changes things... it is the company creating their own liability based off of a point system to encourage customer loyalty.

There seems to be two main part of the puzzle. How many points (ins and outs) and what is the value of those points? Lots of balance sheet transactions.

Simple to more complex transactions... simple gift cards or simple gift certificates, basic loyalty points, punch cards, in-store credits, coupons. As a fun side note, some of these transactions are subs of the balance sheet. Kinda like sub inventory but on the balance sheet side. Maybe we need to think about how the transaction takes place. Is there already cash on hand (paid in advance)? or is it just lowering the total owed, like a form of a discount? Who pays for what? What about coupons that a manufacture pays for or pays a part of?

On the main balance sheet items, we may need another switch to help us know if this is a main account and/or a sub account. We may also need to know if the asset, liability, and/or equity account is real or phantom (shadow). This is kinda fun, but we are seeing a fracture that is needed in order to record the balance sheet items. Everything is breaking into sub accounts.

Going back to discounts and special discounts... do we apply the discount to the cart/invoice on a whole or do we have to re-distribute that discount back through the system?

On a different note, we had a request from a client to be able to permission and/or fully turn off standalone discounts. Also, we are seeing that taxes make the discounts more complicated. We have options to do both in-line discounts and/or standalone discounts. Things get really fuzzy as you try to tax, especially with excise taxes and taxing things at the different levels (per item category, per customer type, per inventory type, etc.).

We had a great talk about "bad debt" payments. Don't worry about the words (verbage), think about the concept. That helps to satisfy the invoice (monies owed to us), the taxes are fully correct,  but it is then showed as an adjustment to revenue (rewards, coupons, loyalty points, etc.) on the income statement. Both coupons and loyalty points are similar. It is the internal company basically saying "I'm going to cover that part of the invoice". We claim that that invoice and/or ticket is x dollars and has y amounts of tax. We then cover the invoice by real monies and/or monies that mean something, but no real money changed hands. Look deeper in this. The main difference is the verbage between bad debt vs rewards or loyalty points.

Maybe we should add some new standard payment types such as: Rewards, Loyalty Points, Coupon, In-Store Credit, Gift Card/Gift Certificate, etc.

We are seeing the need for a good mix of user-maintained pieces, system-maintained pieces, and possibly some mixed-maintained pieces (user and system). We are seeing this in the watchers, feeders, standalone declarations, time templates, settings, etc. We need to let them play where they can and need to, but also make sure they have the tools and pieces to get the job done, even if we control the pieces behind the scenes.

Eric would like to check in on loyalty points around 11 am for a couple of hours. He texted me and said that he was unable to meet today due to some things that came up. So, in the meantime, Steve and I had a great discussion and made some good breakthroughs. Good stuff.

Eric and I jumped on a meeting. We spent the afternoon working on the special account tracking stuff for things like loyalty points, gift cards, in-store credit, punch cards, etc. Our task today was to build the database structure. I was mostly building things, while Eric was watching and working on some of the next pieces. Once we get all of the pieces ready to play, Eric will be doing most of the wiring of the pages. We created branch elt-2 for the new code.

Steve popped in towards the end after Eric left. We worked on some of his pages and talked about 3rd party solutions and how to help integrate with more of them that offer great functionality and customized solutions. Good ideas. We'd also love to keep up good relations with both Russell Moore and Calvin Chipman. Both are great developers and could bring some fun tools and features to the party. We'll have to see how things play out.

Emails and tech support stuff. Writing updates on the compromised data server from this morning. Light follow-up.

Working with Eric on the special accounts project (sub of the balance sheet). This will be for things like rewards, loyalty points, gift cards, in-store credit, punch cards, etc. The task today was boiling things down into a small to do list. After that, I made a small clean-up function, wrote some new documentation, and started into the basic page layout and structure. Once that is done, Eric will take the project and start filling in code on the different pages and components.

Eric and I were working on special tracking accounts. He was wanting to know how to create a master list and then have all servers play accordingly. I showed him how we currently use the copy tables and update tables function from the data 0 box to all other serves, including local development boxes. That got him thinking and excited about possibilities.

After that, we went back and started building from where we were yesterday. We are way up high on the add/edit special accounts page (master or universe level for things like loyalty points, gift cards, in-store credit, punch cards, etc.). We finished up the day by having a simple add/edit form, a results page, and an action page. Eric has done tons of custom code inside of adilas. Having said that, most times, he has been tweaking what already exists. This project is a good one for him, because he is building from the ground up. He is chewing it up by leaps and bounds. Really cool.

Jumped on the meeting with Eric. We were working through more flow and logic on the special tracking accounts (balance sheet subs of subs and used for things like loyalty points, gift cards, in-store credit, etc.). We made some good progress on the master level settings and rules (super high up on the adilas admin level).

See attached and fill in some info about the meeting. Planning out the next level of the sub special tracking accounts (sub of the balance sheet) for things like loyalty points, rewards, gift cards, in-store credit, etc.

Eric and I had a work session on the sub special account tracking project. This is where we are going to be allowing rewards, loyalty points, gift cards, in-store credit, and other special tracking needs. We spent most of the block reading over a brainstorming doc and refining it a bit more. We made a few decisions and added a number of new notes. Towards the end of the session, we even added a new payment type (money type) to the data 0 box for "Rewards/Loyalty". Our plan is to hit it again tomorrow.

See attached for a copy of the current notes.

On with Steve and Dustin. We got caught up from happenings over the weekend and both Steve and Dustin had a couple of questions. After that, we then all of us went on mute and started working on our own projects. My first task was buckets full of emails and what not. Setup some sub account stuff for Wayne on the Newtek site to help manage some of our servers, support tickets, and account details.

Eric popped in and we setup some blocks of time to work on the sub special account tracking stuff - first couple weeks in January. This is for things like rewards/loyalty points, gift cards, in-store credit, etc. It will be good to get some dedicated time to work on that project.

Steve and Dustin were on the morning meeting. Steve had a quick question about a custom report for owners. We talked about some security hashes that could help the report be more secure. The admin report needs to be outside the secured environment and kinda a quick access link to a quick breakdown report for admin users. Steve has the report built, he is just adding some security and then going to add an access point from inside the secured environment.

I got a call from Russell. We talked for quite a bit about some custom client needs and how best to proceed with those requests. We also spent some time talking about using Bridgerland or BTech to help build out some of the fracture type pieces. The term "Fracture" comes from an idea that Steve had back in June of 2017. Everything in adilas seems to be fracturing and breaking into smaller and smaller pieces. Just discussions at this point, but basically a centralized brain (backend engine) and then a deployable front end that could be hosted on any client server or through a commercial web host. No special setup and a fully customizable frontend interface. The whole thing would talk and/or communicate through API socket connections and back and forth API traffic. We talked about ideas, options, etc.

If I were to put together a small fracture tick list, it would be something like this: (just ideas)

- Customizable look and feel (corp-level, department level, user level, and whatever in between)

- Preset defaults with ability to tweak out the defaults and settings (good starting spot and/or basic structure - starting templates)

- Permissioned out and/or micro permissioned (down to the functions per section)

- Settings for layout, settings for display (show/hide, sort order, aliases, instructions, required yes/no, validation rules, etc.) - As of right now, we are seeing settings on 4 different levels. They are world (corporation or business entity), groups or system player level (customers, invoices, deposits, expense/receipts, PO's, parts/items, vendors, users, stock/units, balance sheet items, quotes, elements of time, etc.), page level settings (what will show/hide, sort order, placement, flow, etc.), and finally, user level settings and defaults. How do I want to play the game (at a personal level)?

- Existing structure and flow, but it could be modified. Basically, a template of the starting procedure and/or process but make it able to be modular (build mini data assembly line type options per procedure/task). Think of our model with the mini bubbles and/or pods. These interface with flow, permissions, time, flex, and mapping clear out to the accounting levels.

- Real in-line database extensions. This allows us to provide a basic starting point (database tables and template flow) but also allows for things to be expanded and/or contracted (lessened) based off of configuration. These database extensions could be data types and allow for numeric, decimals, text, dates, on/off toggles, and even long text or JSON storage.

- Be able to save and build any kinda of report or data export - using existing tools

- graphics, charts, graphs, and other summary type options

- Support of both transactional data (what happens day to day) as well as aggregated (summed or pre-calculated values)

- Digital story telling, using characters, relationships, cause/effect choices, consequences, etc. World building concepts.

- Configurable interfaces and functionality per business vertical - click of button to switch layouts and/or processes.

- Customizable (data or logic hooks or black box technology) on client side, server side, and display and logic sides.

- Responsive and/or mobile ready

- Tons of flags, tags, and special callouts

- Be able to tie everything to time or elements of time. This could allow for groups, categories, types, sub locations, sub phases, sub status, etc.

- The list goes on... Most of the ideas have been recorded somewhere in the adilas developer's notebook pages. A great resource, it just may take some time to review and categorize. 

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

Back to other topics, Eric popped in and we made a few more notes and decisions on the sub special account tracking stuff (gift cards, loyalty points, in-store credit, etc.). After that, Wayne jumped on and we talked a little bit about email servers and what is needed there. I spent the rest of the time recording notes and reviewing to do lists. Busy times.

Going through code done by Eric for the sub special account tracking project (loyalty points, gift cards, in-store credit, etc.). I was working through master account rules today.

Back doing code review for Eric's sub special account tracking project. This is a sub of the balance sheet and will end up allowing for things like reward points, loyalty points, gift cards, gift certificates, punch cards, in-store credit, lunch cards, vendor credits, employee payroll draws, affiliate programs, tiered marketing options, and tons of other special accounts. Basically, we will track all of the special accounts and then connect them to a single balance sheet item. The main balance sheet item will show up on the actual balance sheet. Behind the scenes, we will keep track of all of the tiny twists and turns and individual transactions. The summed up results will then be available for the balance sheet as part of the assets, liabilities, equity accounts, or even phantom accounts (kinda there and kinda not there). Pretty interesting.

Shannon and I met and talked about progress. I shared with her that we have 4-5 big projects that are coming into play in the next little while that all have a balance sheet flavor of sorts. We went over those pieces and how they play in. Some of the projects are: expand the transitional invoices and adding in inventory in transit (shown as an asset), new transitional PO project that Will is working on (in code sign-off but stills needs a little work), sales tax expansion project (on phase 5 of 5 and just need to finish some things up), Eric's sub special account tracking project (sub of the balance sheet for things like loyalty points, gift cards, in-store credit, etc.), and sub inventory with mini conversions (deeper inventory tracking and how that affects the balance sheet).

I also spent some time drawing out some changes that are coming with our transition out to AWS (amazon web services - new web hosting model) and things that Wayne is working on. I drew our current model and also what I know of the newer AWS model. We talked about pros and cons and I tried hard to help Shannon know where things are going. Some exciting stuff coming down the pipeline.

We talked about the concept of filtering and boiling things down and using a funnel type analogy to get towards the goal. Sometimes it takes years and years, but we are still making progress and learning along the way. We ended our meeting by using a quote from an author (different Shannon - Shannon Hale) - "There will still be time..." Sometimes that really helps me out, if I'm stressed or something. There will still be time...

Josh joined the meeting and we worked through a few small things. He has 5 files that needed to be looked at. We talked about a few things and he will be reporting back in tomorrow for the final sign-off.

Wayne jumped in and had some questions about where and how we are storing images. We talked about what it would take to get all of those images pushed out and stored on the adilas content server. As part of our conversation, we did a quick search to see how many pages may need to be updated. We got a number around 340 pages that deal with images and/or image paths. All of those files would need to be updated.

Back on the code review project for Eric and the sub special account tracking stuff - sub of the balance sheet for things like loyalty points, gift cards, in-store credit, etc.

It must be Monday... We started out on the morning meeting and only Steve and I were on at first. We chatted about the transition over to the AWS (amazon) stuff. We have a number of questions and aren't really sure which way to turn. Steve needs to provide some of our clients with an answer, can we service them or not, and we need to know how long it will take to get the AWS stuff fully up and running. Lots of unknowns, but some great potential. Part of us wants to return to what we know (older stable ground) and the other part of us wants to keep pushing forward (new and uncharted but promising ground). It creates an emotional battle of sorts.

We switched gears and Steve had some questions about a project where he is tying in balance sheet numbers to vendors. As part of his project, he was trying to come up with a switch that we could flip to help us know if a vendor was an inventory (parts or items) vendor or just a normal vendor. As we talked about it, we decided to take it out to an app type level (the 12 main system players). We talked about that and Steve liked that idea. I got him some code to help him get started. It is amazing how much, as we keep going, that the system keeps organizing itself into main player groups and what kind of relationships are needed per system or main player group. Very interesting. Almost like it likes to be organized into groups and related functions. We sure have learned a lot along the way.

Alan joined the meeting and we were talking about some of his projects. He is still working on automating some of the reoccurring invoice stuff. We also talked about having Bryan work on the dynamic field names and settings per main player group. That is pretty deep and we may keep it tabled for now. Also, as we were talking about it, we were talking about how an object oriented programming approach may be a better solution for some of these new settings and defaults. Currently, we build and break, build and break (speaking about pulling and accessing settings). It may be nice to keep and hold some of the persistent or permanent settings and features. An object oriented model may be better equipped for that type of transaction. Currently, we look things up just in time. In the future, we may need to catch and hold those settings and maintain them in the user's session (stored in memory) options.

Eric popped in and we did some check in and follow-up with his code review on the sub special account tracking project. This project is a sub of the balance sheet and deals with special accounts (mini bank account type objects) like customer loyalty points, gift cards, in-store credit, etc. That project is promised by next Monday. I will be trying to focus on the code sign-off this week.

After that, Eric and Steve and I started talking about some of the new look and feel, CSS, and user interface stuff that Eric is wanting to help with. Both Steve and Eric were talking about a virtual "Adilas Cafe" or a global landing spot for the adilas users. This all goes back to separating the users from the main application code. There will still be a tie-in, but we are seeing a bigger need to keep users on the outside as a single entity and then allow them to go in and work or be a part of a corporation. We have many users that  have and/or will need access to multiple corporations, and even be able to bridge across physical servers. Currently, our model is based on users per server and then tied to corporations based on active permissions to those corporations. We are seeing a need to break that down even further and have a master or global user id (virtual pool of users) and then allow them to be bridged to different corporations on a more global scale vs just per server (physical box) vs the possibilities of dynamic cloud networks.

As we got deeper into the conversation about the potential of the Adilas café type model, we were talking about doing mock-ups, flow charts, etc. Eric had some questions about authentication servers and how that would all roll into the mix. We told him that he would need to get with Wayne to get more details. As we talked, we decided that Eric and Wayne should work together in a mini team type environment. As we explored the options, some of Steve and I's concerns (listed at the top of this entry) started to go away. We ended up somewhat asking Eric to be a project manager type role for this transition project between Newtek and AWS. That little tweak in the plan and how the developers were paired up, made a ton of difference and some of the anxiety started to go away.

We need to crate a list of specs for Wayne and what we want the application to do. Plan and play as if for years. We also talked about in-house coordination and communication. That is a huge key and helps all parties involved. Steve was talking about skating to where the puck (pretend we are playing hockey) is going to be. He and Eric were talking about the existing login pages and the corporation chooser page as being the beginning of the adilas café (landing spot or centralized common ground area). Good discussion.

We would really like to keep pushing the ball forward and making each system its own entity. This means having a centralized database controlling users and access to different corporations and/or entities and then having the individual entities having their own database or system for just their stuff. Currently, there are a number of tables that are shared between parties. For speed and efficiency, we really need to split things up more. This may also affect how we are able to bill for storage and processing vs a set monthly system fee. Anyways, as the conversation progresses, Steve and Eric were talking about using the choose corporation page as the starting common spot or commons area. Steve was also saying that he would like the users to be able to go to work (assigned or authorized corporations) as well as go play (demo sites, play grounds, or play sites). Basically, anybody could have an adilas account, and then they could either go into a real site (aka work) or a play site (aka play and testing). Fun ideas.

One of Eric's and Wayne's first item of business will be to do a virtual inventory check of where things are at on the project and what will still be needed and/or stands in the way. That will be awesome. It really was an mini answer to prayers that we decided to team up Eric and Wayne. It helped us let go and be willing to embrace some of the unknowns. As part of that, we are hoping that having the guys work together in mini teams helps us prioritize what really needs to be done and when. Sometimes, by yourself, it is hard to know what needs attention first, especially if it feels like everything is vying or trying to get the input, attention, and/or priority. Crazy stuff, I'm been there before and will be back again.

Steve and I talked about cycling through hardware and how that is just part of the line of work we are in. Later this year, we will need to buy some new laptops and upgrade some of our development environments.

One of the breakthroughs for today was the mini team concept. We have Steve and I, Steve and Dustin and Josh, Brandon and Alan, Wayne and Eric, Shari O. and Pat and Drea, etc. There are starting to be all kinds of little teams. That is awesome.

Shawn popped in and reported on some payroll updates and changes. We scheduled a time to meet again tomorrow. He is also willing to help me out with some of my projects and such. After that, I spent the rest of the session recording notes and trying to get caught up (as good as I could).

Working on the special account transaction homepage. This is part of Eric's special account tracking project (sub of the balance sheet and deals with customer loyalty points, gift cards, and in-store credit type stuff). Made some headway on the special account transaction search and homepage (what are the individual recorded details).

Also helped Shawn with getting back into the invoice due date project.

4.32 - Gift Cards, Rewards, & Loyalty Points

-Tons of custom options are available. Often these reward programs have some corporation specific flare.  

-The Adilas standards are still currently under construction. Expected release data first quarter of 2019. Some of the standards will include: loyalty/rewards, gift cards, punch cards, in-store credit, vendor credits, etc.

-Technically all of these special account types or payment types are subs of the balance sheet. Behind the scenes all of these accounts will be run under a general title called sub special account tracking. Within that we will allow you to name the special programs according to your needs. For example, if you want to call your gift cards XYZ Bucks, that is totally fine.

-All of the programs that get setup will automatically inherit a default set of rules. Then we will let you modify those rules to match your company. This may be custom naming, special ratios, values, redemption exceptions, all kinds of rules, etc.

Back working on the code sign-off for the sub special account tracking project (customer loyalty points, gift cards, in-store credit, etc.).

Got a call from Bryan and we had to jump onto the SWC dedicated server to check on a database problem. We found a locked table and had to reset the database server.

Pretty quite meeting this morning. Dustin checked in and then bailed out. Alan jumped on and gave me a small report. We also spent some time looking at the custom tables for holding sub inventory attributes. We talked about some possible rework options and helping that process. We logged into a server and looked around at database activity, column counts, row counts, and basic database stuff.

I got back on the code review and code sign-off for the special account tracking project. This deals with things like customer loyalty points, gift cards, in-store credit, etc.

Back on the loyalty points, gift cards, and in-store credit project. It has been on the side lines for a couple of months. Back in looking around on the sub special account tracking project that includes the loyalty points, gift cards, etc. Took about an hour to review notes, get back to the correct branch, look around and find a spot to start back in on the project. I would call that transitioning.

Spent the rest of the time doing code review, checking, and moving forward. Started back in on the corporation special account transactions homepage.

Spent a couple of hours back working on the special accounts project (rewards, customer loyalty points, gift cards, in-store credit, etc.).

Interesting conversation between Josh and Steve. The topic was dealing with project management and how quickly our developers can be highjacked by custom requests. Steve was recommending that we try to capture all of the custom requests out in the adilas community funded projects vs just having the clients go directly to the developers. There are pros and cons to that... If they go directly to the developer, they (our clients) get things quicker, but it has a hidden cost (called distraction and/or highjacking of resources). If they go through a channel, it has some different pros and cons. One, we could mix and blend and figure out project management, allowocations, budgets, and priorities. We could even match funds and do other things. On the flip side, sometimes, if it gets mixed in with all of the other projects, it may not get done quite as quickly. Pros and cons and each side. It is amazing how it comes back to a balance type dance.

Steve and I had some great conversations about our guys, our process, and where we want it to go. Another topic was dealing with returning and reporting and checking in. Sometimes we have huge projects and we don't get any communication for weeks on end. We are going to try to implement more regular communications. That should help everybody know what is what and where things are at. Funny how it goes back to forming, storming, norming, and performing (team building skills).

Eric joined the meeting and we setup some big blocks of time to work on the special accounts project next week. That is for customer loyalty points, rewards, gift cards, in-store credit, and other special payment or special accounts.

In working on sub special accounts (rewards, customer loyalty points, gift cards, in-store credit, etc.). Added some new validation and formatting to the show special account transaction report.

Spent some time working on code sign-off and review for the special accounts project. This deals with rewards, loyalty points, gift cards, in-store credit, etc. Working on the methods inside the submit cart page. Lots of nested logic and methods calling other methods. Things like look up account types, see if they should/shouldn't use loyalty points, how many are earned per invoice, how many are redeemed (spent) per invoice, balances, rules (point values), etc.

Spent the entire afternoon working on the sub special accounts project (sub of the balance sheet). This will be used for customer rewards, loyalty points, gift cards, in-store credit, etc. Lots of good break throughs today. We added a fix for using application scope variables in the cfc's (ColdFusion components - backend logic pieces), tested the submit cart page, and we added in the account rule that dealt with show/hide the loyalty points on the invoice (customer receipt). We also showed totals on the customer log file with a valid drill-down to see the details. We are making progress. I also added some new notes to the main scratch file for the project. See attached. Good session.

See some of the attached media/content pieces for an overview and preview of a new feature called special accounts. This is for things like rewards, customer loyalty points, gift cards, in-store credit, punch cards, etc.

Thanks for choosing adilas.biz!

Got up early and merged in some code from Eric and I's project on the sub special accounts. This is for things like rewards, customer loyalty points, gift cards, in-store credit, etc. Anyways, we had about 50 files to merge in and test. Worked on some new help files for the new pages and sections. I got all of that done and launched code to the data 0 for testing. Everything went well, so I pushed up code to all servers. Immediately, we got some calls and texts and people were getting an error. We jumped on it and had it resolved pretty quick but still had some complaints. We try, I literally tested on both local and live before pushing to all servers. Certain people have different settings and sometimes that affects things. We got it done and then I went to the Adobe ColdFusion conference. Busy start to the morning. 

Bryan and I met to talk about refunds. Those get kinda funky as each corporation may have different steps, fees, requirements, and processes. We talked about some of the possible variables and looked at some situations and scenarios. We did some negative invoices, talked about validation, and even setup a refund recipe to help automate a couple fees that the client wanted. I think it helped to talk through things. Lots of human variables in a refund, partial refund, exchange, or applying in-store credit.

Shannon and I were working on the presentation gallery outline. Our topic for the day was accounting. We got to a certain point and basically said "plus, plus, plus" meaning and it just keeps going. I was ready to stop and Shannon kept asking some great questions. Before long, we had more than double what we started with and were still going. I'm really glad that she kept asking questions and having us talk about things.

As a fun takeaway from our meeting, we talked about making conscience decisions and then sticking to those decisions. For example, we often say to people, sorry, but we do it this way vs that way (fill in the blanks). As Shannon and I were talking, we decided that we are not doing this because we have to or we got forced into something. This, what we do and why we do it, is a conscience decision and that's what makes us who we are.

See attached for our brainstorming document. You may have to scroll down to page 18-19 to get to the new brainstorming stuff on the business function of accounting. Just for fun, here are some of the ideas...

- We started out with basic stuff like: balance sheets, P&L's, user-maintained items, system maintained items, accounts receivable, accounts payable, aging, reimbursements, expenses, banks, inventory tracking, layaways, work in progress, loans, etc.

- Next we got into photos, media content, custom documents and ways of connecting with other outside file assets (documentation).

- Natural flow, flex grid tie-ins, payroll, people, deposits, invoices, customers, users, stock/units, floorplan, tons of reports and exports, bank reconciliation, etc.

- Slight switch to more concepts such as: operational lead accounting, mapping, roll calling, translating, where do the numbers come from (relationships and cause and effect options)

- Loyalty points, taxes, sales tax, withholdings, PO's, manufacturing, inventory tracking and manipulation, life cycles, going backwards and forward, and automation.

- Traditional vs non-traditional accounting

- System and how that makes a difference - everything is there and you can start to interconnect the pieces - digital storytelling

- We do accounting because we have good data - the accounting comes from the data

- Tons of permission levels and who gets to see what

- Accounts, ledgers, glossary, terms, and concepts

- Data assembly line, digital story telling, cause & effect, characters interact to solve trouble and problems, more relationships and building, maintaining, and in some cases destroying those relationships. Processes.

- Time - time is a huge piece of the puzzle

- How do we zipper operations and accounting together to close the gap between the two?

- How does the system handle roll call technology, who, how, what, and why???

- If someone can do their accounting by their own design and take it to their accountant (shoe box, spreadsheets, random records) - then why can't I create something that automates and maps out that process.

- We play according to the standards and the rules but we on purpose create the processes to get to those data points.

- Tradition - our biggest competition

- This is daily, real-time, sharing, no batching/waiting, managers and admin can look at things real-time, cloud based, editable, full history, audit trail, cause and effect, cart and horse, data drill-downs, proof behind your numbers.

- Why we chose to build in a non-traditional manner - because we see all the benefits and we want to keep going in this direction - conscience choice

- We are pioneering and we are on purpose creating tools that are proof of concept

- Crazy accounting things like phantom costs, funny money, slush funds, etc.

- Sub inventory and cost controls - perfect costing vs other costing models

- Normal revenue, COGS (cost of goods sold), gross profit, expenses, net profit, assets, liabilities, equity, retained earnings, etc.

- Future - we have a challenge and we build to solve that challenge that is before us - this is part of our accounting model

- Some people expect us to be completely done but we are not done - we are going to keep building and breaking, building and breaking. That is part of our model.

- You really need human input at certain places - decisions have to be made - you really can't automate some pieces.

- Ongoing development - bring your ideas - stone soup "Bring what you've got, throw it in the pot. We are making stone soup."

- Open to suggestions and new growth

- Things that drive change: pain, brick walls, burning platforms - all these pain points help to bring about change and new solutions

- Static vs dynamic - both flow and environment - things are built differently based on the conditions (static vs dynamic)

- Allow for updating inventory counts - how do you deal with theft, shrinkage, expiration dates, spoiling, and other inventory reconciliation stuff.

- In-store credit, accounts, discounts for terms, bonuses, games, vendor credits, etc.

- We give you the tools to play the game

- Accounts, sub accounts, locations, sub locations, phases, sub phases, etc. - details, layering, and stacking (aka space)

- Add notes to anything, able to add log notes and tie things together

- Track the story - the story is powerful - telling the story is your audit protection

- We can and do deal with multi-locational stacked models. We also deal with cross corp stuff and multi-worlds rolling up or down into the respective holding containers. It can get really deep and complex.

- We don't require you to do this... this, meaning how we do and track accounting, is optional.

- From Russell Moore back in 2016 - We can be a good companion with any other software package. Run any part of our application without using the pieces you don't want. We can feed information to any other software package you want to use. Adilas is a great companion software package for ANY business.

- Conflict management - it is okay to stand your ground. Be confident in what you have built and why you have built it that way. We are going in this direction! If you like what we are doing, great! If not, great, feel free to use some of our other products, services, or pieces if you would like. You do not need to apologize for things that are in line with your values and your vision. The vision helps us all work and succeed.

Anyways, fun brainstorming session. We will take these ideas and refine them into a section in the presentation gallery that deals with the business function of accounting. Great session and fun stuff.

Cory, Steve, and I were talking about different projects. We decided to scrap one of them and wait for some other changes to roll into place. I was pitching an MVP (minimal viable product) on some payroll stuff. We chatted about needs there and where it could go. We talked about bulk payroll, special time card aggregates for some of the math, multi-department based timecards, new fields and settings for special programs, and other fields and values that are needed.

As a fun side note, we even talked about mixing payroll functions with special accounts (accrued hours and virtual time based loyalty points for employees and special laws dealing with additional funding and special programs). Special accounts are for things like loyalty point for customers, gift cards, in-store credit, vendor credits, etc. In this situation, we would be using special accounts to accrue or add up additional hours that are earned over time. Then, the employee/users could redeem those extra hours or bonuses, when they wanted. We would have to keep track of values being added to their account, as well as values being paid out or virtually redeemed. This gets into liabilities, and who owes who and the timing that goes along with that. Interesting twist.

Cory and I going over a list of questions. About halfway through, Steve and Chuck joined us. I think that they were going to meet and work on some look and feel, but Cory and I were on the meeting. Anyways, the question got brought up about doing down payments on stock/units and how to book that and keep everything straight. The real answer is using transitional invoices. Having said that, we went round and round talking about possible options. Towards the end, Chuck was saying that when we redo our fracture stuff, we may need to make it part of the system that a prepaid invoice, deposit on merchandise, in-store credit, and other things be put in place and education and training made available.

For the record, here is how you would do it right now... using a transitional invoice.

1. Stock in the item, even if you don't have it in stock. If it is in stock, use that item. Anything that is unknown, just make a note of that. For example: a serial number or VIN number - maybe use the customer's phone number or email address.
2. Go to the stock/unit and go through the invoice/sale process. Make sure and set it to a transitional invoice (that wording is dynamic - layaway, prepaid, etc.).
3. Do the sale for the full amount and then take the amount that is either pre-paid or deposited. That will start the journey of the stock/unit and the payments received. All of these transactions will auto flow over to the balance sheet (already built-in) if using a transitional invoice.
4. Keep the invoice in the transitional state until it comes in, gets delivered, or whatever. If needed, additional payments (deposits on merchandise) may be made along the journey.
5. When ready, flip the transition invoice over to a real customer invoice and finish out the rest of the info. Once flipped, it will show up for sales taxes, on the P&L, accounts receivable (if money is still owed), and will count against inventory values. Prior to that, the whole thing is held on the balance sheet as the work in progress, pre-paid invoice, layaway, deposit on merchandise, etc. (dynamic naming).

Anyways, the takeaway is for fracture, we really want to have a way to show our people how to do certain tasks (searchable education mode). We also want to have some of the special account stuff like in-store credit, vendor credits, gift certificates, coupons, punch cards, etc. all done and part of the system. Those features may be built-in prior but need to be there. As a note, a lot of those will be sub sections of what we call special accounts, just like the current loyalty points stuff.

Meeting with Steve and Cory to go over projects. We talked about a couple of projects for Eric. We talked about gift cards, other special account projects (in-store credit, vendor credits, punch cards, coupons, and gift certificates or gift cards). Another one is the mini aggregate project to handle inventory quantities per location. The other possible project for Eric is getting back to the enterprise item catalog project. All of those have value and would be great add-on's.

The next major subject was projects that Alan is either working on and could work on. He is one of our top developers and is in demand, because he can do so many things. One of the projects that Cory really wants him to work on is the transition invoices out in ecommerce land. They already exits out there, they just need a little bit of loving. He could also help Steve out with some BioTrack production stuff.

Lots of talk about other developers and what they are working on. It is a challenge to coordinate projects and developers. Lots of moving pieces. We also talked briefly about some projects for Bryan. We are still trying to help our clients transition from billing in the old independent way to dealing with Adilas as a team or an entity.

Another subject that came up was the number of hours spent in a training and tech support with our clients. It takes a lot of time and effort. One of the benefits is that we learn a lot along the way. The more we help our clients, the more we learn, and can adapt the tools and features that we have to get the desired outcome. Along those lines, sometimes we (internally) need to be reminded of certain processes and tools that exist that we may not remember or are new to us. For example, all of Steve's new backorder stuff that he developed and managing quotes, orders, PO's, and backorders.

Cory was kinda putting her virtual foot down on certain projects. We are trying to retain our clients but sometimes they get out of line. We talked about preventative maintenance type stuff with our existing clients and helping them along the way. We, as a company, are offering more and more internal service offerings. We used to sub it all out to outside independent sub-contractors. We are trying to make those same offerings, but do it all internally now and helping out in new ways. It makes for a better product and better retention.

Steve and Sean were touching base on sales. Steve had a few code questions for me dealing with queries and flow. John joined the called and was asking Steve and Sean about prices and options for clients (pricing structure stuff). Eric joined and was asking questions about gift cards and going over different ideas.

This may or may not help, but I went in and found a bunch of older files that we were had started and worked on dealing with special accounts, loyalty points, gift cards, customer in-store credit, vendor discounts, and other special account stuff. See attached.

Just Steve and Sean were on the meeting with me this morning. By 9:30 am, both had bailed out to do different things. We were doing some quick updates and going over things before they bailed out. Here are some of my quick scribbles (notes):

- Gathering ideas from different people. Including new people who are already influenced by existing adilas theory and designs.

- The value of education

- Talking about options for selling shares, percentages, and maybe going public with adilas in order to raise funds for projects that we want to do and pursue. It's all about the connections.

- Steve was talking about the drive to make more money that is shared by most business owners and entrepreneurs.

- Selling adilas to fill in small parts of the business as fill-in pieces. Not piecemeal but selling certain tools and features to help round out other businesses, models, or software packages. For example: Say someone just needs ecommerce, online ordering, scheduling, timecards, or even things like gift cards. We pitch it, get them going on what they need and hopefully they like it and want to expand to other parts and pieces. This is an older saying from Russell Moore back in 4/13/16, "Adilas is a great companion software package for any business!".

- We are still seeing a future need for in-store credit and being able to apply those liabilities to outstanding invoices. You can do it right now, but you have to do everything manually. We would really like to automate that whole process and make it super easy and smooth. This will end up being another one of the special accounts type functions. Not everybody gets it, only certain people or customers need it, and it is basically a reverse account where you overpay and then get to use that value to pay for other things. Very similar to gift cards. As a matter of fact, you could issue a gift card for the overage and then let them use it at will as a payment. Once again, in-store credits will play along with other special accounts such as gift cards, gift certificates, loyalty points, punch cards, lunch cards, vendor credits, and other special account options.

- We got into some talks about deployment as a bottleneck and how training and education could help solve some of that pressure and bottlenecks. There is also a huge need to keep educating and providing learning for new functionality that keeps getting developed. That's an ongoing process.

- Small discussions about keeping up some of the demo sites and making them nice and clean. There is a huge value in nice, clean, data.

After Steve and Sean left, I sent the rest of the time looking over emails and looking into a possible bug on invoices and the new bigger alternate logos for PDF invoices (some new invoice settings).

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.

Sean, Shari O., Michael, John, and I were on the morning meeting. We all checked in and said what we were working on. After that, we all either left or went on mute and worked in the background. Shari O. had to take a tech support call and Sean was waiting to chat with her once she was finished. John had some flex grid tie-in questions. I was doing some research on MVP's and past data that we had recorded for what we wanted in some of our MVP (minimal viable product) stuff.

Here is a short MVP list that I'm thinking about - for the record, we already have some of this, we just need to refine it and make it watertight:

- Special accounts and in-store credit - We already have loyalty points, and round 1 for gift cards. Eventually, we would like to do in-store credit, vendor credits, punch cards, and other ones. The next biggest need is for the in-store credit stuff (in my opinion).

- Round 2 on gift cards - We've been gathering ideas and wants and needs

- Coupons and promotion codes - clear out and through ecommerce and internal shopping carts

- Take Calvin's adilas label builder to the next level - we've already done some planning and prep work there

- Standardize the merchant processing options - We have like 9 different integrations. Here's my next goal, pick one, make sure it flows from start to finish and is super simple. I want to do normal sales, pre-auths, captures, tips, refunds, voids, and reoccurring payments, etc. We have to be able to do manual key (like ecommerce mode), swipe, chip/EMV, and tap to pay hardware integrations. I want to do and offer all of the merchant processing functions. I was thinking that we could do a big push and try to get all hooked up with Datacap and then let them handle all of the different hardware pieces and different merchant gateways. That's my thoughts right now.

- Revamp the internal shopping cart, my cart favorite buttons, and general look and feel. I would love to head towards the fracture project - we have a bunch of R&D on where we want to go with that.

There are tons of other things on my list, but that is my quick MVP list for right now.

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.

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!

Suzi and I jumped on a demo meeting with the Puppy Pals folks (potential client). Suzi was doing the demo. They, the Puppy Pals folks, need real time texting (push notification). Suzi was demoing the messaging stuff that we have out in ecommerce. Their clients need a quick way to get logged in, communicate, and even get automated responses. They really need notifications.

We switched to flex grid and showing limited flex grid options (for entering pets and one-to-many relations between clients and pets). Talking about dashboards. We went back to messaging for a bit - they really want real time text messaging. Deeper talks about wanting automatic messaging and responses. Two-way communications are needed (big time). Even batch messages.

Suzi handed over the demo to me and I helped with some scheduling stuff. Lite show and tell. They like the time down the side and people across the top for their horizontal time views. Lots of other notes and requests. Basically, they have a complex scheduling need. Almost a 3D model. They have time, rooms, and attendants. They have to matchup all of the pieces.

Partway through the demo, I started writing things down... this is kinda rough (my notes) but here is what I recorded in a quick notepad doc...

- Booking and re-booking

- Moving appointments around

- 5-6 clients coming in at a time

- 100 appointments a day

- Logistics of what happens each day

- Need a quick overview

- Docking and sliding appointments into the slot - temp copy and paste to move things around - move all of the pieces - all of the extras - maintain relationships

- Complex appointments - and then rebooking those appointments

- KISS (keep it simple silly) - visually formatting things to work with the team

- Be able to move the data around

- POS integration

- Be able to divide the tips

- Be able to take a deposit on upcoming services - pre-pay

- They have both taxable and non-taxable items and services

- Bill for no show

- Payoff accounts

- Customer credits - in-store credit

- Notes for customers, notes for pets, notes for appointments - two or three years of notes

- Calendar and time-slot issues and needs

- Per appointment - show dog name - show client name - breed - color code(s) - size, appointment type, assistance level

- Conflicts and rules - max out levels - how many rooms may be booked at once

- Conflict notices

- Each location is different - they are trying to grow from two locations to 10+

- Biggest challenges - complexity of the appointments and be able to move things around

- Be able to manage things and move things around

- Everything happens within 15 minutes... they come in, they get serviced, and they get checked out (payment), and maybe get re-booked

- Future dashboard options - financials, scheduling, inventory, etc.

- We want to help you further that (what you are doing)

- These are "dog" (pet) people

- Pare it down... make it look easy... (frontend)

A lot of that we already have. I was just writing down what they were saying so that I had a record of it. One of the ladies on the call was very sharp. Her name was Jen. You could tell that she had some software and development level background. Great questions, responses, and just knew her stuff. I was impressed.