wir arbeiten bei der Materialstammanlage mit der externen Nummernvergabe.
Die Materialnummern werden dann nach einer eigenen Logik über das Userexit EXIT_SAPLMG02_002 (ZXMG0U04) ermittelt.
Damit das Userexit durchlaufen wird, muss der Benutzer aber eine Materialnummer eingeben, die dann in eine "richtige" Materialnummer umgewandelt wird.
Bei uns ist das die Materialnummer 0, die es so nicht gibt.
Jetzt mein Problem, solange ein Benutzer ein Material anlegt, sperrt das System die Materialnummer 0 (obwohl die ja garnicht verwendet werden soll).
Meine Idee hierzu war, im Userexit die Materialnummer 0 direkt wieder zu entsperren.
Dazu habe ich mehrere Versuche in der Art
lv_varkey = sy-mandt.
lv_varkey+3 = '4000000000000000000000000000000000000000000'.
*unlocking table
call function 'DEQUEUE_E_TABLE'
exporting
* MODE_RSTABLE = 'E'
tabname = 'MATNR_LOCK_INT'
varkey = lv_varkey
* X_TABNAME = ' '
* X_VARKEY = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
lv_varkey = sy-mandt.
lv_varkey+3 = '000000000000000000'.
*unlocking table
call function 'DEQUEUE_E_TABLE'
exporting
* MODE_RSTABLE = 'E'
tabname = 'MATNR_LOCK'
varkey = lv_varkey
* X_TABNAME = ' '
* X_VARKEY = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
CALL FUNCTION 'DEQUEUE_EMMARAS'
EXPORTING
MODE_MARA = 'S'
MANDT = SY-MANDT
MATNR = matnr
* X_MATNR = ' '
* _SCOPE = '3'
* _SYNCHRON = ' '
* _COLLECT = ' '
.
aber die Sperre bleibt auf der Tabelle MATNR_LOCK und MATNR_LOCK_INT bestehen .