ME51N User Exit

[Former Member]

Hi all,

I need to create a user exit that is able to capture the Purchase Requisition(PR) number (BANFN), document type field (BSART) and requisitioner field (AFNAM) after it is saved in ME51N. After that, the exit should call transaction 'TRIP' and assign the PR number into one of the fields there.

I have tried using enhancement MEREQ001 especially in particular EXIT_SAPMEREQ_006 and EXIT_SAPMEREQ_007.

I am able to call transaction 'TRIP' after the PR is saved with EXIT_SAPMEREQ_006 but cannot capture PR Number, etc.

With EXIT_SAPMEREQ_007, it is not fired during create PR. It is only fired when there is a Change PR.

What should I use to capture the PR number, etc after the PR Create is saved?

Please help. Thank you very much.

[christian_wohlfahrt]

Hi Kevin,

you need a different process design. As long as you are inside ME51N, you can't make a call transaction - because this is a separate logical unit of work (with own commit work). You would corrupt transaction logic of ME51N.

I havn't looked at the exits, but you need one very late (after number was fetched from number range) - probably in update task. There you can trigger your follow-on functionality, e.g. by writing change pointers.

Have a look at the following posts, to get an idea of 'how to':

Regards,

Christian

[Former Member]

Hi Christian,

Thanks for your suggestion. However, what we need is that after creating the PR in ME51N, it needs to call transaction TRIP and still allow the user to key in particulars in TRIP. Only the PR Number needs to be populated in TRIP.

What we are trying to do is actually integrating/connecting Travel Request (TRIP) with Purchase Requisition.

[christian_wohlfahrt]

Hi Kevin!

Nice idea - unfortunately you need a new (Z-) transaction for this.

If you try to combine two standard transactions, you need to have a 'coming back' without commit work / save.

It's possible and done in many standard transactions (e.g. by calling the screens directly) - it's just not possible to use call transaction inside a user exit for this.

With a call screen you might ask for additional data for travel requests. This you can use to create travel requests independently later (e.g. via change pointers).

Regards,

Christian

[Former Member]

Hi Christian,

Thank you for your input. Hmm... so does that mean that what our functional consultants are requesting is not possible to be not (or not recommended) technically?

I have noticed that my PR did not get saved after call transaction 'TRIP' unless if i return back to the PR screen. Yes, you are right.

However, I also found out that the PR got created with one particular exit, EXIT_SAPLMEREQ_004. The PR gets created before calling transaction 'TRIP' with that exit.

Hmmm... Could you check out the exit EXIT_SAPLMEREQ_004 and is it advisable to continue with this idea?

Thank you very much.

[christian_wohlfahrt]

Hi Kevin,

you found a tricky exit. It's called during unregistering of an object (so somewhere at closing the transaction).

Seems to be late enough to have already the PR. But in general it's not a good idea - in case of errors complicate (inconsistent!) situations might appear. Even if you are lucky and get this running, I don't have a good feeling about it.

Another way:

wrte a very simple program (e.g. report):

1) call transaction ME51N (only entry screen, stop at error -> user 'skips' first screen, depending how much data you provide with this call)

2) when coming back, success message with doc. number has to be catched

3) if PR was created: call transaction TRIP (again only entry screens in BDC data, stop at error, user can fill in the rest)

Then you can assign Z-transaction code and from users point of view it's just one transaction (with two times pushing save).

Regards,

Christian