Skip to Content
0

How to mass change tables T095 & T095B ?

Jan 09 at 09:09 AM

162

avatar image

Dear all,

I need to replace about 700 G/L account numbers in the tables T095 and T095B.

Am I bound to use the customizing transactions AO88 and AO90 to do this manually?

Or are there any ideas to realize a more automated way? E.g. how to solve this with an ABAP report (table dependencies etc.)?

Looking forward to your kind help!

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Best Answer
Eli Klovski
Jan 09 at 04:22 PM
1

Hi,

Well, you can directly update the tables via SE16N. But, I wonder how many asset classes accounts determination patterns you have that mass update of accounts is such a problematic task.

Regards,

Eli

Show 4 Share
10 |10000 characters needed characters left characters exceeded

Thanks for your answer!

I thought of making the changes in SE16N directly.

But if I use AO88 and AO90, I get a transport mentioning view cluster VC_T093_01, see:

Can I just ignore node VC_T093_01 when changing T095 and T095B in SE16N?

0

Yes, you can.

1

Eli Klovski, thanks again for your answer and sorry for the late feedback.

I edited table T095B exactly as you suggested and it worked like a charm (transport to Q system still pending).

Nevertheless table T095 wasn't that easy to change. After changing the account number in field KTANSW, I got error message 00058 ("Entry 60 does not exist in table T093"). So T093 seems to play a role here, even if - in my opinion - the entry 60 was present in table T093.
For this, I switched to transaction AO88 and edited the values manually (that's why it took me so long to answer).

0

These are misleading messages. In SE16N you can receive this type of errors, even if the value for what the system is complaining is perfectly OK and exists in the relevant reference table. This is due to the fact that certain checks, which are applied in direct tables update in SAP, are not performed in the right order.

For future, you can use function module SE16_INTERFACE with parameter I_CHECKKEY put to 'X'. In this way, you would have the same thing as with SE16N, but no check on the key values will be performed and you won't encounter an issue.

Another trick is to hide the 'problematic' field in SE16N output. Of course, it will work only if you don't need to modify this particular field.

If your issue is solved, you can close the thread :)

1
avatar image
Former Member Mar 14 at 04:03 PM
2

Hi,

for mass changing T095 see note 2457480

Show 1 Share
10 |10000 characters needed characters left characters exceeded

I blogged about this awhile ago. It's OK but has it's limitations.

http://serioconsulting.com/blog/a-new-way-to-maintain-gl-account-determination/

1
Shakeel Ahmed Jan 22 at 04:24 PM
0

Hi D.W.

LSMW works absolutely fine for configuration as well, just insert a TR and things shall be fine. This way you would be able to move this change to Quality and Production through Transport Request.

I have used LSMW for various bulk customization.

Regards

Shakeel

Show 6 Share
10 |10000 characters needed characters left characters exceeded

Thanks for your answer!

Which import method would you choose for the LSMW? I guess a batch input recording on transactions AO88 and AO90 isn't possible, because you can't automate the clicks in these transactions. (To be honest: I didn't try it, yet.)

Also I couldn't find an appropriate BAPI to change the account numbers.

0

Hi D.W.,

You can not change at table level as you need these value in the TR to move to QAS and PRD. Now option you are left with:

1. LSMW - Try it.

2. BDC - Involve ABAPER

3. Manual change

Keep us posted on your solution/workaround.

Regards

Shakeel

0

Who is speaking of QAS? And in any case, if a change in the tables could be made in PROD, it can be equally done in QAS. LSMW might work, if carefully prepared; still, considering the screens involved some glitches are anticipated.

0

Eli, don't take it otherwise. I am just saying making such changes at table level in production are never advisable just because work is lengthy.

0

And why so? Any change in the tables can be done directly, as long as you know all the possible consequences. The maintenance view or program which you operate through a SAP transaction do exactly the same update. Of course, as I mentioned before, you have to understand what you are doing.

0

If you are justifying direct table entry just because task is big. I will have to take a step back from this post. :)

0