2010 Jul 13 8:19 PM
Hi,
I am implementing the BADI interface IF_EX_LE_SHP_DELIVERY_PROC and coding the save_document_prepare method in which I check the delivery qty and some additional checks and even if one of the line items of the order fails I do not want delivery to be created for other line items too. In short, if the order has 5 line items and 3 fail then no delivery for rest of the 4 line items too.
In order to achieve this, I clear the ct_xlikp and ct_xlips internal tables accordingly. Sometimes they become totally blank, sometimes they are partially blank. But in both the cases, after this code is executed and when the standard code is processed I get dumps sometimes.
My latest dump was ' SAPSQL_ARRAY_INSERT_DUPREC' as detailed below..
My question is clearing these internal tables the right approach in my case ? or is there any deletion indicator or something that I can set in the records in these tables by which SAP will not take these into consideration for delivery ?
Pl advise.
thnks
-
Termination occurred in the ABAP program "SAPLV05I" - in "SD_PARTNER_UPDATE".
The main program was "RVV50R10C ".
In the source code you have the termination point in line 480
of the (Include) program "LV05IU15".
The termination is caused because exception "CX_SY_OPEN_SQL_DB" occurred in
procedure "SD_PARTNER_UPDATE" "(FUNCTION)", but it was neither handled locall
nor declared
in the RAISING clause of its signature.
The procedure is in program "SAPLV05I "; its source code begins in line
1 of the (Include program "LV05IU15 ".
2010 Jul 13 8:28 PM
If you're getting duplicate database key values from Partner Update, looks like the problem is somewhere other than LIKP, LIPS! I don't recall whether or not XLIPS, etc., has a UPDKZ field...check on that for I, U, D codes for insert, update, delete. There is at least one SAP Note about proper coding of delivery exits; it's done quite a bit differently from SD Order exits, and is worth reading if you can look it up.
If you're getting duplicate database key values from Partner Update, looks like the problem is somewhere other than LIKP, LIPS! I don't recall whether or not XLIPS, etc., has a UPDKZ field...check on that for I, U, D codes for insert, update, delete. There is at least one SAP Note about proper coding of delivery exits; it's done quite a bit differently from SD Order exits, and is worth reading if you can look it up.
2010 Jul 13 8:28 PM
If you're getting duplicate database key values from Partner Update, looks like the problem is somewhere other than LIKP, LIPS! I don't recall whether or not XLIPS, etc., has a UPDKZ field...check on that for I, U, D codes for insert, update, delete. There is at least one SAP Note about proper coding of delivery exits; it's done quite a bit differently from SD Order exits, and is worth reading if you can look it up.
2010 Jul 13 8:42 PM
Thanks I will look into that. Meanwhile I noticed that this method has other internal tables too like VBPA, VBUK, VBUP related and an inconsistency occurs when I delete the LIKP, LIPS and do not delete in these tables. Hence now the dumpt at VBPA is resolved but I get at VBUK level !!!
So may be clearing the tables here is not a very good idea. Let me see if I can find the OSS note.
thanks
2010 Jul 13 9:16 PM
You should control delivery creation with copy control requirements. If an item level check fails, you issue an error message to the log and the delivery does not get created. Don't use backend user exits to control something like this...
2010 Jul 19 6:35 PM
In my case I had to use the delivery user exit and I resolved this issue but updating UPDKZ as 'D' only in Lips table and left it as 'I' in LIKP table...This way, SAP did not dump..
2010 Jul 13 9:10 PM
This may be solved with the help of configuration. May be it is not taking the next available document number in the number range.
| User | Count |
|---|---|
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |