Skip to Content
avatar image
Former Member

What is the best way to mass update "Custom fields" in master tables FKKVK, DPSOB_BP_ACC and BCONT?

SAP PSCD module has master tables FKKVK for contract account,

DPSOB_BP_ACC for contract object and BCONT for Business contact.

We have created Z fields in these tables using Customizing includes in each table.

We want to run a program which update these z fields in the tables daily.

Number of records processed can be anywhere between 10,000 and 500,000

I tried looking for BAPI to process multiple records together(to maximize performance) but could not find any.

So I wrote a Projection view and updated the tables.

But the quality team insists on BAPI because we are updating a standard table.

I tried explaining that we are only altering the Z fields in these tables.

My question(s):


Is my approach correct and because I can just call FMs for locking and authorizations.

to make it work like a bapi. (Here I will also need to know how to call mass change of "Change documents"). Have I missed anything ?



Should I call BAPI in a loop 500,000 times.


Do you have a better way ?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    Aug 26, 2017 at 08:19 AM

    I think that the Quality Team needs to be more informed. Tell them again that these are custom columns in standard tables, so you may update them directly, and I fully agree with your point A (could be also workflows, change pointers, ...)

    Using a projection view is a nice way to guarantee standard columns are not updated; if you run single updates, you may also specify the exact columns you update, UPDATE table SET zzcolumn = ... WHERE ...

    To avoid conflicts with other processes running at the same time, you may eventually be careful if other jobs only read these tables (if the database does committed reads, like Oracle, there could be "Snapshot too old" dumps), but this is the same precaution as for BAPIs.

    Add comment
    10|10000 characters needed characters exceeded

    • If you update standard fields, then you may break the database integrity. Of course AEDAT and AENAM don't seem so harmful, but who knows. You decide.

      For the lock, there's the risk that someone starts editing the business object right before the mass update, so the save could take the custom fields back to their values at the beginning of the editing. A SAP lock (not a database lock) is quick and harmless to do right before the mass update (it would fail if only one user is editing a business object, but it's a fair reason for failing, nobody should work on these business objects during the mass update).

  • Aug 28, 2017 at 09:28 PM

    Hmmm, it is a rare occasion I would _partly_ disagree with Sandra.

    Data integrity is but one aspect, there's also locking, change documents, change pointers, PPF, WF, BTE's, BAdIs, exits, whatnots; all of which could have some special functionality.

    I say partly disagree, because of the assumption that the OP has all of those under control and would even go so far as to create change documents. Fair enough.

    I can picture a simple scenario: There is A BAdI or enhancement that the developer is not aware of, which does some stuff that includes the Z-fields. If the Z-fields are updated directly, it won't be called. If the update is via BAPI then it will (probably).

    So if you are certain there are no secondary activities that could be impacted then fine.

    If it's a once-off process, then I'd save myself the headache of messing around with change documents, locks and auths and searching for other potential change hooks, and just do it via BAPI. Batch the 500,000 up into overnight packets and weekend runs if need be. Work process time is cheaper than developer time.

    Add comment
    10|10000 characters needed characters exceeded

    • Agreed for SAP locking, it's important to prevent another activity to update the table at the same time, but I guess that it wouldn't harm the database if an update fails, as it would only kill the process there couldn't be any database integrity error in standard programs (for custom columns, it's under the responsibility of the client team).

      The important part of the original question is that the Quality Team insists on not updating directly a standard table, but I'm sure that this principle was intended for standard columns, not for custom ones (at least, probably there was no study about it).

      SAP support still applies in case of problems with standard programs as long as they can be sure that the standard columns are not updated, it's why using a projection view or naming columns explicitly is important).

      For change pointers, and so on, it usually apply to individual updates, so it's only under the responsibility of the client developers, there is no risk that it impacts standard processes.

      PS: of course, all this is valid if it's only about updating custom columns (not inserting or deleting rows).

  • Sep 08, 2017 at 01:52 AM

    Can I ask: what is the business requirement for these Z fields, and what triggers the need for these fields to be updated?

    There could be another way to meet your requirements. You have told us about your solution, but not really about the business scenario.

    (Just thinking out loud here: you could create a Z table with same key as FKKVK. Then you are free to update it any way you like with no BAPI or locking issues.)

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member


      Business requirement: Assess daily whether any CA/CO/CC is ready for the setting of an archiving date(as per government laws).


      Set a default archiving code (Z field 1) at the time of creation of masters for CA, CO and CC.

      In a daily run, check if any of the masters CA or CO or CC changes its status from active to passive or from passive to active. Set a date (Z Fiedl 2) to indicate that the master is not active and hence eligible to be considered for Archiving.

      Then set a date (Z Fiedl 3) to indicate that the master can be archived on a date which is calculated based on Archiving code and a formula defined by Government law.

      To answer your question: We cannot create another Z table in order to achieve our requirement.


      1) The Z fields are properties of masters and since we have customizing includes in their respective master tables(it is SAP PSCD module which uses events to create/alter) we need to use them in masters.

      2) At this point in time altering the design is not feasible due to

      a) Dependencies

      b) time and resource limitations