Marisa has some questions about EDI (electronic data interchange) and API sockets. We told her that EDI and API's are very similar. EDI was more of a front runner, but most modern apps and systems communicate via API sockets. They are very similar in that it allows computers to talk to one another via electronic communication channels. She and Steve were also talking about other client messaging options besides text and email. Different types of push type notification based on elements of time and/or customer logs that are visible via a valid ecommerce or customer portal login.

Steve, Cory, and I spent the rest of the time going over ideas and brainstorming on aggregate totals, and moving grouped and pre-summed data up the chain. We did a lot of drawing and talked about different ideas. We know that the bottom most level or base of the pyramid is the transactional core or transactional data. We also know, that per world or per corporation, we need to get to the aggregated totals for the P&L (profit and loss statement or income statement) and the balance sheet.

Cory was taking notes... here are some of them that she passed over to me.

- ETL (Extract, Transform, Load) - this is how you work with aggregated data. You extract what you want, change or transform it into what you need, and then re-load or push it into a database in the stored or transformed format. Make it easy to get it back out.

- We have a map (using the existing adilas system from operations into accounting) - we need to follow it backwards. Be able to pull the P&L and balance sheet quickly and pull it in from one single query. Currently, we have to go all over the underlying transactions and data details to pull back the values. It would be so cool if we could aggregate things as needed, based on the current map that exists in the system.

- P&L and BSI reverse mapping? Let's look into it. What if we could start from the top and then work/map going down? Follow the flow of the data. There are many sub pieces that may need to be linked and/or aggregated together before we can pull the hard, fast, numbers - all from one single place.

- As we map things out, we know we need to deliver what they (our clients) want and also try to head in the direction we want to go as well. That can be challenging.

- Different levels of drill-downs. Balance sheet starts at Inventory levels (way up high), not at part categories, vendors, parent items, or sub inventory items (child items). Eventually, we have to be way up high for the P&L and balance sheet info. Then, as the user needs more details and sub information, they will do what is called a drill-down (going deeper into the details).

- Here are the main pieces for a P&L: Revenue, COGS, Gross profit, Expenses, Net profit

- Here are the main pieces for a Balance Sheet: Assets, Liabilities, Equity

- Futuristic goal: run the balance sheet and P&L over time all the way down to the second. Imagine a time lapsed view of your financials. You have to go from transactional data up to fully aggregated totals in order to get those numbers. Let it begin!

- Thinking about data... Am I tied to a corp? Am I tied to a location? What is my date/time stamp? Do I have a main category or grouping? Reports and financials by day are the current goal. Eventually, it could go all the way down to hours, minutes, and seconds. For now, we will focus on a per day basis.

- Think of a pyramid. Top most would be all pieces, all of the sums. Quick sums- held at the top. We want to capture and hold these sums or totals per day. Much less information at the top than at the bottom.

- Value added cores - we had a great discussion about how we want to use a value added core type model to help businesses run on adilas and also ways that we could monetize the different value added cores or levels that get added onto the main transactional core (the adilas system).

- One table with totals for each (top most level): Corp ID, Date, Revenue, COGS, Gross profit, Expenses, Net profit, Balance Sheet, Assets, Liabilities, Equity, Out of balance value (sum). These would be the top most corp or world level aggregation tables. Quick financials and numbers.

- We don't know how deep it goes yet, but imagine one table with totals for each level going down - until you get to the transactional data. Not sure how deep this goes yet? This might take more than one iteration to build and figure things out. For now, just pretend and start back filling as needed.

- We were talking about tracking things up to 4 to 5 levels deep. These are some of the existing pieces (verbage from the system): Destination/main title, main category/main grouping, sub group or sub category, vendors or types. We need to figure out the 4-5 deep path for all major pieces. For example: If recording revenue, it has a certain path. If recording an expense/receipt, it has a certain path. The same thing is true for things like: deposits, user-maintained balance sheet items, system-maintained balance sheet items, basically every piece of the P&L and the balance sheet - they all have specific paths and need to be at that 4-5 levels deep. Even BSI’s are 5 levels deep. Five levels should cover everything (for now).

- Talked about everything being under one database (new aggregated or math sum/count tables). If we feel we have reached capacity, we could always go out to another database (level 4- aggregated sums) or just add more tables. Lots of options. Once again, trying to figure out where the natural lines exists and what could be extra or add-on values.

See attached for some drawings that we were talking about as we were discussing some of these details and ideas.