Moved To New Technical Blog

Dear all,

We grew old each day, and it has been in my mind to upgrade this blog too. Today, I upgraded my blog and now it has moved to a new blog as follows :

WILLIAM WILSTROTH - DEVELOPMENT

As there are still some unpublished entries, which I was still in the midst of writing, it will be published in the new blog. Time has moved one, this blog will move on too so it reflects my motivation to keep contributing to this technical blog of mine.

Thank you for all your support to this day. I hope you will enjoy more of my technical blog at the new site. Please provide your feedback and advice, if you have one...

Yours truly,

William Wilstroth

SAP ECC6.0 : Associative attachment error...

Associative file error, is a common problem if your programming to attach a file without an extension in your send email attachment. This function module is 'SO_NEW_DOCUMENT_ATT_SEND_API1'.

There are 2 steps you can check whether if your file association (extension is supported):

1. Go to Control Panel, Default Program, Set Associative. Check if your file is supported.

2. If your file is supported in Set Associative, the go to your coding, particularly at parameter OBJECT_HEADER. Make sure your file has an extension otherwise the above error popup will appear.

Is sky the limit... associative error

SAP ECC6.0 : SO-DO (No Pricing Display)

Recently I had an issue that cracked my brain left and rigth. An Sales Order(SO) created that will initiate a DO in the background (Rush Order). In the event of doing so, this DO will automatically print a Pre-Invoice form. Unfortunately, the price was not display and as a result, the total price became zero. So I had to figure out the root cause. First few days of troubleshooting the SO to DO was painstaking. I loose patient as I am not sure which part was causing it. Several question popped here and there.

1. Is it the print program that causes it?
2. Is it the upgrade that cause the print program to loose it mind?
3. Is there any difference between ECC6 standard print program and the customized one?
4. Did we forget to transport certain versions of the print program?

So I had to take out my gloves and grind and till the land until my glove gone and my hand bruised! One big hassle if the price suddenly gone somewhere after an upgrade. It was working fine in 4.6c. After the upgrade the price was missing. So where had it gone to?

Tracing it wasn't easy though as it being produced by DO in the background. I couldn't make the system to stop at the break-point even though I'd put more than 10 in it. TCODE JDBG was helpless. SM58 was not stopping at correct points because SO was travelling at unknown location towards DO. So it was brain crushing! The hell was it I still need to prove that the print program was fine!

As tracing was helpless, I took another option to put in some trace log in the print program so at least I can trace data movement to SAP Directory AL11. Proven as good as it is, the standard function module "RV_PRICE_PRINT_ITEM" was not getting any pricing condition out at all by the print program. So the conclusion was simply : during the process of saving DO at the background, Sales Order's SO number (VBELN) and Pricing ID (KNUMV) had not yet COMMIT WORK. That's a pretty straight guess! So it had to be it. Afterall, I can get back my pricing condition if I did the DO manually or after that. So, while SO was not committed to save, the print program will forever not be able to retrieve it's pricing condition.

Now I had to go out to the jungle to find the ultimate root cause why the function module "RV_PRICE_PRINT_ITEM" unable to retrieve pricing condition back from SO while its generating DO at the background. So its like finding the golden needle in the haystack!

All over again, but I had only question in mind as I race against time to get that root cause:

Where the hell happen?!

It took me painfully the next 4 days to track and hunt the error. Adding salt to the situation, the error had gone from thin air in the development system. Out of nowhere had it gone to and my functionals had their heels on me whether I had fixed anything or done anything. My answer was NO. So all over again and again, several questions add to another unsolved question:

Who made the changes?
What changes was made?

Time was running out and I was running out of ideas and ways to solve this problem day by day. My boss kept coming to me if it will be solve. Given any day or any moment my answer to him was always YES. Unfortunately, this issue is a real mess and if things go disappear suddenly then I can say this is a serious X-files! Bear in mind, SAP problems always had a cause and an explanation behind but you need to take the pain before you gain it. So I had to force myself, this time, I repeated this time, I will go line by line and open up each door to see what was behind the mechanism.

As I went to each line, I was determined that someone, had to be a person, from another team who did something to a user exit, an enhancement-point or a BADI that suddenly make the DO to correctly print the price out.

You would have said, "Hey buddy, wait for the next transport of whatever into the quality system and production system to correct the error!" However, this will not be the case, things just do not dissappear for a reason. I need to find that out. Furthermore, the quality system and production system still having the error. So it need to be fix pronto even though development is correct! Anyway, I went along thousand of lines of ABAP coding, I found an alternative solution instead of the root cause.

I will make use of the following :

1. USER EXIT->MV45AFZZ->USEREXIT_SAVE_DOCUMENT
2. A customized TABLE
3. Modified the PRINTPROGRAM

Before I go on to explain why I would use such crude way, it is best that you follow my trace below.

01. SAPFV45K->FV45KFKD_VBKD_BEARBEITEN->VBKD_BEARBEITEN
02. SAPMV45A->MV45AIAK_VBAK_FUELLEN->VBAK_FUELLEN
03. SAPFV45K->FV45KFKD_XVBKD_LESEN_DIREKT->XVBKD_LESEN_DIREKT
04. SAPFV45P->FV45PFAP_VBAP_BEARBEITEN_VORBE>VBAP_BEARBEITEN_VORBEREITEN
05. SAPFV45P->FV45PF0K_KALKULATION_BEARBEITE->KALKUlATION_BEARBEITEN_ENDE
06. SAPMV45A->MV45AF0B_BELEG_BEARBEITEN_ENDE->PREISFINDUNG_GESAMT_BELEG_ENDE
07. SAPMV45A->MV45AF0P_PREISFINDUNG_GESAMT->PREISFINDUNG_GESAMT->(38)
08. SAPMV45A->MV45AF0P_PREISFINDUNG_GESAMT->PRICING_COMPLETE(61)
09. SAPMV45A->MV45AF0B_BELEG_BEARBEITEN_ENDE->BELEG_BEARBEITEN_ENDE->(315)
10. SAPMV45A->MV45AF0B_BELEG_SICHERN->BELEG_SICHERN->NUMBER_GET_NEXT(654)->GET VBAK-VBELN
11. SAPMV45A->MV45AF0B_BELEG_SICHERN->BELEG_SICHERN->NUMBER_GET_NEXT(792)

Editor's note : Yes I took my pain ass going around the merry go round to get those traces out. Yes, MV45AF0B_BELEG_SICHERN is the standard include file that is for SAVING THE SO! Mind me, I haven't finish tracing to DO!

Look at item 10 onwards, this line gives me that idea to use an user exit to solve the problem. This line 10 and line 11 is the important part of the standard coding that SO begin to create a SO no. and KNUMV id. But bear in mind standard internal tables XKOMV still not updated with the new KNUMV id though it had its pricing determine.

So at this point, I have a new SO number, a new KNUMV number and a table of pricing condition not tied to the new KNUMV yet. Three new things that is untied of each other. Therefore, I had to tied these three together and make the DO's form to print them out.

1. A new SO no.

2. A new KNUMV

3. A table of determined pricing condition with no KNUMV yet.

The userexit (MV45AFZZ->USEREXIT_SAVE_DOCUMENT and CUSTOMIZED TABLE) now come into role. I wrote a piece of logic to combine these three things into the CUSTOMIZED TABLE. The customized table has underlying KONV structure and added VBELN and a RUNID to it. This whole portion will be use by the print program.

At the print program and just after the function module "RV_PRICE_PRINT_ITEM", I will make use of the customized table. If RV_PRICE_PRINT_ITEM can get the price condition out, this customized table will not be use. Else, it will be processed and fill back the TKOMV adn TKOMVD tables. TKOMV and TKOMVD are table parameters of "RV_PRICE_PRINT_ITEM".

So that's the alternative solution that I had implemented for the time being. Now back to those questions:

What happend to DO's Pre-Inv, during background creation by SO, unable to capture those pricing condition out by the function module RV_PRICE_PRINT_ITEM?

It is stil an unanswered question till today. Anyone out there who knows this mysterious issue?

is sky the limit... SO->DO->RV_PRICE_PRINT_ITEM...

SAP ECC6.0 : IDOC stuck at status 30

Certain assignments will require you to purpose write a program to send out IDOCs to your business partner to process data. So you will need to process your Partner Profiles information, deciding which segments, basic type and message type to use. However, you will not run away from not using Function Module 'MASTER_IDOC_DISTRIBUTE'.

This function module will help you to issue out IDOC (send) to your customer and business partners. However, there is a problem to using this function module. You need to use another function module together with 'MASTER_IDOC_DISTRIBUTE'. This function module is 'EDI_DOCUMENT_DEQUEUE_LATER'.

As per HELP.sap.com description, if one wants to sent out IDOC with '03' status, function module 'EDI_DOCUMENT_DEQUEUE_LATER' need to be process after distributing IDOC then only COMMIT WORK.

1. MASTER_IDOC_DISTRIBUTION

2. EDI_DOCUMENT_DEQUEUE_LATER

3. COMMIT WORK.

If you do not want to use 'EDI_DOCUMENT_DEQUEUE_LATER', then your partner profile's port should be set either to FILE or CPIC. Futhermore, TRFC will not direct send your IDOC (status 03) even though you select 'Transfer Immediately'. As of ECC6.0, function module 'EDI_DOCUMENT_DEQUEUE_LATER should be use between 'MASTER_IDOC_DISTRIBUTION' and COMMIT WORK.

Reference:

http://help.sap.com/saphelp_nw04/helpdata/en/52/16adef543311d1891c0000e8322f96/content.htm

OSS Notes:

150202, 1097730

is sky the limit... status 30 to 03...

SAP R/3 : Constructing form with style

Detailing the form either portrait or landscape can determine if the form can display more information to the user and at the same time can even save paper.

1. It is very important that only certain information are display or user requires. Therefore, user requirement should be carried out in detail so the developer can come out the correct form. However, SAP does provide standard templates according to specific business solution (module). These SAPScript templates are developed by developers as required by users in the industries that has been used for many years all over the world. Hence, these templates eventually assimilated into SAP modules as standard templates.

2. In every form, there should have at least a header, a body and a footer but the body is a must and should exist in every form development. Every form in SAP referring SAPScript and SMARTFORMS. I am not too sure about PDF Forms that is now the rave among SAP Developers. I will surely look into it when time permits. Continue on, as repeated, a header in a form depending on the module it might display information differently. A Sales order, the header will display Sales Order Number, Date Document, Partner address, Delivery address, Company name and address and so on. Each of this can be display separated in a window. This window is not the MAIN window. A MAIN window is a fixed window that usually displays ITEM HEADER, LINE ITEM and ITEM DETAIL. ITEM DETAIL usually display items such BATCH No, SERIAL No, Component dates like Delivery Date, Expiry Date, or even Batch Description.

3. In SD module, it is pretty straight forward, the print program or program that drives the flow and display nature of the form is accordingly GET_DATA, OPEN_FORM, DISPLAY_HEADER, DISPLAY_ITEM_HEADER, DISPLAY_ITEM, and CLOSE_FORM. Each of this subroutine plays a distinctive role in coming up of Sales form. Get DATA normally retrieves primary data especially sales data like price header condition, sales partner and sales document information.

4. In SAPScript, there is one part call PARAGRAPH Element that derives the font attributes and tab alignments. You can do adjustment at this part. Moreover, apart from this adjustment, you can use SAPScript command or TAGS. TAGS for word, text or characteristics specific manipulations are on limited to Bold, Italics and Underlines and ending with forward slash tags . Apart from using tags and SAPScript commands, you can use SAPScript STYLE to manipulate SAPScript templates.

5. SAPScript templates are normally stored in client 000 and if required you can copied them out to your specific client development. Or, you can developed up from scratch only if your requirements are fulfilled. SAPScript development requires not only the basic understanding of form but technique to come up with a stable form. Stable forms will display line items, boxes, lines, and other information accurately (including text remarks, sub totals and grand totals when there is a page break or protected section of a window).

6. It's a good practice to always process your data in the print program before it is display in the form. FORM should always display information only. If FORM should meddles into processing data during display it might get messier and your coding can get disorganize. I am saying the PERFORM of subroutine in INCLUDE from FORM which appears most of the time in MM module. Managing MM forms can be tedious and one should be very careful when managing MM forms especially PO forms because it involves a lot of PERFORM calling from the FORM itself.

7. Lastly, a good UNDERSTANDING of the flow and logic of the print program is important to FORM modification and FORM development.

Below are transaction codes that you can use to create/maintain SAPScript:

SE71 - SAPScript Layout Create/Change

SE72 - SAPScript Styles

SE73 - SAPScript Font Maintenance

SE74 - SAPScript Format Conversion

SE75 - SAPScript Settings

SE76 - SAPScript Layout Translation Sets

SE77 - SAPScript Translation Styles

is sky the limit... SAPScript Concern

SAP R/3 : QM BADI

INSPECTIONLOT_UPDATE is a very good BADI to enhance TCODE especially QA11, QA12 and QA13. It has all the following methods that you can use in your enhancement:

CHANGE_AT_SAVE

CHANGE_BEFORE_UPDATE

CHANGE_IN_UPDATE

CHANGE_UD_AT_SAVE

CHANGE_UD_BEFORE_UPDATE

CHANGE_UD_IN_UPDATE

CREATE_AT_SAVE

CREATE_BEFORE_UPDATE

CREATE_IN_UPDATE

SET_UD_AT_SAVE

SET_UD_BEFORE_UPDATE
SET_UD_IN_UPDATE

It is a very important BADI if one needs to do assignment on updating Inspection Lots and Usage Decision. You can even use this BADI in ME23N from another use exit to auto create Inspection Lot, update Usage Decision and also Shelf Life Expiry Date.

is sky the limit... qm badi

SAP R/3 : READ_TEXT and WRITE_TEXT

In any SAP modules' standard screen functions, users and functionals get to maintain certain text like remarks, vendor notes, and others important elements in the header. These extra notes are stored somwhere in SAP's transparent table. Furthermore, SAP forms and customize forms also make use abundant of such feature like having a certain format of signature stored somewhere at a specific location and later read out to the template for printing or viewing.

These are what I call free texts that is non specific that is not specifically catered by SAP to be saved by certain fields. Hence, these texts are not similar to fields like BUKRS, MATNR, or MEINS but its of RAW format.

"RAW text is a machine readable form of characters or string of characters that is before being process by any analytical software, in this case our very own SAP"

RAW text is gibberish to any developer's view. User or functional will not be able to read it straight from SE16. SE16 won't even show this field that contains RAW format. RAW format for this entry I am referring to non other tables than STXH and STXL. All your free text wheter used in SAPScript or standard screens are stored here in STXL. TCODES such as SO10 and SE75 are both tools for you to create text. Underlying code that keeps such data are RAW format. So the question will be how do i see those RAW text without using those TCODES?

You will need the following functino module : 'READ_TEXT', 'EDIT_TEXT', 'WRITE_TEXT' and so on. You can always refer to this function module's documentation to know more about STXH and STXL tables. Afterall, this is one functino module provided by SAP for you to see RAW format.

This function module is an analytic processing logic to read RAW formatted string of characters. As an ABAP developer, this function module is your next best girl friend to develop/maintain your SAPScript fonts or programs that need to extract long text out from the system.

Another alternative, you can go to SPRO to maintain it.

SPRO->IMG->TO CONFIG TEXT ID

STXH is the text header transparent table

STXL is the text line transparent table

STXD is the text file header

In addition to the above, I found several tables that normally associates itself to RAW format are as follows :

1. VBBP (Billing)

2. EBAN (Requisition)

3. BELEG (JV)

4. PMS (Project and WBS)

I list the following above in the following order of what I usually get acquainted with my daily assignments.

Here's a link that I'd found:

1. Fuller(MIT)

is sky the limit... read text and write text for RAW

SAP R/3 : LOTUS Notes Receive .SCR File

Editor: This will be a simple entry. Source of error is directed at email format receiving at your email end has error.

Email content displayed as .SCR. Recently, my development with SO_NEW_DOCUMENT_SEND_API1 had a problem which my email display its content incorrectly. Instead of the content I wanted, it was attached with a file. This file is a .SCR file. I am using LOTUS Mail and this error had occured at my workplace. I am not sure if any of you guys using other type of email servers having this error. Maybe Microsoft Exchange does not have this issue at all.

Nevertheless, if you come across this issue, you can check out this OSS notes 171698. Again, the attachment in the email display your contents with .SCR file format. This normally occurs if your developer uses SO_NEW_DOCUMENT_SEND_API1 to send notification to users. The problem is not restricted to this FM but other send email function modules too.

OSS noteNote 171698 - SAPconnect: Formats, conversion, and device type.

is sky the limit... 171698, Email as .SCR

SAP R/3 : Spelling Currency to Words

There are a few ways to spell currency into words. However, it is limited to few languages and its denominations that you can maintain in the T015Z table or your server's language. In order to spell a string of currency, for example, USD 102034.00 or VN 23,000 then you will either need to use an SAP standard FM or you might need to write it out yourself. Here are some options:

1. Call function 'SPELL_AMOUNT'
2. Call function 'HR_IN_CHG_INR_WRDS'
3. Customized a function to convert currency that is not supported by SAP

PS: Another option is check SCC4 for your language/currency or see table T015z or TCURC for currency.

is sky the limit... currency to wordings

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)

...

KEY FIELD n

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)

...

CHECKBOX n

CREATED ON

CREATED AT

CREATED BY

CHANGED ON

CHANGED AT

CHANGED BY

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

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: http://isskythelimittechnical.blogspot.com/2007/02/sap-r3-spool-converting-report-to-xls.html

Reference : 857823, 910300 and 959775 and obtain from https://www.sdn.sap.com/irj/sdn/thread?messageID=4770708#4770708

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 http://isskythelimittechnical.blogspot.com/2008/09/sap-r3-alv-limitation.html

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...

SAP R/3 : GET PERNR or SELECT or PROVIDE...

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

SAP R/3 : Trailing The Pricing Condition

Last several weeks, an unusual incident occured at the area of pricing condition in which one of the pricing (condition type) is not populating price correctly. Initial coding were done in one of the user exit to recorrect the value. However, the value was not updated as the functional wanted. So I had to follow the trail of Indiana Jones by tracing the standard program. So below is one of the gruesome steps on how the pricing condition was determine during invoice creation (VF01).

Put a break point accordingly to each of the path below:

1. SAPMV60A (Travel Here)

*****>MV60AF0X_XKOMFK_ENDE

**********>RV_INVOICE_CREATE

2. SAPLV60A (Travel Here)

*****>LV60AU01

********>PERFORM FAKTURA_ERZEUGEN

3. SAPLV60A (Travel Here)

*****>LV60AA26

********>PERFORM FAKTURA_LIEFERBEZ0GEN

4. SAPLV60A (Travel Here)

*****>LV60AA22

********>PERFORM FAKTURAPOSI_LIEFERBZ0GEN

5. SAPLV60A (Travel Here)

*****>LV60AA21

********>PRICING_COPY
******>(INITIALLY JIN1 KWERT IS STILL 0.00)<br>
6. SAPLV60A (Travel Here)

*****>LV60AA60

********>PRICING
******>(At this point, JIN1 KWERT WAS REINITIALIZE TO 0.22 -> Which We do not WANT!)<br>
7. SAPLV61A (Travel Here)

*****>LV61AU01

********>PERFORM XKOMV_BEWERTEN
******>(How all 0.22 started)

8. SAPLV61A (Travel Here)

*****>LV61AA55

********>XKOMV_BEWERTEN
******>(91 - LOOP AT XKOMV - WHERE IT ALL HAPPEN!)
******> KSTEU and KMPRG (This is the two brothers that caused it!)

Therefore, we had the good owner to initialize the KSTEU and KMPRG to a certain value so it the value can be remain as the Functional wanted to meet the requirements.

is sky the limit... pricing procedures rocks!

SAP R/3 : User Exits in VF01

Something to help everyone on all the userexits and BADI for transaction code VF01. VF01 is to create invoice. Below are the list of all userexits and some BADI invoke (maybe). In which of late, i had a headache to check out why VF01 had problem in creating invoice successfully.

EXIT_SAPLV60B_006
EXIT_SAPLV60B_002
EXIT_SAPLKBER_002
COPA_CALL_CUSTOMER_EXIT_KEAB04
EXIT_SAPLKEAB_003
SD_CIN_LV60AU02
EXIT_SAPLMCS6_000
EXIT_SAPLMCS6_999
EXIT_SAPLMCS6_001
BADI_SD_DOCUMENTFLOW
IDOC_OUTPUT_INVOIC
SDVFX010 - for those who wants to do something during SAVE

In any way, if you find this user exit unable to help you and would want to know more if there are other user exits. You can always punch up the ST05 to do an analysis on your VF01.

is sky the limit... user exits on VF01

SAP R/3 : Sending Multiple PDF Invoice From Output Type

Sending email with an invoice attached to it has never occured to me if it can be done without the working mechanism of business workflow. The requirement was fairly simple during discussion and it was seriously sounded simple enough to put it straight to development immediately. However, I am not very familiar with business workflow. So the question now was how am I going to send an email out with an invoice attach to it. So here is the requirement in question:

"When user create an invoice via VF01 or from a customized IDOC that creates invoice, several output types are created and one of them is an outbound IDOC that will send back to the sender to let them know invoice has been created. Now, after the invoice and IDOC has been sent out, there should be a mechanism to check whether the outbound IDOC is successfully send out. If it is successfully sent out, the mechanism will grab that invoice, convert it to PDF, attach it to an email and send it to responsible recipients..."

Oh boy, it sounds easy to one who is not aware of the workaround behind or does it sounds very technical to one who has minimal working knowledge on it? I was the latter. So below are some of the questions which had formed in my brain:

1. How do you grab an invoice which has been produced by the system (VF01)?
The CLOSE_FORM function module will return a spool no when the SAPSCript has finish processing and display.

2. How do you convert an invoice to a PDF?

The CONVERT_OTFSPOOLJOB_2_PDF function module take the input of SAPScript and returns in PDF format.

3. How do you attach a PDF to the email?

The SO_NEW_DOCUMENT_ATT_SEND_API1 function module will hold the PDF

4. How do you send an email?

The SO_NEW_DOCUMENT_ATT_SEND_API1 function module will hold the PDF and send the email

After giving some thoughts to those questions above, now comes the big part of the whole mother of all questions:

How on earth at which point in the VF01 should I initiate this whole process?

So the my mind start to processing again. The answer to this might be using USER EXITS or Business Add-Ins (BADI). These two solutions seem to be the most absolute answer to the problem. However, when I revealed a solution at the end of this entry, you might find it with disbelief. But to the very few people who started with that solution was real good! Now, let me tell you what I had implemented initially to cater to that problem.

I went ahead to ST05 to get down all the USER EXITS and BADI from VF01 so I see which of them are more suitable to initiate this process. Doing so, I'd found one, it was XXXX. At this point, my imagination went beyond. Somehow, it is sometimes bad to venture too far from my own imagination. Because the next step I wanted to know how do I check the outbound IDOC's status from this USER EXIT XXX. It was simple, I used transparent table NAST and EDIDC to check the outbound IDOC's status. If its status are 03, 30 and XX, then it should go ahead to process the invoice convertion and IDOC send out. For the time being I'd solved 2 major problems.

Next, I need to get the latest invoice to do conversion. Unfortunately, with the current USER EXIT, I might not be able to get that SPOOL ID because it has not been created yet. VF01 has to be finished first. This pose another problem, how do I let VF01 finish off so I can get the SPOOL ID? After an overnight sleep, I decided that creating another RFC function module in the USER EXIT will do the trick. An RFC that executes with a new process created in the background. Thus, with this RFC initated as a new process run and letting the VF01 to finish processing, I can get the SPOOL ID.

Hence, I was definitely sure that my concept will surely work. However that will not work. Because of the RFC that i am using, it will cause overlapping. If you ever do my silly method, you will come across overlapping problem. RFC does not care if your PDF has been generated and sent by previoius document. It will just grab and resent everything including the new. Thus, my way does not work.

The only solution is to have the PDF converted, attached and sent from the print program. Not only does this eliminate duplicates of document but will ensure that it will not sent out duplicate copies of form due to overlapping. Printprogram should be any program that is used to process and display your SAPScript. For any standard program that prints forms, you can go to NACE to find out which program and form that it is using for print out. This way you also know the output type that is used by the standard program.

is sky the limit.... print, converting and sending...

SAP R/3 : Tracing Outbound IDOC

Troubleshooting outbound IDOCS can be very exciting and interesting activity. You get to see the wonders of sending data out of SAP to some other 3rd party systems. If you are unaware of some technicalities and behavorial of outbound IDOCS then testing it can be quite a challenge. Recently, I had this problem of trying to trace an outbound IDOC.

Previously, I could trace the outbound IDOC with minimal difficulty in WE19. If you put a break-point in your outbound process code or function module, the WE19 will stop at that point. But, what if WE19 fails to stop at that point? You will be scratching your head until you reach to a certain point you want to write an extra program just to trace the outbound IDOC. That is just what i did. Read my statement, I wrote an extra program to do that.

Though its a bit consuming but if you know which table and which fields to use then the concept will work just like the my now ever loving standard output type program RSNAST00. I shall have to thanks one person who let me know this existing program. But first, I would like to let you know what I'd gone through the latter method.

To developed an extra program to trace outbound programs is not as difficult as it seems. All you need is declare three tables i.e. NAST, EDIDC and EDID4. NAST is the output type control table that stores all of your 6 output types from printout to telefax. EDIDC is the IDOC control table. EDID4 is the IDOC data table. Therefore, you need to access the first table, NAST, in order to get the output type that you are supposed to execute. After you had obtain the necessary data from NAST, you will need to approach the EDIDC to get the DOCNUM and subsequently the EDID4 for its data. Then you pass all these three data selected data to your outbound's function module. Therefore, you can primitively test your outbound data. However, you will still need to set your output type to be scheduled run at other time.

Now, let us move on to life saving method to test your outbound IDOC or output types. In any of your standard programs that can send out IDOC, Telefax, Print out, set it to 1 (scheduled run at other time) in the FURTHER DATA section. Then you turn to RSNAST00 program where you put in your APPLICATION, OBJECT KEY, MEDIUM and OUTPUT TYPE. Before executing, put a break-point at your function module. Then you are ready to trace your outbound IDOC.

A note, the RSNAST00 does not only let you trace your outbound IDOC it is in fact a standard program that let you execute output types that you have schedule for later run. Hence, a very great thanks to Vincent Teoh from the SD (Sales and Distribution) module team. The RSNAST00 had definitely helped me a lot. Though I am still keeping my old program for reference. Concept still work very the same like RSNAST00.

is sky the limit... RSNAST00 and NAST, EDIDC, EDID4

SAP R/3 : Payroll Detail and Field Symbol

Very similar to a past report which I had done and requires it to display dynamic numbers of column and it occurs to me maybe I should just put a template here and share it with everyone who are using it. The report which I had just completed displayed list of employees with all of their basic pay, allowance, deductions and employer contribution from left to right.

Thus, any employee at one point might not have the same number of wagetypes [allowance/deductions] with hers or his peers. So the list that displaying those wage types will need to be very flexible when its display an employee and spreading their wagetypes to right of the report. Here goes the coding that I used to display it dynamically.

Assumingly your field for wagetypes in a structure looks like below:

DATA : BEGIN OF ta_wage,

pernr like pernr-pernr,

col001(010) type c,

col002(010) type c,

col003(010) type c,

col004(010) type c,

...

col050(010) type c,

DATA : END OF ta_wage.

As you see the above data structure has 50 columns. Each of this columns will hold a number of wagetypes [allowance/deductions] for an employee. So it should be dynamically to recognize a column that is occupied and to append it with the next employee's wagetype. Otherwise, it will use the next column.

Thus the coding to recognize the degree of each column that spread from left to right is as follows.

DATA : tp_ind(003) TYPE n.

CONSTANTS : cn_col(011) TYPE c VALUE 'TA_WAGE-COL'.

FIELD SYMBOLS : TYPE any.

LOOP ta_wagetype.

DO VARYING tp_value FROM ta_wage-col001 NEXT ta_wage-col002.

IF tp_ind = 50.

exit.

ENDIF.

CONCATENATE cn_col tp_ind INTO tp_dyncol.

ASSIGN (tp_dyncol) TO tp_value.

[add your logic here]

ADD 1 TO tp_ind.

ENDDO.

ENDLOOP.

Notice that i had declared an index variable to hold the count of item; a constant to assign to a field symbol to capture the column dynamically; and the field symbol to move contents fluidly (in my terms not SAP official explanation).

After that i perform a DO VARYING in the INTERNAL TABLE ta_wagetype so that for each employee, I can scroll the columns dynamically to the right and get the content. As I go to the right of each column's content I can actually assign a new value, shift left or shift right and determine which is the last column that it last stop.

is sky the limit... do varying and field symbol...

SAP R/3 : Transaction Codes

I have gathered a few important transaction codes along the way in my projects and it had helped me a lot. Here are the following and I hope it will help you like it had helped me in the past, the present and the future:

SE43 - Menu Customization

SE93 - Transaction Code Maintenance

SE16N - Enjoy Screen version of SE16 for data viewing
SCC1 - Transport Copy

SE18 - Class and Methods templates for creation and maintenance

SE19 - Class and Methods maintenance

PA03 - Payroll Run - Release

FS00 - GL master data maintenance (create, change, delete, display)

FK03 - Display vendor master data

FK01 - Create vendor master data

FK02 - Change vendor master data

F-02 - FI posting

S_ALR_87012086 - to be confirmed

PC00_M99_DKON - GL account and wage type display (payroll)

PE01 - Schema maintenance

PA40 - HR maintenance
RSTXSCRP - SAPScript Export/Import


is sky the limit... transaction codes

SAP R/3 : GUI_UPLOAD with # as SPACE...

There are many times when we need to upload a text file into an internal table we are not aware that the SPACE among the line of strings in the text file is represented as '#'. When we unknowingly get a row of items and started to split it, using SPLIT syntax with the normal '#' symbol, into the columns of your internal table then we get garbage or unreadable contents in the internal table.

That is because the space is not recognized during upload by GUI_UPLOAD function module. The SPACE among the strings of line items will be replace by '#'. However, this hash or '#' is not your average character '#' but it is an ASCII character of value 09. Thus it showed as '#' in your strings of line items.

Therefore, you will need to do something in your coding so you can SPLIT your string of items properly with the '#'. So, you have to declare a variable with X and value of 09 at the begining of your code. Then only you can use it in your SPLIT syntax. For example, the code below.

Data : tp_hash TYPE x VALUE '09'.

Data : tp_result1(15) TYPE c.

Data : tp_result2(15) TYPE c.

Assuming variable tp_file-item contains 'WILLIAM#WILSTROTH' and obtained via GUI_UPLOAD.

SPLIT tp_file-item AT tp_hash INTO tp_result1 tp_result2.

Write : / tp_result1, tp_result2.

Thus, it now shows:

William Wilstroth

is sky the limit... split with ASCII 09... not #...