Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 12/14/2019 9:49 am
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 5315
Template/Type: Brandon Time
Title/Caption: Adilas Time
Start Date/Time: 1/23/2020 9:00 am
End Date/Time: 1/23/2020 11:00 am
Main Status: Active

click to enlarge - photo by: Brandon Moore - Small drawing on how we could setup an enterprise or aggregated system. The levels are listed on the left side in white text. All of the worlds are level 5's. The level 6's are locations and sub locations. The per day per location stuff is the roll ups.
click to enlarge - photo by: Brandon Moore - This drawing shows some concepts of using a single invoice to capture revenue and cost of goods sold. And a single expense/receipt to capture the expenses per day per location. Those two would be rolled up to the enterprise system through an API socket.
click to enlarge - photo by: Brandon Moore - A drawing on top of the cross_corp_mapping table. The goal here was to show a mapping from corp 1 to corp 2 for a vendor. The drawing in purple shows some rough data that would be stored per record. The yellow was just to show a drawing of the data.
click to enlarge - photo by: Brandon Moore - This was a small sketch of the upper levels of the world building concepts. These are things like: universe, galaxy, cluster, solar system, and world levels.
 
 


Uploaded Media/Content & Other Files (4)
Media Name   File Type Date Description
solar_system_aggregates_pic_3_mapping.jpg   Image/JPEG 1/23/2020 As we were talking about cross corp mappings, we brought up the cross_corp_mapping table and ran a small sample of data through it. This is just a drawing to show what the sample data would be. The purple is the fake data, per field. The yellow is a drawing of what the data may look like and how it is stacked. Playing with ideas.
solar_system_aggregates_pic_2.jpg   Image/JPEG 1/23/2020 Full sized drawing of the virtual solar system based on an enterprise or aggregated system with subs or transactional data systems that feed the bigger or enterprise system. We talked about how pulling aggregated totals, per day, per location, per category allow you to get the totals for the P&L (profit and loss statement or income statement) and the balance sheet. The data could be shown, reviewed, locked down, and transferred to the enterprise system. All of this through API socket connections to help keep track of the ice-downs, transactional data, and aggregated sums and totals.
solar_system_aggregates_pic_1.jpg   Image/JPEG 1/23/2020 Full size layout of the drawing on how to help configure the enterprise and transactional systems inside of a virtual solar system (level 4) model. This drawing also has some other ideas and concepts and how the model relates to other things such as corps, locations, and aggregated totals (virtual roll-up of totals and financials).
universe_drawing_solar_systems.jpg   Image/JPEG 1/23/2020 This is a graphic that was drawn in 2017 to show the different levels within the adilas universe. They are: 1. adilas universe level, 2. galaxy level, 3. cluster level, 4. solar system level, 5. world level, 6. location level, 7. group level, 8. individual level, 9. data level, 10. run all levels over time


Notes:

Steve and I had a good session talking about options of creating a true solar system level system (using the world build and space analogy). We did some drawings, took a few notes, and looked at some older drawings and graphics. Here is a good reference for some older world building graphics - click here.

- Ice-down dates - We had a good conversation about this. What if we pull a general aggregate for revenue, cost of goods, expenses, assets, liabilities, and equity - then when they pull it, they can then push it. These aggregate totals would be on a per day per location and per category basis. At this point, when they pull these totals, we could allow them (the users) to lock things down on that day (the date could a date back in time, depending on when they pull the data). Basically, each day could virtually get a lock-down or ice-down date. If needed, they could unlock things and then lock them back down. Just ideas and we still need to figure out the particulars, but these were some more ideas from today.

- Parent/child >> in the solar system level - We have had a very good experience talking with people about parent/child relationships and how that plays into the mix dealing with inventory items and other stacked relationships. If you go far enough, eventually it gets out into grandparents, great grandparents, etc. Normal parent/child relationships exist all over the place.

- Solar system >> planets (transactional worlds) and the sun (enterprise or aggregate system). We were talking about what terminology works best for our solar system analogy. The solar system is made up of different worlds that are closely related and somehow interconnected either through the database or through a relationship (parent/child or brother/sister or something like that).

- In inventory, we have vendors & customers (high level), PO's & invoices (medium level), items (small level), parent/child items and relationships (smaller), mini conversions (even smaller or micro)... in the universe analogy we have solar systems, suns (controller world), planets (transactional worlds), locations, groups, individuals, data, etc. Almost everything goes from big to medium to small levels, depending on how things are grouped and/or shown.

- Top level mappings - corps, locations, vendors, part categories, expense types, deposit types, etc.

- Enterprise solutions >> who is your buddy and how is everything setup (structure)? We had some brief talks about how to set this up. For now, we will just hard code things and then introduce variables a little bit later on down the road. Eventually, there may be database records and even one-to-many relationships with what corp type (world style or world type setting), who are the players (buddy list), and which way does the data flow (up, down, bi-directional, etc.). More planning is needed.

See attached for some drawings