cancel
Showing results for 
Search instead for 
Did you mean: 

SCAL update calendar, transport. How check DEV = QAS = PRD before change

former_member271718
Participant
0 Kudos


Hi there,

Unfortunately, SAP mentioned in some notes that you always should use the transport tool to transfer changes/updates in calendars to Production client. Even a small update, like adding a new holiday, you should transport it from Development to Quality and then Production. Unfortunately you can only transport "everything" , that means all calendars all rules etcetera will be transported everytime.

What problem do I have with it:

Suppose you are orded to transport a small change to production. You know everything will be transported. You change it first in DEV, the question / Problem is, How can you be sure that you don't transport temporary trials of other people who has changed something in a calendar of DEV as well?

The only way to avoid transporting "****/test" from others, to me is to check the contents of all tables related to Calendars:

So can anybody tell me how to check that the contents of all underlaying tables are equal in DEV, QAS and PRD, before I make the change, to avoid the problem mentioned above? and

How can I be sure that after the check when doing my change, somebody else is doing the same before I release the transport?

Some remarkt to that:

  • Offcourse everything needs to betested, but that isn't the question.
  • It is a pitty that SAP wasn't able or didn't find it worthwhile to have the option to transport individual objects of a calendar, because if they did, then there was no reason to do the job in production. I did that many times though without any problems because I didn't want to transport all test objects as well, i did have some bad experience with that.

Regards Kees

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Sounds like you need to use SCU0 (and you'll probably need Basis to set up the connections for you).  Compare Dev to QA and QA to PRD i.e. have to do as two steps.

Answers (2)

Answers (2)

former_member271718
Participant
0 Kudos

Hello,

I agree that these kind of changes should be centralized and restricted to specialized person(s), but that isn't the question. My customer hasn't organized that yet and it isn't sure whether he will. So I have to live with the fact that the calendars might be different, but the customer wants to know if the settings of DEV QAS and PRD are equal, so how can we check that?

I think that is almost impossible without spending a lot of time and the problem will not dissapear. So I am thinking of proposing the customer to transport from production to QAS and then to DEV to assure that everything is the same and then advise them to centralize the maintaining of Calenders?

What do you think?

Regards Kees


JL23
Active Contributor
0 Kudos

Did you try Nick W2's proposal?

Looks interesting for me, it is new for me too. I know some customizing can be compare directly from the menu with QAS or PRD if the RFC connections are setup, but that function is not there for calendars.  Maybe its possible with Nicks transaction.

Alternative you can check the change logs. you have to go into the factory calendar overview and then select from menu Extras > Display change logs. (same is available for holiday calendars too).

Enter a star * instead of the defaulted user name.

And then you can just check manually whether you find those changes in QAS and PRD.

former_member271718
Participant
0 Kudos

Hi Jürgen.

I tried SCU0 as proposed by Nick, It looks indeed very promissing. However at the point of comparing SCAL I got an erro / warning message TB814 Place the cursor on a comparable object. I assume this function isn't available for SCAL (Calendars).

However if you want to know the objects involved start the comparison based on Project IMG (Button create) e.g. Select activities, select the customizing step in my example Maintain Calendars and Choose Button "Object over" and you get an oveview of objects of transaction SCAL. Soa very good tip of Nick indeed.

Your second option I will check later on. I have to go into a meeting.

Regards Kees

former_member271718
Participant
0 Kudos

Hi Jurgen,

I tried your option and selected the changes in DEV, there were many changes on different objects. In QAS there were no changes in the same period (most probably due to the fact it has been transported). So unfortunately it doesn't give me a clue about the differences between the different systems.

I think I have 2 options now:

  1. SCU0, select the objects (14 in our system), most of them or all are transparant tables with many entries. Download them e.g. with SE16N to excel of all three systems and compare them via concatenating all fields of the table of every row and compare them with the downloads of the other 2 systems using excel VLOOKUP.
  2. Transport all from PRD to QAS to DEV and make one person responsible for the transport of Calendar objects after that.

Ad 1. No guarantee whether all objects have been compared, so no guarantee that they are the same

Ad 2. Actually, at least to my opinion, the only secure option.

Do you agree with those options and conclusion?

JL23
Active Contributor
0 Kudos

I did not expect to do the same check for changes in QAS and PRD. I just meant you take the latest change which is not your current change  and check in QAS and PRD if it is there. If it is, then you can be sure that all is there, since the SCAL tables are transported as a whole.

If it is not there then you have at least the name of the person who did it and you can call him to transport.

former_member271718
Participant
0 Kudos

Hi Jürgen,

Ok understood, but still did doesn't guarantee that all systems are equal, because the last change as well as the previous change might not have be transported and that was the starting point of my problem.

My conclusion:

Almost 100% guarantee when:

Before you check the systems, one should organize that the systems at least regarding calendars is maintained by one person on beforehand and only he is responsible for the transports of calendars and he should only be allowed to change the calendars. Next he should check whether the systems are equal regarding calenders:

  1. Only if you are sure that everything is transported in the past then you can check for the last transport request as opposed by Jügen. Unfortunately there is no guarantee.
  2. He should check all systems DEV, QAS and PRD whether they are equal via ransaction SCU0 determin the tabes involved and download the contents of all tables to excel and compare them, if not equal then change them acc. and / or
  3. Transport the Calender as a whole back to QAS and DEV.

I think initially to get the maintenance of calenders back on track as it should be option 3 seems to be the best and easiest way to be carried out and you can be sure that initially the calendars are equal.

Regards

Former Member
0 Kudos

Hi,

Can using different transport requests for each change not suffice your requirement?

Regards,

Pratik

Petepall
Contributor
0 Kudos

Using different transports for each request will also require transport in the correct sequence.

In our company we had 1 team that was available for making changes to calendars and transporting these. When a calendar is going to be changed they send a mail to everyone in that team (PP) this way everyone knows that changes are being done.

Also the rule was that every change made to a calendar in development needed to be transported the same day into test and production.

In the end this year we changed the set-up as we where getting a huge number of tickets regarding calendar changes (allot of plants) and now we in fact directly maintain calendars in each system.

In each plant 2 people and only 2 people are allowed to make changes to the calendars.

They where trained and provided with detailed job-aids. The access to make these changes is controlled through the SAP GRC firefighter set-up which only allows 1 user at a time to access the SCAL transaction and all changes are monitored.

The IT team has also got this access in case of users being out of office or ill to support the business.

This same procedure we also follow for the maintenance of planning calendars (MD25/MD26).

JL23
Active Contributor
0 Kudos

You just need to make sure that no newbie ever starts to transport a calender from DEV to PRD as this will screw up everything then.

There are many more such objects that can only be transported with all entries, e.g. account determination. A development system is not a sandbox for trials that never get changed back.

We cannot even create a transport without having an approved change request, which is one way to make a development system safe from being used as sandbox. Clear responsibilities -as Peter already mentioned - for critical customizing objects like number ranges, calendars and account determination is another way