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