Going over some new database updates that Steve was working on. We then switched gears and started working on some internal API socket connections. Steve is working on a small internal project that takes sales data and passes it between servers for a consolidated mini report of sales per corp.

We then got into a small brainstorming session about corp-specific aggregated data (summed up data) and how we could help with a multi-corp consolidated aggregated data type model. Eric said something the other day about having a master corporation and then getting data from that one (from the master) to feed the smaller or sub corporations. We talked about taking that option out further and how another corporation could be a great collecting spot for the cross-corp and/or consolidated aggregated data.

Random notes from our brainstorming ideas:

- Start with the corp-specific aggregated data. Each corporation will end up needing their own corp-specific aggregated data table. Our goal is daily totals per location and per category (we need to figure out what those categories will be, but pretend that they are at the category level).

- We were talking about terms and how best to state and/or call the consolidated aggregated data - if they (different and multiple corporations) want consolidated data... we could sell them another system and get cross-corp aggregated data passed back to that system - not sure which way it sounds better (two options): aggregated consolidated data or consolidated aggregated data

- What about cascading our model - we may not want to alter our model, we may just want another consolidated corp and use internal API sockets to update master controls.

- How do location(s) play into the model? What do location(s) look like on a corp-specific model vs consolidated data and what location(s) are/do out there? We talked about maybe having different mappings from corp-specific data to consolidated data and what is tracked and shows up and what may be combined together. In a small way, it almost feels like application flex grid type mapping and such. Fun ideas and concepts.

- Going back to a master corporation. We could setup a master lists of items, a master lists of customers, etc. If any of the subs add/edit things... we could figure out if those add/edits go uphill or only roll downhill (direction of updates and changes to data and master lists).

- We may need to take the part/item categories to a multiple level (deeper one-to-many system). This is an older project, but it has laid dormant for awhile. We may need to pick it back up.

- Technically, we could do the cross-corp consolidation stuff right now, we could remove the double entry out of the solution and help automate things. Figure out the flow of data.

- Eventually, we will want (or our clients will want) location specific aggregated totals, even out in the consolidated aggregated model.

- We talked about maybe having a special mapping table on the consolidated corporation side. More application flex grid and advanced mapping stuff.

- There may be some huge advantages by using existing tools such as invoices, deposits, expenses, PO's, balance sheet items on the consolidated side of the equation. Many of those things are already mapped to income statements (P&L) and balance sheets. That might be a good approach to helping out with the consolidated reporting.

After the brainstorming session, I left the meeting and starting do some other smaller tasks. I payed bills, did some emails, and got on the phone with a couple of other developers. I chatted with Calvin about custom labels and maybe getting into sub inventory and sub attributes. I also talked with Alan about helping out for the rest of the week as I will be out of town on a scout trip.