Soft errors/warnings are creating idocs in 51 status, and creating orders

[Former Member]

In our SAP 4.7 environment, inbound orders that encounter credit checks, materials in the wrong status, blocked customers, and several other issues that should just be warnings or messages rather than resulting in status 51 idocs, are hitting 51 error status, and they are creating orders in SAP as well (51 status idocs are still creating orders, and nuisance messages are creating 51 status idocs, and still creating orders). I assume someone made some programming changes years ago to cause this to happen. This is really polluting workflow and BD87, and customer service is duplicating orders as they process 51 status idocs through workflow, unaware that orders already created immediately regardless of the 51 status.

Can anyone point me in the direction of where I can specify what warnings or errors constitute 51 status, and where I can stop 51 status idocs from creating orders until the error is repaired?

Would it be in program RBDAPP01, or the inbound function module EDI_DATA_INCOMING?

Any help would be appreciated. Thanks!

[Clemenss]

Hi KEVIN,

you are right that is is not standard.

Take an IDoc, enter the numer it in WE19 test transaction. If you click 'standard ibound processing', a popup comes up and the configured function module for IDoc inbound processing of this Idoc is displayed. This function will return the EDIDC IDoc control record that has the status.

Check if you see any modification/userexit here, check where status is set. If not found, process WE19 in debug mode, set a watch point on EDIDC parameter of processing function. This should lead you to the point where sh.. happens.

Regards,

Clemens

[Former Member]

Clemens,

Thank you for your input. I have been troubleshooting this problem for a few days, and still have not found where the error messages are set and/or stored. We are using standard function module IDOC_INPUT_ORDERS, which is quite complex for my level of expertise. I think I looked through every INCLUDE and User Exit within the function module.

It would help me to understand where the errors would occur even if the system were working as it should.

If this were a normally operating process, how would errors be set for a situation such as a blocked material on the EDI order, which should cause the idoc to go to the 51 status? I need to figure out what determines if a specifc error code is information, error, or success (maybe a table in SAP?), and what determines if an information message causes a 51 status.

I've found a lot of information about error codes and how to resolve them, but no mention of how those errors are set.

Any advice from you or any forum member would be greatly appreciated. Thanks again.

[Clemenss]

Hi Kevin,

in the function IDOC_INPUT_ORDERS you see a LOOP AT idoc_contrl - this is the loop or processing all IDocs passed to this function. One of the PERFORMs calls FORM errorhandling.Here user exit CUSTOMER-FUNCTION '008' (EXIT_SAPL_VEDA_008) is called. Check if it is implemented by clicking on ZXVEDU10.

Next chance to change the EDIDC is EXIT_SAPL_VEDA_011, include ZXVEDU13, then EXIT_SAPL_VEDA_010, include ZXVEDU12, then EXIT_SAPL_VEDA_0003, include ZXVEDU05, then EXIT_SAPL_VEDA_004, include ZXVEDU06, then EXIT_SAPL_VEDA_005, include ZXVEDU07.

Please let me know if any of these includes exist.

You can also put a break point on command MESSAGE, but that can be exhausting.

Regards

Clemens

[Former Member]

Thanks for your suggestions.

The only user exit that seems to be active is EXIT_SAPL_VEDA_004, include ZXVEDU06, which contains some logic to put a pricing delivery block on orders from a specific customer if pricing doesn't match our system. Everything seems to be specific to just one customer. The other user exits appear to be unused.

[Clemenss]

Hi Kevin,

so then it is time to check it out in WE19 debug mode. After each PERFORM in the EDIDC Loop in the FM IDOC_INPUT_ORDERS, check the control and status data, this will lead you to the point where the unexpected and/or unwanted behavior appears.

In the LOOP AT IDOC_CONTRL, in our system line 183 you find the comment fill IDOC Status. Check if field OK is not cleared here. If OK is set although you should have errors, then it's already too late.

But please double-check EXIT_SAPL_VEDA_004 if it changes the tables parameter didoc_status = idoc_status.

What I did not mention yet as I think you are talking only about IDoc not about online processing, applies to both:

Customizing SPRO, SAP Reference IMG, Sales and Distribution -> Sales -> Sales Documents -> Define variable messages:

Here you may have entries for application area V4, Sales messages (variable messages and EDI messages). Check if you find suspicious messages set to 'W' here.

If this is the case and table logging is switched on as it should be, you can use menu uitilities -> change logs to find out who changed what when.

Good luck!

Regards

Clemens

[Clemenss]

Hi KEVIN,

what did you find out meanwhile?

Regards,

Clemens

[paul_quinn]

hi Kevin,

Status 51 and saved orders should never happen

i think there's a COMMIT WORK in the EDI userexits or the sales userexits MV45AFZZ/A/B

search all the relevant code for commit work

if somehow a bapi was called in the userexits, bapi_transaction_commit would also cause the issue.

If you have an idoc you can test with it, you should be able to find any commit statements by putting a breakpoint looking for the commit statement when you call transaction va01 via the inbound function module (e.g idoc_input_orders)

See SAP note 380603 which tells you how to use SDJEDI - essential for troubleshooting

hope this helps

Paul Quinn

[Former Member]

This troubleshooting has stalled because the problem is no longer occuring. It was an issue for about a year, until I arrived at this company and was assigned the task of fixing it, and the problem abruptly stopped. Without being able to reproduce the problem, I am unable to troubleshoot it. I have searched all CTSs done by our programmers to see if another change may have fixed this, but found nothing that seems to apply. Although it's good to have the problem apparently resolved, it is frustrating to have never found the problem. I've learned a great deal about ABAP and debug, and I greatly appreciate all your support. I will also study the suggestions that Paul added, because I think these tools will be useful in the future.

I'm going to mark this ticket as Answered because I feel there is enough detail here to lead me to a solution.

Thanks for everyone's help. These forums have been a lifesaver for me.