Sage 100

I'm working with a customer on 4.4 Sage 100 trying to renumber a significant quantity of inventory items. I'm finding that before importing to delete/change Sage requires that the item I want to CHANGE TO already exist. However that also requires that the two items (Old/New) share the same costing method (which is probably not the case for a material number of my changes). Has anyone dealt with this limitation and is there any way around having to create the item first before importing to delete/change? Seems odd I can key it manually but no VI when the new item does not exist.

If you MANUALLY key the new number (which does not have to exist) into the Delete/Change - it works fine. This appears to be largely a VI related issue.

Is there a back door way to adjust the validation for a import?

I think it is all in the Business Object now so you need to Modify the code. Scripting might be allow to change to business object too? @AlnoorCassim is that true?

Now I understand what @JaneScanlan was asking about in a related post. This means there are business rules being set in the UI object (uh oh) and they are different than what's in the business object. Steve Malmgren's blood would boil over stuff like this. What's going on is when you enter the Ending Item in the UI it is not a doing SetValue command (they must've done that on purpose because of this very issue!). However one must do a SetValue for the bus object (V/I, scripting, BOI, etc) and that triggers dictionary validation (IOW they must've been thinking it's okay if V/I loses because nobody imports into this file). For me in Providex.dde the EndingItemCode field is key 000503000003 Prolly it's the same for you but not guaranteeing that (you can step thru the DDF trail to find the correct DDE key). So if you pull that up in DFDM, you'll see Field 14 = ITEMCODE That is called dictionary class validation (as opposed to Field 20 which dict external validation). It effectively means this field is validated against CI_Item, So you could backup Providex.dde and blank this field out, then run Activate() function to make change flow into the physical IM_DeleteChange M4T file That would solve your Renumber problem (but please test it!). However it would break something else. If you're importing in Merges you NEED this validation to exist. They should've created separate fields as in: EndingItemCodeRenumber EndingItemCodeMerge But that would mean changes in the UI and business logic. Poor marks to the 4.40 Design Team for this one.

Thanks @AlnoorCassim I'll give this a try. It's definitely a puzzler and dampens my enthusiasm for VI because up until now (ok maybe a few other times too) I've always taken the stance that if you can key it you can VI into the file. Not true in this case -- at least not true without a potentially very time consuming workaround which requires you to setup the new inventory item ahead of time with presumably the same info as the one you're transferring (renaming) from. Yeah it's not brain surgery and you can do it with multiple VI jobs but my opinion is that you shouldn't have to and these tools which Sage sells should be maintained to the level/purpose that they are sold for. Thanks much!!

The whole point of having ""business objects"" is that EVERYTHING uses them to read/write data. Steve Malmgren's blood should be boiled for not having checks in place to keep things like this from ever getting out the door.