Chronicles of an SAP Newbie

Virtual Remote Cube

2008-12-20T02:45:00.002+08:00

There's times when you want to model an infoprovider, but you don't really want to store any data contents into it. Well, for that, the virtual remote cube comes in handy. This 'beast' can be used to 'act like an infocube, feel like an infocube, but is not an infocube', You can create this virtual infoprovider, having the same structure similar to infocube, with dimensions, characteristics and key figures. But the actual generation of data for this cube, is, well depends on your making.

You can choose to create a virtual provider with a 'direct access' to R/3. This means that upon viewing the data in this virtual provider, a remote function call is called direct to R/3 to get the values on the fly. You can also choose to get value from a function module of your calling, so the implementation details is really up to you. Now that's really flexible ain't it?

So how do you create this? In BI7, just right click on any infoarea, and choose create 'virtual provider'. For direct access, you choose Virtual Provider with 'direct access'. There's an option to use the old R/3 infosource. What this means is that you can create an infosource with transfer rules and such, and when you create the virtual infoprovider, it will use the structure in the infosource automatically and the flow of data is automatically link R/3 with the transfer rules and the virtual infoprovider. Note that no update rules exist with this kind of setup.

But in Bi7, you have a more flexible approach in that you can create a transformation to configure the 'transfer logic' of your virtual infoprovider, along with start routine, end routine or any other transformation technique visible with using a transformation rule.

But using BI7 setup, you need to create a sort of 'pseudo' DTP, which doesn't actually do anything, meaning you do not 'execute' it to start a data transfer.

After all is done, you need to right click on the virtual infoprovider and choose 'Activate Direct Access'. If you use Infosource, go to the Infosource tab, and choose the infosource. If you're using BI7 setup, choose the DTP related to the transformation and save it.

Now your virtual provider is ready to be used!

A word of advise though, a virtual infoprovider with direct access is really slow if you have a lot of records transmitting between the remote function calls. So, thread wisely!

BW IDOC Status

2008-12-07T17:12:00.002+08:00

Sometimes, when we load data to BW, it's important to know the idoc status of the loads. There are times when the load is stuck and it's good to know the reason why.

Anyway, here's a list of some of the known IDOC status:

00 Not used, only R/2

01 IDoc generated

02 Error passing data to port

03 Data passed to port OK

04 Error within control information of EDI subsystem

05 Error during translation

06 Translation OK

07 Error during syntax check

08 Syntax check OK

09 Error during interchange handling

10 Interchange handling OK

11 Error during dispatch

12 Dispatch OK

13 Retransmission OK

14 Interchange Acknowledgement positive

15 Interchange Acknowledgement negative

16 Functional Acknowledgement positive

17 Functional Acknowledgement negative

18 Triggering EDI subsystem OK

19 Data transfer for test OK

20 Error triggering EDI subsystem

21 Error passing data for test

22 Dispatch OK, acknowledgement still due

23 Error during retransmission

24 Control information of EDI subsystem OK

25 Processing despite syntax error (outbound)

26 Error during syntax check of IDoc (outbound)

27 Error in dispatch level (ALE service)

28 Not used

29 Error in ALE service

30 IDoc ready for dispatch (ALE service)

31 Error - no further processing

32 IDoc was edited

33 Original of an IDoc which was edited

34 Error in control record of IDoc

35 IDoc reloaded from archive

36 Electronic signature not performed (timeout)

37 IDoc added incorrectly

38 IDoc archived

39 IDoc is in the target system (ALE service)

40 Application document not created in target system

41 Application document created in target system

42 IDoc was created by test transaction

50 IDoc added

51 Application document not posted

52 Application document not fully posted

53 Application document posted

54 Error during formal application check

55 Formal application check OK

56 IDoc with errors added

57 Test IDoc: Error during application check

58 IDoc copy from R/2 connection

59 Not used

60 Error during syntax check of IDoc (inbound)

61 Processing despite syntax error (inbound)

62 IDoc passed to application

63 Error passing IDoc to application

64 IDoc ready to be transferred to application

65 Error in ALE service

66 IDoc is waiting for predecessor IDoc(serialization)

67 Not used

68 Error - no further processing

69 IDoc was edited

70 Original of an IDoc which was edited

71 IDoc reloaded from archive

72 Not used, only R/2

73 IDoc archived

74 IDoc was created by test transaction

Day of Last Period ABAP Function

2008-11-13T17:41:00.002+08:00

Sometimes, in the course of your BW work, you will encounter a situation where the business requirement is to get the day of the last fiscal period. This is due to the fact that you want to populate, say calday infoobject, but the datasource only contains information in FISCPER format like 002.2008 for February 2008 for example.

So how do you overcome this? How to derive the last day in that period? Well the easy way is to use this built-in ABAP function in your transformation rules / or transfer rules etc:

CALL FUNCTION 'LAST_DAY_IN_PERIOD_GET'
EXPORTING
I_GJAHR = your_fiscal_year
I_MONMIT = 00
I_PERIV = your_fiscal_variant
I_POPER = your_fiscal_month
IMPORTING
E_DATE = output_last_day_of_period
EXCEPTIONS
INPUT_FALSE = 1
T009_NOTFOUND = 2
T009B_NOTFOUND = 3
OTHERS = 4
.
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

result = output_last_day_of_period.

So how to use this function? You need to replace the following fields which is highlighted in bold above, 'your_fiscal_year', and 'your_fiscal_month', should be replaced by the fiscal year and fiscal month respectively, in this case, you can derive this from fiscper from datasource. Remember, that 'your_fiscal_month', must be in 'financial format', meaning that its length is 3 and not 2 as usual. Remember to also populate the 'your_fiscal_variant', without this, the program will return with an exception error most likely.

This function will return 'output_last_day_of_period', and you can use this value to populate your calday in the transformation rules / transfer rules as you like!

Presto! That's easy isn't it?

SAP BI 7 Features

2008-11-11T21:09:00.003+08:00

It's been a while since my last post. Anyhow, today I would like to explain a bit about SAP BI 7.0 so called new features.

New Transformation Rules - You heard that right, ladies and gentlemen, no more deciding whether this routine should be in update rules or transfer rules, now you can lump all those into one transformation rules which combine the best of both worlds. With the new 'end routine' and 'expert routine' features, you can further customize how data transformation is done.
New DTP (Data Transfer Process Layer) - This is an additional layer on top of the 'normal' infopackage. So now, infopackage will move data to PSA level only. You will then use this DTP thingy, to move the data further to BW data targets, like infocube, ODS (they called this DSO now) or to infoobject. This is good in that you can debug more, but it will add additional layer especially for loading master data or text, which is in my opinion works better with the 'direct update' thingy in the previous version. But maybe SAP direction is in 'standardization', so no more differentiation between Flexible Update Rules or Direct Update I guess.
New Remodelling Tool - So far I haven't used this yet, but they say, you can easily modify an existing infocube structure (with data in it) using this tool. Whether it will affect the data integrity of the infocube is another question.

Well there are many other features, or improvement you can found in SAP BI 7, but these are the major ones so far. And also, the BEx Query Designer and Analyzer is also different, but then Business Object is already in the picture, so expect this to be changed in the near future too.

Dang Users

2006-09-25T10:37:00.000+08:00

Dang Users! After many months, our users finally decided not to use SEM-BCS.
Reason stated, it's too complicated, and too inflexible!

Oh well, time to move on to other things.

SAP BCS - The experience...

2006-04-01T19:35:00.000+08:00

Recently, we did some preparation for some SAP SEM BCS prototyping. All I can say is wow. A lot of detailed accounting setup need to be made on paper even before we can do the necessary configuration.

So how do you start? Well first, you need to prepare an excel worksheet, with the necessary consolidation simulation data. You need to create a T-account thingy, balance the account and such.

Using this excel worksheet, we start configuring the BCS system. First, (like my previous post), you configure the master data, FSI Item and such in the Consolidation Workbench (UCWB).
After that, you use the Consolidation Monitor to enter your Investment and Equity data (AFD - Additional Financial Data). This includes the percentage of ownership, etc etc of the various company (consolidation unit).

After completing the exercise, we use the Flexible Upload Method, to load data into the BCS infocube. Mind you, this flexible upload is slightly different than the one we used in BW. In fact, I think it's more flexible and much easier compared to the one in the BW Infopackage.

Why? Well first, instead of configuring the mapping of the flat files via Transfer Structure, there's a much better interface in the Consolidation Workbench under Consolidation Functions -> Flexible Upload. Here, you can define the header structure of the flatfiles, and the data rows.
You can set the comment character, in this case, I use the default *. By having comments in your flat files, you can create a standard template that your users can understand and easily use.

Now, back to the consolidation monitor, we upload the Total Records Data via Flexible Upload for each company (consolidation unit). After doing this, we run validation to see, whether the Reporting Financial Data is 'balanced' and such.

Well that's the current step that we've gone through. I'll update more when we progress to the other stages of SEM BCS.

SAP BW Authorization

2006-03-17T16:18:00.001+08:00

SAP BW Authorization is definitely different from R/3 authorization. Why? Well, first, R/3 authorization usually involves up to the transaction code level. But for SAP BW, the mostly used transaction is "RSA1" and "RRMX". Therefore, authorization based on transaction code alone, is definitely not sufficient.

So how do we design authorization in SAP BW? There's a few authorization objects that relates to SAP BW.

For reporting, you will most probably use the following SAP BW authorization object:

S_RS_COMP - Reporting Component, here is where you control the query authorization blah blah.
S_RS_COMP1 - Reporting Component Owner, you can control users to only be able to access report created by Power Users, here.
S_RS_FOLD - Disable/Enable the 'InfoAreas' button.

Besides that, you will also need to configure the following authorizations:

S_RS_ICUBE - Infocube authorization
S_RS_ODSO - ODS Objects
S_RS_HIER - Hierarchy Authorization

For SAP BW administration purposes, aside from the above, you also need to configure the following authorization objects:

S_RS_ADMWB - Administrator Workbench
S_RS_IOBJ - Info Objects authorization
S_RS_ISOURCE - Transaction Infosource
S_RS_ISRCM - Master Data Infosource

There that's what you need for authorization. Anyway, to achieve "field level" authorization like those in R/3, you can create a customize object, select the infoobject that has been set "authorization relevant", and add it in the authorization matrix, and walla, you got "field level" authorization.

SAP SEM BCS

2006-03-10T08:58:00.000+08:00

Recently, I had the chance to learn a general overview of SAP Business Consolidation or BCS in short. Or more precisely, the consolidation process. All I can say is that, I'm quite overwhelmed. I mean I feel more like an accountant each day. With all the mumbo jumbo about 'interunit elimination', 'equity method' blah blah blah, It's sometimes, quite hard to digest.

Anyway, to cut long story short, this SAP BCS is basically a long process that follows a certain sequence that will eventually transform a certain infocube, into a virtual cube that can be used as a basis for consolidation reporting.

The following is a gist of what process that we have to go through to do consolidation:

Master Data
- Consolidation Unit, Consolidation Group, FSI Item, Breakdown, Version
Data Collection
- Method
- Validation on Reporting Financial Data (RFD)
- Currency Translation
- Standardising Value Entries
- Validation on Standardized Financial Data (SFD)
Consolidation Process
- Manual Entry of Consolidation Financial Data (CFD)
- Interunit Elimination
- Reclassification/Allocation
- Consolidation of Investments
- Balance Carry Forward
- Validation on CFD
Reporting
- Standard
- Customized

So basically, it's a lot. I'm not going to elaborate much on what each process is. Well for that, you have to attend SAP BCS course :) But the main point is, there's a lot of "creative accounting" at work here, and for that my friend, you might have to take, perhaps an accounting certificate!

SAP BW360 - Day 5

2006-03-01T13:37:00.000+08:00

On the last day of our SAP BW 360 Training, we learned about attribute change run and process chain.

Remember the stuff about dropping index before loading, create index after, load master data first before transaction blah blah? Well, there's an easy way to automated all this. Yep, using 'Process Chains'. This process chains can connect all the different things required to do for the whole extraction/loading/transformation 'shebang'!

You can group different process chains, mix and match here and there, and automated much of the itty gritty administrative stuffs.

What about 'attribute change run'? Well, we use this attribute change run, to propagate changes in the master data attribute to all the relevant objects that uses this master data. For example, aggregrates etc etc.

So that's what we learn in day 5. All in all, I think the SAP BW360 is a good course to teach you about different ways to improve performance of SAP BW. It's a bit of BASIS, ABAP, Functional and Application lump into one.

SAP BW 360 - Day 4

2006-02-27T09:42:00.000+08:00

In day 4, we learn about a bit about SAP BW extraction and loading and how to improve performance. So basically, the rule of thumb for extraction and loading is that, for full data load, you have to delete the index first before loading, and recreate it after that. Because, it will be much slower to extract and load data when indexing exist.

For, incremental loads, again depends on how much the difference is, if it's more than 20% of the original data, then you might as well just delete the index.

Also, when you do BW extraction and loading, bear in mind that the more "customized" rules you have, be it routines or just formula, either in transfer or update rules, the more will it affect performance.

Another thing, for loading, you should also 'tweak' the package size in the infopackage scheduler. This package size will determine the size of each packet transmitted during extraction.

SAP BW - Day 3

2006-02-23T09:40:00.000+08:00

On day 3 of SAP BW 360 - Performance and Administration, we learn about aggregrates.
What the heck is an aggregrates? Well, in short, it's just another mini
cute little infocube, which further aggregrates the bigger infocube.

Well it means that, let say you have A,B,C and D characteristics. So, in the minicube, it will combine, for example, A,B characteristics only. Which means that, if the infocube has like 5 Million records, the minicube might contain, say 10K records. When you're querying the cube for A,B characteristics, instead of reading the whole 5 million records, it will query the smaller mini infocube reading 10K records. Which results in better query performance.

Yeah,yeah, it's good and all, but, aggregrates takes extra storage space, and maintenance could be hell. Considering you have to run the 'attribute change run' to propagate any changes of master data to the aggregrates mini cube.

So how do you know which characteristics are a good candidate for aggregrates? The answer my friend lies in the power of SAP BW Statistical Information! After the BW is in production for quite sometime, BW will gather some useful statistics which you can use to tune performance. This also includes which characteristics combination is used the most. This characteristics combination, is a good candidate for aggregrates. So, you can let the system propose to you which aggregrates to create, but you have to ensure that the statistical information of each cube is activated.

Or for a truly 'SAP BW Master', you can use your awesome power of foresight to predict which characteristics is a good candidate for aggregration!

SAP BW 360 - Day 2

2006-02-20T09:24:00.000+08:00

In day 2, we learn about connection source system to SAP BW. In short, if possible, use DB Connect. When connecting to some 'arcane' source system, use UD Connect.

But, the most important of all, is that we learn that to design a good Infocube , you must design it to become a "balanced" star schema cube. What that means is that the cube must have the following traits:

Small dimensions
Few dimensions
Only as many details as necessary
Hierarchies only if necessary
Time-dependent structures only if necessary
Avoid MIN,MAX aggregation for key figures in huge Infocubes
Balance the permutation, or 'cardinality' of each dimension. Each dimension must be 'balanced'.

There. Bottomline is, designing infocube is an 'art'. Not exactly an exact science.

We also learn about transporting in SAP BW. You click 'here', click 'this', package blah blah blah, anyway, again, the bottomline is, becareful about transporting, because there's a 'feature' call BEx transport that has the habit of automatically transporting objects that has been flagged 'transportable'. What it means that, it is possible that any changes you did to a query object that has already been made transportable(especially global objects) in the development server, there's a highly probability that the changes will propagate to the QA server or even the PROD server. Which means 'hell' is coming through!

So that's it folks. I'll continue with Day 3 update.

SAP BW360 - Day 1

2006-02-17T09:06:00.000+08:00

Sorry for this late entry. Yeah2, I know I'm suppose to post a daily update of the training, but it seems that the instructor has the habit of not allowing us to surf while 'listening' to his/her teachings.

Anyway, in Day 1, we learn overview of performance, some 'boring' SAP BASIS stuff (I nearly fall asleep during this time) and some more stuff. In general, what we learn is that, to be a good BW consultant, you must have a little bit of functional, application, technical, and a little bit of ABAP. He also reminds us that there's no such thing as an all-knowing 'superman' SAP BW consultant. To be that, you have to ammassed an awful lot of knowledge which is simply not possible for mere mortals.

So, a good SAP BW implementation, must consist of many people with different skill set as mentioned above.

Also, in Day 1, we learn about the evolution of BW underlying architecture. It seems that SAP BW has evolved a lot. From having a Basis 4.6C to Web AS 6.40. From ITS to IGS.
Basically, to make it short. With that kind of evolution, SAP BW is most probably a 'mutant'.

K. I guess that's about it. I'll post later, since our last day training is about to start.

SAP BW 360

2006-02-12T22:09:00.000+08:00

Tomorrow, I'll be attending the BW 360 performance training. Finally, I'll some stuff about BW process chain yada yada. I'll try to update the blog daily on what I learn the whole of next week. So, stay tune for more.

In other unrelated notes, I'm at the stage where I no longer like going all "ga-ga" over SAP like I used too. I think it's just another tool, and like any other software, it has it's flaws and shortcomings. Like all things in life, when you've become used to it, the 'magic' that you felt the first time, will cease to exist.
SO that's that.

Creating Infoobject

2006-01-25T15:37:00.000+08:00

In the course of configuring your SAP BW, you might come across a situation where you'll have to create your own infoobject instead of using the standard business content. So, how do you that? First, as usual go to RSA1. Then choose infoobject, and expand to the relevant infoarea.
If you want to create a characteristic, go to the Characteristic Catalog and right-click:

Same goes to key figure, go to the Key Figure Catalog and right click on it and create InfoObjects. You'll get to the next screen:
If you want to create the infoobject based on template, fill the template field, otherwise leave it empty. If you fill the reference field, the infoobject you create will be sort of like a "C pointer", or reference to the existing Infoobject. The difference is just the name.

In the next screen, you'll be able to configure the InfoObjects. You can create master data, text, hierarchy, attributes, unit, time dependent etc etc, to suit your needs. And that's all folks.

How to create hierarchy in SAP BW

2006-01-16T11:20:00.000+08:00

Before you can create a hierarchy for an infoobject, say cost center, you must first ensure that the infoobject supports hierarchy. So in the infoobject change screen, choose the hierarchy tab and select "with hierarchies":

Save/Activate etc usual stuff. Now, go back to the infobject catalog directory, right click on the infoobject and choose create hierarchy:

And walla. You'll get to the hierachy screen, and can add nodes and such. But to make things much easier, I recommend using flat files upload to load your hierachy from excel. Which I will cover in a much later post.

Dataflow in SAP BW

2006-01-09T11:41:00.000+08:00

Sometimes, in your cause of creating "stuff" in SAP BW, you'll get lost in a puddle of Infocubes, ODS, Infoobject, Infosource blah blah blah. So how do you find yourself in this sea of confusion?

The answer is dataflow. With dataflow, you can see exactly how does the data comes from the source system up to the data target. You can do this by right clicking on the data target and choose data flow:

and you'll get something like this:

Which is quite nifty eh?

SAP BW Communication Structure and Transfer Structure

2006-01-03T09:53:00.000+08:00

When I first started dabbling with SAP BW, one of the questions that boggles my mind is "What's the difference between a Communication Structure (short: Comm Structure) and Transfer Structure?".

Well, transfer structure is like the data template of the source system. What it means is that, this transfer structure is exactly like the fields of the originating data. So, if you have a flat files with the fields: Cost Center, Business Area, Sales Amount, the transfer would be exactly like that. Also, in the transfer structure, you can have some conversion routine to convert for example, the date format of the originating data. Things like that.

But what about the communication structure? Why do we need it? Well, the answer to that my friend, is that, from the transfer structure, using a certain "transfer rules", we map the fields in the transfer structure to the communication structure. This communication structure is data-source independent, and this is what the "infocube" or the data targets would see. Not the transfer structure. Why is this good? Say, when extracting from legacy system, you still don't have in mind which fields you want to transfer and all. So, what you did is you transfer everything, which means that your transfer structure would be quite humongous. But, for now, you knew, you only need a few fields for reporting purposes.

So, in the communication structure, you will only select the "infoobjects" that you need, not all the fields in the transfer structure. In a way it acts as a filter for the transfer structure.

That, ladies and gentleman, is why you have a transfer structure and a communication structure.

Datamart in SAP BW

2005-12-27T09:35:00.000+08:00

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.

The power of SDN

2005-12-19T07:59:00.000+08:00

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.

Ruby and SAP

2005-12-15T09:46:00.000+08:00

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:

Method is only feasible for delta loading, as it uses XML-SOAP interface to load data into BW.
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.
When creating the Info Package based on the generated datasource, under "update" tab, choose "Initialize Delta Process" and "Initialize Without Data Transfer".
Schedule the load. Now under RSA7, your delta queue will be there.
Now create another infopackage, choosing "Delta Update".
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.
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.
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!

SAP Project Implementation Timeline

2005-12-13T09:01:00.000+08:00

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.

SAP Role Separation

2005-11-29T09:47:00.000+08:00

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!

SAP Pro Blog

2005-11-27T01:00:00.000+08:00

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.

SAP Bag of Tricks

2005-11-26T02:54:00.000+08:00

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.

More than one SAP-BW Query

2005-11-24T21:55:00.000+08:00

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:

Click on "Tools" icon.
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" :)

SAP BW Customer Enhancement (CMOD)

2005-11-22T16:33:00.001+08:00

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 :)

SAP-BW Update Rules not working as expected

2005-11-17T13:42:00.000+08:00

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.

SAP User Expectation and Technical Limitation

2005-10-28T12:02:00.000+08:00

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.

A moment of silence.

2005-10-20T10:02:00.000+08:00

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.

Migration. How to get an SAP migraine!

2005-10-17T19:18:00.000+08:00

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.

The Holy Grail of SAP

2005-10-09T17:21:00.000+08:00

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.

ABAP: Program that speaks many language

2005-09-20T13:55:00.000+08:00

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.

Resistance is futile. You will be assimilated by SAP!

2005-09-10T19:47:00.000+08:00

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! :)

SAP-SEM: Completing the Picture

2005-08-20T16:17:00.000+08:00

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.

SAP: Short form, Short codes.

2005-08-10T15:50:00.000+08:00

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.

What the heck is SAP?

2005-08-03T00:28:00.000+08:00

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.

The Beginning of an SAP Newbie

2005-08-02T14:59:00.000+08:00

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