Locking problem when calling FM in background OR destination NONE....

[Former Member]

Hi,

I've made a RF transaction to handle some movements from one Storage Unit to another one by creating a TO using standard FM L_TO_CREATE_SINGLE - so far, so good.

My problem is that this FM makes a lot of standard checks (which is fine!) and if any of them fails - it issues a message, although I certainly don't want any message to be issued in this RF screen other than the ones that can be displayed on another screen.

In order to avoid those annoying on-line messages I've tried to call the function in background, and even with DESTINATION 'NONE' - and here it is doing fine regarding the message handling (it is handled by the sy-subrc handler after the FM call) BUT now I'm having an even more annoying problem -> a lock is created (on tables LQUAX and VEKP) which I can't get rid of!!! (unless deleting manually the lock in SM12.......)

Anyone experienced this by performing L_TO_CREATE_SINGLE in background mode or DESTINATION 'NONE' ?

A check whether the TO is succesfully created or not is important, as after the TO creation I'm creating an Idoc (via L_SUB_INITIATION_FOR_PICK_HU) for that TO.

Any ideas?

Message was edited by:

Branko Jovanovic

[Former Member]

Hi,

I've made a RF transaction to handle some movements from one Storage Unit to another one by creating a TO using standard FM L_TO_CREATE_SINGLE - so far, so good.

My problem is that this FM makes a lot of standard checks (which is fine!) and if any of them fails - it issues a message, although I certainly don't want any message to be issued in this RF screen other than the ones that can be displayed on another screen.

In order to avoid those annoying on-line messages I've tried to call the function in background, and even with DESTINATION 'NONE' - and here it is doing fine regarding the message handling (it is handled by the sy-subrc handler after the FM call) BUT now I'm having an even more annoying problem -> a lock is created (on tables LQUAX and VEKP) which I can't get rid of!!! (unless deleting manually the lock in SM12.......)

Anyone experienced this by performing L_TO_CREATE_SINGLE in background mode or DESTINATION 'NONE' ?

A check whether the TO is succesfully created or not is important, as after the TO creation I'm creating an Idoc (via L_SUB_INITIATION_FOR_PICK_HU) for that TO.

Any ideas?

Message was edited by:

Branko Jovanovic

[Former Member]

what u do...after everything gets well use UNLOCK fm to unlock the tables...

Try using

BDL_UNLOCK_BDL2TRANS_TABLES

RTP_US_API_UNLOCK

TXW_TEMP_STORAGE_UNLOCK

Message was edited by:

Ramesh Babu Chirumamilla

[Former Member]

Thanks Ramesh, but strangely this lock occurs each time the FM is performed in background - as if the FM was locking itself in background mode. And this makes it of course impossible to use any unlock mechanism after the FM call as it's out of my reach. Moreover, I prefer to avoid to m'anually' unlock some standard FM's locks, but I'd rather use a way to have a better control of the background processing of this FM. ....or calling the FM in foreground but having full control of them ^*%&@# messages!

[Former Member]

L_TO_CREATE_SINGLE has a parameter, I_COMMIT_WORK. Set that parameter to 'X' and see if the problem persists.

Regards,

ravi

[Former Member]

Yes, I've tried with I_COMMIT_WORK parameter when using BACKGROUND MODE, but then my TO isn't created at all! ....

[Former Member]

Hi,

When creating TO in backgroud you shoukd have the parameter I_update_task set and as for messages are concerned, capture them and display in standard RF message using FM 'CALL_MESSAGE_SCREEN'.

regards,

Suri.

[Former Member]

We had locking issues during TO confirmation. Is the TO immediately confirmed during creation?

Make a call the function module. 'DEQUEUE_ALL'. This will release the locks.

Manoj

[Former Member]

Maybe you can try to call this function module with the extra exception error_message. Using this exception will only issue error messages to your user. Warning and information messages will be ignored.

Message was edited by:

Arnold Mostert

[Former Member]

Indeed, this solved my problem:

CALL FUNCTION 'L_TO_CREATE_SINGLE'

EXPORTING

i_lgnum = whs_id

i_bwlvs = ltak-bwlvs

i_matnr = wa_lqua-matnr

i_werks = wa_lqua-werks

i_lgort = wa_lqua-lgort

i_charg = wa_lqua-charg

i_anfme = rl03t-anfme

i_altme = ltap-altme

i_vltyp = ltap-vltyp

i_vlpla = l_vlpla

i_vlenr = ltap-vlenr

i_nltyp = ltap-nltyp

i_nlpla = l_nlpla

i_nlenr = ltap-nlenr

i_update_task = c_true

i_commit_work = c_true

IMPORTING

e_tanum = g_tanum

e_ltap = itab_ltap

TABLES

t_ltak = itab_ltak_vb

t_ltap_vb = itab_ltap_vb

EXCEPTIONS

<b> error_message = 01 "Shows errors if this is commented</b>

no_to_created = 1

bwlvs_wrong = 2

betyp_wrong = 3

benum_missing = 4

betyp_missing = 5

foreign_lock = 6

vltyp_wrong = 7

vlpla_wrong = 8

vltyp_missing = 9

nltyp_wrong = 10

nlpla_wrong = 11

nltyp_missing = 12

rltyp_wrong = 13

rlpla_wrong = 14

rltyp_missing = 15

squit_forbidden = 16

manual_to_forbidden = 17

letyp_wrong = 18

vlpla_missing = 19

nlpla_missing = 20

sobkz_wrong = 21

sobkz_missing = 22

sonum_missing = 23

bestq_wrong = 24

lgber_wrong = 25

xfeld_wrong = 26

date_wrong = 27

drukz_wrong = 28

ldest_wrong = 29

update_without_commit = 30

no_authority = 31

material_not_found = 32

lenum_wrong = 33

OTHERS = 34.

IF sy-subrc NE 0.

MOVE sy-subrc TO g_rc.

message_id = sy-msgid.

message_number = sy-msgno.

message_var1 = sy-msgv1.

message_var2 = sy-msgv2.

message_var3 = sy-msgv3.

message_var4 = sy-msgv4.

PERFORM error_message.

ENDIF.

So I'll reward Arnold eventhough I got the answer earlier .....

Cheers!

[Former Member]

Hi,

I am having a problem with the FM L_TO_CREATE_SINGLE. After passing all parameters TO is creating, but when you check the Transfer Order, it wat not reflecting Material document number.

Can you please tell me what are all the values you are passing to TABLES parameters T_LTAK and T_LTAP_VB.?

If possible can you pls send me the block of code. my personnel ID is [email protected].

Thanks in advance.

Regards,

Nanda.