Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 9/20/2018 12:28 pm
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 4041
Template/Type: Brandon Time
Title/Caption: Adilas Time
Start Date/Time: 10/17/2018 9:00 am
End Date/Time: 10/17/2018 12:00 pm
Main Status: Active

click to enlarge - photo by: Brandon Moore - Working with Steve and Alan on unit based selling and count or weight based selling. We also talked about recording some standalone values to help with reporting and equivalence values.
 
 


Uploaded Media/Content & Other Files (1)
Media Name   File Type Date Description
talking_about_counts_and_equivalence_values.jpg   Image/JPEG 10/17/2018 Full size screen capture image of the unit based selling and the count based selling options.


Notes:

Small discussion on weight based selling of eaches. The topic seems to have two parts... you have normal quantity and you have a possible weight or count that might be applicable. This whole section is a precursor to full on mini conversions and was somewhat of a simple (1 layer deep) mini conversion based on sub weights or sub counts. We are seeing that each item has a main unit quantity (recorded on the invoice and/or PO - what actually went out the door). It may also have a count or weight  (sub information) for the main unit quantity. Lastly, we talked about another section to hold a single weight or standalone value to help with reporting and equivalency stuff. As a side note, the naming may need to be dynamic because different things (categories) play in different ways. You might have a serving size, dosage, or count per package and then maybe even different percentages on different levels, etc.

Some of those could be sub attributes within sub inventory, but we were looking to give a few more fields on the parent item to record basic, non-changing information. Steve was talking about a converted piece... Basically, it shows x, but it really mean y, and needs to report or extend to z for certain reports. It is starting to get pretty complicated. We started to talk about a secondary multiplier and how that might play in. See the scans and media/content for our session playing with numbers and ideas. We came away, saying, that we need an out the door unit quantity (physical units or number of per's - single packages or units), we need a count per or a weight per (secondary multiplier), we also need a standalone value per (just for reporting in certain scenarios - equivalence values). Each of those three main pieces would also need a unit of measure to go alone with it. That way you could say, I sold such and such in eaches, they all have a count or weight of such and such, and that equates to this or that. It gets into tracking the different layering and depths of the information (the z axis - space, layering, and depth).