Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 2/2/2019 4:20 pm
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 4356
Template/Type: Brandon Time
Title/Caption: Meeting with Molly about ICC
Start Date/Time: 2/4/2019 2:00 pm
End Date/Time: 2/4/2019 3:00 pm
Main Status: Active

Sorry, no photos available for this element of time.


Notes:

Molly and I met for about an hour to talk about options and possibilities for ICC's or internal cost corrections. She started out saying that she has worked with a number of clients and sometimes it takes up to 20-30 hours to do some clean-up (depending on the size of the client and how long its been since the last cleaning). As a side note, we see bigger problems with normal parent inventory due to the last known cost that is held at the parent item level.

Sub inventory is much tighter and works pretty good. The only known problem with sub inventory deals with some rounding error problems over time. Basically, by the time you split up certain known costs over and over again, clear down to 5 levels of decimal accuracy, there becomes a small rounding error for certain items. It is just math but it still ends up looking like a problem.

The catch 22 is on what it takes to look things up and fix them. On parent inventory, Molly goes and looks at the usage per item. She can then fix things fairly quick. On subs, there are much less problems (originally), but sub inventory is even harder to clean-up due to closed packages, parent item settings and status, and some of the math.

The main goal is to get the cost of goods perfect and/or help the user get to a perfect level. Ideally we would like to build out a new core tool called ICC's or internal cost corrections.

Molly would really like it to follow a FIFO (first in first out) type model for costing. This would require us to be able to go all the way back in time and see what came in and at what cost. It would then try to reconcile itself based on how many have been sold and at what value. For example: if we start out with a 100 at $0.45 per, ideally, we would sell the first 100 items for that $0.45 cost. It gets complicated as things change over time, we don't fully sell out of a specific quantity based on cost, or a person buys multiple things from different cost levels. We have also had problems with users just going in and randomly changing item costs.

- At some point, we need to make an adjustment and/or update to the COGS (cost of goods sold).

- Molly was talking quite a bit about the in/out extended cost. We had some discussion based on FIFO vs last known cost.

- Molly and I were trying to figure out basic rules - only grab items that have an in/out extended cost that is not zero and a quantity that is not zero (don't worry about items that match perfectly or have zeros). If an item has a quantity (+ or -) - we need to look at it. We may need to work backwards to get our numbers.

- We also had some discussion about are we trying to get super detailed (matching PO's with invoices with costs) or be more general and just get the grand totals correct per item? Good discussion. We left off with Molly going to reach out to Eric to see if he has more time to meet and work on a tool/report to help fix things. I am supposed to think about options and come up with some ideas. Lots of moving pieces.