‎2007 Jun 18 4:52 PM
Hey guys,
I have a situation here... I tried searching the forum i could not really
find anything...
We have an incommin SALESORDER_CREATEFROMDAT2 IDOC which has 10 line items .
1 out of the 10 items fail, The sales order is created with the 9 line items..
Now when the error for the single line item is fixed, and the batch process reprocesses the IDOC we have a new SO with all 10 items and 9 items repeated. So we have double sales order for 9 items.
Now we handle the inbound IDOC using BAPI_IDOC_INPUT1, the standard process.
The IDOC status is 51 - but the document is still created.
I am not really sure what we are missing at this point of time, when the IDOC is reprocessed how do we know that it is a change to and existing sales order which had one line item failed.
any ideas... my words could be a little incoherrent here... please let me know if you guys need more information...
Message was edited by:
Abhishek Dhoundiyal
‎2007 Jun 18 11:26 PM
Abhishek,
I will suggest you one thing. First, check which inbound process code/inbound function module you are using. And after that, inside the inbound function module, you will find some customer exits. So, if you know what is the validation because of which the Item is getting errored out, perform you validation inside that customer exit and change the status of the IDoc to error so that it cannot be processed. For, example, if u r using the process code ORDE (Inbound fn module IDOC_INPUT_ORDERS), you are having few customer exits EXIT_SAPLVEDA_011, EXIT_SAPLVEDA_010, etc. I think this would be the best way in order to handle your scenario.
Thanks,
Adithya K
askSAP@googlegroups.com
Note: Dont forget to reward points if it is useful.
‎2007 Jun 18 7:06 PM
Hello Abhishek,
<b>1 out of the 10 items fail, The sales order is created with the 9 line items..</b> - is it one item created or 9 items created ? did you use any user exit within program ?
‎2007 Jun 18 8:23 PM
9 items were created , Only user exit that is in use for sales order creation is MV45afzz. besides tht there is no other user exit being used...
‎2007 Jun 18 11:26 PM
Abhishek,
I will suggest you one thing. First, check which inbound process code/inbound function module you are using. And after that, inside the inbound function module, you will find some customer exits. So, if you know what is the validation because of which the Item is getting errored out, perform you validation inside that customer exit and change the status of the IDoc to error so that it cannot be processed. For, example, if u r using the process code ORDE (Inbound fn module IDOC_INPUT_ORDERS), you are having few customer exits EXIT_SAPLVEDA_011, EXIT_SAPLVEDA_010, etc. I think this would be the best way in order to handle your scenario.
Thanks,
Adithya K
askSAP@googlegroups.com
Note: Dont forget to reward points if it is useful.
‎2007 Jun 20 8:08 PM
There can be many validations that SAP performs, so i can not really simulate all of them before hand.
What i really wanted to know was... how is it handled by other business scenarios.. i am sure i am not the only one facing this
‎2007 Jun 19 5:31 AM
Hi,
If you create a sales order with SALESORDER_CREATEFROMDAT2 , you will get <b>a warning message</b> in its return table specifying that a particular sales orders already exists and it also gives the existing sales order.
<b>If you are creating the sales order:</b>
Try to check the orders for errors before creatting the sales order:
1)For each record in the dataset, check for the corresponding record in the materials database using 'BAPI_MATERIAL_GET_DETAIL'
2)Check that the customer record for the sold-to exists in SAP
'BAPI_CUSTOMER_GETDETAIL2'
3)Order key should be unique within the same invoice date:
check that no other order exists in the database with the same exact key
'BAPI_SALESORDER_GETLIST'
Else try to get the return table and analyse its messages
Regards,
Sooness
‎2007 Jun 20 8:12 PM
Hi ,
So in short there is no standard way of handling this issue..
I was wondering how other ppl who have implemented this have handled this...
Thanks