Skip to main content
Solved

Inventory Pieces/Remnants - Any ideas on best way to deal with this?

  • 3 February 2022
  • 14 replies
  • 673 views

We are in the metals industry, and one of the somewhat unique aspects of our business from an ERP perspective is that sometimes we will cut pieces of material that we sell into smaller pieces, per our customer’s request. So as a simple example, let’s say you have a 20ft x 20 ft piece of aluminum plate, and the customer asks for a piece that is 16ft x 18ft. We will cut that plate to size, and then have a remainder (what we call a remnant or a piece) that is left over. Sometimes we will directly scrap this remainder (not keep it around), and other times we will keep it on hand and sell it to another customer, or use it to cut another piece for a customer who may require a size smaller than that previously cut piece. We need to maintain heat/lot tracking of these pieces from the parent item.

Does anyone have any clever ideas about the best way to program this in Acumatica? You could obviously create a new item every time you create one of these pieces, that is the exact dimensions of the piece. And you could have some sort of reference system to link back to the parent item.

Since these are all one-offs, should they be stock or non-stock items in Acumatica? We will still need to track them in the warehouse.

I’m mostly interested in how to model this as a data problem in Acumatica (versus UI concerns), but any creative ideas on how to handle it up and down the stack would be appreciated.

Keep in mind that while MRP is probably an answer to this problem, it may be overkill. We are literally just taking one thing, and making it two (or three or four), with all the same characteristics as the parent (except its new size/shape).

Thanks,

 

Jonathan

14 replies

T
Rank

This is a pretty classic problem in all MFG ERP’s and I don’t know if I’ve ever seen anyone come up with a great solution, that isn’t super transaction intense.    Some blend of human material review would seem to be required, along side a hard allocation of a remnant to a production order.   I’m following this discussion hoping more will chime in! 

L
Rank
Userlevel 6
Badge +6

Is your 20x20 plate it’s own stock item number?

Could you issue .75 of it to your production order thereby leaving 25% in stock to be used later?

If a member helped you, please *Like* their post. If a member provided an answer to your question, please mark it as *Best Answer*.
R
Rank
Userlevel 6
Badge +5

@ltussing03 Sure, we could do something like that. However, I think we want to be able to separate full stock items from remnant inventory. For example, if you have 4x .25 of a stock item, that is not equivalent to 1 of that same item. So there are some challenges with how we track the inventory in the system, and how it exists out in the warehouse.

We don’t want to create a new stock item for every random remnant. I am leaning towards creating a “catchall” stock item that will aggregate remnants from different stock items that have the same properties except for their size (i.e. a 12ft rod and a 6ft rod are exactly the same except for their length...once cut pieces from both go into a single stock item where one of the inputs is the length of the item. This way there is a single item that aggregates these remants, but you can still keep track of unique properties, like the custom length of the remaining piece).

I’m still thinking this through. But that’s how I’m leaning.

Chris Hackett
Rank
Userlevel 7
Badge

Hi @rosenjon were you able to resolve this issue? Thank you!

Chris ~ Let us know how we're doing: https://forms.office.com/r/xmJUdZ1QE5 - A member helped you, please *Like* their post. A member provided an answer to your question, please mark it as *Best Answer*.
Doug Johnson
Rank
Userlevel 7
Badge +3

You may have already solved your problem, but an option that might work is to use lot/serial attributes to keep track of remnant sizes. Using attributes allows remnants to have the same SKU number (with the same cost and price) and you can sort through attributes on the sales order screen so your sales team can sell the proper item.

On GitHub (https://github.com/Acumatica/Acumatica-LotSerialNbrAttribute) we have an older version of a customization which would give you an idea of how it could work. Adding lot/serial attributes to the core product is an idea that we are actively prioritizing. 

R
Rank
Userlevel 6
Badge +5

Hi @Doug Johnson -

There are obviously a lot of different ways to think about lot tracking in an ERP system, depending on the use case. In my opinion, the most robust version of lot tracking is full reverse traceability, so that you can track a specific lot of material from receipt through to shipment. This is a common requirement in the food industry, where in a recall situation you have to know every customer that received a certain lot of product from a specific manufacturer and when those shipments went out.

In Acumatica currently, lot identifiers are treated as “tags” or attributes against the product identifier. This is quite cumbersome to deal with, since the user has to enter this information on receipt of the material, and then has to tell the system which lots are being picked when the order is shipped as well. It also makes it more likely that the user can choose the wrong lot when doing picking, because the system is not actually aware of the location of any given lot in the warehouse (only that it exists and in a specific quantity). These are all the issues with the current attribute driven lot tracking system in Acumatica.

Now that Acumatica has separate tables for doing Line Splitting (this used to be attribute driven as well), it would be possible to do lot and serial tracking against the individual receipts of product in the system, rather than using an attribute driven system. I think this would form the basis for doing reverse traceability and other more robust forms of lot and serial tracing in the future. So for example if you buy 100 units of a product, on receipt the system would automagically split out your receipts into different lots. in the POReceiptLineSplit table, which forms the basis for tracking that material receipt through the warehouse and to shipping. It would also allow you to uniquely identify the receipt of that material with barcodes as well, so that you can move lot and serial tracked items with a single scan.

I’ve gotten into this a bit with your developers in the past...here is some additional context: New Line Splitting methods - Can we have some examples and further documentation please? | Community (acumatica.com)

 

Thanks,

 

Jonathan

 

R
Rank
Userlevel 6
Badge +5

@Doug Johnson The same issues I have with the attribute driven lot/serial tracking would be even worse if using this for remnant tracking. That would potentially make the size of the remnant a multiselector field that the user could mis-click, which would be even worse than the current situation with lot identifiers. Basically, this functionality really needs to be rethought if it is going to be used in industries that require any kind of robust lot or serial tracking.

K
Rank
Userlevel 5
Badge

@ltussing03 Sure, we could do something like that. However, I think we want to be able to separate full stock items from remnant inventory. For example, if you have 4x .25 of a stock item, that is not equivalent to 1 of that same item. So there are some challenges with how we track the inventory in the system, and how it exists out in the warehouse.

 

We are also working with steel pieces, and as mentioned above, keeping a good measure solely through ERP is difficult - some variance in quantities will be unavoidable.

What we are currently testing is: 

  1. Steel items should have an aggregating factor as the stock item code, so that usage can be the other main factor (eg. steel bars based on diameter, then usage = length / steel plates based on thickness, then usage = area).
  2. Transfer full steel bars from storage to production floor - have some supervisor control whereby full bars are only transferred in if the floor remnants do not have bars of sufficient length
  3. Issue materials to the production order from the production floor 
  4. Any balance on the floor location are your remnants to be used for future production / scrap.

While under this method you still can’t keep track of exact remnant sizes (it will be aggregated based on SI code and original lot/serial), it does at least ensure that full stored items are kept separate from the remnants in their storage location and that usage can continue to be pulled into production based on the usage factor. 

Depending on how granular you specify your locations, you could have ad-hoc physical counts whenever remnant quantities are low enough to be feasibly counted to keep quantity variances from building up at the location.  

We also floated ideas of going more granular by using on-the-fly locations (ie. floor supervisors segregate the remnant quantities at the end of the day to locations with their exact dimensions as descriptors, subsequent issue of remnants can be done directly from those locations), but at a certain point you need to wonder if that much traceability is worth the tradeoff in manpower.

R
Rank
Userlevel 6
Badge +5

@kokjietan There are a lot of different ways to do it, depending on how you want to think about the stock items. We tend to think of the stock items as your standard distribution “widget” with a part number that you stock and sell. So we don’t really want to start tracking those by area or by length, since that just makes things confusing (a 40 IN x 40 IN metal plate has area 160 IN, but nobody really thinks about it that way in real life).

If you break down why this problem is hard, there are really two main strains of ERP Manufacturing software, discrete and batch/process manufacturing. In discrete, you take smaller items and assemble them into a big item (this is why MRP systems are super popular). In batch/process, you take ingredients and make something (think food or chemicals).

But what about when you take a stock item and break it down into smaller pieces, all of which are essentially one-offs? Your customer sends you a CAD drawing to cut out from a single stock item with a laser cutter, and what is left over is the skeleton of that cutting process. How do you structure that into a logical “item” in a traditional ERP?

I think the answer is you don’t. The truth is that ERP needs the concept of “ephemeral” items. These are items that may only ever exist once (as the result of some manufacturing process), and then will go away forever. We have the software tools to do this….it probably looks like a JSON item inside of a sql table (as can be done in SQL Server now). When that item is done, it is marked as “deleted” never to be seen again, except perhaps to be looked at in the future for reporting purposes. It only takes up a single row in the database, and it does not require changing the database structure whatsoever. Its schema can be defined on the fly.

The problem is no one has really built this that I know of. It could actually be built pretty easily in a system like Acumatica, but it would require a rethink of some of the software tools in the stack (the “DAC” would have to bind an object from a single record and not a sql table).

S
Rank

@rosenjon did you ever solve this? if yes how did you go about it in the end? and is your customer happy?

R
Rank
Userlevel 6
Badge +5

HI @swati74 -

We are still in the process of selecting various pieces of our software stack, so nothing is locked in yet. However, I will give you some pointers.

If we take cutting metal sheet/plate as an example, you start with your standard stock sku of a 1/4” thick 60INx60IN Aluminum plate. You then have a manufacturing process that cuts pieces from this plate and sells them to the customer.

In the metal industry, the cutting does not usually affect the thickness of the metal, only the width and length dimensions. So once you consume the input sku, you could create a rollup sku based on the thickness of the cut metal plate (i.e. 1/4” in our example). So your SKU could be P25INALREM (which is a rollup sku for all metal of this thickness/alloy that remains from a cutting process). Then, whatever is left over from your cutting process, you assign it that sku and a unique serial number, and it’s UOM in the system is by weight (which is a uniform measurement for all pieces regardless of their dimension). Then, you create custom fields that are relationally tied to the serial number, that track the individual dimensions of the sku (could be just WxL, but could also get fancier like GCode, etc).

 

This describes a relatively complete rem tracking system I think. There is some custom code involved most likely, but for the most part it leverages out of the box system components.

 

Hope that helps a bit.

 

Thanks,

 

Jonathan

R
Rank
Userlevel 6
Badge +5

There’s one more piece I should mention here. Because the weight will be variable, you will need to track the weight of each individual piece. This is often referred to as “catch weight” in the ERP industry. The same way you create the relationship between the serial tracked items and its specific dimensions, you could track its specific weight there as well. Or you could invest in an out of the box solution like this one: SiPD-Catch-Weight-Management-Module-for-Acumatica.pdf (servicessipd.com)

The closest analogy to the metal piece cutting problem is found in food industry use cases, where the lot tracking and subdivisions of material are quite similar.

S
Rank

Hi @rosenjon, our situation is slightly different in that the costing is not by weight but by lengths of metal bar and the left over pieces are put back to stock, to be used on future production orders not directly sold to customers.

But I get the gist of your solution.

Many thanks for your help

R
Rank
Userlevel 6
Badge +5

@swati74 In a bar cutting scenario, it’s actually a bit easier than with the complex cutting on sheet, because bar can only really be cut by length (not in other dimensions). So you could consolidate to a sku that is tracked by length, as long as the diameter/alloy of bar is the same. Since it can only be cut by length, the weight of the bar will be 1:1 with its length (if a bar weights 30lbs/foot...then if you know the length you know the weight, and vice versa).

We are talking about a scenario where the remnant are put back to stock...that is the purpose of the rollup sku. But presumably parts of the order are sold to the customer also...

 

 

Reply


Terms & ConditionsCookie settings