I'm new to ABAP, and I'm trying to build a field catalog using the REUSE_ALV_FIELDCATALOG_MERGE function module. This function module exits with sy-subrc value 1 ("Inconsistent interface") and a message dialog appears saying that the field catalog couldn't be build.
My code is the same as the examples found online. Maybe I missed something.
My program consists of a TOP include, a FORMS include and the main module:
FORMS include:
FORM DISPLAY_WITH_ALV_LIST.
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = sy-repid
I_INTERNAL_TABNAME = 'it_report'
I_INCLNAME = sy-repid
CHANGING
CT_FIELDCAT = it_fldcat.
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
IT_FIELDCAT = it_fldcat
TABLES
T_OUTTAB = it_report.
ENDFORM.
FORM ZSELECT.
SELECT VBELN ERDAT ERNAM
FROM VBAK
INTO CORRESPONDING FIELDS OF TABLE it_report
WHERE ERDAT IN S_ERDAT
AND ERNAM IN S_ERNAM.
ENDFORM.
TOP include:
TYPE-POOLS: slis.
TABLES VBAK.
DATA: BEGIN OF it_report OCCURS 0,
VBELN LIKE VBAK-VBELN,
ERDAT LIKE VBAK-ERDAT,
ERNAM LIKE VBAK-ERNAM,
END OF it_report.
DATA it_fldcat TYPE slis_t_fieldcat_alv.
Main module:
REPORT ZMLA_EXO1.
INCLUDE ZMLA_EXO1_TOP.
INCLUDE ZMLA_EXO1_SCREEN.
INCLUDE ZMLA_EXO1_FORM.
INITIALIZATION.
AT SELECTION-SCREEN.
START-OF-SELECTION.
PERFORM ZSELECT.
PERFORM DISPLAY_WITH_ALV_LIST.
END-OF-SELECTION.
I would advise using the "SALV" class. It's pretty straight forward, in your case it would look like this:
DATA: go_salv_table TYPE REF TO cl_salv_table.
CALL METHOD cl_salv_table=>factory
IMPORTING
r_salv_table = go_salv_table
CHANGING
t_table = it_report.
go_salv_table->display( ).
If you still insist on using the function module (FM) REUSE_ALV_FIELDCATALOG_MERGE, and generate field catalog from internal table, then these conditions must be observed:
Your internal table with the data to be displayed has to be declared with the word "OCCURS" (not a must to use addition "WITH HEADER LINE").
Fields of the internal table have to be declared using "LIKE". It will not work if you use "TYPE" to declare the fields.
No line in your program should exceed 72 characters. Otherwise a short dump will be generated with the exception cx_sy_read_src_line_too_long since the FM has to scan your program code looking for the internal table definition.
In short, it's an old FM with a lot of problems.
Related
All the flows seen like okay, however when pass through the call function, the update also failed and the field that need to be update not updated, not sure where is the problem, can someone help me with this problem? do i miss any step?
Error message Log in LT_PROT
DATA: LT_PROT LIKE PROTT OCCURS 10 WITH HEADER LINE.
DATA: LT_VBPOK LIKE VBPOK OCCURS 500 WITH HEADER LINE.
DATA: LS_VBKOK LIKE VBKOK.
DATA: GT_LIPS LIKE LT_LIPS.
DATA: WA_LIPS TYPE LTY_LIPS.
DATA: EF_ERROR_ANY_0 TYPE C,
EF_ERROR_IN_ITEM_DELETION_0 TYPE C,
EF_ERROR_IN_POD_UPDATE_0 TYPE C,
EF_ERROR_IN_INTERFACE_0 TYPE C,
EF_ERROR_IN_GOODS_ISSUE_0 TYPE C,
EF_ERROR_IN_FINAL_CHECK_0 TYPE C.
SELECT * FROM LIPS INTO CORRESPONDING FIELDS OF TABLE LT_LIPS
WHERE VGBEL = LT_BCODE_I-VGBEL
AND VGPOS = LT_BCODE_I-VGPOS.
LOOP AT LT_LIPS INTO WA_LIPS.
WA_LIPS-LFIMG = LT_BCODE_I-MENGE.
MODIFY LT_LIPS FROM WA_LIPS INDEX SY-TABIX.
ENDLOOP.
"VBPOK IS CHANGE INDICATOR, AFTERWARD CALL FUNCTION TO CHANGE FIELD LFIMG IN STANDART TABLE LIPS.
LOOP AT LT_LIPS INTO GT_LIPS.
LT_VBPOK-LFIMG = GT_LIPS-LFIMG.
APPEND LT_VBPOK.
ENDLOOP.
ls_vbkok-vbeln_vl = LT_BCODE_I-REF_DOC.
CALL FUNCTION 'WS_DELIVERY_UPDATE'
EXPORTING
vbkok_wa = ls_vbkok " DELIVERY DOCUMENT NUMBER
synchron = 'X'
no_messages_update = ' '
update_picking = 'X'
commit = 'X'
delivery = LT_BCODE_I-REF_DOC "VARIABLE OF DELIVERY DOCUMENT
nicht_sperren = 'X'
if_error_messages_send_0 = space
IMPORTING
ef_error_any_0 = ef_error_any_0
ef_error_in_item_deletion_0 = ef_error_in_item_deletion_0
ef_error_in_pod_update_0 = ef_error_in_pod_update_0
ef_error_in_interface_0 = ef_error_in_interface_0
ef_error_in_goods_issue_0 = ef_error_in_goods_issue_0
ef_error_in_final_check_0 = ef_error_in_final_check_0
TABLES
vbpok_tab = lt_vbpok "TABLE TO BE CHANGE
prot = lt_prot.
First of all, this function model has the status "Not released" on its attribute tab. That means that it should not be used in customer code, because
SAP might change or delete it in a future update without warning, and then your code won't work anymore.
It is very likely not properly documented.
It might have hidden and unexpected gotchas. Like for example only working for specific corner-cases, not doing everything you would expect it to be doing or requiring to call some other function module before or afterwards in order to do something.
The error handling might be missing or might provide information that's misleading outside of the context where the module is usually used
So before you use a "Not Released" function module, you should check the transaction code BAPI if there is an official bapi function module which does what you want. Bapi function modules are specifically intended for use in customer code. They are well-documented, are guaranteed to take care of everything and SAP promises not to break them in future updates.
So much for the preaching, let's look at your actual problem.
Whenever you encounter a data structure with fields like MSGNO, MSGTY, MSGID and up to four generic variables, you are dealing with a message. You can look up message codes like that in transaction SE91. There we can see that the number 280 in message class VL means:
Required field in interface to delivery update missing VBELN 00000 00000
This could refer to the structure ls_vbkok or to the table lt_vbpok. I would recommend you to set a debugger breakpoint in your code and find out where that VBELN field could be missing a value.
All the flows seen like okay, however when pass through the call function, the update also failed and the field that need to be update not updated, not sure where is the problem, can someone help me with this problem? do i miss any step?
Error message Log in LT_PROT
DATA: LT_PROT LIKE PROTT OCCURS 10 WITH HEADER LINE.
DATA: LT_VBPOK LIKE VBPOK OCCURS 500 WITH HEADER LINE.
DATA: LS_VBKOK LIKE VBKOK.
DATA: GT_LIPS LIKE LT_LIPS.
DATA: WA_LIPS TYPE LTY_LIPS.
DATA: EF_ERROR_ANY_0 TYPE C,
EF_ERROR_IN_ITEM_DELETION_0 TYPE C,
EF_ERROR_IN_POD_UPDATE_0 TYPE C,
EF_ERROR_IN_INTERFACE_0 TYPE C,
EF_ERROR_IN_GOODS_ISSUE_0 TYPE C,
EF_ERROR_IN_FINAL_CHECK_0 TYPE C.
SELECT * FROM LIPS INTO CORRESPONDING FIELDS OF TABLE LT_LIPS
WHERE VGBEL = LT_BCODE_I-VGBEL
AND VGPOS = LT_BCODE_I-VGPOS.
LOOP AT LT_LIPS INTO WA_LIPS.
WA_LIPS-LFIMG = LT_BCODE_I-MENGE.
MODIFY LT_LIPS FROM WA_LIPS INDEX SY-TABIX.
ENDLOOP.
"VBPOK IS CHANGE INDICATOR, AFTERWARD CALL FUNCTION TO CHANGE FIELD LFIMG IN STANDART TABLE LIPS.
LOOP AT LT_LIPS INTO GT_LIPS.
LT_VBPOK-LFIMG = GT_LIPS-LFIMG.
APPEND LT_VBPOK.
ENDLOOP.
ls_vbkok-vbeln_vl = LT_BCODE_I-REF_DOC.
CALL FUNCTION 'WS_DELIVERY_UPDATE'
EXPORTING
vbkok_wa = ls_vbkok " DELIVERY DOCUMENT NUMBER
synchron = 'X'
no_messages_update = ' '
update_picking = 'X'
commit = 'X'
delivery = LT_BCODE_I-REF_DOC "VARIABLE OF DELIVERY DOCUMENT
nicht_sperren = 'X'
if_error_messages_send_0 = space
IMPORTING
ef_error_any_0 = ef_error_any_0
ef_error_in_item_deletion_0 = ef_error_in_item_deletion_0
ef_error_in_pod_update_0 = ef_error_in_pod_update_0
ef_error_in_interface_0 = ef_error_in_interface_0
ef_error_in_goods_issue_0 = ef_error_in_goods_issue_0
ef_error_in_final_check_0 = ef_error_in_final_check_0
TABLES
vbpok_tab = lt_vbpok "TABLE TO BE CHANGE
prot = lt_prot.
First of all, this function model has the status "Not released" on its attribute tab. That means that it should not be used in customer code, because
SAP might change or delete it in a future update without warning, and then your code won't work anymore.
It is very likely not properly documented.
It might have hidden and unexpected gotchas. Like for example only working for specific corner-cases, not doing everything you would expect it to be doing or requiring to call some other function module before or afterwards in order to do something.
The error handling might be missing or might provide information that's misleading outside of the context where the module is usually used
So before you use a "Not Released" function module, you should check the transaction code BAPI if there is an official bapi function module which does what you want. Bapi function modules are specifically intended for use in customer code. They are well-documented, are guaranteed to take care of everything and SAP promises not to break them in future updates.
So much for the preaching, let's look at your actual problem.
Whenever you encounter a data structure with fields like MSGNO, MSGTY, MSGID and up to four generic variables, you are dealing with a message. You can look up message codes like that in transaction SE91. There we can see that the number 280 in message class VL means:
Required field in interface to delivery update missing VBELN 00000 00000
This could refer to the structure ls_vbkok or to the table lt_vbpok. I would recommend you to set a debugger breakpoint in your code and find out where that VBELN field could be missing a value.
While displaying an ALV I get a crash report when executing the program. To create an ALV I have followed a few tutorials and stuff and at the moment it looks like this:
TYPE-POOLS: slis.
*build field catalog
DATA: it_fieldcat TYPE slis_t_fieldcat_alv,
wa_fieldcat TYPE slis_fieldcat_alv,
repid TYPE sy-repid.
REFRESH it_fieldcat.
CLEAR wa_fieldcat.
wa_fieldcat-reptext_ddic = 'Table ID'.
wa_fieldcat-fieldname = 'table_id'.
wa_fieldcat-tabname = 'lt_where_used_data_of_coll'.
wa_fieldcat-outputlen = '18'.
APPEND wa_fieldcat TO it_fieldcat.
CLEAR wa_fieldcat.
wa_fieldcat-reptext_ddic = 'Table Description'.
wa_fieldcat-fieldname = 'table_description'.
wa_fieldcat-tabname = 'lt_where_used_data_of_coll'.
wa_fieldcat-outputlen = '40'.
APPEND wa_fieldcat TO it_fieldcat.
CLEAR wa_fieldcat.
wa_fieldcat-reptext_ddic = 'Numer of Records Found'.
wa_fieldcat-fieldname = 'nr_of_records'.
wa_fieldcat-tabname = 'lt_where_used_data_of_coll'.
wa_fieldcat-outputlen = '30'.
APPEND wa_fieldcat TO it_fieldcat.
*pass data and field catalog to ALV function module
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
i_callback_program = repid
it_fieldcat = it_fieldcat
i_structure_name = 'lty_where_used_data_of_coll'
TABLES
t_outtab = lt_where_used_data_of_coll.
'lt_where_used_data_of_coll' is my local table that I have already filled with a working function earlier in my program. This function works and I have tested it and the table fills itself with data. My next step was displaying this data to the end user. The error report I receive when executing this program is:
Short text: Field symbol has not yet been assigned.
What happened?:
Error in the ABAP Application Program.
The current ABAP program "SAPLSLVC" had to be terminated because it has
come across a statement that unfortunately cannot be executed.
Error analysis:
You attempted to access an unassigned field symbol
(data segment "-1").
Trigger Location of Runtime Error:
Program SAPLSLVC
Include LSLVCF36
Row 3,273
Module type (FORM)
Module Name FILL_DATA_TABLE
I really don't know how to start finding my mistake. It seems like it runs bad when calling a function from ABAP itself.
Any help is much appreciated.
EDIT: As was suggested I implemented another way of displaying an ALV that can be found below. This way works fine and gives no errors. Question still remains why the older method does give me an error.
I replaced the entire block of code above with this:
DATA alv TYPE REF TO cl_salv_table. DATA message TYPE REF TO cx_salv_msg.
*initialize ALV
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = alv
CHANGING
t_table = lt_where_used_data_of_coll ).
CATCH cx_salv_msg INTO message.
" error handling
ENDTRY.
*display ALV
alv->display( ).
why the older method does give me an error
Field catalog names are case sensitive. Capitalize every fieldname and tabname value and see if the error's still there. Also make sure that the names match those of your internal table lt_where_used_data_of_coll
I am working on a program in Business Warehouse that allows you to map out all of your process chains by following the hierarchy of parent to sub-chains by using the rspcchain table. As of right now I have it printing the output to the screen, but would like to export this output to excel instead. I have been unable to find a function module that serves this purpose, so any help would be greatly appreciated
note - after learning about the SALV classes available I changed the code to display the table differently.
REPORT Z_PC_VARIANT_MAPPING.
*Declaring types and variables
TYPES: BEGIN OF t_chains,
chain_id LIKE rspcchain-chain_id,
variant LIKE rspcchain-variante,
END OF t_chains.
DATA: lt_rspcchain TYPE STANDARD TABLE OF t_chains,
lwa_rspcchain TYPE t_chains,
o_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg.
TABLES: rspcchain.
*selection screen setup
SELECT-OPTIONS chain_id FOR rspcchain-chain_id.
SELECT-OPTIONS type FOR rspcchain-type.
*filling local table
SELECT chain_id variante
FROM rspcchain INTO TABLE lt_rspcchain
WHERE chain_id IN chain_id AND
type IN type AND
objvers = 'A'.
*original code to test printing output on screen
*LOOP AT lt_rspcchain INTO lwa_rspcchain.
* skip.
* WRITE lwa_rspcchain-chain_id.
* WRITE lwa_rspcchain-variant.
*ENDLOOP.
IF sy-subrc NE 0. "sy-subrc = return code
WRITE 'Data not found'.
ENDIF.
*loading data from local table into alv object table
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = o_alv
CHANGING
t_table = lt_rspcchain ).
CATCH cx_salv_msg INTO lx_msg.
ENDTRY.
*calling display method to display table
o_alv->display( ).
You can use the SALV framework for this, it comes with a class to export whatever would be displayed to various formats, including .MHTML and .XML formats that are understood by Excel. The class CL_SALV_TABLE has a method TO_XML to support this; additionally, you might need the CL_SALV_BS_XML_UTILS to handle the transformations. See the report SALV_TEST_TABLE_DISPLAY_OR_XML for example coding.
You should look at the ABAP2XLSX project.
http://wiki.sdn.sap.com/wiki/display/ABAP/abap2xlsx
Not sure if all the necessary components exist in BW, but this is really the best solution for creating spreadsheets out of ABAP code that I have found.
You can try the following which will download a CSV file, which with the .xls extension opens flawlessly in Excel:
Convert lt_rspcchain to a csv internal table by calling SAP_CONVERT_TO_CSV_FORMAT
Figure out where the user wants to store the file by calling cl_gui_frontend_services=>file_save_dialog( )
Store the file by calling cl_gui_frontend_services=>gui_download( )
I assume you will be able to find how these work by experience or through Google.
I'm thinking that I'm probably missing an export parameter (from my Function Call POV).
In the REUSE_ALV_GRID_DISPLAY function call, the parameters I pass around are:
Exporting:
i_callback_program,
i_callback_pf_status_set,
i_callback_user_command,
is_layout,
it_fieldcat,
i_save
Tables:
t_outtab
And the exceptions plus handling.
I've checked that the internal table that I pass has data and it does.
I think the information I put up will suffice but if you really need to see the code, I'll do so.
I'm a noob and any help would be appreciated.
Thanx.
There are several ways to use ALV, so we may indeed need more info on your code to help.
First Method is to use the function module REUSE_ALV_GRID_DISPLAY. This will directly display the table content in the output dynpro. If all you need is a display, then go for it, as this is the simpliest : If the table structure is in the dictionnary, this call can be as simple as the following (this will display all members of the struct as column)
myreport = sy-repid.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
i_callback_program = myreport
it_excluding = exclude_tab
TABLES
t_outtab = display_data
EXCEPTIONS
program_error = 1
OTHERS = 2.
If the structure is declared in the program, then you have to create a field catalog.
the following code can serve as basis :
FORM fill_fieldcat CHANGING p_fieldcat TYPE slis_t_fieldcat_alv.
* Data definition
DATA ls_fieldcat TYPE slis_fieldcat_alv.
* Macro definition
DEFINE append_fieldcat.
clear ls_fieldcat.
ls_fieldcat-fieldname = &1. * name of the field in struct
ls_fieldcat-tabname = &2. * name of the table
ls_fieldcat-row_pos = &3. * column
ls_fieldcat-ref_fieldname = &4. * field in ref table
ls_fieldcat-ref_tabname = &5. * ref table
ls_fieldcat-outputlen = &6. * size of output
ls_fieldcat-seltext_m = &7. * text (space if using the element typetext)
ls_fieldcat-ddictxt = 'M'.
ls_fieldcat-key = &8. * is this a key field in table
ls_fieldcat-emphasize = &9. * emphisze column display
append ls_fieldcat to p_fieldcat.
END-OF-DEFINITION.
* Init.
REFRESH p_fieldcat.
* Append fielcatalog for ALV
append_fieldcat:
'FORMATIONCODE' 'DISPLAY_TAB' 1 'SHORT' 'HRP1000' 12 'Code Stage' space space,
'FORMATIONTEXT' 'DISPLAY_TAB' 1 'STEXT' 'HRP1000' 20 'Libelle Stage' space space,
'SESSIONID' 'DISPLAY_TAB' 1 'OBJID' 'HRP1000' space 'Session' space space,
'BEGDA' 'DISPLAY_TAB' 1 'BEGDA' 'HRP1000' space 'Debut' space space,
'ENDDA' 'DISPLAY_TAB' 1 'BEGDA' 'HRP1000' space 'Fin' space space,
ENDFORM. "fill_fieldCat
you then call the form to create the field catalog, and use it in the it_fieldcat parameter of the function call.
Second method is to use ABAP-Object. Use check se83 for exemples of this use. the basis is as follows :
In your Dynpro you declare a custom container with a given name ("ALV_CONT"). Then in then PBO of the dynpro you initialize the container and put an ALV objct inside :
* global variables :
DATA : delegationlist_table TYPE REF TO cl_gui_alv_grid,
delegationlist_container TYPE REF TO cl_gui_custom_container.
data : gs_layout TYPE lvc_s_layo.
in PBO
IF delegationlist_container IS INITIAL.
* create a custom container control for our ALV Control
CREATE OBJECT delegationlist_container
EXPORTING
container_name = 'ALV_CONT'
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2
create_error = 3
lifetime_error = 4
lifetime_dynpro_dynpro_link = 5.
* create an instance of alv control
CREATE OBJECT delegationlist_table
EXPORTING
i_parent = delegationlist_container.
* Set a titlebar for the grid control
gs_layout-grid_title = 'Délégations'.
gs_layout-sel_mode = 'A'.
gs_layout-cwidth_opt ='X'.
* set table as data source
* the struct name *must* be uppercase
* the table must have this struc
CALL METHOD delegationlist_table->set_table_for_first_display
EXPORTING
i_structure_name = 'ZPRT_DELEGATIONLIST'
is_layout = gs_layout
CHANGING
it_outtab = delegationlist.
ENDIF.
Hopes this help,
Regards
Guillaume PATRY
EDIT: Oh, and another thing - if you're really in POV (process on Value-Request = F4), be aware that there are limitations to what you can do. Try your code in a simple report right after START-OF-SELECTION, and if that works, try the same code in a POV module.
===
If you don't pass a structure name, you have to ensure that you pass a complete (!) field catalog, otherwise the ALV grid might start to work erratically or not at all. Use the function modules LVC_FIELDCATALOG_MERGE and LVC_FIELDCAT_COMPLETE (in this order) to get a LVC field catalog that can be used with the classes or REUSE_ALV_GRID_DISPLAY_LVC.
A couple people here suggested using the REUSE_ALV_GRID_DISPLAY. I'm sure this is a common way to get things done (I used to use it myself), but I've taken a sap delta course recently and they strongly suggested to not use it anymore (you can look it up, REUSE_ALV_GRID_DISPLAY is not officialy supported by SAP anymore).
Instead, use CL_SALV_TABLE, documentation here: http://help.sap.com/erp2005_ehp_04/helpdata/EN/d7/b22041aa7df323e10000000a155106/frameset.htm
It's actually rather convenient to use too.
Thanks for the effort but as it turned out, the mistake I did was that I didn't capitalize field names in building the Field Catalog. Such a newbie mistake. I guess I won't be doing that mistake again any time soon.
-migs
Pass the output internal table to the FM Parameter "t_outtab".
It will print your data output.