As the title indicates this is about Checks while creating Measuring Documents and hence about a user-exit namely the very useful IMRC0004 . I felt an immediate need to record and preserve the solutions for various types of checks discussed so far, because it has been realized today that 3 times in last half year, I started by suggesting solutions through user-exit IMRC0001 for these queries and corrected myself in the end by giving final solution through IMRC0004. Also, being such an useful exit, this IMRC0004 is very less talked about exit.
Now few lines about the difference in using the above referred two exits for these checks.
I always remembered this exit as the one which triggers at the Saving of a MPt or MDoc as the description starts so. ‘MeasPoint/MeasDoc: Exit before update (after COMMIT WORK)‘. All such requirements about checks while creating Measuring documents, look work well with this exit but there is an issue caused by this part of the exit description i.e, ‘after COMMIT WORK‘.
What happens is, our code successfully prevents the MDoc from getting saved if the conditions are not met, but it interrupts the COMMIT WORK. So after preventing the MDoc when the system takes us to IK11 initial screen, if we continue by hitting Enter or by clicking on Back key etc, it would result in a short dump, because the code interrupted the COMMIT WORK. (We can avoid this short dump by coming out of the screen by using some tcode in the command bar).
So that is a clear limitation for using this exit for such purposes.
The description here says: ‘Measure.doc.:Exit according to stndrd checks for new mes.doc‘ . So far this description failed to trigger in my mind at right time in using for MDoc checks. But not here onwards because this event of blog creation will have its punch in the mind and would not let me forget again .
The basic difference in triggering of these exits is, the former triggers at the time of Saving the MDoc and the later namely our subject exit, triggers instantly at the time of entering values in the IK11 screen.
Now, I am listing below some typical requirements of Checks while creating MDocs and the Codes to be written in the include ZXMRCU04 of the exit IMRC0004 .
To prevent users from entering readings in the ‘Counter reading’ field of the Measuring document (of a counter obviously).
As mentioned earlier all these codes being discussed are needed to be put in include ZXMRCU04.
IF sy–tcode = ‘IK11’ AND impt_data–indct = ‘X’ AND imrg_ins–idiff IS INITIAL.
MESSAGE: ‘Reading in ‘‘Counter reading’‘ field is not allowed. Please enter your reading in the ‘‘Difference’‘ field.’ TYPE ‘E’.
This code first checks whether the tcode is IK11, then checks whether the Measuring document is for a Counter and then checks whether the field Counter reading entered as difference (IDIFF) is empty. If this field is empty, then it understands that the Reading is entered in the Counter reading field and throws the following error in the status bar of IK11 screen.
To prevent users from entering readings in the ‘Difference’ field of the Measuring document for ‘M’ category of the MPts.
IF sy–tcode = ‘IK11’ AND impt_data–mptyp = ‘M’ AND impt_data–indct = ‘X’ AND imrg_ins–idiff IS NOTINITIAL.
MESSAGE: ‘Reading in ‘‘Difference’‘ field is not allowed. Please enter your reading in the ‘‘Counter reading’‘ field.’ TYPE ‘E’.
This throws an error in the status bar the moment someone enters a reading in the Difference field and hits Enter (for ‘M’ category of measuring points)
To prevent creating of a MDoc of a particular MPt, in case the difference between previous reading and current reading is more than a value say 20,000.
DATA: l_readg TYPE imrg–readg,
l_point TYPE imrg–point,
l_prvrdg TYPE imrg–readg,
l_diff TYPE imrg–readg.
CLEAR: l_readg, l_point, l_prvrdg, l_diff.“wains
l_point = imrg_ins–point.
l_readg = imrg_ins–readg * 1000.
SELECT SINGLE readg FROM imrg INTO l_prvrdg WHERE point = imrg_ins–point.
l_diff = l_readg – l_prvrdg.
IF l_diff < 0.
l_diff = – l_diff.
IF l_point = ‘000000000500’ AND l_diff > ‘20000’.
MESSAGE: ‘The difference between consecutive readings is more than ‘‘20000’” TYPE ‘E’DISPLAY LIKE ‘I’.
This throws the following error popup
To restrict users from entering values below or above certain limit if particular ValCode is chosen.
IF imrg_ins–codgr = ‘DEDR’ AND imrg_ins–vlcod = ‘0010’ AND imrg_ins–cancl <> ‘X’.
IF imrg_ins–readg < 3.
MESSAGE: ‘Incorrect Reading, For the selected ValCode reading can not be less than ‘‘3’” TYPE ‘E’.
Here is the IK11 screen with the values and the error in the status bar.
To prevent users from entering same Counter reading as the last MDoc.
IF impt_data–indct = ‘X’ AND imrg_ins–cancl <> ‘X’.
DATA: old_readg TYPE imrg–cntrr.
SELECT SINGLE MAX( cntrr ) FROM imrg INTO old_readg WHERE point = impt_data–point.
IF imrg_ins–cntrr = old_readg.
MESSAGE: ‘Counter reading equal to previous reading not accepted’ TYPE ‘E’.
In this case system throws this Standard warning message first in the status bar:
Upon continuing by pressing Enter key, an error triggers in the status bar preventing MDoc creation, which is as a result of above code.
So, like these there can be many cases. But the different code samples discussed here, have the potential to address all such requirements by suitably using.
- User-exits are very effective and convenient means of having checks, by having little knowledge about ABAP syntax.
- As the author always reminds, any user-exit functions only when it is assigned to a Project created through CMOD.
- If you are not a Technical person take help of an ABAPer and test well before transporting to target Client.
Hope the forum especially EAM space will be benefited through this knowledge sharing.