Saturday, September 12, 2009
Thursday, August 13, 2009
Friday, August 07, 2009
1. Is it the print program that causes it?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?
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?
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?!
Who made the changes?
What changes was made?
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.
10. SAPMV45A->MV45AF0B_BELEG_SICHERN->BELEG_SICHERN->NUMBER_GET_NEXT(654)->GET VBAK-VBELN
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!
1. A new SO no.2. A new KNUMV3. A table of determined pricing condition with no KNUMV yet.
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?
Tuesday, May 12, 2009
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.
Tuesday, February 17, 2009
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.
Friday, January 16, 2009
is sky the limit... qm badi