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