To all dear readers, sorry for this late post. I was away for the Christmas Holiday. Oh, btw, Merry Christmas and a happy new year to all.

Anyway, back to our usual SAP topic of discussion. While we're trying to create a datamart in SAP BW by linking an Infocube to another infocube, we stumble into this problem: How to create the datamart infosource infopackage.

You see, we're able to generate the datasource from the cube and all, but the problem is, infosource for the datasource didn't show up in the "Infosource directory". So, we're not able to generate the infopackage. We did a hack by creating a customized "infosource" and linking it with the generated-datasource. But this solution is just that, a hack.

So, I meditate on this problem and the "divine" inspiration told me to right click on the Infosource directory. And what do you know, there's the option for "Insert Lost Nodes". I did just that, and walla, the generated-infosource is displayed in the "Infosource Directory".

I guess, since we did not install the business content for the "infosource directory structure", the generated datamart infosource cannot tag itself to an infosource area, thus becoming the "lost nodes". So, that's how we solve our problem. Like Occam's Razor (spelling?), the simplest explanation is always the right one.

Recently, I needed to extract some data from R/3 HR to do some reporting. Using "SAP Bag of Tricks" I activated the BW-OM business content, configure the relevant datasource in R/3, create infopackage yada-yada, you know, the boring stuff.

Anyway, the point is, after doing all that, my infocube still did not load all the necessary master-data information into itself. I change the update rules, reload again. Still, no changes. This stubborn infocube, just simply refuse to recognize the master data, even though the information is in the infocube to extract the necesary information. You see, in the update rules, most of the characteristic in the business content cube 0PAOS_C01 is derived from the master data 0EMPLOYEE. But somehow, when loading data into the cube, the characteristics is just not loaded.

Annoyed and highly agitated, I finally post a question in SAP Developer Network regarding my dilemma. In just a few minutes, some helpful soul out there answered my questions and bingo! It solved my problem. You see, the problem is, I didn't realize that some of the master data is not activated. I did activated it before, but someone did something, and caused all these activated and loaded master data to become deactivated.

So, I re-activated the master data, and reload the infocube from PSA, and presto, the data is loaded! The moral of the story people, is that when in doubt, seek the wise SDN forum. Some "enlightened" soul will fulfil your quest for knowledge!

Thank you, whoever you are.

I was browsing through SAP Developer Network, when I came across this interesting blog: Interfacing data into BW using Perl, Ruby, or Python. Well, being a "no longer active" open source advocate, I love the idea of being able to interface data into BW using open source tools.

What better tools to use then the language of ruby, the birth mother of the "super framework" of the almighty "Rails". FYI, Rails is a framework to develop web applications in super-fast time and less-codes. Well that's the promise anyway. Also, developing AJAX enabled web application is a breeze.

So, without wasting time, I installed ruby using the Ruby One Click Installer and installed mysql for database. I created some mockup data to simulate data load to BW and these are my assessment:

1. Method is only feasible for delta loading, as it uses XML-SOAP interface to load data into BW.
2. Before creating XML datasource, you have to create a "mockup" Flat File datasource. The generated BW XML datasource will be created based on this flat file comm and transfer structure.
3. When creating the Info Package based on the generated datasource, under "update" tab, choose "Initialize Delta Process" and "Initialize Without Data Transfer".
4. Schedule the load. Now under RSA7, your delta queue will be there.
5. Now create another infopackage, choosing "Delta Update".
6. Everytime data is available in the delta queue, the data will be loaded to the data target when the scheduled delta update info package take place.
7. Infocube cannot be used as a data target for this XML delta update. Instead use an ODS which can push the data to an infocube later.
8. 0RECORDMODE is a necessary field in the transfer structure for this delta process.

And yes, it works folks! So, if you need interfacing to some unknown proprietary system, this is one way to solve it. Bravo Piers for a job well done!

In the world of IT, one cannot separate themselves to the "awesome power" of Project Timeline. Gone are the days where a project implementation consist of having an "idea", and implementing it overnight based on an adhoc discussion between geeks. Now, with the technology of Microsoft Project, all IT based project must be properly planned; time and resources tabled out using a gantt chart and such. And thus was born the role of "Project Management" in any IT project implementation.

Well, SAP, being a humongous beast, cannot escape this necessary "evil". As always with SAP, they have their own term to describe the overall "project implementation lifecycle". Instead of the usual waterfall "Spec Analysis Design Implementation Testing Evaluation Maintenance" cycle, they use a more catchy terms. So here, ladies and gentleman we have SAP project implementation lifecycle:

• Project Preparation
  This is the phase where all the mumbo jumbo such as "Defining Critical Success Factor", "Business content GAP Analysis", "Define System Landscape", "Capacity Planning" etc takes place.
• Business Blueprint
  This is where a "blueprint" or the document which contains the "design" on how the SAP system is going to be configured will be documented in detail. Customer must agree to this before the actual configuration/customization takes place. I would like to call this phase, the "Hell and Fire Fighting Phase".
• Project Realization
  This is where the "dirty work" take place. Configuration, customization, interfacing blah blah blah you name it, is here. Heck, even Quality Assurance (if you defined a Q-system landscape) is here.
• Final Preparation
  This is nearing the end of implementation. Here is where all the last minute stuff like Setting up Production environment, conduct system test, end user training etc is conducted.
• Go Live and Support
  System is "Live" here. Any quirks will be observed here. Also, any validation of Live Business Process is done here. Last but not least, support for the live system is done here too.

So, that's all folks. SAP Project Implementation Lifecycle.

Yes, yes, I know I should be talking about SAP, being an SAP blog an all, but I just can't resist to tell you about the recent movie that I went to: Harry Porter and the Goblet of Fire. All I can say is, "Wow!". This is more like it. Much darker and more gloomy in nature. My kind of movie. Feels like the "doom" you feel in the "Lord of the Rings". To all, yes, I do recommend watching this movie. I'll give it 4 out of 5 stars.

Now back to our usual program.

One thing I realize about SAP, is that the way they structure things, there's a clearly separation between technical roles, and the so-called "functional roles". Functional roles is divided into the respective modules. A typical functional roles looks something like the following:

• SD/MM Consultant
• FI/CO Consultant
• PM/PS Consultant
• HR Consultant

etc etc. Basically, functional people are the "domain expert" of the module. They are the ones who'll be facing directly with the users, gathering requirements, and configuring the modules to suite the clients business process.

The technical roles is the supporting the roles. They're the ones who will customize, fine-tune, install, etc etc to support the functional team. A typical technical team looks like this:

• BASIS consultant
• ABAPers
• BW consultant

Clear separation between these roles means greater benefit attain from specialization. But the drawbacks: it's harder to find someone who can look at the "bigger picture", the overall perspective of the SAP system.

In other words, no one person can claim that they know everything there's is to know about SAP. To claim such a thing would be an outright blatant lie!

While surfing the web to find SAP resources, I've encountered this interesting site:SAP Blog.

If my site describes how an SAP Newbie view the SAP world, his site gives a SAP Pro view, ones who've been in the industry for quite sometime.
Quite an interesting resources. He describes his experience of becoming an SAP consultant, how he joined the SAP world, the hardship, the rewards etc.

I hope, with more SAPians joining the blog community, the mystery and misinformation that's been surrounding SAP will be finally dispelled. Yes, yes, I know you guys are busy, being a consultant and all, but it's good to share with the world what SAP is.

Have you ever wondered, how some company managed to implement SAP ERP in less than say 3 months? Sounds like a load of crap right? Actually it's possible pending the following conditions:

• No customization. All ERP processes follows the SAP processes.
• Business content are used

You see, SAP consultants have one trick out of their sleeves. That is using pre-delivered SAP Business Content. What the hell is this "Business Content" thingy? The short answer is, after extensive research done by SAP AG, the've created a sort of "template" as a basis for consultants to use in implementing SAP. This so-called template can have further categorization according to industry, such as "Retail","Oil & Gas" etc etc.

Using this "business content", consultants can shorten the implementation of SAP. Instead of having to create everything from scratch, they just need to configure a few stuff, and walla, we have an "SAP out of the Box"!!

But again, depends on customer, sometimes on top of the "business content", they still want to customized something to suit their existing business processes.

Lucky are the consultants who could find such miracle-customers who want to follow the SAP business process 100%, and are willing to use the pre-defined Business Content delivered by SAP! Amen.

A normal Profit and Loss statement usually contain some Revenue portion, and some Cost portion, and most of the time, there's a section where you deduct the cost to get the net profit yada yada yada.

But to do that in SAP Business Explorer proves quite a challenge especially if the row is in some sort of hierarchy format. The work around this is, yes, you got it, to combine 2 or more query into one worksheet, to create the "illusion" of having it all in one statement.

So how do you combine more than one query into BEX? Simple. Follow this step:

1. Click on "Tools" icon.
2. Select "Insert Query..."

and Walla! You got more than one query into your workbook. Don't forget to save the workbook for later use.

See, nifty trick eh? But a better solution would be a way to have a calculated row that computes from the revenue portion, and the cost portion. Any SAP Guru out there willing to give some tips on how to achieve this? Oh well. For now I guess I have to be contented with this sort of "hack" :)

When I started to 'play' around with SAP Business Warehouse (BW aka BI), I thought that I would forever leave the role as a "programmer" behind. I thought, finally, I can concentrate more on "configuration" and "designing".

Well today proves that inevitably, it all boils down to good ol' hacks. You see, I want to create this report which includes a Quarter-to-date (QTD) columns. But, instead of creating a variable where the user enters which quarter the month resides in, I want to be able to use the existing 0FISCPER variable already created previously. So, what I need to do is create a customer Exit variable which will take the value of 0FISCPER variable, and find the appropriate QTD range.

Unfortunately, this customer Exit, can only be created using ABAP codes, and not just a simple Formula thingy. So here's what I did:

• Went into SAP enhancement screen (T-code: CMOD) and create a new project.
• Add the following enhancement assignment: RSR00001 (Enhancements for global variables in reporting)
• Adopt the existing include sample functions and start changing the include file 'ZXRSRU01'.

Here's some descriptive info on what you need to do in the function:

I_VNAM: The variable name.
i_t_var_range: contains all the information about the other query variables available in BW.
l_s_range_low: Is the low limit value of the variable. For non-interval variable, this is the value.
l_s_range_high: Is the high limit value of the variable. Make sense only for interval type variables.
l_s_range-sign: denotes whether it's 'I' inclusive, or 'E' exclusive. Again, make sense for interval type only.
l_s_range-opt: what type of variable, either 'EQ' equal-type, or 'BT' between-type (interval).

Another lesson that I learn in ABAP is that:

some_variable = A + B

not equal to:

concatenate A B into some_variable

In other words, string not the same as add operation. I assumed it's like Java fixed string, which is not.

All in all, it's a good experience :)

I'm stuck. I have this customized Key Figure i've created based on an existing InfoObject. When I tried creating update rules for this key figure, it does not propose update rules for this customized key figure. My question is, how do I add the customized key figure into the update rules? Any SAP-BW Guru out there willing to help? TQ.

On another note, I think i've ran out things to say about SAP in general. Why? Well I guess the bulk of the itty gritty stuff is coming to an end. See, the most headache part of any implementation is during user requirements gathering. Or in SAP terms, the "Blueprint Phase". Now it's nearly coming to an end, I've no juicy stories to tell :)

But I guess my post after this would be more technical in nature as I want to document stuff that I've discover during "Realization Stage".

Updated (22/11/2005): Actually I did a mistake. When creating the "Key Figure" instead of entering the existing InfoObject into "template", I accidentally put it in the "reference" box. That's why it's not appearing in the proposed template.

When the SAP marketing guy promises this and that, be forewarned that what is promised might not be what you're gonna get after implementation.

This is the main culprit for every implementation headache. The marketing guy will say this and that, but in actuality it's different in SAP.

For example, they will say BW can produce report with a "single-click of a button and it's very flexible". But when comes to implementation, we know better that it's not the way things work.

Why? Well to produce a report there's a whole chain of process that needs to be done in BW to support that reporting. To add even one field for reporting, will require changing various steps, from transfer structure, to communication structure, to even the data target level (infocubes and such).

See. Not that flexible eh? Well to all the marketing guy, next time, please do not promise something that you know the technical team cannot deliver. Set the user expectation right from the start. Saves a lot of headache and "RESCOPING" later.

Deepest condolence to our PM Pak Lah for the passing of our First Lady Datin Seri Endon Mahmood. Al-Fatihah.

Yep, most Malaysian News Portal have been jammed by massive http requests as of now.

Yes ladies and gentlemen. There is such a "pain in the ass" in the SAP world. And you will only feel the full blown of pain during data migration.

Why? Because most likely, your users will want to migrate all the historical data that they have in their previous legacy system. Hell, they might even want you to migrate all the manual documents since the company was formed!

But guess what, the general guidelines for an SAP legacy migration is "open item" and "balances" only. What does this mean? Well, let's say you have an invoice that has not been completed yet, so all data in the legacy system pertaining to this invoice is considered an open item. What about all the completed ones? That my friend, won't be migrated to SAP.

This statement alone will invoke the fury of the users. Why such limitation? Why do we have to irritate the users with this statement? The reason is due to the integrated nature of SAP. If you wanted to migrate the information about the invoice, most likely you need to feed some other information that won't be available in the legacy system in the first place. Therefore, migration of that completed invoice doesn't make sense.

So, in one hand you have the users who will pressure you to migrate all historical data available. And yes, they will make all sort of justification (including but not limited to "legal or statutory requirement"). And in the other, you have the "SAP guidelines" for a hassle-free implementation and no data-integrity issues.

My advise: Thread wisely.

If there is such a thing as a holy grail in SAP, then I think it would be the the Charts of Account (CoA). This chart of accounts will determine the structure of the financial elements of the SAP implementation and this will chain-react to the other SAP modules.

So, what the heck is CoA? CoA is like a big animal. Simply put, it's a list of accounts to be used in a company. This CoA has a few elements in it to bring meaning to the financial accounts.

An example of the elements of a CoA is:

• GL Account No - Simple number of a General Ledger (GL) account
• Cost/Profit Center - An organizational unit that's a sales dog (profit center) or just a big spender (cost center)
• Yada yada yada (too mouthful to mention)

All these elements will define the CoA. So, any GL entry, should have part or all of these information to make a really good posting. Thus, a good CoA, will make financial analysis a breeze. Things like Profitability Analysis, Cost Analysis will become much much more meaningful.

So, what happens if suddenly some tom,dick or harry decided to change the CoA in a middle of an SAP implementation? All hell break lose!!! I pity those SAP consultant who's in that kind of situation.

Recently I had the opportunity to learn the ABAP programming language. ABAP is the "interpreted" language use to create the core modules in SAP R/3. Well actually they called it "Advanced Business Application Programming". Anyway, what I'm saying is that you can use the 'Repository Information System' to browse for any application component and lookup the exact source code for each T-code say FB50 - GL Posting.So, in a way, yes, SAP R/3 is open source.

Well back to our discussion on ABAP, it is an easy language compared to Java, C++ etc. But, to achieve an objective, say you want to get some records and display, there's like 10 or more ways to do it!

You can create a working area, populate it line by line from transparent table, or you can create an internal table to achieve the same way. Well in fact, in creating the working area you can a) create your own structure type or b) use an existing structure in the ABAP dictionary.

In other words there's no right or wrong way. Therefore it's pertinent to a Team Leader to dictate what kind of standards you should use. The reason being is that ABAP is backward compatible. Since the 70's the've been using ABAP, so the coding during that mainframe (R/2) time can still be used in an R/3 environment.

So yes, it's a program that speaks many languages. Which language, is up to you.

One thing about SAP that distinguish it from other applications is the way it position itself. Call it the German stubborness or arrogance. But one thing is for sure. SAP changes you. Not the other way round.

SAP consultants will repeatedly through the use of the word "Best Practices" try to convince you to change and follow the SAP processes. So, if you're use to be doing something i say 3 steps. Implementing SAP, might mean that you might have to do it in maybe 1 step, or perhaps in 5 steps. You see, there's no way in hell the consultant would want to write an ABAP program just so that they can customize SAP to be exactly like the way you run things.

Using SAP means that "YOU" have to change! Yes. Resistance is Futile. Prepare to be assimilated by the Germans! :)

While SAP R/3 is used for the day to day operational 'boring' stuff, like Finance, HR, Procurement, the SAP SEM or Strategic Enterprise Management module is used to complete the overall big picture of an Enteprise Management.

Using SEM, we can see the 'birds eye view' of the overall company. All the processes and interactions between the R/3 module (HR/SCM/FIN/EAM) will manifest itself in SEM and provide us with the bigger picture.

Thus, SEM is a powerful tool for CEO's, Strategist, Planners of a Company to see snapshots of how 'healthy' the company is doing. Using 'Management Cockpit', 'Business Planning and Simulation', and 'Balanced Scorecard Strategy Management', a CEO can decide what's the best way to run and fine tune the company. With the information at hand, he can decide the next move of his company. Like a seasoned chess player, he will move the pieces with the help of a powerful ally, SAP SEM!

Therefore, any SAP implementation will only be complete with the addon of SEM components.
Without it, it's kinda like the story of the 3 blind men who felt the different parts of the elephant. Each of them will have a different interpretation, without being able to see the bigger picture.

Previously in my post, I highlighted that SAP consultants love to use short-codes / abbreviation to explain the mechanics of SAP. Today, I will explain few of the short codes widely used in SAP to illustrate the point.

• SAP R/3
  Is the 3-tiered transactional business application of SAP. 3 means 3-tiered, presentation layer (SAP GUI), application layer (ABAP layer), and DB layer (Oracle/Mssql or any other DB).
• FI - Financials Accounting
  This is the core module of R/3. Every other module is tightly integrated with FI. FI is where the accounting book, GL (General Ledger), AP (Accounts Payable), AR (Accounts Receivable) resides.
• CO - Controlling
  This is the "management" aspect of financial. Costing, Revenue is determine here. You can define Cost Center, Profit Center, Cost Object, Internal yada yada yada here. This is used by management to plan cost/revenue flow effectively.
• HR - Human Resource
  Anything related to people.
• AM - Asset Maintenance
  Management of fixed asset, purchase, depreciation etc.
• PS - Project System
  Use for management of Project related stuff. Either it's CAPEX, OPEX or Customer in nature. You can define level of WBS (Work-breakdown structure) of the project.
• PM - Plant Maintenance
  Everything related to equipment preventive maintenance, management etc.
• MM - Materials Management
  Procurement and inventory tracking. This is where you can have the so-called 'Just In Time Inventory'. Gone are the days of having a huge warehouse just to store spares.
• SD - Sales and Distribution
  This module handles from customer sales order to delivery of product, and billing.
• ABAP - Advance Business Application Programming
  In house Business Programming Language of SAP. Instead of manipulating database directly, you use modified OpenSQL to access Business Objects.
• BW - Business Warehousing
  Unlike R/3 which is OLTP in nature (transactional based), BW is an OLAP (analytical in nature. Used for statistical reporting and such) tool. It handles data ETL (Extraction, Transformation and Loading), query, and complex analysis. BW can obtain it's source from different source system, be it SAP R/3 system, or from different sources altogether.

There. This is just a small list of what to come. Yes, I do get lost sometimes with all the jargon and stuff. But nothing beats this typical conversation with an SAP consultant: " Hey, can you SAP Logon into R/3, check in FI module and make a GL posting FB50 so that I can create an ABAP program to interface with BW, to produce a nice report using Bex?".

Anyway, I guess the reason for all this short codes is, SAP is a screen-based, dialog kinda module. So, every transaction is attached to what they called a T-Code. For example, to make a GL posting you only need to type 'FB50' in the SAP GUI command line. Thus leads us to the overzealousness use of abbreviation in the everyday life of an SAP consultant.

Before we even begin to delve further into the core of the SAP, we need to ask ourselves the main question. What is SAP? Does it stands for "Sistem Ayah Pin"? Or could it be a "Systemic Abundance of Pain"? Call it what you may, but in reality, it stands for "Systems, Applications and Products". Well not exactly correct. The original acronym should be something in the German language which I don't bother to find out.

Personally to me, SAP is a "System that caters All Possibilities". Before knowing SAP, I'm just like any other software developer who prefers to code stuff from scratch, or use some open-source stuff like PHP or MYSQL to develop software like say, An Asset Management System. But after a few hours of introduction to SAP, I knew that my "Homegrown" system is far more inferior than what SAP has to offer.

For example, my Asset Mgmt System only provides the usual Asset system like asset tracking, registration, preventive maintenance etc. But SAP, not only provides that, but the whole system is tightly integrated with Financial Elements, heck even HR is tightly integrated with it's asset system. Hell, after browsing the SAP solutions website, I knew, the project that I'm involved in only caters a small portion of the complete solution of SAP. We're just using the standard mySAP ERP solution + SEM BW stuff whereas, SAP provides more, including Product Lifecycle Management and Even CRM. I mean with the right customization, I'm pretty sure SAP can do my laundry too!

But with all greatness comes a flaw. Like Superman who's vulnerable to Kryptonite, SAP is so complex that when I first started in this project, I was completely blur! To make matter worst, SAP consultant like to use short-code. Stuff like FI, CO, MM, SD, PM, PS, HR is assumed to be well known to the uninitiated public! I will elaborate further on this in my future posting. For know, let's just assume that SAP is a world of jargon.

Anyway, to sum up the above, SAP is complete integrated solutions that covers the whole spectrum of Enterprise Applications, be it Back Office ERP Functions, or Customer-Facing CRM and Product Lifecycle Mgmt system. There. What a mouthful.

"A journey of a thousand miles starts with a single step.", thus said wise-old Lao Tzu.

Like all journey, this one will start with the first small step into the unknown. Filled with uncertainty, doubt, confusion, and an almost child-like naivety. Here, I will document my journey towards attaining "nirvana" in the world of SAP.

Thus born the "Chronicles of an SAP Newbie".