Sage 100

While working on an inventory issue at a client, I found a bunch (over 400) records in IM_ItemCost where the Item ID contains padded spaces. The result is an Item ID that fills all 30 characters. This in some cases has caused semi-duplicates on lot records for the same item. For part number R00002 in warehouse 000, there are two records, one with a 6 character id and one with 24 blanks after the ID. Unfortunately, these pseudo-duplicates are causing an issue with third-party app. I suspect that all the records containing the trailing spaces are a leftover from issues with their 4.4 upgrade which apparently what rather unpleasant (prior VAR). My questions are: How else could these records have been created with left padded item id's, What is the risk in deleting them? The newest Last updated value is 11/15/2001 though only 36 of the 452 even have record tag information. As always, your input is greatly appreciated.

Doesn't this also track lot/serial info

Correct Wayne, that is why we have a problem. The primary key to the table includes Item ID, Warehouse, Cost type, and Group ID which in our case is the lot number. Only lotted items are showing instances of right space-padded item id's. I have many instances where I have two records for the same item, warehouse, lot combination; one without trailing spaces in the item id and one with trailing spaces in the item id. In all but a very few instances, the record without the trailing spaces does not contain any record tag information (date/user created, date/user last updated, etc)

In legacy, primary key segments are supposed to be right-padded with spaces, so in 4.30 and earlier what you describe is correct for IM3. In BF, it is null padded (with the $00$ character) instead of space padded. Visually in DFDM you won't see the trailing null characters you would just see ""R00002"" . I/M conversion is what's supposed to change padding on existing IM3 rows to IM_ItemCost. Conversion would be my first suspect where the pre-4.40 data was amiss to begin with somehow. But based on the date updated / time updated info, if you see newer space padded item IDs (more recent than from conversion) then suspect the programming that does the lot number receipts (assuming it's a mod). Presumably if it was a mod writing ""duplicates"" they would've fixed it by now. If you think this is all from the past, that current programming is working correctly, then yes deleting the space padded item rows, assuming you find the matching rows with the null padded items, is appropriate for standard MAS. BUT do it in a TEST company first.

@AlnoorCassim, you have confirmed my suspicions. I assumed that the space padded rows were a legacy carry over. I need to ensure that all the rows are duplicates. I am pretty sure they are. I know that at least 275 are. Those are the ones first reported as problems. However, after further investigation, I found addiionals and I think I need to Nuke them all. I will make sure I pull a copy of the rows into a csv table prior to deleting them so they can be reimported via VI if absolutely necessay. Thank you again for the brief history lesson Oh Wise One!