2015 Aug 04 12:57 AM
Dear All,
I am currently facing the following situation:
Let´s say that yesterday I delist some articles for certains assortments by DATALOAD using transaction WSP6, so these entries on tables WLK1 have been correctly updated for articles and assortments; although, entries on table MALG haven´t been deleted for those articles and assortments and this was SOMEHOW enough to relist them back, updating the table WLK1 and activating them again for those assortments.
On other hand, If I delist these articles using transaction WLWBN, both entries on WLK1 and MALG are updated and deleted correctly.
With the situation above:
Can you see a standard program or transaction that was responsible for this relisting based on MALG entries not deleted?
Thanks in Advance and Best Regards,
Eduardo
2015 Aug 07 3:13 PM
Issue solved;
What relisted the material for assortment was the function CREATE ASSORTMENT on transaction WLWBN, even when it was executed for another and new material.
Basically, this function considers all materials with entries on MALG to relist them back, maintaining the WLK1.
For Dataloads I am considering an extra function to delete entries on MALG, so before WSP6 , I have to run for material and layout module:
WRF_MALG_ARRAY_DELETE_LITE
2015 Aug 07 3:13 PM
Issue solved;
What relisted the material for assortment was the function CREATE ASSORTMENT on transaction WLWBN, even when it was executed for another and new material.
Basically, this function considers all materials with entries on MALG to relist them back, maintaining the WLK1.
For Dataloads I am considering an extra function to delete entries on MALG, so before WSP6 , I have to run for material and layout module:
WRF_MALG_ARRAY_DELETE_LITE