Saturday, September 20, 2008

SAP ECC6.0 : Proper customer table creation...

Editor: I will not touch SE11's EVENT MODIFICATION under Table Maintenance Generator. I will probably do it at a later period.

Every company have their own customize development guidelines for customer table developments. Specific naming convention and specific type of data declaration. All this are part and puzzle of development team rules. Unfortunately, I observed that this doesn't really help much when it comes down to gist of realization of what fields should be included into a customize table. I emphasized here about what fields should be used because we are only, as usual, informed which fields will be required by our functionals. Essentially they only want to see and use that particular fields. However what of other additional fields that is required for your proper development? This entry, I want to share with you of my experience in customize table development.

A proper customized table as required by functionals should always has the following structure:(I did not purposely come out with this recommendation because of ECC6, I'd practiced doing this since 4.6c. Moreover, this practice was passed it down from one of my seniors who is now in Singapore!)

MANDT (this is to tell which data belongingto which client)
KEY FIELD 1 - CHECK TABLE (it can be your required field)
KEY FIELD 2 - CHECK TABLE (it can be your required field)
non key field 1 - CHECK TABLE (it can be your required field)
non key field 2 - CHECK TABLE (it can be your required field)
non key field n
CHECKBOX 1 (optional)
Observed those additional fields especially CREATED ON until CHANGED BY fields. Those fields will help your user to especially keep track of line data's accountability. With these fields users are able to monitor who at a certain period created this or update the line item. This can be important when it comes to troubleshooting and determination of responsibility and safety (compromised?). It may not be as important but there may be expectation that this fields can be made use in future (who knows) to be use part of report filtering.

Yes, you may not need to do this, because at the SE16, you can view your CHANGE LOG feature. This feature is only guaranteed if your customized table had its "Changed Log" checked at Technical Attributes in SE11. So it is still fine that those additional fields are put in. As i said, you might never know when an executive or someone from the department comes over to you and ask "Who change the table's data?". So credibility on this part plays a great deal!.

Though now we had moved from 4.6c to ECC6, SE11 had made several changes which included a new feature called 'Enhancement'. You can actually regulate your customize program whether the next developer can change the fields, specific fields, or cannot change the customize program at all. Look it up, my friend. You won't miss it because everytime you activate your customized table, there will always be a WARNING message telling you that this table is not set for certain enhancement!.

is sky the limit... proper customized table

Tuesday, September 16, 2008

SAP R/3 : ALV Limitation...

ALV report itself is a nice tool that allow developers to quickly come out with a nice report that does not require much of programming to build columns, pump in data, sort it, or providing it a few icons or additional instructions. Allowing you to focus on processing data only. Unfortunately, ALV report itself presents a few problems or limitations that somehow hampers our requirements when it comes to large and long report that user wants.

OSS Notes : 857823
Detailing that cells with CHAR or STRING type are truncated after 128. This affects ALV Grid function control and some other SAPGUI display. This is a standard behavior.

OSS Notes : 910300
Next, this notes detailing (UNICODE) that it is also a program limitation for ALV Grid that truncates text. The only solution is to modify the program to only take in a maximum of 42 character for a cell.

OSS Notes : 959775
Also, ALV GRID column of text based cells are truncated or replace '...' so to display that there are more text after that position. This is considered by SAP as an error. You might include the layout method optimize_colwidth = 'X' but it is not the solution but applying SAP Patch.
PATCH : SAPGUI 640 PATCH 21 (Release since 6.0)

OSS Notes : 78401
In addition, last year, I did mention there's another limitation to downloading xls from ALV. Here is the link:

Reference : 857823, 910300 and 959775 and obtain from

is sky the limit... alv grid limitation...

SAP R/3 : Overcome ALV limitations...

As an alternative solution to make your icon in ALV to download xls file smoothly as a result of a few notes due to

I would normally recommend a few options:
1. IF your ALV is a list (not GRID), and your xls downloads are messy, most probably, the spool does not recognize the vertical lines from the list. Spool buffers often recognize ALV grid's vertical line as the optical border to help it separate the columns neatly. Solution: convert your report to grid.

2. IF your ALV GRID, present a problem during xls downloads, you might want to consult BASIS to enable the spool to collect more than its limited number of column. Or, you can go to SPAD and modify the spool column.

3. IF your ALV GRID, present a problem during xls downloads, and your BASIS does not want to modify it for fear of other situations - you can custom your standard ALV toolbar's xls icon to download using FM GUI_DOWNLOAD.

(Use SE41) Modifying ALV toolbar is not difficult. You can disable certain ICONS from the ALV toolbar which you do not want user to use it. You can even enable a custom ICON into the standard ALV toolbar so to fullfil user requirement. Thus there are two objects that you need to know in order to custom standard ALV toolbar:

Program : SAPLKKBL
Status : STANDARD*

Copy that status and re-paste it to your custom program. Copy button will popup a dialogue that allows you to transfer that copied ALV status to yours. From there you can edit the toolbar's icon you like.

You will know which icon to modify because xls button is easily recognized by its excels spreadsheet avatar. At the function portion for that xls button, change the function code to your own zXXX so you can use it during CALLBACK from your ALV report.

However, there are 2 things you need to do before you can use your custom xls icon. First, at your ALV function module, you call I_CALLBACK_PF_STATUS_SET to set your copied status so your custom ALV toolbar appears at the report. Second, use I_CALLBACK_USER_COMMAND to trigger your GUI_DOWNLOAD to download your excel files. I_CALLBACK_USER_COMMAND will throw your icon's function code to sy-ucomm.

There you are, in conclusion, a neat step to overcome your ALV problems. I hope there will be more solutions being handled by SAP ECC6.0. Any one who has other alternative solution or some steps I miss you can email to me personally.

is sky the limit... managing your excel download...


To access employee's record in HR module are multiple ways of doing so. You can use GET PERNR, SELECT, PROVIDE or even function modules. However, the question lies on the difference of each of this syntaxes that allows you to access employee information when we are using it for reporting, enhancement and other data queries.

First, GET PERNR is a macro that contains PROVIDE statements and a logic of filteration based on the logical database PNP. GET PERNR allows you to focus on processing data immediately and less worry on the data selection because the PNP automatically provide a set of predefine group of selection screens. You can even modify and set your own selection screens using HR Report Category and still able to use GET PERNR. HR macros are all stored in this table TRMAC. You will see that each of this line items in that table are specific ABAP coding. GET PERNR should be use when your reporting does not max out the database processing (where there is many read and write) or mass processing. Mass processing will not be very suitable to be queried by GET PERNR. GET PERNR gets each record of an employee of a cycle. Each cycle in GET PERNR does 4 events that will listen to set handler to get data, process data, present data and lastly checking if there are user exit or enhancement to the GET PERNR.

Second, SELECT statement/syntaxes are more suitable to query for large data (mass processing) especially if you are downloading employee data at one shot to a text file or to an IDOC for data transfer. You should use SELECT statement to select a lot of employees for a certain condition so to minimise table read transaction so your performance in an ABAP program can focus more on ABAP processing. In my personal opinion, getting side topic a bit, analysis result yield by SE30 after checking a certain ABAP program should have its performance shoulder towards on ABAP processing side. In other words, it is okay to see the percentage falls towards ABAP processing rather than sliding towards database read. High percentage of database reads indicates your program contains a lot of SELECT SINGLE and a whole START-OF-SELECTION filled with SELECT-END SELECT statements. Worse, there might be a possibility that your program contains NESTED SELECT statement. You should group your SELECT statement in one place and gather all data before going to processing stage.

Third, a good mixture usage of GET PERNR and INFOTYPE syntax can help you ease your HR report processing reading your infotype tables a great deal. At each read of GET PERNR, INFOTYPE syntax will be automatically filled with data related to the particular employee so it helps you to reduce coding and in one way, getting correct rows of record for an employee that is time dependent. Time dependent in HR meaning each record of transaction for an employee has a trace of time that dictates the time and date that affect that record. Not all infotype is dependent time. Infotype like 0000 (Action) is time dependent because it can tell you when an employee is recruited, confirm, transfer, promoted, terminated or on leave.

GET PERNR and SELECT statement should be used accordingly to reporting condition. GET PERNR sometime can slows down your report. Also, instead of using PROVIDE statement, you should use GET PERNR because PROVIDE is in the macro itself.

is sky the limit... GET PERNR/PROVIDE/SELECT