2023 Oct 02 3:50 PM
Hi all,
Isn't @DATA() used in user-exit and enhancement operations?
It works on normal code screens.
Does anyone know the answer? Does anyone have any ideas as to why this is the case?
Thanks.
2023 Oct 02 4:03 PM
As the "standard" main program doesn't include the "fixed point arithmetic" flag, some statement options are forbidden.
You can try moving your code into a specific class with the flag set, and calling some of its methods from the user-exit include. (Or stick to traditional syntax).
2023 Oct 02 3:55 PM
The error is clear that it can only be used when fixed point arithmetic is activated in a program... and this is not the case for SAPMV45A.
2023 Oct 02 4:03 PM
As the "standard" main program doesn't include the "fixed point arithmetic" flag, some statement options are forbidden.
You can try moving your code into a specific class with the flag set, and calling some of its methods from the user-exit include. (Or stick to traditional syntax).
2023 Oct 03 4:43 AM
Shifting the code out of the include into its own class should be done anyway. Otherwise these exits become very cluttered and unmanageable. It's called encapsulation and modularisation!
Furthermore, everytime you change the include, the programs that use it have to be regenerated, which can become a performance issue (on import of a transport) if the include is included in many places.
2023 Oct 03 5:52 PM
yalcin.mete For information, posting twice my comment here and below your answer.
The main program of MV45AFZZ is probably SAPMV45A, so using obsolete "no fixed point arithmetic":
The main program of MV50AFZ1 is probably SAPMV50A, so using the now mandatory "fixed point arithmetic":
2023 Oct 17 9:35 AM
2023 Oct 02 7:22 PM
As already stated by the others, you must explicitly define the work area in a non-fixed-point arithmetic program:
DATA:
s_ct0253 TYPE zsd_ct0253.
SELECT SINGLE * FROM zsd_ct0253
INTO s_ct0253.
A workaround would be to create a Z class and put the code inside a static method and call it from the standard code (e.g. ZCL_SD_UTIL=>GET_CT0253(…) ). Normally this should work as well.
Another question: Why is there no WHERE condition?This doesn’t make much sense to me.
2023 Oct 03 11:56 AM
Not a static method. Better is:
new zmv45_exit_handler( )->save_document_prepare( ... ).
I've many times regretted using static methods (though they have their uses). I've never regretted using instance methods instead!
2023 Oct 03 12:57 PM
Hi matthew.billingham,
what exactly is the advantage of using instance methods?
Thanks in advance!
Best regards,
Thorsten.
2023 Oct 03 5:44 PM
matthew.billingham Better use private instantiation classes (create private) + factory methods e.g. zmv45_exit_handler=>create( )->save_document_prepare( ... ). I'm kidding. LOL.
2023 Oct 04 10:00 AM
c12b61ded10b4e18beae75c3b6218d2c Static methods make abap unit tests more difficult and generally make enhancing the functionality harder.
Note "generally". Sometimes you'll get away with it, but I've been bitten so many times by the assumption "this will never change" or "it'll only be called from here", that I go for code safety. Do it right first time and you don't have to change it. Changing a method from static to instance can be very painful - which you might have to do e.g. when you suddenly find that attribute you need is instance not static.
With the keyword NEW and chaining, it's not even more code.
Static methods have their uses, but they should be used sparingly.
2023 Oct 04 10:03 AM
sandra.rossi
I'm kidding
I'm not! But I didn't want to scare anyone. Anyway the best is: use private instantiation classes (create private) + factory methods e.g. zmv45_exit_handler=>create( )->save_document_prepare( ... ), where the factory method returns an instance with reference to an interface, not a concrete class.
c12b61ded10b4e18beae75c3b6218d2c The reason for the above is that it conforms to SOLID principles, which if followed make it much easier to make changes to software without impacting other areas.
2023 Oct 04 12:43 PM
matthew.billingham Of course, I was not kidding, I'm doing same as I said/like you 😉
2023 Oct 03 11:26 AM
Thank you very much for your answers, but isn't the naming "fixed point arithmetic" a bit strange? When "fixed point arithmetic" is mentioned, don't decimal expressions come to mind?
It also allows use of another user-exit or enhancement on the same system :
2023 Oct 03 11:50 AM
Yes, it's a misleading message and the flag is set on some module pools and not others. Take it up with SAP. It's been like this for around 30 years so I don't see them fixing it soon. Or ever.
Btw- to comment, use comment. Not answer. As it says near the answer edit box:
You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details.
2023 Oct 03 12:04 PM
thank you matthew.billingham .
I will be more careful when answering next time.
2023 Oct 03 12:57 PM
In your original question the code is part of the FORM userexit_save_document_prepare, and thus part of the main program. This second example includes code that is part of an implicit enhancement registered as part of FORM userexit_save_document, but is not technically part of the main program. The two approaches are not equivalent from a technical perspective.
2023 Oct 03 5:51 PM
The main program of MV45AFZZ is probably SAPMV45A, so using obsolete "no fixed point arithmetic":
The main program of MV50AFZ1 is probably SAPMV50A, so using the now mandatory "fixed point arithmetic":
2023 Oct 03 6:02 PM
sandra.rossi good point... I didn't notice that the OP was referring to an include from another program, so surely that would short circuit any possible error in MV50AFZ1.
2023 Oct 17 9:39 AM