Sage 100

Manufacturing question - customer has bills with options with no components except for option interactions (they make knitted cuffs so the components depend on size, color, etc.). For one item, when they enter a work order with various options, it is overstating the quantity per item for one component. (Happens in Production Entry as well.) For example, for one specific option interaction, a yarn is supposed to be .008 per item but in WO, it comes through as .02. There are only two components - both yarns - and one component is correct but the other is increased. On another, the first yarn is supposed to be .015 per item but comes through as .05. It is not the same yarn/item and there is no scrap involved. Can't figure out what I'm missing. @DebThomas @BethBowers ?? This started upon upgrading them from 4.3 to v2014 PU 4.

NO idea, but you could try dumping out every field in the bills to see if there is some difference between them...

Yeah, I thought of that. Such a mess with option interactions.

Sorry, no wild thoughts from the peanut gallery either.....

@ThereseLogeais - am having a similar issue but not with options - client has LENG unit of measure that is rounding up yet it is not setup to do so in BOM options. Client is using WO as well. Recently upgraded to 2015 and still happening.

Rounding to just two decimals or to integers?

In my case it's rounding to integers, but it was only 2 places in the first place, unlike Therese's 3 decimals. Having them check Prod Entry right now. Seems to be machine specific, though, which would be totally whacked - but have yet to verify that.

Anyone take it upon themselves to define it as an integer. I am sure NO ONE did, but might be worth the look.

Already checked, no dice. Unless it was at one time, and someone deleted it, and there's some file somewhere that can't let go...

Perhaps if you add it back in, save, then delete???

I think I figured out mine. They have five options but have option interactions for the first two categories and all five categories (see below). Since the same item is in both option interactions, it is combining them so a work order for 01, 06, 08, 07, 04 is calling for .047 lbs of 70/3.BLK21. Is that how it is supposed to work???

@BethBowers @DebThomas Am I incorrect in how option interactions should work? In the above example, the first one with only two options selected, is for a 1.5 inch all black cuff while the second one is for a 1.5 inch striped cuff with more than one color. Should it be adding in the black yarn from the first 'bill' whenever you add additional options? I'm thinking this is only happening since upgrading to v2014. A bug or is it WAD?

Seems like WAD to me, but what do I know?

Just checked their v4.3 and it does the same thing. How have they not noticed this until now??

This is correct. The components are being rounded in each instance of the bill. So each time it is referenced it rounds up the qty needed and then adds it up at the end. Rounded then summed.

I'm still confused @JoanSerr . If they enter a production and include five options, shouldn't it only be looking at THAT option interaction??? Why is it including the option interaction for the first two options? And mine has nothing to do with rounding; it is simply adding different option interactions.

The rounding issue could be how integer units of measure are set up. It automatically rounds up partial quantities based on the integer unit of measures defined. That is why it is not a good idea to use ""EACH"" for items you want to use partials in the bills. It is an integer unit of measure by default and is grayed out in options.

Haven't worked with option bills much. No live installs, just the demo data. do you have to back out one of the options so that it doesn't add both...this is in the help screen...6.Select a line and enter the components that will be added to or deleted from the base bill when a specific combination of option codes is used.

That was my understanding @alanniergarth. The base bill has NO components so technically, it should add the components included in the option interaction, not look for other option interactions that are partial interactions.

Therese, sadly, it is working as ""designed"" but not as it should. I argued the point with Sage, but you know how that goes. It should ONLY consider the interactions for the specific item. Not every bloody interaction in the BOM.

Really @DebThomas ? I was hoping you'd say it wasn't so. I guess they will have to adjust the option interaction by doing a negative entry for the yarn included in the first interaction? Huge sigh....

I know Therese, wish I could have been more supportive, but Sage really has no skill in managing BOMs or manufacturing requirements. Drives me flipping nuts. As far as I can tell, you will need to reverse the material use. However, if someone has a better solution, I'd sure like to hear it. I hate Option BOMs in Sage. I try my best not to use them...well, you can imagine how well that works.

I don't blame you Deb, believe me. I'm just trying to think of a logical way to explain this to the customer: ""If you have an option interaction for one size and color then have the same size and color in another option interaction, don't forget to do a negative quantity of yarn in that second option interaction so that it equals the yarn you actually need for that size, color, striping, etc."" Yeah, that makes total sense...

Right?! Sigh....such poor design so drives me nuts.

Well all these comments have gotten me lost, (says the geographically challenged). How can you have a Bill without any component or an option to nothing? Shows you how much I still need to learn.

This customer makes knitted cuffs/collars. There is no base bill because it all depends on the size and color(s). For example, a 1.5 inch cuff takes .00X .lbs of yarn per cuff. Since they have different styles (e.g. knits), they have multiple bills but no base components. The options are typically - size, color, stripe, 2nd color (if striped), and 3rd color, (depending on striping option). SO.... sometimes they simply make a single color cuff, say a 1.5"" black cuff (option 01:06 - 1/2 inch, black). That interaction calls for .035 lbs of black yarn. Now if you add a stripe with two other colors, option 3 is the striping type and options 4 and 5 are the second and third colors. Since the cuff size is the same, the black yarn is reduce to a third (or should be) and one third will be color two and one third will be color three. They have all of these things set up correctly IF it only looks at the particular option interaction for those five options. However, in this case, it adds the .035 lbs of black from the option interaction for 01:06 PLUS the .012 lbs for the three-colored striped cuff - 01:06:08:07:04. Again, Sigh.....

Perhaps it was fixed in v2015???? Has this been reported to Sage? Maybe Diane Coffman can champion this for you...

At summit Diane Coffman was putting together a task force for what to do with Work orders in the new framework. @DebThomas should be on it!

I wouldn't count on Diane Coffman being as active with the channel. It seems to me that Scott Munro, Mike Ritchie and now Linda Cade are taking on the face of Sage in terms of dealing with us. I also believe that the manufacturing discussions will remain within BPAC, where there appears to be a great deal of experience. These are all just observations/opinions on my part.

It won't matter @alanniergarth . Years ago I was on the Sage (Best) Manufacturing Advisory Committee. Nothing, I repeat, nothing we suggested was ever implemented. Sage has decided that manufacturing should be handled by 500 or X3 and you're not going to get them to move. I have always believed that the manufacturing modules ""could"" be streamlined and ready for prime time. Just doesn't look like that will ever happen. But thanks for the kind mention.

I asked about future Mfg enhancements eons ago. I talked to I don't know how many people who were supposedly on the ""Mfg Team"" and they always said, ""We're working on it. Contact (whomever it was at the time) and NOTHING ever came from it. Appreciate your efforts @DebThomas !