Yes, it works.  The reports that print during the delete/renumber process include a note as to why an item was not deleted.

Usually the reports do indicate a reason (eg; inventiory exists, transactions exist etc), but no noted reasons were found.

Also, since I was able to manually delete the parts, those same types of issues would have prevented me from deleting them.

I'll try some more tests

Ok.

When I added the following fields to my import in Visual integrator:

AllFiles, DeleteItems, DeleteItemWarehouses,DeleteItemCosting, DeleteAlternateItems, DeleteItemPricing, DeleteEBMItemsCategories

..and on the [Data Tab] for the import; Set the Import Field Properties as follows for each of those fields:

Operation: [Assign]

Default Value: ["Y"]

The items are now gone. Very cool...takes awhile, but it worked.

I suppose the field names in the DeleteChange table are somewhat self explanatory, but...

Being the curious sort, is there any documentation besides the File Layout in Sage regarding these fields, ..which ones are required, logic etc

Thanks for your reply

I use the UI to enter something, then mimic the data created within a VI job.  The help files are probably all you're going to find.

While it's fresh on my mind. When using the BOI to delete item_codes, I've normally just verified the item_code exists then deleted it, (which mirrors the [Delete] button on the Item Maint screen)

It seems to work much faster...and I don't have to have everyone out of the system, but it's not doing the additional table clearing that the Delete/Change table...it seems.

Any additional comments from the super data people out there would be appreciated.