Dynamic Attribute Class Questions

Kinetic ERP
1

We’re playing with dynamic attribute classes and have a few questions.

  1. What are the differences between the 4 inventory calculation types (Basic, Calculated Expression, Quantity and UOM, UOM) for dynamic attribute classes? I think I have figured out the differences in how the system performs the UOM conversions, but I am struggling to find a use case for more than the Calculated Expression example.
  2. When you assign a Dynamic Attributes Class to a part record, there is a check box to turn on inventory tracking by attributes. What would be the use for assigning a Dynamic Attributes Class to a part record but not turning on inventory tracking?
  3. What is the purpose of the Dual UOM Class? I can’t find much documentation on it and it appears to be very similar to just using an Other type UOM class.
1 Like
2
    • Basic - this would be where no calculation is needed. Let’s say you have an attribute for the thickness of sheet metal, you would set this as Basic because you just want someone to select the attribute.
  • Calculated Expression - this would only apply to attributes you want calculated like metal weight.
  • Quantity & UOM - this would be if you wanted to use the UOM conversion already defined in the base UOM setup. So, you stock something in boxes and eaches, instead of having to write an expression, you set up the UOM conversion and use that.
  • UOM - This would be for multiple UOMs on a part that you want a drop down for. You have bar stock and recieve it in feet, inches, mm, cm, km, etc. You want the receiver to select the correct UOM they are receiving and putting into stock.

  1. Your jobs may require some liquid as a material and is issued in tablespoons. You buy the liquid in gallons. You don’t want to store the liquid in gallons because you don’t want to see that you have .02486 gallons in stock.

  2. I have not found a use case for it either.

3
  1. I still don’t think I’m understanding a use case for the “UOM” calculation type. I think I can come up with an example for the other three. For example, if I want to stock steel plates in “Square Feet” but stock in varying sizes, I could use the “Calculated Expression” type to multiply a length attribute by a width attribute. If sell different colors of the same mug, I could use the “Basic” type because the number of pieces of each color mug would directly correspond to the total number of mugs. Or if I receive in scrap metal that I then inventory by weight, I could use the “Quantity and UOM” type to specify that I received in “235 Pounds” or “8.63 short tons.” Granted, I think that calculation type only makes sense if you have another attribute that you’re tracking (so “sheet metal” vs “structural” in the current example). Otherwise, you could just set “Track Multiple UOMs” to true on the part record. However, I’m still struggling to come up with an example for “UOM”.
    2.As far as stocking and buying in separate UOMs, why wouldn’t you just set up UOM conversions and then set the purchasing UOM to gallons but the inventory UOM to tablespoons? And at any rate, doesn’t the that only work with the attributes class if you turn on “Track Inventory Attributes.” If you leave that turned off, what purpose does the Attribute Class serve?
4

I got this explanation of what a dual UOM class is:
The ‘Dual’ feature was introduced with the ’10.2.600’ release and complements the ‘Advanced Unit of Measure (AUOM)’ functionality. However, you can be use it without it as well, if required. I won’t go into the ‘AUOM’ concept because it is complex. Nevertheless, if you are interested in ‘AUOM’ I can point you to the knowledge resources we currently have or answer any questions you may have.

The main purpose of using ‘Dual UOM’ – without ‘AUOM’ – is to be able to make an update to existing parts that already hold some transactions. Let’s say there are already some part transactions in the system but you need to delete the ‘UOM Class’ the part holds. Since you cannot do this, you can link the existing part with the ‘Dual UOM Class’ and make the two classes communicate, if there are some updates you want but cannot make, because the part is being transacted. Below is some info on the ‘Dual UOM Class’ but you would want to use it most likely with ‘AUOM’. The reason for this is that you don’t need it and can do it with a standard ‘UOM Class’ (Other Class Type). You can define your conversions there and have one class assigned to your part instead of two.

1/ You set a ‘UOM Class’ record to ‘Dual’ in the ‘UOM Class Maintenance’ app by selecting the ‘Dual’ type. You need to have the ‘AMM’ license.

2/ The ‘Dual’ unit of measure class works in conjunction with the ‘Inventory’ base unit of measure class to convert defined units of measure.

IMPORTANT: The base unit of measure for your ‘Inventory’ class must match the base unit of measure you set up in the ‘Dual’ class. This will allow the two class records to link and cross convert with the units
of measure. However, the primary ‘Sales’ and ‘Purchase’ units of measure can be from either the ‘Standard’ or ‘Dual’ unit of measure classes.

For example, you create a new part record. Let’s call it ‘RL’. When you create a part, you select the ‘UOM Class’ called ‘Pound’. Let’s make it the weight-related class. You select the ‘UOM Class’ in the ‘Part’ app here. This is a standard ‘UOM’ class with the ‘Other’ class type.

3/ The selected ‘Pound’ UOM class includes ‘2’ UOMs – ‘SH’ (Sheet) and ‘LB’ (Pound). The ‘LB’ UOM is set to ‘Base UOM’. You do this in the ‘UOM Class Maintenance’ app.

4/ As a result of you selecting the ‘Pounds’ UOM Class in the ‘Part’ app when you were creating your part record, the ‘Inventory’ UOM defaults to ‘LB’. This is because you selected ‘LB’ as your base ‘UOM’ in the ‘UOM Class Maintenance’ app.

5/ Next, create another ‘UOM’ class but this time select ‘Dual’ as the ‘Class Type’.

6/ The ‘Dual’ class holds ‘LB’ as the ‘Base UOM’. For your ‘SH’ unit of measure, you specify a Conversion factor. Let’s say you want ‘1’ SH to weight ‘511.2’ LB.

Therefore:

Assume, your warehouse holds ‘5,122’ pounds of steel that consist of ‘10’ sheets (warehouse bin).

Now, the system would only list the ‘Dual’ UOM Class records that hold the ‘Dual’ class type (UOM Class Maintenance) and that include the same ‘Base UOM’. A standard UOM Class needs to hold ‘Base UOM’ that is also ‘Base UOM’ for the ‘Dual’ class. I am talking about the list of classes that you can select in the ‘Part’ app.

In summary, the ‘Dual’ class allows the two class records to link and cross convert with the units of measure. This is ‘Advanced Unit of Measure’ related but can work independently as well. That is why you can select it in the ‘Part’ app on the ‘Attributes’ card.

1 Like
5

Thanks Alisa. So independent of Advanced UOM, Dual UOM comes in handy when you’ve already assigned a UOM class to a part that already has transactions and want to be able to perform conversions that cross classes (e.g. length (so feet, inches, meters, etc.) to weight (so pounds, ounces, tons, etc.)), because otherwise you would just create an UOM Class of type “Other,” and perform the conversions there. Is that fair to say?
…
…
…
If you don’t mind, I’m going to pick your brain on some of the AUOM stuff because we want to explore it and I’ll try to explain how. We inventory hot rolled (HR) plates of varying thicknesses and sizes that we then use on our CNC plasma table to cut plates of different shapes. Now if I store each HR plate as a part in a traditional ERP sense (e.g. store a 1/2" x 60" x 96" as its own part number in EA, a 1/2" x 72" x 96" as its own part number in EA, a 1" x 60" x 96" as its own part number in EA), I think I run into some problems:

  1. When I set up the BOMs for assemblies/subassemblies that use these parts, my QTY/Parent for the assembly is a decimal number in a discrete UOM, which is just clunky. How do I have 0.0653 EAs of something?
  2. Which plate number do I use as the material on the BOM for the assembly if I don’t always use the same size material? I let the nesting/optimization software take care of that. For example, when setting up the BOM for a 1/2" x 12" x 12" assembly, do I list the 1/2" x 60" x 96" HR plate as the material or the 1/2" x 72" x 96" HR plate? Its confusing and also leads to planning problems.

My solution for this was to create a part number for each thickness of HR plate (e.g. 1/2" thick plate gets its own part number, 1" gets its own part number, etc). and then use a “Weight” type UOM class on the parts so that I could store in pounds (or tons, etc.). Now my QTY/Parent for the BOMs of my assemblies is a decimal number in a continuous UOM. 7.59 pounds just looks better than 0.0653 eaches. Also, I don’t have to just blindly pick a material. For the 1/2" x 12" x 12" plate assembly, I just pick the 1/2" HR plate as the material.

However, this approach is not without its own problems; I have no visibility into the sizes of the plates in inventory. If I want to know how much 1/2" plate I have in inventory, just seeing that I have 5,200 pounds doesn’t tell me much. This is where I thought AUOM could come in handy. I figured I could store the actual sizes using the attribute sets. But, like most things in life, the research has left me with more questions than answers.

  1. What are the design intents (and example use cases) behind the different calculation types? I think in my specific scenario I would use the “Calculated Expression” type and then just calculate the weight from the Area of the plate, but I want to understand the other 3 as we potentially come across more scenarios in the future.
  2. Why is the ability to assign a Dynamic Attribute Class to a part record not mutually inclusive with setting “Track Inventory Attributes” on a part record? What would be the point of assigning Widget-ABC a Dynamic Attributes Class but not tracking inventory attributes? Where is this useful? What is the design intent? Most of the documentation I have found indicates that Dynamic Attribute Classes is not used solely for AUOM, but I can’t find a use case.
  3. Beyond the reasons we talked about earlier, how is the Dual UOM feature intended to be used with AUOM? Couldn’t we just set up a UOM Class of type “Other” and perform any conversions there? Or are there additional advantages when used in conjunction. All the education material constantly states that Dual UOM can work with AUOM, but it never really states why or how.

Sorry for the length.

6

I’m no expert - that info I pasted is the answer I received from Epicor development when we were working on AUOM last year. We ultimately couldn’t get it to work the way we needed it to and did not proceed with purchasing the module. However I will share our experience since it actually sounds like we had similar requirements.

We wanted to be able to calculate the weight from the length or area of the part (just like what you are trying to do). Here is one of the classes we set up. We did some with area too - basically the same way.

image

So basically, the length was variable, and the weight was calculated (for example, length* .02, or however many pounds per inch for that part). Then we had to add another attribute for calculated length (the expression was literally just, length) because otherwise we couldn’t set the length as the final expression and set the UOM for length. If you don’t do this then you don’t get to see your inventory converted in that measurement throughout the other screens.

There is a lot I don’t understand about AUOM, like for example your question about why you would NOT track inventory attributes. No idea.

Ultimately my conclusion is that Dual UOM is not needed unless you were planning to use existing parts and try to reassign them to dynamic attribute classes. We were talking the approach that we would be setting up all new parts so that wouldn’t matter.

My suggestion to you is to go to insights and do the AUOM training or AUOM sessions (I am sure they will have them this year like last year). I got so much great info from the developers at the conference and they were extremely helpful.

Our decision not to implement AUOM at this time came down to these gaps (keep in mind, we are on 2021.2 - I have no idea if any of these have been addressed in later versions):

  1. Cannot set non-calculated attribute as the final attribute (aka final expression) and set the UOM
    Our primary scenario for attribute tracking would be for materials where we stock and purchase in length, but we also want to know the weight, and the weight is a calculated expression. The only way we could get this to work was by setting up a dynamic attribute class with three attributes:
    Length (not calculated)
    Weight (calculated)
    CalcLength (formula for calc length is just, length) - set as final expression, defined as UOM inches.

Without having that expression defined for calc length, we were not able to get Epicor to properly convert between number of pieces and our inventory UOM (inches). While this is clunky, it’s a one-time setup issue that we could workaround. It just seems like you should be able to pick any attribute as the final attribute (so that you can set the UOM), not just a calculated expression. I can’t think of a reason why it could not work this way. I entered this with support and they referred me to Epicor ideas (which I did create an idea for it).

  1. Unable to extrapolate jobs that are required to cut stock material to length
    In this scenario, we have a piece of tubing. The required length of the tubing material on a given job can be anything from 1” to 240” (in 1/16” increments), but we only purchase and stock the 240” length. We used the 9.5” attribute set of this material on our method of manufacturing. It requires 2 pieces per parent so a total of 19” – 2x9.5” – for each operation. With a run quantity of 450, that means we need 900 pieces of the 9.5” part, or 8,550 inches total. However, we only purchase the 240” stock part. We can get 25 of the 9.5” pieces out of each 240” stock length, with a drop of 2.5”. That means we need a purchase suggestion for 36 pieces of the 240” attribute set. Then we need a job suggestion to produce 900 of the 9.5” attribute set using the 240” attribute set. We tried to create a subassembly within the method of manufacturing to produce the 9.5” piece from the 240” piece, under the theory that would spur the correct purchasing suggestion, however we were unable to get this to work because it won’t let us reference the finished good (the 9.5” piece) as a material on the job. Our consultant’s recommendation is to manually create a separate job to cut the 240” lengths into the 9.5” length, but that’s not a realistic solution (how would anybody know or figure out that it needed to be done?). My next idea is to create 2 separate part numbers. One part would not be attribute tracked, would have a length of 240” inches, and would be stocked. The other part WOULD be attribute tracked, in lengths from 1” to 239.5”, and would be non-stock. But how do tell Epicor that you can manufacture the second part from the first part? Without defining a separate method of manufacturing for each of the thousands of possible lengths? We are stumped on this one.

  2. Can’t backflush attribute tracked parts
    While I am well aware of the dangers of backflushing, the reality is that the way our plant currently operates is by backflushing and that isn’t something that will change (soon, if ever). It is obviously technically possible to backflush an attribute tracked part, because you can mark the backflush flag on the job details, and it works (it does backflush the correct attribute set). But for some reason you can’t check the default backflush box on the part itself, which means it is a manual process on every attribute material on every job to mark it backflushed, when the entire point of having the backflush checkbox on the part record is to set the default. I think Epicor’s reasoning for disabling this flag at the part level is flawed. Yes its true you don’t know which attribute set you are backflushing when you are on the part record, but that doesn’t matter, because you aren’t actually backflushing anything at that stage. The only thing you need to know is that WHEN you use that material on the job (at which point you specify the attribute set) THEN you backflush that specified attribute set. I believe this should be re-enabled. There is no practical way to customize around this limitation and there is no legitimate reason the existing functionality shouldn’t work for attribute tracked parts the way it does normally. I entered this with support and they referred me to Epicor ideas, which I did create an idea for it.

7

Alisa,

We are running into number 1 on another part we tracked. We purchase steel coils that we roll form into various parts. Because of the nature of the process by which they are made, the coils vary in weight, so we purchase and inventory them in pounds. We saw AUOM as a potentially opportunity to help with this part as well. We figured we would just enter the number of pieces received at each weight. Like you, we discovered that we either have to calculate the weight from the entered weight or change the calculation type to “Quantity and UOM.” We are still debating whether to go the calculation route just hide the calculated field so the user isn’t confused or to go the “Quantity and UOM” route and set the initial value of the UOM attribute to “Pounds” and then set it to “Read Only” and maybe even “Hidden” (I don’t want some users entering the weight of the coils in tons and others entering the weight in pounds). We also submitted an idea requesting that another calculation type be developed that is “Quantity” so that the UOM can be selected at the class level without the need for the unnecessary calculation.

I cannot speak to number two as we are not far enough into testing to see how jobs and other areas of the system are affected. I also cannot speak to number 3 as we have to lot track (almost) everything and therefore can’t backflush.

8

This is a use case for the UOM option. The user entering the weight could select what UOM to enter it at. But then you would have the Dynamic Attribute Class convert it to what you wanted.

We are still early in using AUOM because we cannot set Mins per attribute class. Once we can, we will start using a lot.

We are strictly sheet metal and ended up with the following attributes.

  • Length (manually entered)
  • Width (manually entered)
  • Thickness (defaulted as we decided to have 1 part per thickness)
  • Weight (calculated)
  • DFARS (check box)
  • Grain direction (manually entered)
  • RoHS (check box)
  • Vinyl coated (check box)

As we worked through it, we went to both extremes of 1 part number for Stainless Steel with every option an attribute to thousands of part numbers for stainless steel with only just the dimensional data as attributes. As we did the mental exercise of trying to come up with the best possible way, we realized that we needed to concentrate on the reason why we got the module, which was needing to know what cut sizes were in stock. While we could still get the cut size with 1 part number, we did not want to overcomplicate it for people. So, we made out part number be the metal (aluminum, ss, steel) with the type/alloy (5052, 6061, 304, 316, cold rolled, hot p&o) and the thickness. This makes it easy for employees to see what they are looking for but will still allow us to store our metal in various cut sizes.

What I learned through the implementation process is that while it seems like a magical tool, it is not. You need to figure out what you are really looking for and then back into it.

9

Thanks for the words of wisdom. I will heed them because we too are struggling to decide where to make the cutoff.

10

I’m curious if you ran into any of the issues that were showstoppers for us (that I noted above), and whether you found any solutions to them. The feedback I got from my team after 2 months of testing was “half baked” but I don’t know if that is the fault of the module or just because our consultant wasn’t able to provide solutions to the issues. Or maybe we just aren’t a fit for AUOM.

11

Yes, we ran into 1 & 2. It took a little while to get past them, but we were able to. I would need to understand what metal you are using to help with 1. Then I think I would be able to help with 2 also.

I am completely against backflushing until a company gets it right through issuing, so I am not allowing it. When we implement in our other two divisions they are not going to be able to backflush any more :smiley:

12

Alisa,

On a semi-related topic, you mentioned that you didn’t end up purchasing the module but you did test it. Did Epicor give you a free trial of the module? I was under the impression that they don’t let customers test modules prior to buying.

13

1 we got past with the alternative I described, its just clunky. Did you find a different solution?
2 In that example, the issue was steel tubing that we stock in 240" lengths and then cut to size.
3 I’m against backflushing too, its just not up to me :laughing:

14

Yes we did a trial. You essentially execute a purchase agreement with a clause that says if you don’t cancel by (x) date in writing, then you will be invoiced for the module.

15

Yes, we realized that we had to put the dimensions in. So our must enter are length and width. That allows us to see what we actually have in stock. It sounds like for you I would make the length the only attribute that must be manually entered.

16

Hi i want to tak about your point in 2.

  1. But how do tell Epicor that you can manufacture the second part from the first part? Without defining a separate method of manufacturing for each of the thousands of possible lengths? We are stumped on this one.

If you had the cut set up with a configuratgor that would modify the bom for each part attributes could this work ??

i am in the same boat, i am trying to manage bar lenght and cut length… Cant figure with this is so fuckin complex, we are probably not the only machine shop that want to track inventory properly…

17

Interesting idea . . . we don’t have configurator so I don’t know.