01-13-2011 4:04 AM
Hello All,
I am getting system dump due to "DYNPRO_FIELD_CONVERSION". This is happening as negative sign is appearing in cumulative quantity field in VBAP and VBEP tables.
"Information on where terminated
The termination occurred in the ABAP program "SAPMV45A" in
"VBEP-EDATU_AUSGEBEN".
The main program was "SAPMV45A ".
The termination occurred in line 13 of the source code of the (Include)
program "MV45AOEP_VBEP-EDATU_AUSGEBEN"
of the source code of program "MV45AOEP_VBEP-EDATU_AUSGEBEN" (when calling the
editor 130)".
The Domain MENG15 for this field does not allow negative sign. Why is then negative sign appearing?
Please help me with the solution to remove the negative quantity from the field.
As a temporary solution, to stop the system dump can I put "V" at the end of the text in "Texts/I/O templates" tab? As this is a standard field I have doubt.
Please suggest.
Thanks & Regards
Sonalika
01-13-2011 1:03 PM
Is there a modification somewhere that is changing quantities? I'd like for exit coding that is erroneously generating an negative amount. How could we handle an order for negative quantities? Can't deliver a -1 to a customer. DEBUG to see why you're getting that negative value...
There is an OLD SAP Note (530212) about this, but it applies to VA03 in R/3 4.5B systems. I hope you're not still on 4.5B
Edited by: BreakPoint on Jan 13, 2011 2:08 PM
01-14-2011 3:51 AM
Hello,
Thanks for the reply.
In my case we are not getting negative delivery quantity. The required quantity and delivery quantity are appearing as postive. But the cumulative quantity field is having the negative sign.
For my project we are using a 3rd party tool for availability check. Quantity calculation happens everyday during reatp and data is sent back from 3rd party system.
Dont know exactly where the negative quantity is coming for one order item. There are thousands of line items in the order.
Only one or 2 items get such error.
Thanks & Regards
Sonalika
08-25-2011 12:05 AM
We've had this problem for years. We finally traced it back to a user exit (MV45AFZB). For us, it's caused by a strange combination of deleting or rejecting schedule lines.
Our temporary fix is to put a line in that exit that says if brgew < '0'. -> "Yell at order taker" and set weight to 0.01 which at least stops the order from crashing.