Sage 100

I have a client that has an ongoing issue. A duplicate record gets created in the IM_ItemCost file. It is for lot items. The duplicate record is the same in every way except the Tier Type field is blank. They had the issue in 4.4 and it continues intermittently in Version 2013. They are using Sage100ERP Standard. Anyone else experiencing?

Are they importing records with VI? Using Scanco or Scanforce? Are they current with the PU's? Can they trace it back to a particular update/event?

They are not imported or integrating. No third party enhancements. I do not remember what service update on 4.4 but they are on 5.0.4. The issue occurred on both versions.

@LarryBradford - I have a client suffering this same thing, BIG TIME. They are on 2014 now, were on 4.4, and it has kept happening. Have also had 2 other clients have it happen once in a blue moon. My client with the BIG issue is using Bills for production - is yours? I have created a report for them to list all lots with the blank Tier field, and then another one to list all lots with a Committed Qty because that too is screwing up. We're trying to pin down when the blank tier field happens.

No production modules at all here. It is a duplicate record. At first I thought it was when receiving was done but I am not convinced it is not some other process and the creation date and time of the record is just duplicated with the rest of the fields. Many of these records were created prior to the last time I had the issue and cleaned up so in theory it is occurring in the sales process. Does your client use the committing of lots in sales order? I am betting this is somehow related.

My client does NOT but swears it is doing it anyway - they are convinced it has something to do with that, too. I'll check to see if they have it turned on but are just not using it.

OK, just had one come up. (Client does not have it checked to commit Lots in SO Entry, by the way.) This was a lot with 4 lines of activity on it - 3 lines happened in 2011, one line happened this year, in July. HOWEVER, my report showing blank field 3 did not show this item a week ago. No activity happened on this item in the past week. WTH??????

Maybe recalculation of committed quantities is causing? Are they running these utilities? Physical Count? I have made more progress working with @BethBowers on this in a few hours. Thanks for the detail.

No, nothing. They don't know about those utilities, haven't done a physical count. The item might be on a sales order (I didn't check), but nothing has actually UPDATED it since July, yet in the last week it suddenly turns up with this issue. I'm getting angry now.

Amazing - Just off the phone with client running v2014 with this exact issue. However, the tier may have been created in v2013 based on the date.... Looks like I will scan item cost for other tier issues....

Now I'm getting really grumpy. Have a client with SERIALIZED items and they accidentally updated a physical count register before entering any count. OK, fine. You can see the serial item being adjusted off. But then they put their counts in and the IM_ItemWarehouse qty was updated, but the serial number remains at 0 count and you don't see any adjustment coming back in on the SERIAL number. You do see the adjustment back in on the Trans Tab. Client is on 4.4. What the heck is up with this meltdown of lots and serials?????? Oh, it's that group that hacked Sony, isn't it?

Has anyone setup a case with Sage yet? My client just had 2 more whacko things with lots and I'm totally fed up.

I never bother with opening cases with Sage. They always say this is the first they heard of it.... Which is a lie. Plus, what does it really take to get any movement out of them or a RESOLUTION. Look at the posts today about how long it took for a new paperless driver (thanks @JohnnyPabian , the issues with the new driver not working at the server console and this issue. Have I mentioned how much I hate liars???

OK, I'm diving in. We'll see what happens. They have a case re the Tier Type field, so I can just push that a little harder as in - what's the reason, since you have the fix?

Update on this - have been working with Sage for a couple of months now. Sage has client's data (and whole system - they required that because client has some Item UDFS) and has not been able to recreate. Connecting with client again next week to continue to try to catch it happening. Client continues to get 2-5 a week.

Any news? I am meeting with my clients to go through open issues. This is a big open issue for sure.

Hell, no. Sage can't recreate. I'd love it if you would report it. though, because when I did they said they'd never heard of it.

Do you have a Sage case number that I could cross reference @BethBowers ? I am calling Sage for this issue and would like to get past the ""tech support has never seen this before"" answer.

@KerryEsser - it's 8004193535

Putting another call into Sage on this issue. A year later and still an issue. The client is completely feed up. Anyone ever receive a resolution?

Beth - just wondering with your lot issue anyway, that just happened in the last week... did period end happen?

I have a customer experiencing this as well. They have to DFDM to fix. It comes up in conversation quite frequently and not in a pleasant way.

Is this happening in v2016 also????

I'm not sure. I think this customer is on 2014

Sage could never recreate. Since upgrading to 2015 from 2013, the frequency of occurrence has dropped drastically, but still happens at least once a month, but usually on just one item. Client has hanging Committed qtys also, but it's never the same item as the missing tier field item. I have found that the record with the missing tier normally has the original received qty as the qty on hand, then there is another tier that usually has the correct qoh or would be correct if one last usage was subtracted from it. That would lead you to believe the tiers are created when the item is originally received, but I've never actually caught it at that point - it needs to have more activity than that. So if some MD that has a lot of time on their hands could just look through every single program in every single module that writes to the ItemCost file, I'm sure we could find the culprit. Ha.

Beth, I know I have fixed these as time passes and searched the IM_itemcost for records with a blank tier type. The original date and time matches the duplicate and several have dates earlier than the last time I fixed all records. This leads me to believe this is something other than the receiving process. Now, I do believe my clients have multiple receipts against the same lot... Maybe that is something all of our clients have in common.

Hm. I didn't think my clients did, but I'll ask - good thought! I have a report I created for the client that lists any record with a missing tier or a committed qty and they run that daily and send them to me when there is an issue.

@BethBowers , more bad news on this issue. I have upgraded the client to Advanced 2016 and we have just found the issue continues in 2016.

Any Enhancements / custom programming?

Does anyone have a client with this issue that also has Sage Alerts? We could create a job that sends a notice when it occurs. That way we could at least look to the client for a register or transaction that impacts that item.

No enhancements. Just UDFs.

@LarryBradford - I'm pretty sure no one reading this thread is surprised about the 2016 issue.

I think we should take this on as a 90 Minds group project in collaboration with someone at Sage. We seem to have enough examples that we can press the matter.

I was just reading a sage knowledgebase article and they say to populate the tier type. I am pretty sure that will be what we call... bad. Mine creates a duplicate record that needs to be deleted.

I would love to see this solved but I understand getting Sage to solve this would be difficult when we cannot even ID the cause.

Someone in 90 Minds should be the lead - maybe @BethBowers because she has the case already. Then we should be able to go to Sage and ask for some attention. Especially since it seems we have about 1/2 dozen actively experiencing the issue over multiple versions. I would go directly to one of the product people and skip the front lines. Maybe Diane or Kevin - I think either Jeff or Jim W have good contact with either/or.

I can do that. Which person should I contact?

Let me find out and I will get back to you.

To add to this, it happens on version 2017 too.

Has anyone ever found any sort of resolution to this? I searched the Sage KB and found one of those articles thats of no use at all. It simply states its a known issue - but they can't reproduce. We are investigating at DSD but can't seem to find any commonality between the two customers who we've come across with the issue have lots, inventory adjustments, BM product entry in common - but its not every single time. It appears to be completely random. I thought maybe the issue had to do with VI imports but that doesn't appear to be the case. Are others still experiencing this issue?

Absolutely still occurring. Just had it this last week. It is the same client. This client does not import inventory. Long ago we modified their Product Lines for them but otherwise no regular import of items. The record is a complete duplicate including the creation date and time. I know definitively the records are created after the original receipt because of finding and removing all records and having an occurrence later with a record with an older date than the prior repair. My suspicion is it is related to physical count or sales order entry lot assignment. I have no proof.

Thanks Larry. For the client that I was looking at, many of the items only had IR transactions. nothing else. I re-entered the same transaction in a copy company and everything was fine. This is so peculiar.

I also had it happen again recently for a client. They do frequent physical counts so I think it has something to do with that along with some other unidentified event. I can't duplicate it. They don't import data, but have Mapadoc and Starship. Their sister company who is no longer using Sage 100 used to have it happen even more often. They also did frequent physical counts, didn't import data, but had no enhancements. It seems really hard to believe that Sage programmers can't figure this out since it's been happening for a fair number of customers and for several versions now.

Our clients are acquiring the inventory through PO. We have no third parties on the install. Do any or all of your use the Sales Order capability of assigning the lot during SO Entry instead of Shipping or Invoice Entry?

@ShariEckersley do they allocate lots/serial in Sales Order Entry?

@LarryBradford at least one of the two clients that we have does allocate in SO Entry. They other i have to check.

I don't think they use that function, but I will check.

As @WayneSchulz said above, 90 Minds should contact either Diane Coffman or Elliot Pritchard to push this for a resolution. @BethBowers did you ever do so? If not, would someone be willing to get this going with Sage? There are seven 90 Minders with customers experiencing this. They should know that. elliott.pritchard@sage.com diane.coffman@sage.com

@ThereseLogeais I can email Elliott. I just wanted to gather as much info as possible.

Actually I'll just email both Elliott and Diane. I have a good relationship with both of them. If anyone else has experienced this issue - please add to this thread so I can pass along to Sage.

Agreed it needs to be moved up. The problem is we can't determine when the duplicate is created. If we could narrow down to which process is creating the duplicate, it would be much easier to get Sage to solve it. If we can answer this though, we probably have the expertise to determine the line of code and tell Sage how to fix it. Then it is getting Sage to fix it in less than a year. SO... Does anyone have Sage Alerts already implemented and licensed on one of these clients having the issue. Could we not be monitoring the IM_ItemCost file for a record with a blank tier type. We would then be able to look at the transaction history file for a record created at the same time as the generated alert (or within a limited timeframe). Am I oversimplifying this?

Isn't that Sage's job @LarryBradford???

Probably Sage's job. We have seen how that has got accomplished so far. If the process cannot be narrowed down, it would be VERY hard for Sage to solve.

Sorry, finally off the phone. To be honest, I don't know who all I talked to about this issue, but I know it was multiple people multiple times, including sending the client's entire Sage folder to Sage for testing. I have noticed that sometimes the record appears to have been created when there is NO corresponding activity, which is even scarier. The pattern with my client is that a record suddenly appears with a blank tier type AND the Qty On Hand is the entire original amount of the lot (which is usually 0 now for the real record). I can delete the record with no issues because the same lot WITH the tier type is also still in the file.

Just so you guys know - I sent an email over to Diane and Elliott. I'll let you know what comes of it. We're also reviewing the programming here internally at DSD to see if we can figure out the problem ourselves. As Larry said though, it is VERY hard to solve this without getting a lot of information. As everyone knows there are a lot of things that can effect IM_ItemCost. So its basically like a needle in a haystack.

Every time called we query the file for records in the file with a blank tier type. There is never just one. You can simply delete but we are having to do this about every month to three months for the same client. Because we will have instances without a IM_TransactionHistory Record, we feel it is inventory related. Because many clients don't have the same issue it could be because inventory is not processed frequently for many clients, the number of clients in the system or a newer feature like the Sales Order Lot/Serial Assignment added in more recent version. This client has had the software for 15 years and has had the issue for the last 5 to 7 years.

I attached a list of questions that I started and please add any that you think of. We want to first get a complete list of questions in the document so we each complete documents with the same set of questions so please review, add/revise, and share the list. If we all fill it out based on our client experiences so that Nicole can submit them to Sage then it will provide valuable information for their analysis in determining the problem (or at least eliminate what's not causing it) and ultimately the solution since at this point none of us can duplicate it.

Mine is attached.

Great collaboration!

Attached

@BethBowers , mine is creating with the original quantity as well. You are confident they are not doing physical counts other than once a year?

Yes, @LarryBradford.

On the one that I had issues with - they are new to Sage 100 and have not done physical counts yet for those items.

And I agree with @MoiraGoggin its this kind of stuff that 90Minds is all about! Thank you everyone for your input!

I'm still waiting to hear back from my client for the remaining answers to my questions, but from our combined findings it doesn't look like we are seeing any pattern, but it provides a lot of things that Sage can eliminate from causing it. I think the idea about using Alerts to know when it happens is key since no one is recognizing that there are records with missing tier types until a lot after the fact when no one remembers anything out of the ordinary happening. Unfortunately my client doesn't own Alerts.

Well... Gee Wilikers. There goes my theory all to hell.

I do have a Crystal report that my client runs daily....

Three years later (and this was an old issue at the time of this post) and the client continues to have 1 or 2 tiers duplicated with a blank tier type every month. The client has been purchased by a large corporate entity and will likely consider changing software because of lack of confidence in the product because of this repeated issue. Anyone ever find at least a cause of the record duplication?

I have someone on 2016 who makes heavy use of lot/serial and I have not seen this.

@WayneSchulz , does the client that you referenced earlier in the post continue to have the issue? What is different about that client?

I'm not sure if they are still experiencing it. We since upgraded them to 2017 Premium. They were taking care of the issue with DFDM so I may not have heard from them after the first few occurrences.

The user on 2016 creates Lot/Serial items solely through BOM Production Entry. As of 12/28 has not done any physical count (new user in 2016). I see two blank tier type but they are not duplicates of another record.

Bringing this issue back up again - status update. We at DSD back several months ago, found in the Sage program where we believe this problem was occurring. I had reported it to Sage development but it fell off their radar apparently. @LarryBradford and I mentioned this issue to Ronnie and Chris at MoTM and I followed up with an email with the requested code changes when MoTM was over. Ronnie and Chris pushed it back to development and I received an email from Sage development today that they will be implementing the code change. They will email me next week with an update on which versions/product updates it will be included in. Once I have more info I will let everyone know. (My guess is that its too late to make it into the PUs that are set to be released this month and it will be in the next round of product updates)

@NicoleRonchetti - the next time I see you, after giving you a huge hug, I'm going to buy you numerous drinks. :-)

@BethBowers dont count your eggs before they've hatched though. They've told me they are going to do it and while I want to believe everything they are telling me..... I've learned to not believe anything that Sage says will happen until it actually happens :)

I don't care if Sage NEVER does it - I appreciate that you guys took the time to find something and point it out!