Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 2/27/2017 11:43 am
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 2370
Template/Type: Brandon Time
Title/Caption: Adilas Time
Start Date/Time: 3/7/2017 9:00 am
End Date/Time: 3/7/2017 12:00 pm
Main Status: Active

Sorry, no photos available for this element of time.


Notes:
On a GoToMeeting with Steve and Eric. We helped Steve with some questions and then talked with Eric. While talking with Eric, they were talking about coding things for a drive-through pharmacy type model with digital signatures, photo captures, video captures, remote file upload stuff, etc. All kinds of digital paperwork stuff.

Calvin joined the call just after 10 am. We chatted and talked about mini conversions up until about 12 pm. Calvin and I divided and started doing some light research. I was looking in the adilas university site and inside of adilas for info on conversions. Calvin was doing some looking inside of the adilas shop site. Here are some of our findings:

7/16/09 - adilas university - Time Id: 2377 - Photos – Lots of loose pages and playing with ideas.

- Idea - catch the lowest possible increment (or value of 1)
- Everything needs a base of 1
- Cost per 1
- Weight/measurement per 1
- Weight/measurement per type
- Idea - there may be a difference between quantity and weight. We need to account for both.
- Idea - part of this element of time was around the time when we added multi decimal point accuracy (code name – adilas dewy decimal).
- Question - How are items sold? Quantity, Weight, Length, Package, Volume, or some other measurement?

7/22/09 - adilas university - Time Id: 1435
- Idea - New corp-wide setting for allowing part number (item) conversions. This was created but has sat dormant for years.

7/28/09 - adilas university - Time Id: 2380
- Photos - Multiple pages that show questions and answers for a single company and their flow. This was from Trinity Fasteners and how they work (buying and selling nuts and bolts). Good flow and ideas. Real life scenarios, needs, and requirements.

12/11/09 - adilas university - Time Id: 1590
- Photos - Notebook entries with some ideas and bullet points. Basically, there will be some dust (+ and -) - play in a ball park level and allow for rounding errors.

2/1/14 - adilas.biz - Time Id: 838
- Photo - whiteboard session with some ideas on it
- Idea - Qty in, u of m in, qty out, u of m out, multiplier qty
- Idea - add a conversion qty and a conversion u of m
- Idea - add a flag that says use or don’t use the conversion
- Idea - reverse recipes (preset things, hold all of the details, distribute pieces and products as needed)

/// notes from Calvin.
Time Id's from the shop...
1221
995
1480
1449
1633
1645
1054
1839
2062 * good stuff
2130
2193
2157 * (good stuff - grid drawing)
2167 * (good stuff - screen shot of conversion/pring: steves_mini_convesion_page_for_qr_codes.jpg)
2258 * (good stuff - more notes)
2260 * (good stuff - spreadsheet)
2403
2405

/// notes from Steve
- We have pricing needs, conversion needs, etc. Kitting, recipe/builds, batches, lots, packages, sub inventory, packaging and repackaging (unlimited number of times - make a box, put x number of boxes in a bigger box, take y number of bigger boxes and put into a case or palette).
- Every time you break down a child, we need to be loose-y-goosy. The parent and child needs to be the same unit of measure. Then below that, we can have all kinds of different price to quantity relationships. (quantity discounts, pricing matrix, cost of goods sold, etc.)
- We need a dynamic tool that could hold user-defined data.
- Steve sees the interface as part of the solution - (see his prebuild template for a starting point)
- The interface will have parent info, vendor info, child quantity and/or weight, child id, package tag, etc.
- Be able to name it (what to call the unit of measurement - example: cones, shake, trim, eighth, quarters, etc.), setup the underlying relationship to the parent and child unit of measure, set a price per, etc.
- We also need to track all items being tracked in carts, sold, made, created, available, reserved, etc.
- Be able to create a mini conversion template and/or conversion matrix. These would be standalone pieces that could be setup like a template and then used over and over again. Think one-to-many.
- Maybe have the parent item be tied to a certain conversion matrix and/or template. We may also see that the templates might need to be tied at the part category level (this may help cascade things out better and more efficiently).
- We need a tool that allows for individual business to decide what is what... and how they want to convert things, break things down, sell things, and display things. Very dynamic.
- We allow them to build as many main conversion templates as needed. They could copy, duplicate, remove, reuse, etc.

/// other notes...
- We talked about of the history behind a few of the bigger pieces such as the dewy decimal system, flex grid tie-ins, sub inventory, sub attributes, and current mini conversions. They are all somewhat inter-related and we have built from one thing to the next.

- We talked about building in a one-to-many traditional database model and go vertical vs. horizontal. This will help things be smaller and more agile vs. heavier and lots of unused fields and extra columns. Think just in time as a sub or mini conversion of the sub inventory packages, batches, or lots.

- We also talked about what is needed to show the mini conversions on a quote and/or invoice line item. We need at least three fields (maybe more). They would be the visual unit of measure (conversion uofm), visual quantity and/or weight (conversion number of some kind), and a flag to use or not use the visual (mini conversion) fields.

- Dealing with the show/hide options on the quote and invoice line items, what about setting the normal fields like we already do (main line quantity and main unit of measure), then we could either duplicate that data on the show or special visual fields or we could set it to some kind of blank or default value. The goal here is to decide if we want to use one set of fields to do the backend accounting and then have another set of fields that show what was really going on. If we made it consistent, we could run certain reports off of certain fields and other reports off of other fields. That way we would have to add any special logic, it would be real values vs. show values. That might be nice. Just an idea.

- When Steve and Calvin talked, they made it sound very simple and straight forward. When Brandon talked, it got technical and went into other requirements. As a side note, we may need a little bit of both simple and technical.