Here's one for you.
I have a number delivered in a text file as a packed number of length 13 with 2 decimal places.
0000000627909
so in reality it represents the following number 6279.09.
Now in the old world there was this beautiful ABAP sentence...
PACK packed_number TO number_with_decimal_type
...unfortunately this is not allowed in OO context and marked as obsolete with a comment that a normal assignment does the same. Well, it does not... at least not where there are decimal places to be concerned.
Here is an example:
REPORT zzpj_unpack_test.
DATA:
BEGIN OF gs_structured,
loan_entitlement TYPE c LENGTH 13,
END OF gs_structured.
DATA: gv_packed TYPE p LENGTH 13 DECIMALS 2.
INITIALIZATION.
gs_structured = VALUE #(
loan_entitlement = '0000000627909'
).
DATA(gs_dc) = CORRESPONDING /ibs/sbsc_change_main( gs_structured ).
PACK gs_structured-loan_entitlement TO gv_packed. "works beautifilly!
gv_packed = gs_structured-loan_entitlement. "does not care about decimal places
CLASS lcl_main DEFINITION FINAL CREATE PRIVATE.
PUBLIC SECTION.
CLASS-METHODS:
main.
ENDCLASS.
CLASS lcl_main IMPLEMENTATION.
METHOD main.
DATA ls_structured LIKE gs_structured.
DATA lv_packed TYPE p LENGTH 13 DECIMALS 2.
ls_structured = VALUE #(
loan_entitlement = '0000000627909'
).
"PACK gs_structured-loan_entitlement TO gv_packed. "does not work in OO context
lv_packed = ls_structured-loan_entitlement. "does not care about decimal places
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
lcl_main=>main( ).
A simple assignment makes 627909.00 out of what should be 6279.09.
So my question is: what is the real equivalent of PACK sentence in OO context?
You may make ABAP believe that your packed number has 0 decimals although it hasn't, via ASSIGN gv_packed TO <p> DECIMALS 0.:
CLASS lcl_app DEFINITION.
PUBLIC SECTION.
CLASS-METHODS simulate_pack.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
METHOD simulate_pack. "<=== simulate PACK
DATA: gv_packed TYPE p LENGTH 13 DECIMALS 2.
FIELD-SYMBOLS <dec> TYPE p.
ASSIGN gv_packed TO <dec> CASTING DECIMALS 0. "<=== <dec> points to GV_PACKED memory
<dec> = '0000000627909'. "<=== assigns the value to GV_PACKED !
" Check Actual values = Expected values
ASSERT <dec> = 627909.
ASSERT gv_packed = '6279.09'.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
lcl_app=>simulate_pack( ).
DATA: gv_packed TYPE p LENGTH 13 DECIMALS 2.
PACK '0000000627909' TO gv_packed. "<=== use PACK
" Check Actual value = Expected value
ASSERT gv_packed = '6279.09'.
The accepted answer is very clever, although I will post my own solution as well.
I just created a simple function module that does the work as the PACK sentence is allowed in its context. Then I use such a function module in methods of my classes, which is (still :) ) possible.
FUNCTION Z_PACK_NUMBER.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" REFERENCE(IV_PACKED_NUMBER) TYPE C
*" EXPORTING
*" REFERENCE(EV_VALUE) TYPE P
*"----------------------------------------------------------------------
PACK iv_packed_number TO ev_value.
ENDFUNCTION.
Related
I know when I need to pass an internal table to a subroutine, I need to declare a type so I can use it in the FORM statement.
What happens if the internal table is an inline declaration table from a SELECT statement like this:
SELECT * FROM KNA1 INTO TABLE #DATA(LT_KNA1)
Is there any way to pass this table to a subroutine?
Thank you.
The subroutines are obsolete since ABAP 7.02 (2009), so I use a method in my example.
Inline declarations are an easy way of declaring types implicitly, but the limit of this solution is that you can type the parameter of a method only generically (types STANDARD TABLE, INDEX TABLE, ANY TABLE, ANY) which prevents you from stating the component names statically in your code.
But inline declarations of type DATA(...) are always based on a complete "bound" data type, so you can declare the type explicitly with TYPES and use it to type both your parameter and your data object.
If you use the ABAP Development Tools (Eclipse), you may use the Quick Fix "Declare local variable ... explicitly" to simplify the task:
which gives this code:
REPORT.
CLASS lcl_app DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
METHOD main.
TYPES: BEGIN OF helper_type, " <=== automatically generated
carrid TYPE scarr-carrid,
carrname TYPE scarr-carrname,
END OF helper_type.
DATA: lt_scarr TYPE STANDARD TABLE OF helper_type. " <=== automatically generated
SELECT carrid, carrname FROM scarr
INTO TABLE #lt_scarr. " <=== automatically changed
ENDMETHOD.
ENDCLASS.
Now, declare manually the table type, use it to type a parameter of a method (a new one here):
REPORT.
CLASS lcl_app DEFINITION.
PUBLIC SECTION.
TYPES: BEGIN OF helper_type,
carrid TYPE scarr-carrid,
carrname TYPE scarr-carrname,
END OF helper_type.
TYPES: tt_scarr TYPE STANDARD TABLE OF helper_type. " <=== declare the type
CLASS-METHODS main.
CLASS-METHODS process_table " <=== new method with this type
IMPORTING table TYPE tt_scarr.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
METHOD main.
DATA: lt_scarr TYPE STANDARD TABLE OF helper_type.
SELECT carrid, carrname FROM scarr
INTO TABLE #lt_scarr.
ENDMETHOD.
METHOD process_table. " <=== new method
LOOP AT table REFERENCE INTO DATA(line).
DATA(carrid) = line->carrid.
ENDLOOP.
ENDMETHOD.
ENDCLASS.
Use TYPE ANY or generic table type for parameters, TABLE parameters are obsolete:
FORM fill_table USING tab TYPE any
CHANGING ptab TYPE INDEX TABLE.
APPEND LINES OF tab TO ptab.
ENDFORM.
And yes, subroutines are obsolete themselves, use them only if you absolutely must do this, e.g. in legacy environment.
You don't need to indicate structure type for perform variable table. But you can get error on runtime if any field name change which are used in perform. Two working example below.
SELECT * FROM kna1 INTO TABLE #DATA(lt_kna1).
PERFORM test TABLES lt_kna1.
FORM test TABLES pt_kna1 STRUCTURE kna1.
*
ENDFORM.
Risky one:
FORM test TABLES pt_kna1.
*
ENDFORM.
So I need to use the INCLUDES rpcblo00 and rpcbdt00 to get the type of infotype change (create, update, delete). Beforehand I used a subroutine that had no problem with the includes, but I cannot get them into a class for the life of me.
If I try to put the include into the method as described here (it's even about the same HR include), I get the following error (because of the minus in lo-key):
Syntax error: Names may only consist of the characters "A-Z", "0-9"
and "_". In addition, they may not begin with a number.
minimal reproducible example:
CLASS lcl_infotypaenderungen DEFINITION.
PUBLIC SECTION.
TYPES: tty_aenderungs_operationen TYPE STANDARD TABLE OF pc403.
METHODS:
constructor
IMPORTING is_aenderungs_kopf TYPE pldoc_key,
get_aenderungs_operationen
RETURNING value(rt_aenderungs_operationen) TYPE tty_aenderungs_operationen.
PRIVATE SECTION.
DATA: s_aenderungs_kopf TYPE pldoc_key,
t_aenderungs_operationen TYPE tty_aenderungs_operationen.
METHODS:
select_aenderungs_operationen.
ENDCLASS. "lcl_infotypaenderungen DEFINITION
*----------------------------------------------------------------------*
TYPE-POOLS: abap.
DATA: lo_infotypaenderungen TYPE REF TO lcl_infotypaenderungen,
lv_fehler TYPE sy-subrc,
lt_log_kopf TYPE pldoc_key_tab WITH HEADER LINE,
lt_log_felder TYPE TABLE OF hrinftylog_fields,
lt_infotyp_vorher TYPE prelp_tab,
lt_infotyp_nachher TYPE prelp_tab,
lt_aenderungs_operationen TYPE STANDARD TABLE OF pc403.
FIELD-SYMBOLS: <log_kopfzeile> TYPE pldoc_key.
*----------------------------------------------------------------------*
CALL FUNCTION 'HR_INFOTYPE_LOG_GET_LIST'
EXPORTING
tclas = 'A'
begda = '20190315'
endda = '20190315'
IMPORTING
subrc = lv_fehler
TABLES
infty_logg_key_tab = lt_log_kopf.
CLEAR lv_fehler.
SORT lt_log_kopf DESCENDING BY infty bdate btime pernr.
LOOP AT lt_log_kopf ASSIGNING <log_kopfzeile>.
CALL FUNCTION 'HR_INFOTYPE_LOG_GET_DETAIL'
EXPORTING
logged_infotype = <log_kopfzeile>
IMPORTING
subrc = lv_fehler
TABLES
infty_tab_before = lt_infotyp_vorher
infty_tab_after = lt_infotyp_nachher
fields = lt_log_felder.
CREATE OBJECT lo_infotypaenderungen
EXPORTING
is_aenderungs_kopf = <log_kopfzeile>.
REFRESH lt_aenderungs_operationen.
lt_aenderungs_operationen = lo_infotypaenderungen->get_aenderungs_operationen( ).
ENDLOOP.
*----------------------------------------------------------------------*
CLASS lcl_infotypaenderungen IMPLEMENTATION.
METHOD constructor.
me->s_aenderungs_kopf = is_aenderungs_kopf.
me->select_aenderungs_operationen( ).
ENDMETHOD. "constructor
METHOD select_aenderungs_operationen.
INCLUDE rpcblo00. """ <---
INCLUDE rpcbdt00. """ <---
lo-key-tclas = me->s_aenderungs_kopf-tclas.
lo-key-pernr = me->s_aenderungs_kopf-pernr.
lo-key-infty = me->s_aenderungs_kopf-infty.
lo-key-bdate = me->s_aenderungs_kopf-bdate.
lo-key-btime = me->s_aenderungs_kopf-btime.
lo-key-seqnr = me->s_aenderungs_kopf-seqnr.
IMPORT header TO me->t_aenderungs_operationen FROM DATABASE pcl4(la) ID lo-key.
ENDMETHOD. "select_aenderungs_operationen
METHOD get_aenderungs_operationen.
rt_aenderungs_operationen = me->t_aenderungs_operationen.
ENDMETHOD. "get_aenderungs_operationen
ENDCLASS. "lcl_infotypaenderungen IMPLEMENTATION
Anyone know a good solution? Thanks in advance
Edit: The includes have some declarations and a makro reading from a data cluster. Of course I could just put those directly into the method, but I would like to avoid that (for now I did that).
Alternatively, does someone know of a different way to get the change operation per infotype line?
If you use your class as a local one then the only way to use these includes is to put them at the very beginning of the program. The downside is of course that the variables there become global but unfortunately there is no other way to do that and for sure not if you want to use a global class after all (not sure if your minimal working example is just simplified to use a local class instead of global or not).
REPORT ZZZ.
INCLUDE rpcblo00. """ <---
INCLUDE rpcbdt00. """ <---
CLASS lcl_infotypaenderungen DEFINITION.
" ...
Thanks to Jagger I can make it work with a local class, but in case anyone later wonders how you need to change the include code to be able to use it in a global method, you basically just need to get rid of INCLUDE STRUCTURE declarations and exchange tables with a header line.
So
DATA BEGIN OF LO-KEY.
INCLUDE STRUCTURE PC400.
DATA END OF LO-KEY.
becomes
DATA: lo_key TYPE pc400.
And
DATA BEGIN OF BELEGE_00 OCCURS 100.
DATA:
SPLKZ(01) TYPE X,
FIELD(10) TYPE C,
FTYPE(04) TYPE C,
FLENG(03) TYPE N,
DECIM(02) TYPE N,
OLDDT(50) TYPE C,
NEWDT(50) TYPE C.
DATA END OF BELEGE_00.
becomes
TYPES: BEGIN OF ty_belege,
splkz(01) TYPE x,
field(10) TYPE c,
ftype(04) TYPE c,
fleng(03) TYPE n,
decim(02) TYPE n,
olddt(50) TYPE c,
newdt(50) TYPE c,
END OF ty_belege.
DATA: belege_00 TYPE STANDARD TABLE OF ty_belege.
The macro can stay the same (or I guess you could rewrite it).
I have the following piece of code.
REPORT ZZY.
CLASS lcl_main DEFINITION FINAL CREATE PRIVATE.
PUBLIC SECTION.
CLASS-METHODS:
convert_to_xstring
IMPORTING
i_param1 TYPE i
i_param2 TYPE i
RETURNING
VALUE(rv_result) TYPE xstring,
main.
ENDCLASS.
CLASS lcl_main IMPLEMENTATION.
METHOD convert_to_xstring.
ENDMETHOD.
METHOD main.
DATA: lt_binary_tab TYPE STANDARD TABLE OF x.
DATA(lv_result) = convert_to_xstring( i_param1 = 1 i_param2 = 2 ).
CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
EXPORTING
buffer = lcl_main=>convert_to_xstring(
EXPORTING
i_param1 = 1
i_param2 = 2
)
TABLES
binary_tab = lt_binary_tab.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
lcl_main=>main( ).
A functional method call that is not a part of a function module call can be written like that.
DATA(lv_result) = convert_to_xstring( i_param1 = 1 i_param2 = 2 ).
However when I want to use it exactly as written above
CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
EXPORTING
buffer = lcl_main=>convert_to_xstring( i_param1 = 1 i_param2 = 2 )
TABLES
binary_tab = lt_binary_tab.
I get the following syntax error.
Field "CONVERT_TO_XSTRING(" is unknown. It is neither in one of the
specified tables nor defined by a "DATA" statement. "DATA" statement.
It looks like the compiler needs some guidance in this case to distinguish between an attribute and a method. Why would it be ambiguous for the compiler to let such a case without writing EXPORTING?
CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
EXPORTING
buffer = lcl_main=>convert_to_xstring( EXPORTING i_param1 = 1 i_param2 = 2 )
TABLES
binary_tab = lt_binary_tab.
The design of abap is quite bad. There is something like functional method calls, but you can't use it in combination with all commands. For example the WRITE command doesn't work in combination with functional method calls. This seems to be some kind of "partial compatible" with function method calls.
I don't know why(maybe the sap dev folks were drunk), but it is just a fact we have to live with.
Can I define an ABAP method where the RETURNING parameter and any IMPORTING parameters have a generic type but that can still be called in a single line as a functional method?
In other words I'd like to replace this:
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
input = lv_external_value
IMPORTING
output = lv_internal_value.
With:
lv_internal_value= zcl_conversion=>alpha_input( lv_external_value ).
Unfortunately the fact that Class Methods can't have an untyped returning parameter is preventing me from declaring the functional method's return value as type ANY or CLIKE. The accepted standard of creating generic method parameters seems to be to define them as TYPE REF TO DATA and dereference/assign them. But as far as I know that prevents me from calling the method in a single statement as I have to first assign the importing parameter and then dereference the returning parameter, resulting in the same or more lines of code than a simple FM call.
Is there a way around this?
Unfortunately, there is no other way to dereference data than to use the dereference operator, either in the form ->* for the full value segment, or in the form ->comp, if the data object is structured and has a component named comp (and, even worse, there are a lot of places in ABAP code where you would like to use a value from a derefenced data object but can't do it for internal reasons / syntax restrictions).
However, you could simply keep the data reference object retrieved by your method in a variable of the calling code and work with that variable (instead of using a field symbol or a variable for the derefenced value segment itself). Either generically, as a ref to data variable, or typed, using the CAST operator (new ABAP syntax).
Most things that can be done with a field-symbol, can also be done directly with a data reference as well.
Example: Working with a variable result of the expected return type:
data(result) = cast t000( cl=>m( ) ).
write result->mandt.
See here the full example:
report zz_new_syntax.
class cl definition.
public section.
class-methods m returning value(s) type ref to data.
endclass.
start-of-selection.
data(result) = cast t000( cl=>m( ) ).
write: / result->mandt. " Writes '123'.
class cl implementation.
method m.
s = new t000( mandt = '123' ).
endmethod.
endclass.
On ABAP NW Stack 7.4 you could just use parameters type STRING and then use the new CONV Operator to convert your actual input in string. Little ugly but should work.
lv_internal_value = CONV #(zcl_conversion=>alpha_input( CONV #(lv_external_value) )).
If I were to type the following into a method body:
Dim myInt = 1
the Visual Studio IDE (and therefore, I am guessing, the compiler) infers the type of myInt to be Integer.
EDIT
Apparently using a literal was a bad choice here, since I've become embroiled in a lengthy debate that has nothing to do with the question. If you take issue with the fact that the expression 1 might be interpreted as an instance of different numeric types, pretend I had written:
Dim myInstance = New MyClass()
END EDIT
However, when I put a field declaration with the exact same code at the top of a class, the type of myList is not inferred:
Public Class Foo
Dim myInt = 1
End Class
On mouseover, it mentions the absence of an As clause, and says a type of Object has been assumed. I cannot pass myInt as an argument to a function or sub that expects an Integer argument, without explicitly adding an As clause or casting to Integer.
Is there a discrepancy between how the IDE and compiler deal with type inference? If, on the other hand, the compiler can't infer type in this situation either, why the discrepancy between method variables and class fields?
What you've found is that way on purpose. here is the MSDN expalanation.
Local type inference applies at procedure level. It cannot be used to
declare variables at module level (within a class, structure, module,
or interface but not within a procedure or block). If num2 in the
previous example were a field of a class instead of a local variable
in a procedure, the declaration would cause an error with Option
Strict on, and would classify num2 as an Object with Option Strict
off. Similarly, local type inference does not apply to procedure level
variables declared as Static.