change table value

[cathy_liang]

Hello experts,

I handle SD instead of ABAP. However I got some questions related to ABAP. Pls help. Thanks.

Q1. Is it possible to change the value in field KOSTL of table LIPS? For e.g. KOSTL shows 123, any chance to change it to 456?

Q2. If the answer for Q1 is yes, how to change it, e.g. which Tcode, what is the process steps?

Q3. What is the impact for this kind of change?

[Former Member]

1.it is possible to change by runtime (by debugging) .

steps

go to table and disply the fields like press f8 then give input after double clik on line put /h in command field then press enter  times it is going to debugging mode then clik edit then press f8 after it is going ot edti mode then choose u r required field and change what u want then save . automatlly the data willl save in database.

[rajkumarnarasimman]

This message was moderated.

[Former Member]

Dear Cat,

It is not suggestable to change the any SAP transaction data in debugging mode, it may lead to data inconsistency.

Any transaction data is always advisable to change from the respective tcode ( some cases you may need reverse or cancel the documents)

Thanks and Regards,

Chandra

[Richa_Gupta]

Hi Cat,

Use transaction KS02 to delete cost center 123.

Then use transaction KS01 to create a new cost center 456.

Impact of changing one cost center to another by this way is that wherever you are using the old cost center will become invalid.

So, best approach for you is let 123 as it is and create a new cost center using KS01 as 456.

Master table for KOSTL(Cost Center) is CSKS.

Richa.

[Former Member]

This message was moderated.

[matt]

The impact of making a change directly is that you may not change all the fields that need to be change. I.e. you compromise your database's referential integrity. I.e. you can end up with a corrupt database, which SAP will charge you $$$$$$$$$$$$$ to fix.

Modifying data in SAP Standard tables is DANGEROUS, may be a violation of your license, and can lead to your system becoming inoperative.

[Former Member]

Why do you want to change this?

If you still need to change data why dont you go for respective process i.e reversal/cancellation/change any of particular documents or process then re-create it with correct one.

[matt]

Avirat Patel wrote:

Why do you want to change this?

If you still need to change data why dont you go for respective process

Because, as often is the case, we are presented with a solution, rather than the problem. I.e. "This foolhardy way is the only thing I can think of to fix my problem (which I will keep secret), so please tell me how to make it work".

[raymond_giuseppi]

Did you try VL02N, if cost center greyed, no you cannot, so delete and recreate delivery.

(Don't forget there are MM, FI and CO documents behind the delivery, so don't use any "wild" update as some have suggested.)

Regards,

Raymond

[praveenboss]

This message was moderated.

[matt]

Moderator message: I've rejected all messages suggesting direct change (except the first one). Any further messages suggesting this dangerous method will also be rejected.

[praveenboss]

This message was moderated.

[Former Member]

As an abaper, I always write code to change the value in a table and it has nothing to do with if it is a standard table.

Changing the structure of a standard table is dangerous but this is not the case in changing the value of a standard table. The only thing you need to care about is the data consistency. The value of the field you changed could also exists somewhere else like in another related table. So unless you are very clear about the table relationship, otherwise it is recommended to change value via frontend(like VA03).

[matt]

As an ABAPer with 18 year's of experience, I must disagree. It is dangerous to change any standard data in table as a general principle - especially important tables like LIPS, precisely because what "you need to care about is the data consistency."

This is not limited to ensuring other tables are correctly updated as well, but also ensuring that the data is valid within its context. For example, while a value may be valid according to its domain, it may not be valid in combination with other values in the same (or other tables). Further more, the values in other tables may have already been set according to this current value.

I agree that it is sometimes necessary, but it must always be done very carefully and as a last resort.

[jrg_wulf]

Ming Yu wrote:

As an abaper, I always write code to change the value in a table and it has nothing to do with if it is a standard table.

If this is true, you must either be reckless, lazy or ignorant.

For almost every standard table, there are standard modules like classes with methods, BADIs or FMs to do this with a reduced risc of getting your data corrupted.

Admittedly, there may occurr situations, where you have to manipulate data directly - but only if all else fails.

The TO obviously is not in posession of the neccessary knowledge, so D O N' T  S U G G E S T

things, he might not even be aware of their riscs.

Best regards - Jörg

[Former Member]

Actually I barely change the value in a standard table by writing code, just because it bypasses the frontend data check and also may cause data inconsistency. So it is not recommended.

But I think there is no 'standard' data, because these data are not generated by SAP.

[Former Member]

Strongly believe that direct change to standard table leads to an unexpected results, and as per my old question/answers in this forum and professional experience.

But It also puzzling me that why sap still provide such kind of feature of direct table update [easily]. who is going to use it?

[matt]

It's really useful under certain extreme circumstances. The trouble is it seems to be in daily use for some!

[Former Member]

thank you for your remind.

[Former Member]

Maybe because technically it has nothing wrong and should be allowed.

[Former Member]

"Sober driving today. Alive tomorrow."

Good luck !

[cathy_liang]

Hello experts,

Thx a lot for your prompt and valuable feedback.

Yes, noramlly we should use cancllation / reversal process to make delivery re-capture the correct cost center.

However, transfer order has been confirmed. It is said manual adjustment is needed from stock side. It is quite complicated.

That's why I double check the possibility of table update for the wrong delivery. I mean, to update table for only one wrong delivery.

Again, thank you very much.

ps. for this thread, there is no "points" icon now. I failed to award points to you all Hope the relevant person can handle it. I will award points once available.

[matt]

There are some people on this site who's only motivation is getting points. Your question was likely to attract attention from such people, with them giving the simple answer of changing the value directly in the table. To discourage this dangerous advice, I marked your question as a discussion.

This way, you only get answers from people who are motivated by wanting to help, rather than point hunters who don't care if they give bad advice.

[cathy_liang]

Oh, I see. Thx for your prompt update.

[Former Member]

What are points? Can they be eaten?

The last thing I care about is the points.

People improve the skills by discussion even if they are not correct sometimes.

[matt]

I wasn't talking about you. I meant the people who's posts have been rejected who jumped on the "go to SE16..." band wagon.

edit: like the chap below...

[Former Member]

Hi Cat,

Moderator message: as already stated, further posts offering dangerous advice will not be permitted. Therefore the content of this post has been removed.

Regards,

Ashok.

Message was edited by: Matthew Billingham

[former_member183424]

Please read the entire discussion before giving any reply.

Have you read the first reply from ?

By the way, the &sap_edit option will be no longer after implement the note  1420281 - CO-OM tools: SE16N: Deactivating &SAP_EDIT