There is a complex exit-handler in the IQS0 code that runs the standard IW22 transaction. The reason why this exit-handles is complex is as follows.
1) In configuration, you can define a custom tab for IW22 and place from 1 to 5 custom subscreens on this tab.
2) There is a dynamic loop in the SAP exit-handler which “knows” how many subscreens you’ve placed on the custom tab, and loops the correct number of times to call the each subscreen in succession. This loop fires during output, so the PBO for each subscreen is called in sequence, and also fires during input, so the PAI for each subscreen is called in sequence.
OK – so suppose you have an input-enabled field on subscreen 1 with an edit of this field in the PAI for subscreen 1;
You deliberately place bad-data in this field and then click on a different tab than the one the subscreen is on – i.e. one of the standard SAP tabs for IW22.
Here’s what happens:
3) your custom edit detects the bad data that you’ve entered in subscreen 1 and fires the “E” error message, which appears correctly at the bottom of the main screen.
4) But when you hit “enter” to clear the error message, the system automatically pops the tab that you selected – it doesn’t give you a chance to correct the data. (It doesn’t leave the bad data – it just replaces it with the default data … you can see this is true because when you return to the custom tab after visiting the standard SAP tab that you selected, the bad data is gone.)
Now … I can understand why (3) and (4) are happening – after the PAI of subscreen 1 fires, SAP detects the fact that you’ve selected a different tab … so when control returns to the SAP exit-handler loop, this loop does what it’s asked to do – it takes you to the tab you’ve selected.
Becaue the SAP loop doesn’t know or care that there’s an error condition on subscreen 1 that has to be reset – it only knows it’s been asked to switch tabs.
Suppose I’m correct in the above analysis, and that there is no way to adjust your custom code to prevent the SAP code from operating the way it does,
Does SAP owe its customer base a free-fix of the apparent over-sight in the SAP exit-handler?
Or would SAP be within its rights to say – “hey – this is a customization issue – you’ve got to pay for the fix” (even though the oversight/error is only in SAP code)?
What do you think?