Closing Co Period for each CoCode separately

[Former Member]

Hi there. I'd like to ask You few questions about CO matter. I'm newbie in this topic so please be patient when reading my post

At this moment we've got 1 Controlling Area (Let's say CA1)

We've got 4 CoCodes (let's say CC1, CC2, CC3 and CC4)

The Controlling Area CA1 is common for all 4 CoCodes. That's an Cross-company-code cost accounting .

The problem is that Co Posting Periods are closed 'globally', for the whole Controlling Area CA1 ( = for all CoCodes assigned to CA1, that is CC1, CC2, CC3 and CC4).

I need to create transaction in which user could open/close Co Periods separately for each CoCode. So for example

Period 1 can be closed for CC1, but it's opened for CC2 etc.

Unfortunately when I peek at KAPS table structure ("CO Period Locks") there is no BUKRS (CoCode) field inside. So I assume there is no possibility to separate Co Periods for each CoCode.

Could You suggest me a bit the suitable course of action in that case? How can I divide closing Co Periods for each CoCode? I'd be very thankful for replying my message. Greetings.

PS. The 'Controlling area same as company code' solution cannot be implemented in our company.

Edited by: Piotr Wojciechowski on Jun 16, 2008 3:04 PM

[iklovski · Accepted solution]

Hi,

What activities do you exactly want to lock in CO? Are these internal CO documents or FI documents which cause the creation of CO? In the latter case, you can use, of course, OB52 for locking FI periods. If it's about internal CO activities, then a special development is required.

Regards,

Eli

[Former Member · Accepted solution]

Eli Klovski

What activities do you exactly want to lock in CO? Are these internal CO documents or FI documents which cause the creation

of CO?

Thanks for replying. Both types of activities will be blocked.

Eli Klovski

If it's about internal CO activities, then a special development is required.

Could You give me few words about 'special development' You're telling about?

[iklovski · Accepted solution]

Hi Piotr,

You can create a Z-table where you will manage the locking indicators similar to SAP, but with addition of company code. Then, you can create a validation of posting CO document (OKC7) which will work on user-exit. This user-exit will check the Z-table and see whether the document in question meets the locking rules based upon a company code and a period.

Give this scenario to your ABAP team. It's a minor development...

Regards,

Eli

[Former Member · Accepted solution]

Eli Klovski

Unfortunately I'm that ABAPer who is fixed to solve that problem.

0) I created a ZKAPS table (it's a KAPS structure with BUKRS field additionally)

1) I created my own validation ZCO001 (In Line Item segment)

2) I defined Step1 inside ZCO001 validation

3) For the Step1 'prerequisite' I set 'TRUE'.

Eli Klovski

Then, you can create a validation of posting CO document (OKC7) which will work on user-exit. This user-exit will check the Z-table and see whether the document in question meets the locking rules based upon a company code and a period.

4) Please could You tell me what should I do in the 'CHECK' phase to check if document is posted to opened/closed period? How can I define that USER-EXIT? Every tip will be useful, greetings. P.

[iklovski · Accepted solution]

Hi,

In the check you should use a user-exit that you have previously defined in ZZGBR100 modification pool. Just go to this program, and define the new user-exit (say, U900) in the GET_EXIT_TITLES routine:

exits-name = 'U900'.

exits-param = c_exit_param_class.

exits-title = text-900.

APPEND exits.

...and create a form U900 with all due checks of your Z-table.

Hope this is helpful.

Regards,

Eli

[Former Member · Accepted solution]

I thought problem is solved, but I've got still problems with validation transport

There was validation ZCO00 applied to the system.

As I wrote earlier I created my validation under ZCO01.

What should I do now? When I want to add a 'new entry' ZCO01 in OKC7 (for the same CoArea as ZCO00) 'Entry with given key' error message occurs

Shall I put my Validation step to existing ZCO00 or shall I use new ZCO01?

And what activities should I do to transport my Validation Step properly then?

[iklovski · Accepted solution]

Hi Piotr,

If ZCO00 is actually used in your system (and not just been put there for decoration , you should not create a new validation, but add a step in an existing validation. The transport, of the validation is possible by including it manually in request: OKC7 - Table view (menu) - Transport.

Regards,

Eli

[Former Member · Accepted solution]

Eli Klovski

Sorry Eli, I hadn't precised my post.

We've got 3 servers.

A - for development

B - for test

C - production server

Transports are made sequentially: A -> B -> C

Existing validation ZCO00 is transported only to the server B. It waits for acceptance for some reason. What when I need to transport my ValidationStep to the C (production) server, but I should not apply other steps ZC000 consists of?

PS. Sorry about my english

[iklovski · Accepted solution]

Hi,

It's OK, it's not my mother tongue either

The steps should be these: update a ZCO00 in your dev. server. Create a transport (by including it in CR) and trasnport it up to test/prod. You may ignore the transport that is waiting in test now, as the CR should include all the steps including the one that has been created by you. I would delete that old transport from the queue.

Tell if I get you right...

Regards,

Eli

[Former Member · Accepted solution]

Eli, one more question.

Eli

In the check you should use a user-exit that you have previously defined in ZZGBR100 modification pool.

ZZGBR100 is Z-program. Our program for defining user-exits codes is ZRGGBR000. So, I assume that somebody had to 'tell' SAP which program to take user-exits definitions from. Can You tell me where to define that, because I want to check if that part of customizing was transported to C server too.

Greetings!

PS. What 'CR' abbreviation stands for?

Edited by: Piotr Wojciechowski on Aug 1, 2008 11:41 AM

[iklovski · Accepted solution]

CR - change request (transport)

You define the program for user-exits via GCX2.

You can find more info about validations in the note 842318.