How to get rid of status 55 in inbound idoc.?

[former_member599519]

I have made some enhancement to the Standard function module "IDOC_INPUT_ORDERS" to bypass some errors and process the idoc and create sales order. Of late after my enhancement i see the status 55 sometimes . How can i avoid this,.

This is not consistent, i get 51 and 53 as expected but many times this happen.

My enhancement also updates a ztable? is it because of that?

[nabheetscn]

Can you please paste your Z tables update code, are you using any commit etc for z table update?

Nabheet

[raymond_giuseppi]

Did you

• Trigger some commit in your Enhancements?
• Set a break-point during your test to check if exits such as EXIT_SAPLVEDA_004, 008 or 010 are suitable for your requirement

Could you

• Elaborate on 'bypass some errors'
• Paste some part of your code

[former_member599519]

Thanks both for the insight.

1) My enhancement does several things, When the incoming idoc has any incorrect segment , my enhancement changes that to item category 'TATX' and forces to create sales order and marks it to status 53.However not all incorrect segments are converted to text items, only line items which has incorrect material number or, legacy /sap materials not matched and few other conditions.

2) Also this tatx segments are appended to a ztable.

3) again after the sales order is created there is an update made to the ztable with key idoc number.

4) i don't use commit in my enhancement, also after appending i am emailing this entries which are appended to ztable as an attachment.

[Jelena]

Based on the comment to Raymond's answer I suspect this enhancement is not the right design in general. There are designated user exits in the IDoc processing where we can update almost any value passed in the IDoc (although if some system is consistently sending wrong data usually it's a good idea to ask them to fix the root cause). The item category update can be done in those user exits.

Z table update should be done in a sales order user exit (see MV45AFZZ) and most likely needs to be put in an update function. Email can be an output from the sales order, in this way you'll know data is sent out only when the whole order is saved successfully.

These are all well-known and well-documented IDoc order interface enhancement options. You can even assign a custom FM to the IDoc type, if necessary. Hacking into standard FM can make future maintenance and troubleshooting difficult. (This is coming from someone who is usually stuck maintaining the consequences of very narrowminded and shortsighted past design choices.)