Tracking Dimensional Inventory

inventory

(Chris Conn) #41

Agreed - they will never implement the processes needed to keep this “useful” data current. All that fancy tracking will be for not when the data is out of whack


(Calvin Krusen) #42

Does the material come pre sorted by LENGTH an Qty? (10) 1.1", (1)1.5" etc…
Or is purchased as one bulk qty, like 12.5"

Or does it come in in significantly longer lengths and the lengths you need are the residuals only after some is used?


(al maragni (USA - NY/NJ)) #43

using the Multiple UOMs you get the ability to support QUANTITY and COST (because the system maintain the cost conversions for you) because the UOM table knows that 3 ft are 1 yard or 144 inches is 12 ft … (3 * Cost/Ft) = 1 * cost/yd)
but the system is slow as molasses - but MRP and planning would know the values/amount

using the Multiple BINS you do NOT get the ability to support QUANTITY and COST - because all parts are the same regardless of bins/ There is not COST per BIN and (1ea in a 2FT bin * unit cost) is not the same as (1ea in 1Inch Bin * unit Cost)
although i would expect the system is faster to process, But inventory value will never be right …and mrp. never mind

have you considered using LOT control with Smallest Unit of measure
Put everything in smallest unit … like an INCH … and 12 ft would be 144 “EACHES” and 1.5 ft woulb be 18 “EACHES”
the COST would be by INCH

and use lot control in EITHER FASHION BELOW

(a)
where the LOT charactertis SHOWS the CONTINUOUS LENGTH" for anything in FT
where a BPM can be used to calculated 144 to 12 FT

(b) something similar to the multi[ple bins - have the LOT ID indicate
the “CONTINUOUS LENGTH” for anything

LOT1.5would be where ANTYTHING of 1.5 Ft length would be placed
LOT12 would be where ANYTHING of 12 ft length would be placed

in EiTEHR case
MRP would know how much you have
Costing would know its value

IN either option you’ll most liklely want to customize some way to SHOW the CONTINUOUS LEGNTH value for the UOM

just a thought


(Chris Conn) #44

I asked about MRP as well, apprently it’s not used - whew!


(Brandon Anderson) #45

I’m pretty sure that they would still inventory in length, not each.

So the 4’ bin could have 4ft, 8ft, 12ft, or any multiple of 4 in it.

That would get you quantity and cost still.


(Calvin Krusen) #46

To help convince them a coarser size grouping is better, ask them their confidence to keep the group’ separate and to ONLY pull from the loptimal bin.


(Simon Hall) #47

Anything to add here Mr @timshuwy :slight_smile: I’m thinking your contribution might be highly valuable to all.


(Jose C Gomez) #48

8 posts were split to a new topic: Random Discobot Interjection


(Stephen Edginton) #49

I think you will find Lots is the simplest way to model this. You can create a parent lot for the material as it comes in, then child lots linked to that (by convention) for the cuts and allocations made. So a Job to cut bar stock would produce two separate lots. A Simple customization could automate the cut operation handling as a kind of Kanban type operation driven off the demands needed on the job materials. The Lots then give you the ability to track inventory to this level - purchase suggestions needs to take into account usable lots so you may have some rules as to when you change the part number based on usable size / planning needed. Hope that helps


(Calvin Krusen) #50

If a single P/N is to be used, I assume the part would only ever be a component in a BOM.
And there’d not be Jobs to make “cut lengths”, but that the “less than a whole length” remaining leftovers would returned to stock, but to under a new Lot num.

For example,

  • P/N ‘ABC-123’ is purchased in exactly 10 FT lengths, UOM is FT
  • Whole 10 FT pieces are Received under Lot ‘WHOLE’.
  • A job to make 10 Assy’s, calls for 3 FT of ABC-123 each
  • 40 FT of ABC-123 are issued from Lot WHOLE to the job
  • After cutting (10) 3 FT pieces from the (4) 10 FT lengths, there are (3) 1FT and (1) 7 FT pieces left over
  • 3 FT is returned to stock but under Lot ‘1FT’, and 7 FT are returned to Lot ‘7FT’

I believe that the receiving process creates a lot. But can you arbitrarily return material into a lot that never existed before?

Can the Job Pick List specify the Lot to pull from? Or is the lot the job’s materials used, determined on the back end after they’re issued ?

The above example would be identical using bins instead of lots, with the exception that the Job Lick List could definitely specify the bin to pull from.


(al maragni (USA - NY/NJ)) #51

sure that’s good - least common unit or most common unit


(Calvin Krusen) #52

@Banderson & @amaragni - If separate costing was required, you could just set up a virtual warehouse for each length. Then use an individual cost per warehouse.

I’m sure that doing 11,000 individual physical inventories of 11,000 warehouses (virtual or not), with just one part in each of them would be loved by everyone. :wink:


(Andy Wilson) #53

we had a CSG mod for something similar, it was a child table on the lot table, the company was a stockholder, so had to have traceability for individual bars.

Each delivery was given its own lot number and then each bar was given a number under that, for example, Lot 4500, would have bars 4500/1, 4500/2 etc

The length of each bar was recorded. as well as any treatments that happened to it. It was a massively intrusive mod, but required, each bar was labelled and could be picked at any issuing, reserving or allocating screen.
When the bar had been cut, the length was updated and returned to stock.


(Evan Purdy) #54

@josecgomez I’m super curious what you ended up doing for this.


(Simon Hall) #55

We have a customisation that does that sort of does that created by CSG. We use it for docking packs of timber.

We use lot bin tracking and UOM tracking. We receive supplier pack numbers as lots that allows us to track the pack, at least until we split the pack into its individual pieces, then it gets transferred into our LOOSE bin and gets reassigned a lot number of LOOSE.

Still in the implementation phase at the moment.