all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Blue
|
|
||||||
|
||||||
|
|
|
Notes:
|
|
Just for fun.... Think about sub locations per system player groups.... Just showing 4 of the 12 main system player groups: Invoices: 1. Pending 2. Work in progress 3. Layaway 4. Shipping 5. Archived 6. Etc. Items: 1. Bin # 2. Pallet # 3. Bay # 4. Floor # 5. Area 6. Section 7. Room 8. Etc. Stock/Units: 1. Lot 2. Show room 3. Front line 4. Repair 5. Rental fleet 6. Etc. Employee/Users: 1. Department 2. Office # 3. Area 4. Team 5. Committee 6. Task Force 7. Probation 8. Etc. -Thoughts on sub locations.... What if we made a section under elements of time for sub locations. (Think of sub locations per main player group) We could allow each main system player group to have virtual sub locations. This is kind of new... Instead of a single set of sub locations, what if we could specify subs per group... For example, say subs for a stock/unit could be Montrose Colorado (main location), North Lot (sub location). The item still exists in Montrose but we also know a sub of the main. Where the new piece comes in is by main player group. Let's say we are doing some parts (general inventory) movement, we may not want North Lot as a sub location. What if we only wanted Basement or Storage? Basically allow sub locations per main system player group. A PO might want sub locations of pending, filed, to be paid, shredded, etc. (Different subs for invoice, PO's, products, employees, etc.) -I'm seeing an increased need to cross tie a single data object (invoice #777, PO #251, E/R #555, stock/unit #101) to subs of the elements of time features. This could allow for sub phases, movement, sub tracking, sub locations, sub assignments, etc. We could add time elements to each of the main system player groups. The other part of this new need is where the action takes place. Traditionally, all subs of elements of time happen from the main element of time. What if we stored the data under the main element of time but showed or allowed access to the subs from the host or parent data object. For example: Let's say that invoice #37 (host or parent data object) wanted to track how long it took to build something... We could use sub dates and times (sub of time) but have it show up and be editable from invoice #37. The person could be interacting with time without ever leaving the invoice environment. That could be really cool and has a lot of potential. Here is what it might look like: (Sketch – please see scan in photo gallery – Main system player groups who need to access subs of time... There are actually 12 main player groups – just added a few of them for this drawing: Customers, invoices, quotes, parts, stock/units, vendor, PO's, expenses... Elements of time as a wrapper or pass through to the subs or functions of time – some of the subs or functions of time: sub dates & times, sub locations, sub comments, sub sign-offs, sub payroll, sub reminders, sub GPS & RFID tracking, sub assignments... Basically, use the main elements of time as a wrapper or pass through to access any of the subs or functions of time. Gain access to anything using time as a wrapper. -Wow, I didn't know time and time functionality (subs of time) were so important. Basically, if we used time as the wrapper or pass through media, medium, vehicle, or channel... We could add additional functionality to all existing player groups and individual players. That could be so powerful! I'm excited! -Instead of making time a key player, in this instance or event, it will be almost transparent but will allow main data objects and groups to access additional functionality. -What if... we could create templates for each main player group (all 12). We could then allow access to subs of time based on settings per template. It gets back to “Types” and “Functions”. Both types and functions of time were major topics while we were developing the system section called elements of time. I'm seeing a potential to take those same concepts to all main player groups and even let main player groups connect to sub functions of functionality of time or other player groups. This could get deep, but basically defining different types and functions for the different players and player groups. -Once we define the subs or functions, we could allow cross tying or cross usage as needed. Basically, make everything part of a bigger interactive system or data sphere. Bring it all together into one bigger system. -Things would still have a home or default usage, but we could open up cross overs and functionality to meet the demands of a flexible and complete world. True world building. Taking custom to a new level. -A couple days back I was writing about real in-line extensions. Well today I was explaining the concepts to the adilas interns. I used a couple of small drawings to show them what we were trying to do and come up with. Here are some rough sketches of how I was trying to explain things... (Please see sketches on scans in photo galleries): new in-line extensions, pretend an existing database table, core system with possible extensions, flow chart or relationship model with some extensions, throw things in the bucket, predefined levels, bucket or main data object with subs... -Imagine a one-to-many relationship (main boxes and lines) -Then imagine the flexibility if you could virtually extend and control other needs and wants on almost any table or relationship. Look at the dotted lines. Think options and custom business or data solution. -Imagine a bucket with certain predefined sections or sub containers (how the bucket is organized). Then imagine extending or adding custom containers as needed. -Small fix is needed on creating an internal-repair ticket from a URL web link. If no prior location is selected, it drops the URL.stock value and the user has to re-enter it. Help them out by keeping the known stock/unit value going forward. |