ME23N, ME22N, SY-TCODE in exit and Overview Button

[andrea_galluccio2]

Hi to all,

I have a little question for all of u.

During the program, i'd like to reconstruct the stack of all programs/methods/functions called until it.(like "Overview" debug button).This because i have this problem (probably someone of u had the same in past).

I'm in a exit of a purchase order enjoy transaction - Status "display purchase order" (ME23N).

If i press "display->modify" button (the little pen), the transaction (field sy-tcode) should changed from ME23N (display) to ME22N (modify), but in the exit if i answer the sy-tcode value ( if sy-tcode = 'ME22N' ) it's always the same (ME23N) also if I in modify mode. I must execute different code if i in modify mode (ME22N) or in display mode (ME23N). But if the value of sy-tcode is always the same, i cannot do it.

So, with the overview button in debug mode i saw that 2 different methods are called : CHANGE_TO_DISPLAY and DISPLAY_TO_CHANGE. If i know during the exit which method was called before reach the exit, i could set the right tcode value. Is it right ?

So, someone of u know how to :

1. Create with instructions (probably methods) the stack of the overview programs/methods/functions called until the program run

2. Solve the problem in different manner

Thx a lot in advice

Andrea

[Former Member]

Hi,

Another way could be to find an exit to export the value of sy-tcode to ABAP/SAP Memory and then import this value in your desired exit.

Regards

[andrea_galluccio2]

Hi Shehryar Khan

seems there isn't a good exit to make this.

Each time we try to export the sy-tcode value (in other exits), the value of the sy-tcode field is always ME23N, also if i changed from "view" to "modify" mode.

Thx a lot

Andrea

[Former Member]

Hi,

If it makes sense in your case, rather than sy-tcode, see if exporting 'ME22N' statically works for you.

Regards

Message was edited by: Shehryar Khan

[andrea_galluccio2]

Hi Shehryar Khan ,

in the exit, the value of sy-tcode is ALWAYS ME23N, also if go in changed the mode.

So if i make the export instr. in the exit, i export ME23N value. Always.

Thx a lot

Andrea

[Former Member]

Hello Andrea,

The value of the sy-tcode does not change because there is no new transaction that is getting called. If you observe carefully, the ME23N and ME22N are not different transactions in the real sense of the term. They merely srve as indicators to whether the fields should be open for input or not. Both these transactions will have the same main program i.e., RM_MEPO_GUI.

Now I understand from your requirement that you want to know which action the user has performed : Display > Change or Change>Display. Is that correct? If yes, then you can couple the SY-TCODE value with the SY-UCOMM ( or OK_CODE ) value. For both the actions, the Function Code to be triggerred will be <b>METOGG</b>. So you can now easily determine what the user has just done.

I hope I'm correct in understanding your requirement. In case of any doubt, please get back.

Regards,

Anand Mandalika.

[andrea_galluccio2]

Hi Poornanand Mandalika ,

at this time, i'm just using the ok-code value , but if u think, this is not good for all cases.

Suppose that i start from a simple list (for example ME28 - Release purchase document). With a double click on line (with foward navigation) i can view the purch.order.

But what appens if i change the mode (view->modify) in the transaction?? I cannot test both sy-tcode and sy-ucomm field because the first field contains ME28 and not ME23N. There are many lists that call the ME22N/ME23N transactions. So this way to operate, could be a temp. solution.

I think that the best solution is determine which method was called before.

Anyway, thx a lot for your hint. I'll give u the right reward points

[Former Member]

Hello Andrea,

Have you checked this out? Or are you just aplying the same logic and making a deduction? )

In case you double click in ME28, the sy-tcode value will change. Please check it out and get back to me if I'm wrong. I have something else in mind too.

Regards,

Anand Mandalika.

[Former Member]

Hi,

I had a similar situation with trn FB50.The user can directly call this transaction to enter data or they can call it indirectly through FBV0, by double-clicking on a particular document. The same screen opens but now in display mode. The user then has to Edit the document. I am not an expert on debugging techniques but I think its a profiler that lists complete path of your program execution. If you evaluate that path, you may still loose track in case of branching to a subroutine or a different program for that matter.

The idea is to cater for all known situations (you explicitly set SAP/ABAP memory and then export once again after resetting it to initial value immediately after processing the block).

e.g.

IMPORT tcode FROM MEMORY ID 'tcode'.
CHECK tcode EQ 'ME22N'.
CLEAR tcode.
EXPORT tcode TO MEMORY ID 'tcode'.
...

Assuming you can go in either from ME28 or ME23N or any other trn. By setting a flag (trn code in your case), you can process your block of code as and when you need it. For all other cases, the value of SAP/ABAP memory variable tcode will be initial, so your block of code won't be executed.

Please revert back with your feedback.

Regards

[andrea_galluccio2]

Hi Poornanand Mandalika ,

you're right.

Starting from ME28 trx, the trasaction ME23N is called correctly (i mean that in the exit, the field sy-tcode contains the right value). Also, in the "calls" (during debug) i don't have the methods that could help me to understand in wich transaction i'm in.

So, my idea was not so very good ))

So we can say that we (probably) solved the problem.

To close this post, i'd like to ask if u know the fuctions(methods) used to create the "calls" stack in the debug window. I've alredy check the SAPMSSY3 program, screen 0137 (Active call stack) but that couldn't help me.

Thx a lot again

Andrea

P.s : if u want, u could tell me more about other ideas that u have in mind. Could be helpfull in future

[andrea_galluccio2]

Hi Shehryar Khan ,

thx a lot for your answer.

I understand what u said, and i think this could be another way to proceed, but in this case i'll use the hints of

Poornanand Mandalika .

Thx a lot anyway.

Andrea

[andrea_galluccio2]

Sorry guys,

but i cannot give to u the right reward points.

I have always this error.

Error Rewarding the message failed.

Il'll try again later

Thx

Andrea

[Former Member]

Hello Andrea,

Now that you have been able to solve your problem, I shall try to get into some theory.

In general, all the transactions of the type xxn1(create), xxn2(change), xxn3(display) [here, xx denotes letters and n denotes a number] will have the same main program.

Examples: VA01 - VA02 - VA03
MM01 - MM02 - MM03
XD01 - XD02 - XD03
ME21 - ME22 - ME23

and several others.

In fact, if you look at the program SAPMV45A, it has got several create-change-display transactions associated with it. Doesn't that make a lot of sense ?

A transaction is just a technical way of presenting a complete unit of some functionality. We only need to have different transactions when we have totally different screens and totally different functionalities.

Sales Order , Inquiy , Quotation , Contract etc., are all different types of Sales Documents. So the major differentiator is the TYPE. But they all have the same main program, because most of the technical presentation is the same.

I shall not elaborate further on this point. But just ask your self one question: If you were to design these transactions, would you write totally different programs and design all the (same) screens multiple times for each of the program? If that is what you choose to do, then where is the concpet of re-usability?...

=======================================================

Now consider the transactions like VA05, ME5A, ME2M, ME2L etc., the objective of these transactions is to display all the documents which satisfy a particular set of conditions. so all they need is a selection-screen. But when the user sees the list of the documents, then he might want to visit a particular document. In that case, the corresponding display transaction <u>is called.</u>. The user finishes his checking and comes back to the list from where he can choose to display some other document.

=======================================================

Now what I wanted to say to you is that even if you had found that the transaction code in the above case is ME28 instead of ME23N (which is obviously not a possibility , for reasons explained above) the main program for the particular screen can not change. So I would have asked yo to try out checking the values of <b>sy-cprog</b> and <b>sy-repid</b>.

Hope this explanation has helped you understand some of the basic principles of SAP's way of reusability and that it would enable you to do a better diagnosis in case of such situations in the future.

Regards,

Anand Mandalika.

[andrea_galluccio2]

Sorry,

the right debug button that show the program calls (methods/functios/programs/Forms)is "Calls" and not "Overview" like wrote in before post.

Thx a lot

Andrea