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.

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

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

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

1. S_RS_ICUBE - Infocube authorization
2. S_RS_ODSO - ODS Objects
3. S_RS_HIER - Hierarchy Authorization

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

1. S_RS_ADMWB - Administrator Workbench
2. S_RS_IOBJ - Info Objects authorization
3. S_RS_ISOURCE - Transaction Infosource
4. 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.

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:

1. Master Data
   - Consolidation Unit, Consolidation Group, FSI Item, Breakdown, Version
2. Data Collection
   - Method
   - Validation on Reporting Financial Data (RFD)
   - Currency Translation
   - Standardising Value Entries
   - Validation on Standardized Financial Data (SFD)
   
3. Consolidation Process
   - Manual Entry of Consolidation Financial Data (CFD)
   - Interunit Elimination
   - Reclassification/Allocation
   - Consolidation of Investments
   - Balance Carry Forward
   - Validation on CFD
4. 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!

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.

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.

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!

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.

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.

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.

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.

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.

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?

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.