We have a requirement to automatically generate the notification number for specific notification types based on certain logic that depends on the notification data which standard number ranges cannot cover. This mechanism (number generation) will be used in several places (e.g. IW21, interface, etc..). The problem is not in implementing the number ranges logic, but rather in getting it to be used in IW21 and all other required place. I have two questions:
- Should the number range of these notification types be internal or external? I believe it should be internal. Otherwise, user needs to input the notification number which we should be generating! Unless there is something I am missing
- Which enhancement spot or BAdi, if any, should be used to trigger this number range to be used? I can overwrite the notification number in NOTIF_EVENT_SAVE but the system message that comes after saving in IW21 does not show me the number I generated, but it shows the number system generated according to the standard number ranges Clarification: although in QMEL the number I generated is used and not the system generated one.
Edited by: Sayied on May 2, 2010 11:59 AM
I am thinking of keeping the number range internal for these notification types ( as dummy number range ) and then enhance GEN_NOTIFICATION_NUMBER to override the number generation of these notification types with the required logic.
I am little skeptical about doing this. Any advice if I should do it this way or not?
Some rather unqualified comments as I haven't thought much about it or tested. When I read your post I was convinced that there was a customer exit for number assignment, but I couldn't find it, so my memory probably deceived me.
In general I'd try to go for an external number range, because otherwise you have useless functionality for assigning internal numbers that are then overwritten. However, I can see that it might be tricky to get this working (but should be possible in theory, possibly by assigning some temporary dummy number up-front that is later overwritten).
Anyhow, I think there's one setting that you might want to take a look at on customizing side: You can define per notification type to use early number allocation, which means the number is assigned early on in the transaction. This is often used for example in service notifications that are created in a call center with the customer online, because then you can immediately give the customer a reference number (and don't have to wait for the save).
I quickly tested creating a service notification of type S1 via IW51 with internal number range assignment (and early number allocation) and overwrote the service notification number in customer exit EXIT_SAPLIQS0_017 (enhancement QQMA0025). On the notification screen I immediately saw the correct number and furthermore upon saving the message showed the correct notification number (and parameter ID was set also correct).
So my advice would be to try to utilize standard exit functionality and only use implicit enhancements if you don't find anything else. If possible, use external number range; otherwise you probably should activate in customizing the early number allocation to give you more chances for updating the number.
Thanks Harald for you thoughts... really helpful.
But this will not solve my problem since the early allocation will take place before the user starts manipulating the notification data which I depend on when generating the number. For example, let's assume that I have a Z field that the user select a value from. This value will be used in the number generation logic.
But this will not solve my problem since the early allocation will take place before the user starts manipulating the notification data which I depend on when generating the number.
Well, the early number allocation gives you more freedom to manipulate the number should you choose to work with internal number assignment. Without the early allocation you'd be forced to plug your coding after the retrieval of a new internal number and per your posting I understood that you achieved this, but had problems with the reported number (message statement)...
Thus I still think that early number allocation is a feature that could be useful for you. Based on your comments I was pretty sure that the exit I gave was inappropriate, I just used it as a quick test for manipulating the number fairly early.
The problem with this solution is that it takes place early while I need it to take place late \[..\]
Understood. However, basically your approach with using an internal number range means that you'll have to overwrite the assigned number at the right time. The later the number is assigned, the less choices you have for manipulating the number. Anyhow, that's why in general I'd prefer an external number range (but there you'd run into the problem that early on you'd probably have to generate a dummy number)...
Let me try to give a more concrete example to show what I mean. Activate enhancement QQMA0014 and put a breakpoint at the end of customer exit EXIT_SAPMIWO0_020 (QM/PM/SM: Checks before saving a notification) . Then do the following:
<li>Start transaction IW21 and create notification for order type M2 (this should have early number allocation, but please validate)</li>
<li>Enter all required data and then save.</li>
<li>In the ABAP debugger overwrite E_VIQMEL-QMNUM once the breakpoint in EXIT_SAPMIWO0_020 triggers.</li>
You'll see that you get a message with the notification number that you set in debugging and this number was used on the database as well. If you then repeat the exercise for notification type M1 (no early number allocation, but again, please check) you'll see that a generated internal number is used (because the number was actually generated after we changed it in the customer exit).
I hope this is clarifies what I was trying to say earlier.