There are several different challenges here.
Jewellery, has a similar problem because the same design and length might still have weight difference which are a significant cost difference. Typically either a separate item code or configuration or serial number is assigned to each piece of a part number.
Pipe manufacture also tends to sell in KM, make and serialise in pieces and charge by weight of a truckload!
Your challenge in some ways is more complex because the length of e.g. a saleable piece, and how it is made up of pieces is also changing, - it might take several different lengths of a fixed piece, or one single piece to make up the total.
Even more complex is that not all lengths can be combined. E.g for 2o m I can take 4 x 4, or 2 xx10 or 1 x 10 but I can’t take, 2+ 3 + 5+ 10
Presumably you can slit a roll across its width for a given length and you could also slit it along its length to get a different width. For metal strip there might also be a thickness or density variability.
Ax will hold inventory in its storage unit of measure e.g metre.
The problem is now that when you see an inventory of 2000 m (even with constant width and thickness), you don’t know if its 2000 pieces of 1 m, or 10 pieces of 200m or any other combination.
You could have different batch ids for different ranges of lengths e.g 0-1m 1 to 5m , 5-10 m etc but its then becomes a lot of extra transactions to move between batches, and you still have to physically id and enter which batch you used.
A similar approach is to have virtual locations e.g, you have a location called ‘rolls’, but its the same physical location. Create additional virtual locations for different size ranges. The storeman can thus see how his stock is held e.g. 50 m in the 1m location means 50 x 1m pieces, 200m in the 200m location means one piece of 200. It Still needs a lot of stock move transaction and relies on manual update and physical selection of the appropriate offcut.
You also have to consider batch and serialization when required. If issuing in one piece maybe a ‘piece’ needs to be the minimum unit because you can’t really batch control or serialise or label the metres within a piece.
You can however store items at a higher level of unit e.g. as ‘Roll’ let’s say 100m. There is nothing to stop you issuing a percentage of a roll e.g 0.01 of a roll. Not the most user friendly for the stores but it is feasible (and you could do a small customization to show the alternative UoM, in m.) You still have to physically id the individual roll lengths remaining.
If the rolls are serialised (and labelled with the serial number) and you issue from a specific serial number then it should work – in the sense that you will be able to see the breakdown of different partial rolls.
(It would be possible to write an algorithm I suppose to pick either the minimum number of rolls or to use up the smallest possible rolls first Alternatively there may be third party, non Ax slitting programmes you could use.)
However, even with a configurator, or algorithmIc coding, the physical identification, of which roll, is which length and in which location, still remains and requires serialization or ...?
Maybe the most pragmatic way to deal with this without use of a configurator or lots of coding, is to transfer full units e.g. whole ‘rolls’, to an issue location,.
Then do part issues from there- this means in principle that most of the stock can be assumed to be in its most usable form. For full rolls you can use catchweight or a dual UoM display.
A storeman will first needs to see what he can make from his offcut location and only then move in extra whole roll if need be.
Maybe have a few virtual locations in that offcut location, to represent ranges of length of roll offcuts e.g. 0.1, 0.25, 0.5, 0.75. 0.9.
Record the quantity issued from which virtual location.
Stock check and transfer between those virtual locations as needed once a day/week to get a better insight of what is useable e.g we’ve got 50 m , in pieces each under 0.1 of a roll , 200 m in pieces stored in the location that holds sizes in the range of 0.1 to 0.25 of a roll etc. again a mobile device would reduce the workload and error.
