UOM Best Practice for Sheets

Kinetic ERP
,
1

Working in Pilot now and want to ensure we are set up for success with our UoMs.

In our current ERP system (packs for example) we specify the class as Count and for the UoMs will have Pack10, Pack100, Pack1000, etc. with the conversions set as Pack10=10 each, etc…

We do a similar thing for Area, instead of a generic sheet we specify in UoMs: 4x8SHEET, 5X10SHEET, etc. with base UoM being square inches.

I was told by our consultant that this is not best practice, and instead we should do a generic Pack or Sheet that’s part specific and in the UOM conversions on the part and supplier specify how many each you have for sales and purchasing. Other folks chimed in and agreed this is best practice. To me, this seems like extra work and leaves room for human error. Other than having less UoM’s to choose from and set up time, I cannot see the benefit to manually doing conversions for each part. Plus, our sales orders/purchase orders/quotes will only display “Pack” instead of “Pack100” which I think opens us up to many potential issues. Can someone please explain this to me so I can set up our UoMs the best way? I’ve read many Epicor articles and I cannot get it to make sense.

2

I tend to agree with your approach, if the number of UOMs is foreseeably manageable. If you have a part that can be bought as a 5x10 sheet and as a 4x8 sheet, then you need two separate UOMs anyways, since a single UOM of SHEET can have only one multiplier per part. Same issue with PACK: if I can buy a part in a pack of 10 or a pack of 100 then then a single UOM of PACK doesn’t work. You can finagle some with Supplier Price List UOM conversion overrides, but I agree that this level of detail just increases the chance of error.

We use part-specific UOM multipliers for a UOM like ROLL, where the suppliers will only have one ROLL size, but for one part the supplier’s ROLL size is 2000 labels, but another part comes from a supplier where a ROLL is 1500 labels per roll.

3

Thank you for your input!

4

One scenario where your approach may reach it’s limit is the need to manage remnant/offcut inventory (I don’t how to properly say that in english, sorry).

Let’s say you’ve got a couple of 5ftx10ft sheets in inventory. You drop one on the laser bed and, at the end of the operation, a small 48in x 48in is left. You want to return that remant/offcut into inventory.

In this scenario, it will obviously become a mess if you try to create a UOM for each and evey remant/offcut you return into inventory.

Another option would be to track remant/offcut inventory as square inch, but you will lose the ability to track each remnant/offcut sizes in stock ; you’ll only have a “global” square inch inventory for all the remnant/offcut.

I’ve seen shops use lots to track remnant/offcut inventory, may not be applicable if you actually use track lots for it’s intended purpose.

One last option if you really want to track remant/offcut is the AUOM (Advanced unit of measure) module, which is essentially designed to handle these scenarios.There are obviously $$$ involved and more data/transaction complexity. We’ve implemented it and it works fairly well, but is not perfect and brings some bugs and headache with it

5

Thank you for your response! In your example, I would assume we would inventory in square inches. So if using a 5x10 ft sheet (7200 SI) and a part that’s 100 square inches w/ 10% scrap is being cut, only 110 SI would be adjusted out of inventory, leaving you with 7090 SI in stock. Where I see this being an issue is when we’ll have multiple “partial” sheets vs whole sheets when it comes to verifying inventory. I have not tried working with the Tracking Multiple UOMs tool, perhaps that could help capture that. But overall, I’d use the 5x10 UoM to purchase from the supplier, but once the sheet is in our possession, operate by using square inches. Might need a note to engineering on specific sheet size limitations. I appreciate being able to bounce around ideas!

6

That’s the thing. If you try to issue 100 square inch from a 5x10 sheet in inventory, you’ll have to issue 0.01388 sheet of 5X10 and you’ll end up with fraction of sheets in inventory.

If you do not want to get fraction of sheets in inventory, you’ll have to “convert” 5x10 sheets into square in before the transaction. There a menu to do just that :

image

Run some tests in Pilot.

7

Ya this is a tough one we’ve come across too. Inventory looks like we have a ton…but if it’s all small cutoffs you really don’t have what you need and you may not order more soon enough. What about having 1 Part in a UOM for “Full Sheets” and then salvaging the cutoffs into another Part that’s in Square Inches?

8

Thank you for the suggestion! I’ll run some tests with this.

9

I didn’t know about this feature. Thanks for sharing!

10

Has anyone used Epicors Advanced UOM Module?

11

Yes, there are several of us here that are using it. I think it would help our company a ton, but I have yet to try and use it.

12

We’re using it here.
In short, a lot of it seems fiddly.

We’re a sheet metal shop not-unlike OP describes. We buy sheets of material, usually 48x96 but not exclusively, and then shear it into subsheet “blanks” that might be 24x48, 12x24, or any other non-square increment of feet. We’re supposed to then return one of the Attribute Values we’ve got set up for that part.
InventoryUOM here is all based around SQFT. A given sold-part might have several programs set up for different blank sizes; blank size for a given job is chosen based on total job quantity amongst other things.

Here are the valid Attribute Values for our Length x Width attribute.

image
image1497×830 59.3 KB

Each of these has a conversion factor back to the Sqft that they’re inventoried as.

  • Job requires 24sqft in 2’x4’ blanks.
  • We issue 24sqft as 2 of the “master” sheet, shear it into the required blanks.
    The blanks themselves aren’t represented on the job, aside from some UD information on the Material showing Blank X, Y, and count.
  • We return the remaining material to inventory as 1 48x48" sheet.

In theory, this 48x48" sheet should now be available for anything requiring a blank of 48x24" or less.
However, visibility over the non-base-size offcuts is lacking; Our Shear dept usually knows what they’ve got on-hand, so we get by without wasting a huge amount of material, but Kinetic doesn’t help them much there.

Time Phase doesn’t show attribute or planning sets that don’t have on-hand inventory either, so if your Jobs demand the sub-attribute (blank), you won’t see the demand in Time Phase without manually searching for and selecting that attribute set. If your jobs demand the base blank size, the demand shows, but you need to track which attribute value set you want to actually use separately, either through UD or externally. Operators can issue the sub-blanks to the job to total the required sqft’age of the job, but again, Kinetic isn’t helping them do this as far as inventory visibility or checking. Nothing would stop them from issuing 4 of a smaller blank rather than 1 of the larger blank aside from the downstream process complaining.

Actually getting our shear operators to return 1 48x24 blank instead of 0.25 48x96s is also a fight. Part of this is our fault, due to allowing decimal Each sheets in inventory. Unfortunately, changing that is a huge battle if you don’t just recreate every affected part number, because a lot of these things lock after their first transaction. In practice, we have a whole bunch of 48x96 sheets in inventory at various fractions of an Each.

At face value the whole module seems like it would solve a bunch of problems, but the implementation and backend are both… odd. Happy to answer questions, though some of them might be specific to how we implemented AUOM.

13

If it’s a high consumption material, offcuts are variable, and you normally have full sheets available in stock, this is almost always good enough.

Part specific UOM’s end up doing unintuitive things, like one 5X10SHEET for aluminum and a different 5X10SHEET for steel with a duplicated conversion to square inches. Trying to represent the periodic table with an AREA UOM seems a bit off target. What value does a part specific UOM add that a part record and its other metadata isn’t already more appropriately doing?

As for offcuts, check on current offcut volumes and turnover rates. If consumption is proactive about cycling offcuts they can easily move faster than Epicor can usefully keep up with. If some product(s) are generating lots of consistent offcuts, consider associating a yield part with its own inventory.

Randomized offcuts are inevitably annoying. Sheet material especially, often having a ‘grain’ direction that makes 5x10 and 10x5 incompatible things. Sometimes, conditionally. Same material if it gets painted. Unless it needs to be bent, well, maybe, depending. Unless it’s unpainted and next to another thing and grain directions need to visually match.

14

@hkeric.wci I know the PM and the developer have both implemented/created products for Epicor that we all know and love so I know they are capable and actively listening, but this is why I haven’t taken the plunge 100% yet… that and lets face it, I’m still trying to dig out of a backlog a mile long… Kudos to you @afjulie for doing it and using it to its max right now. I’d love to understand more about life before and after, or did you implement straight away with AUOM?

15

We implemented AUOM at go-live for steel plate. The idea was to engineer and issue in any LxW dimension, order in pcs of common full sheet dimensions, and cost by LB.

There are pros and cons with any approach with it but we like how we setup in many ways.

Biggest critisism is the lack of documentation. The examples in simple help files are poor, imo.

16

We implemented pretty much out of the gate, so I don’t have many stories about pre-AUOM.
I’ve only been in my current role (ERP Optimization Coordinator) for about 2 years now, and we’ve been live in Kinetic for about three. To my understanding, in Vantage we managed this by having a separate partNum for every blank size, which was as convoluted as it sounds.

Despite how much of a management hassle that was, we’ve considered going back to that, since we’ve gotten little to nothing visibility-wise out of trying to track sheets, and cleaning up errors related to it has been awful. There was a while back in 2024.2 where receiving against one size would create a duplicate of the size !with identical primary keys! but without valid planningset hashes, stopping Time Phase from even addressing it. As far as we could tell, the only resolution there was a Datafix since the dupe row couldn’t be deleted through Db-space C# and I wasn’t about to rawdog that through SQL. We haven’t seen this recur since 2025.2, however.

Sorry I don’t have more of a before/after though.

17

No need to apologize about anything, the fact you contributed this much about AUOM to the forum is so great. Also, congrats on the successful tenure, 2 years strong!

18

I’m working with a business that implemented AUOM on Go-Live.

Most of their products are made from sheet metal of all kind (steel, aluminum, stainless, etc), cut with lasers with bending and welding. So a big part of the process is nesting the required parts on the laser and managing full sheet and offcut inventory.

On the method of manufacture, you must specify the AUOM “attribute” for materials. It means that you must tell the system from which sheet dimension the part must be cut from :

image
image1003×588 70.3 KB

This is how MRP can plan ahead the material requirements (time phased, PO suggestions, etc). If this part is required on a job, 70 square inch of 60x120 sheet will be required. Add all the job mtl requirement for 60x120 sheets and you can see how MRP comes up with suggestions and how time phased handles it.

That’s a problem. The requirement says “you must cut this part from a 60x120 full sheet”, but in reality it can be cut on any other sheet (48x96, 60x144, 48x48 offcut in stock, etc), but the system does not handle those “change attribute suggestion”. For example, if this job material required 70 square inch from a 60x120 sheet and you don’t have any in stock, you’ll get a buy suggestion for a 60x120 sheet, even if you have 100s of 48x96 sheets in stock.

Here’s an example :

image
image1291×671 60.4 KB

image
image934×866 74.8 KB

Obviously, you need to make sure that the part can actually be cut from another sheet dimension before ignoring the suggestion. The process would be to open Job Entry and go manually change the Job Material AUOM attribute to select another sheet dimension, which is very heavy for users. We had to build a dashboard to present the “consolidated” view of time phased, which presents all the requirement and inventory in evey AUOM attributes for parts.

Now, about nesting. Our nesting software fetches the Job Materials to be cut from epicor, with the required partnum and op start date. The user selects the Job Materials to be nested, checks the inventory to select a plate, and build the nest accordingly. Our VAR is specialized in sheet metal, so they build a batching software fully integrated with Epicor. This batching software reflects the nesting, so it builds a batch made of all the job materials selected, specifies which sheet (full or offcut) to select from inventory, and if a new offcut is to be return into inventory after the laser operation. The app handles issue materials and labor transactions, and create new AUOM attributes for those new offcuts if necessary.

This part works very well and make it worth it to use AUOM. The users can see the entire sheets (full and offcut) inventory in real time and select a specific sheet for the nest/batch. The material handlers then fetch the required sheet and returns the new offcuts to inventory after the laser is completed.

19

The dashboard to handle assigning attributes per-job is a really good idea. One of the nonstarters here for actually pointing our Jobs at the correct attribute is the sheer amount of time it represents on the job planning and scheduling side, if it’s not consistent to the method every time.

Does your company use global scheduling in any capacity? If so, do you need every job to have an attribute specified before running global scheduling against it? I’m curious about the order of operations of MRP creating the job, your users setting the attributes, and whatever scheduling process you’re using.

20

Nice! Before AUOM I made a Cut Plan tab on Engineering Workbench and had it trickle to Jobs, Quotes etc.. It worked with Get Details and then showed up on the Job Traveler.

image
image996×789 18.6 KB

In Job Entry it worked as a sub-item in the tree.