RSA1: You Can Only Work in Client 001...

After installing a new BI system, we ran across this error before starting the BI configuration and creating connections to the ERP systems. We wanted to do all of our work in Client 100 instead of the default client 001. Of course, when you run RSA1 and get the message "You Can Only Work in Client 001" it stops you dead in your tracks.
Fortunately, there is a simple solution to this.
When you first import the BI content, the system decides what client will be your working client, though it never asks you for this input. By default it will go to client 001 if you do not already have another client built.
If you need to work in a client other than 001, you simply have to change an entry in table RSADMINA. Populate the client field (BWMANDT) in the correct row (most systems will only have 1 row in this table) with the client number you want to work from. Problem solved.
Sometimes this problem will manifest itself in the system log with an entry like this:
DIA 001 100 USER RSA1 D0 1 Transaction Canceled BRAIN 009 ( 001 )
The same process fixes this error as well.

Hope this helps...

"J2EE Status Info Unavailable" After a System Copy...

After performing a system copy with SAPINST, we recently encountered a problem where the SAP Management Console would display the message "J2EE Status Info Unavailable" at the end of the dispatcher status. Then under the Java work process folder, the message "No Info Available" would show up. The exact error messages will depend on your kernel version, but you get the point.
After countless hours pulling out my hair and working with SAP support, we finally discovered the issue. Apparently something went wrong with the Java extract from the source system, so settings were not transferred correctly to the extract files, and thus the target system was populated with erroneous information. Unfortunately, everything from my standpoint was showing to be correct and successful with the system copy. I was only able to correct the problem by returning to the source system and running a new System Copy, utilizing the "database specific" option so that SAPINST only ran the Java migration steps. I then went to the source system and re-ran the system copy target steps, and pointed it to the new Java Migration files.
Worked like a charm.

Hope this helps...

Change Spool Servers in SAP afetr Refresh...

Here is a little query I have used for a while, but for some reason I had not yet posted it on my blog.
If you are like me, and you like to frequently perform a refresh from PRD to QAS, you may find yourself having to change spool servers in SPAD... a lot. It is a very simple task, but there are 5 steps you have to complete for each printer just to change the SAP spooler server. Yes it is a pain, especially if you have hundreds of printers defined in SAP.

Here is a quick query you can run from the database side in order to do this MUCH faster:

update qas.TSP03D
set PAMSSERVER='sapqas1_QAS_00'
where PAMSSERVER='sapprd1_PRD_00'

Of course you will need to make sure you are using the correct schema, SID, and server name, but as you can see it is a very simple query.

Hope this helps...

Grant Management Special Ledgers Will Not Transport...

We encountered a particularly difficult problem this past week, and were directed to an OSS note for the fix, and the application of the note was so broad I thought I should go ahead and post our experience here in case anyone else finds themselves barking up trees and pulling hair out.

When prepping a production ERP 6.0 system for Go-Live, we encountered a problem with master data in the productive system, specifically Special Ledger 90 (an SAP-standard ledger, that should exist in the system). The information existed in both the development and quality assurance systems, but not completely in production (bits and pieces of the data were present, but not in all the necessary tables). The first thing we checked was to make sure the object was included in a transport, and that the transport had been imported into all systems. That all checked out. So, we went ahead and created a new transport to try it again. Same problem: exists in DEV and QAS, but not in PRD. After trying a few more things, but to no avail.

To make a long story short, we opened a message with SAP, and they provided a fix. Apparently this is a known issue with no solution other than a report that fixes the symptoms. SAP does not know why it happens, but there is a long list of programs and reports that it effects. The problem was actually a syntax error in an underlying program that made it look as if master data was not present, even though it was. The note to look for is 377053.

Hope this helps...

Cannot Install SAP License Key after System Copy...

When using the SAP-supplied method for a system copy, often you will find yourself in the situation that you cannot install the permanent license key for the target system since the information from the source system is stored in the database already. The SAP-recommended remedy for this is to delete the invalid license keys before proceeding with the new key install. Of course, it is not as easy as that for a few reasons:
1. If you do not have at least a temporary license installed, you must log in as user SAP*, which does not have the authorization to delete license keys.
2. If you do have a temporary license installed, and you are logged in as a user with authorization to delete license keys, you still cannot delete the invalid licenses because the delete step validates the key to be deleted with the system information. And guess what? They don't match , so you cannot delete the key.
This brings us to the real solution, which took a little digging inside the SAP Marketplace to find: You must manually remove the invalid keys from the database. That's it! Just remove the entries from table SAPLIKEY and all your troubles will be over. Well, at least you will be able to install the new license with the correct information, anyway.

Hope this helps...

Getting an Answer from SAP Support - The First Time...

A colleague of mine, who wishes to remain anonymous, recently gave me permission to post the following:

I feel the frustration of having turned in an issue to the SAP help desk, only to have it bounced back by idiots who appear to not even have read the thing in the first place. There is a way to avoid this – you simply have to out think them. How? By knowing how they think

I had to spend 6 months on the first level help desk in Philly a number of years ago – I think I was being punished for something – not sure. Their methods have madness associated with them that is related to the expectations of the help desk managers and SAP itself. High priorities get the most attention, obviously. After all those are attended to or shipped to level 2, the level 1 guys have to handle so many “other” issues. Based on their severity (low ones are a waste of time and never get answered) they have a time frame in which they must be opened and some action applied and returned to the customer. Handling the issue means opening it and responding and then sticking it back in the customer’s queue. They have a quota to make here and a time frame, so there are several approaches they use to find the “pigeons” they need to make their quota.

One is to review a problem and see if the description request is basically a short one or vague. Another is to take ones who have no note numbers listed in them. The standard level 1 response here is simply to do a search on the OSS note system and send you a lot of notes that appear to be related to the issue. Ever notice that they send you ones that are already on your system in some support pack? That’s because, even though they have the information about which support packs you have, they don’t reconcile it to the notes. That takes too long and they have numbers to meet. Many times you will get some which don’t even apply to your release. They simply don’t take the time to check that out, even though the info is available. Most likely, you’ve already searched the notes and they are sending you the same ones you checked. They don’t know that and they don’t care.

The solution:
Very simple – inundate them with info. Same as the old professor theory – term paper has 10 pages instead of 2 – must be an “A”. Stand at the top of the stairwell and toss the papers down. The ones that weigh the most (have the most pages/info) go to the bottom and those are “A”s. Ones near the top don’t have any information or thought in them, so they must be “F”s. If it takes the level one guy too long to read all your info, he will simply mark it as level 2 and ship it right to them. Get’s it out of his queue and puts it where you really want it.

Tell him EVERYTHING you know about the issue – the more the better. Try to make 2 pages worth of information. Tell them every note you even heard about the issue and which one you tried, and what happened when you did. Put the note numbers in the body of the message near the top. There’s no excuse for missing them. If you tried exotic things or think it may be related to the some other issue – tell them. The more you put in the better, the less you put in the quicker an unusable answer will come back to you.

It may take you a little longer to fill in the message, but it beats waiting 3 days, only to have it come back with useless junk in it. And if they still send it back with just a bunch of notes to look at, and you already mentioned you did those, don’t be shy about shooting the problem right back to them with a nasty-gram attached. When you do, up the priority one level.

This pisses them off, but when they point out the priority error to you, just fire back that you’ve lost all kinds of time already because they didn’t read the message in the first place. Then ask to have a supervisor review their messages and replies.

Ouch! They hate that. But you will get some results then – guaranteed.

Now all of that may seem a little cruel and crass, but maintenance support is a big piece of the customer monthly costs for this software and they need to get their moneys worth like everyone else – don’t hesitate to remind them of that. Shoddy help desk practices are not your concern; you just want results.

The other side of the coin is that a lot of customers get a problem and immediately open a message. Lack of due diligence on the part of the customer to try and find the solution in the note system (which I admit can be a pain) or to trace or test the issue, or even to just think, has been the reason the level 1 people usually just fire back a
string of notes. They are not there to simply solve every issue – only the ones you can’t. So make sure you do your part first. Then write ‘em an epistle.

Happy typing.

Hope this helps...

"Client Status Not Modifiable" Message When Hiring in PA40...

In a test or production client, obviously you want to block configuration changes. A problem this can raise, however, is when adding master data to a production or test client. The issue is that SAP by default wants to tie any master data changes to a transport, thus requiring the client to be set to modifiable or customizing. When hiring a new employee in PA40 is one example of a time when you need to add master data to a closed client.
The solution to this is to tell your system to not tie master data changes to a transport by default. To do so, run transaction OOCR. In the entry for TRSP CORR you need to flag it with an 'X' to deactivate the automatic transport connection.

Hope this helps...