topic Re: Issue with passing decimal values in ABAP Code in Application Development and Automation Discussions

Issue with passing decimal values in ABAP Code

Former Member — Thu, 28 Jun 2012 13:12:27 GMT

Hello Experts,

I am facing a strange issue in one of my developments.

I am trying to pass a decimal value stored in a variable (let's say variable 'A') to another Type 'P' variable (let's say variable 'B').

I am doing this inside the Sales User exit - USEREXIT_SAVE_DOCUMENT_PREPARE inside the include MV45AFZZ.

Variable 'A' has been declared in the ABAP dictionary as a Decimal of length '5' and decimal places '2'.

Variable 'B' refers to the data element KWMENG (quantity), which is of length '15' and decimal places '3'.

When I pass a value of '24.00' from 'A' to 'B', it gets converted to '2.40'.

If I was initially surprised to find this, I got even more surprised when I wrote a random test program with similar variables declared.

I found that the value got passed fine in the test program, with no change of data, except for the additional decimal place getting added, of course.

I have attached snapshots of these 2 scenarios from the ABAP debug screen.

Have any of you faced a similar issue earlier, and if so, can you please enlighten me about what I might be doing wrong?

Thanks in advance.

Regards,

Keerthi

Re: Issue with passing decimal values in ABAP Code

SuhaSaha — Thu, 28 Jun 2012 13:24:36 GMT

Hello Keerthi,

The perennial problem of developers overlooking the units for currency/quantity fields

Is the field ls_block_temp-tgt_doh a currency/quantity field? If yes, then what is the value in the corres. reference field?

Did you check the reference field VRKME - what is UoM?

: Nice observation

BR,

Suhas

Message was edited by: Suhas Saha

Re: Issue with passing decimal values in ABAP Code

Ruediger_Plantiko — Thu, 28 Jun 2012 13:26:08 GMT

Hi Keerthi,

in the userexits of MV45AFZZ, you belong to the main program SAPMV45A. The fixed-point arithmetic is switched off in the properties of SAPMV45A (like in many others of the 'classical' ABAP programs of the ERP core).

This explains the difference you observed. In your MV45AFZZ example, the variable 24.00 is considered as 2400, which, by moving to the quantity field, gives 2.400

Regards,

Rüdiger

P.S.: This, by the way, is another argument to use the exits of SD only as exit points and to jump into custom classes or function groups immediately from there. It is worth the effort to pass the necessary tables like XVBAP etc. through the signature of your custom methods.

Re: Issue with passing decimal values in ABAP Code

Former Member — Thu, 28 Jun 2012 14:25:37 GMT

They are indeed Quantity fields, but I have already checked the corresponding reference fields/tables.

I have in fact maintained them the same way the Cumulative Order quantity field (VBAP-KWMENG) is maintained in VBAP.

For me, Rudiger's point makes more sense. I say this because trust me when I say I have played around with quite a lot of permutations and combinations of data types for these variables, with the exact same result every single time.

So the way I read it, the best way for me to do any such quantity based calculations should be inside a custom Function Module / Method - Rudiger please correct me if I have got it wrong.

Regards,

Keerthi

Re: Issue with passing decimal values in ABAP Code

Ruediger_Plantiko — Thu, 28 Jun 2012 15:28:44 GMT

Hi Keerthi,

yeah, that's precisely what I would recommend:

Use the "old" customer exits - which are only "perform" calls in the standard SD processing logic - only as a hook for calling your own code. The best would be to directly call a custom method or function module.

The advantage of the form routines is that you have all the globals of SAPMV45A at your hands. But the price is that you depend on the main program, leading to strange behaviour like the one you observed.

It is good, also for testing, to design your methods with the necessary data in their interface(signature). You can then write your own module tests for your own code, by emulating some interface data for test calls. Also, you could provide a switch to deactivate your exits, in order to prove that some strange behaviour of the order processing is not caused by your modifications (in simple cases, it will suffice to comment-out the call temporarily for such kind of proofs).

When you create a new program or function module, the flag "fixed-point" arithmetics will be automatically switched on. But the old module pools like SAPMV45A have it switched off, as you can see in the "properties" screen of the editor. See the F1 help of this flag for further documentation.

Regards,

Rüdiger