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