webERP Forum
Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 - Printable Version

+- webERP Forum (http://www.weberp.org/forum)
+-- Forum: webERP Discussion (http://www.weberp.org/forum/forumdisplay.php?fid=1)
+--- Forum: Problems / Bugs? (http://www.weberp.org/forum/forumdisplay.php?fid=8)
+---- Forum: RESOLVED - Bugs/Problems (http://www.weberp.org/forum/forumdisplay.php?fid=15)
+---- Thread: Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 (/showthread.php?tid=48)



Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 - terryp - 01-29-2012

Hi Phil/Tim,

Is it safe to delete the old Item named part via Phpmyadmin directly at the database or is the error a indication of some serious problem ?


ERROR:
Adding the new stock master record ... completed
Changing stock location records ... completed
Changing stock movement records ... completed
Changing location transfer information ... completed
Changing MRP demands information ... completed
Changing MRP planned orders information ... completed
Changing MRP requirements information ... completed
Changing MRP supplies information ... completed
Changing sales analysis records ... completed
Changing order delivery differences records ... completed
Changing pricing records ... completed
Changing sales orders detail records ... completed
Changing purchase order details records ... completed
Changing purchasing data records ... completed
Changing the stock code in shipment charges records ... completed
Changing the stock check freeze file records ... completed
Changing the stock counts table records ... completed
Changing the GRNs table records ... completed
Changing the contract BOM table records ... completed
Changing the BOM table records - components ... completed
Changing the BOM table records - parents ... completed
Changing any image files ... completed
Changing the item properties table records - parents ... completed
Changing work order requirements information ... completed ... completed
Changing work order information ... completed
Changing any serialised item information ... completed
Deleting the old stock master record
Database Error : The SQL to delete the old stock master record failed
Cannot delete or update a parent row: a foreign key constraint fails (`tjporter/salescatprod`, CONSTRAINT `salescatprod_ibfk_1` FOREIGN KEY (`stockid`) REFERENCES `stockmaster` (`stockid`))
Database SQL Failure : The SQL statement that failed was
DELETE FROM stockmaster WHERE stockid='FNA-AMO-5G13'


RE: Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 - phil - 01-29-2012

Looks like it choked deleting the old item code because there are still salescatprod - it is a member of a sales category ... we need to add some code to change the salescat to the new item code - see attached new script. I've not testing so if you could let me know how it goes.

Note that any changes noted in the message will be rolled back as all the changes are wrapped inside a DB transaction - so nothing is changed in fact in your DB



RE: Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 - terryp - 01-29-2012

Hi Phil,
Worked like a charm! Thanks!!!

1) Sales Category Maintenance -> Add Inventory to this category : still shows the 2 items I renamed , before the rename
2) Items shows only the renamed items, not their previous names
3) Your new Z_ChangeStockCode.php renamed the Sales Categories Items in the last two parts whose names I had yet to change. They are gone from the "Sales Category Maintenance -> Add Inventory to this category" part choices.

I deleted the two names from the Sales Categories that remained from the error before your fix, however the database still still shows the two items I renamed , before the rename.

Should I delete them from the database manually ?( stockmaster by stockid) or just leave them there ?


RE: Z_ChangeStockCode.php failed to delete the old stock master record : webERP v4.05 - phil - 01-29-2012

Not sure how that could happen as the changes are all wrapped in a transaction?
You'll have to go through the script and see which tables are changed and which not... and make changes manually ... messy