Cookbook for Adaption to Discontinuation of Status Tables VBUK and

VBUP
Table of Contents
Cookbook for Adaption to Discontinuation of Status Tables VBUK and VBUP ....................................... 1
Introduction............................................................................................................................................. 2
Simplification of Status Data Model .................................................................................................... 2
Adaption .............................................................................................................................................. 2
Identifying Affected Objects and Source Code ....................................................................................... 3
1) Execute the scan report .............................................................................................................. 3
2) Remove Irrelevant Lines from the Results List ............................................................................ 3
Coding Adaption ...................................................................................................................................... 5
Case 1: SELECT for dedicated status values that can be replaced through use of data that was
already read in an existing call to the respective document table ..................................................... 5
Case 2: SELECT for VBUK/VBUP structure that can be replaced through use of data that was
already read in an existing call to the respective document table ..................................................... 5
Case 3: SELECT that can be switched from VBUK or VBUP to one statically-known document table 6
Case 4: SELECT that cannot be switched to one of the document tables ........................................... 6
Case 5: VBUK or VBUP are read to check for the existence of a document ....................................... 7
Case 6: VBUK is read to determine VBTYP or VBOBJ for a given VBELN ............................................. 7
Case 10: Insert to VBUK or VBUP ........................................................................................................ 7
Case 11: Update to VBUK or VBUP ...................................................................................................... 7
Case 12: Delete from VBUK or VBUP ................................................................................................... 7
Case 13: DDIC Projection views (and single-table DDIC DB database views) that refer to a status
table..................................................................................................................................................... 8
Variant A: The object type is statically known................................................................................. 8
Variant B: The object type is not statically known .......................................................................... 8
Case 14: DDIC Database views that refer to a status table ................................................................. 8
Variant A: Status table and one dedicated document table are part of the view ........................... 8
Variant B: View without document table ........................................................................................ 8
Deleted DDIC views joining VBUK ........................................................................................................... 9
Changed DDIC views joining VBUK or VBUP............................................................................................ 9
Appendix 1:............................................................................................................................................ 10
Fields from table VBUK .................................................................................................................. 10

Cookbook for VBUK/VBUP adaption

Version 2.2

Fields from table VBUP .................................................................................................................. 11

Introduction
Simplification of Status Data Model
In SAPERP, the status values of SD transactional documents are not held in the document tables
themselves, but in tables VBUK (for header) and VBUP (for item).
This change was made as part of the S/4HANA data model simplification. The status values of SD
transactional documents are now stored in the document tables themselves. The status information
has been moved from VBUK to VBAK, and from VBUP to VBAP for the sales order and, accordingly, to
LIKP and LIPS for delivery, as well as to VBRK for billing documents. Note that billing documents have
no item status values. Appendix 1 shows the status fields and their relevance for the five tables.
The obsolete tables have not been deleted, they stay active but empty, and can still be used for
typing.

Adaption
Read and write accesses to VBUK and VBUP have to be adapted to these changes.
You might also want to adapt views, LDBs (logical databases), search helps, domains, and TABUs.

Generic Table Accesses for Value Helps and Veto Checks

A special case of read access is the usage of VBUK or VBUP as a check table in structure fields or table
fields, and especially in screens and reports that leverage the check table. These kinds of usage
should be checked to avoid loss of functionality.
Theoretically, the check table can be used to hold a generic value help for a screen field or report
select option. These value helps depend on the content of the table, and they will fail if the tables are
no longer filled. However, these types of problems seem to occur very rarely because dedicated DDIC
search helps are typically used for screen fields.
What is more common in screens is that check tables are used for veto checksof fields VBELN and
POSNR. If the following settings are established, the veto check is active:

Checktable VBUK or VBUP is listed at the structure field or table field

Flag "check required" is set at the foreign key in this field
Foreign key flag is set in the screen field referring to this field

If the screen field is used semantically for only one of the document types, it may be appropriate to
replace check table VBUK with a more specific check table according to the semantic of the fields, for

Cookbook for VBUK/VBUP adaption

Version 2.2

example, VBAK. Alternatively, the veto check could be coded and called in the screen flow logic, or
abandoned if this is acceptable for the scenario.

Identifying Affected Objects and Source Code

With ABAP report RS_ABAP_SOURCE_SCAN, you can scan a list of packages for accesses to tables
VBUK and VBUP, and get a list of coding lines as a result. The advantage of this approach compared
to the where-used function of the ABAP workbench, or compared to using transaction
CODE_SCANNER, is that the results list can be filtered with regular expressions.
1) Execute the scan report
Enter the following string (note that there are space characters in it):
[ ]VBUK[ .]|[ ]VBUP[ .]
Flag String is regular expression
Enter a list of relevant packages
Set Occurrence +/- x Lines to zero
Decide whether you want to flag Explode INCLUDEs
Flag Ignore Comment Lines
This will return a list of all scanned code lines that contain the word vbuk or vbuk with leading
spaces and trailing spaces or periods. You can also export this list to a file.
(If you execute the report in dialog, you can navigate from the result list to the coding objects.)

2) Remove Irrelevant Lines from the Results List

In most cases, you will look only be looking for read and write accesses to the database tables. Using
a file-based tool that can filter out lines that match a regular expression, you can eliminate false
positives (especially lines in which the tables are only used for typing, which is quite common) and
irrelevant lines.
Filter (or search and replace with an empty string). The following lines provide an example:
(to remove spool header lines)
^[|-]*\r\n[|][ ]*(Object Name)[ ]*[|]\r\n[|][ ]*(Line Text)[ ]*[|]\r\n

(to remove assignments)

[|][ ]*[0-9]{6}[ ]+[A-Za-z0-9_]+[ ]+[=][ ]+[_A-Za-z0-9]+[.]?[ ]+[|]\r\n

(to remove typing with the tables)

[|][ ]*[0-9]{6}[ ]+[!]?[A-Za-z0-9_]+[ ]+(like|type|structure)[:]?[ ]+[ _A-Za-z0-9]+[.|,]?[ ]+[|]\r\n

(to remove tables und move-corresponding)

[|][ ]*[0-9]{6}[ ]+(tables|move-corresponding|check|data)[:]?[ ]+[ _A-Za-z0-9]+[.|,]?[ ]+[|]\r\n

Cookbook for VBUK/VBUP adaption

Version 2.2

(to remove includes that have no hits (only comments or lines already deleted in a previous step)
execute several times!
^[|-]*\r\n[|][ ]*[A-Z0-9_/=]*[ ]*[|]\r\n[|-]*\r\n
(to remove separator lines)
^[|][-]+[|]\r\n
We recommend that you back up the results of the scan report, and that you monitor the filtering
process.

Cookbook for VBUK/VBUP adaption

Version 2.2

Coding Adaption
Typically, customer coding that is adapted to work on S/4HANA does not need to be compatible with
SAPERP anymore. It can be adapted without the constraint of keeping the consumer compatible with
the SAPERP data model.

Case 1: SELECT for dedicated status values that can be replaced through use
of data that was already read in an existing call to the respective document
table
Simply use the data that was already read.
Example:
Old:

New:

select single * from vbak where vbeln = iv_vbeln into ls_vbak.

select single GBSTK from vbuk where vbeln = ls_vbak-vbeln into lv_gbstk.
if lv_gbstk = 'C'.
...
select single * from vbak where vbeln = iv_vbeln into ls_vbak.
if ls_vbak-gbstk = 'C'.
...

Case 2: SELECT for VBUK/VBUP structure that can be replaced through use
of data that was already read in an existing call to the respective document
table
Simply use the data already read. Also fill field VBOBJ if needed.
Example:
Old:

select single * from vbuk into ls_vbuk where vbeln = ls_vbak-vbeln.

New:

move-corresponding (structure or even internal table) from LS_VBAK to LS_VBUK.

VBOBJ:
If the VBUK field VBOBJ is evaluated, or the usage extent of the filled vbuk-like structure or
internal table is not known, field VBOBJ must be filled manually because it was previously
part of vbuk, but has not been transferred to the document header tables.
In the example above, add line
ls_vbuk-vbobj = IF_SD_DOC_OBJECT=> SALES_DOCUMENT.
If you fill a table, you need a loop to fill the fields in all records.
You should use the constants SALES_DOCUMENT, DELIVERY, and INVOICE from interface
IF_SD_DOC_OBJECT to do this.
Move-corresponding for internal tables:
Cookbook for VBUK/VBUP adaption

Version 2.2

If you want to use this pattern to replace one SELECT from VBUK for different objects, as was
done in Report SAPDBKMV for sales orders and deliveries, you can add KEEPING TARGET
LINES to allow subsequent moves into the same internal table:
MOVE-CORRESPONDING xvbak[] TO xvbuk[].
MOVE-CORRESPONDING xlikp[] TO xvbuk[] KEEPING TARGET LINES.

Case 3: SELECT that can be switched from VBUK or VBUP to one staticallyknown document table
(If Case 1 and Case 2 cannot be applied.)
If the VBELN in the where clause has been filled from a specific document table, or if only status
fields that exist in only one of the document tables are read or used, replace VBUK/P with the
respective table name.
(For the assignment of status values to tables, see the diagrams in Appendix 1.)
If no column list is specified, but a * is used to select all columns, then:

A change from select into table to Select into corresponding fields of table is
necessary (similarly: from appending table to appending corresponding fields of table
).
The remark regarding field VBOBJ from Case 2 should be considered here.

Case 4: SELECT that cannot be switched to one of the document tables

If its obvious that VBUK or VBUP is read for different document types (from documents stored in
vbak, likp and vbrk or their item tables) or if the document type is unknown, use one of the following
FMs, which can read all header tables or all item tables:
o
o
o
o

SD_VBUK_READ_FROM_DOC
SD_VBUK_READ_FROM_DOC_MULTI (mass-enabled for multiple documents)
SD_VBUP_READ_FROM_DOC (can return one dedicated item of a dedicated document or all
items of a document)
SD_VBUP_READ_FROM_DOC_MULTI (mass-enabled for multiple documents)
o returns all items for a list of VBELNs if only IT_VBUK_KEY is filled
o returns all items requested in a list of VBELN-POSNR pairs if only IT_VBUP_KEY is
filled

The mass-enabled FMs also support VBELNs from different object types (tables, that is) in one call.
If the VBTYP or the VBOBJ of the document is available, it can be passed to the FMs by using the
optional import parameter I_VBTYP or I_VBOBJ. This will direct the access to the one specific table.
Please note that append fields to VBUK and VBUP are not considered by these FMs.

Cookbook for VBUK/VBUP adaption

Version 2.2

Case 5: VBUK or VBUP are read to check for the existence of a document
SELECT SINGLE * FROM VBUK WHERE VBELN = XVBRP-VBELN.
IF SY-SUBRC NE 0.
[structure vbuk not evaluated later]
Decide whether this can be replaced by a call to one document table, or by subsequent calls to
several tables. You can also use FM SD_VBUK_READ_FROM_DOC or SD_VBUP_READ_FROM_DOC..

Case 6: VBUK is read to determine VBTYP or VBOBJ for a given VBELN

Note that field VBOBJ has not been transferred to the document tables.
If VBTYP is known, VBOBJ can be derived without database access using the static methods
IS_ANY_SALES, IS_ANY_DELIVERY, and IS_ANY_INVOICE of class CL_SD_DOC_CATEGORY_UTIL.
If only VBELN is known, decide whether the VBUK select can be replaced by a SELECT to one
document table or by several calls to different document tables. A hit in one table logically
determines the VBOBJ.. VBTYP is part of the document header tables.
FM SD_VBUK_READ_FROM_DOC can also be used, because it fills the field VBOBJ and, of course, also
returns VBTYP.

Case 10: Insert to VBUK or VBUP

For standard SD documents, all inserts to VBUK or VBUP should be obsolete. These inserts have to be
removed. Instead, the inserts to the specific document table that now holds the status values have to
be extended.
However, some industries may still use and fill VBUK or VBUP for their own document types,
especially if they are components of a single codeline.

Case 11: Update to VBUK or VBUP

Updates to Insert VBUK or VBUP have to be replaced with updates for the specific document tables.
If the correct document table is unknown, the two (for item) or three (for header) document tables
have to be tried, one after another, until a hit is found.
However, some industries may still use VBUK or VBUP for their own document types, especially if
they are components of a single codeline.

Case 12: Delete from VBUK or VBUP

Even before the data model is simplified, VBUK/VBUP entries should only be deleted together with
their respective document entries. Therefore, code for VBUK or VBUP deletion can be removed if it is
obvious that the related document entries have been deleted.
If only VBUK or VBUP entries are deleted, this is typically a status repair program, one that is
described in a note, for example. Such programs have to be commented out, because inconsistencies

Cookbook for VBUK/VBUP adaption

Version 2.2

between document tables and status tables are no longer possible, and adaption doesnt make sense
here.
However, some industries may still use VBUK or VBUP for their own document types, especially if
they are components of a single code line, and might (for whatever reason) want to delete VBUK or
VBUP entries that belong to their own document types..

Case 13: DDIC Projection views (and single-table DDIC DB database views)
that refer to a status table
Variant A: The object type is statically known
The simplest adaption is to change all consumers that read this view. You can change them to read
the document table of this object type directly, instead of reading the view. Alternatively, You can
adapt the view to refer to the document table instead. Note that field VBOBJ cannot be filled within a
DDIC view. Wherever this field is evaluated, consumer adaption is required.
If a view has a very large amount of consumers, and VBOBJ is not being evaluated, you might want to
adapt only the view itself, to save yourself the effort of consumer adaption.
Variant B: The object type is not statically known
Because the data could be stored in one of several tables, this scenario cannot be solved with a view
based on a single table. Furthermore, a DDIC database view across all possible tables will not work
because it only supports inner joins. (Note: You could create a CDS view by using union or outer join.)
The consumers reading this view have to be adapted. One option is to use the FMs listed in case 4
instead of the view. Alternatively, each consumer SELECT to the obsolete view can be replaced with
multiple subsequent SELECTs on the possible tables (or on views referring to these tables).

Case 14: DDIC Database views that refer to a status table

Variant A: Status table and one dedicated document table are part of the view
This kind of view can be simplified. Status fields and existing select conditions in the view have to be
adapted to refer to the document table. Then, the status table can be removed from the view.
If the view uses only these two tables (for example, a join of VBAK and VBUK, joined via VBELN), it
may be useful to delete the view and adapt all consumers to access the document table directly. This
applies if there is no explicit desire to limit the document table's fields (to reduce the amount of
transferred data, for example) or to implement central selection conditions ( for reuse, for example).
Again, the number of consumers should be taken into account.
Variant B: View without document table
From an adaption perspective, this corresponds to Case 13 with additional joins, and has to be
handled accordingly.

Cookbook for VBUK/VBUP adaption

Version 2.2

Deleted DDIC views joining VBUK

The following DDIC views have been deleted in S/4HANA:
View
/SPE/LIKPUK
V_CMPB_ASGN
SD_BACKORDER
VAKPA_REF

Joined Tables
LIKP, VBUK
CMPB_ASGN, CMPB_MAP,
VBUK
VAKPA, VBAK, VBUK
VAKPA, VBAK, VBUK

Read accesses to these views should be replaced with SELECT statements on a single table, or if
needed, with appropriate joins.

Changed DDIC views joining VBUK or VBUP

The following DDIC views have been adapted in S/4HANA:
View
VBAKUK
VBRKUK
LIPSUP
VBSSUK
V_CM01_OPT
V_CM02_OPT
V_CM03_OPT
V_CM04_OPT
V_CM05_OPT
V_CM06_OPT
V_CM07_OPT
V_CM08_OPT
V_CM09_OPT
V_CM10_OPT
V_OLR3_VBAX
V_OLR3_VBAX_INQ
V_OLR3_VBAX_QUO

In these views, view field VBOBJ (referring to VBUK-VBOBJ) was removed in most cases. If there is a
consumer that reads and evaluates view field VBOBJ, see the remark regarding field VBOBJ in section
Case 2: SELECT for VBUK/VBUP structure that can be replaced through use of data that was already
read in an existing call to the respective document table.
For some views, status fields that were not relevant for the respective object were also removed.

Cookbook for VBUK/VBUP adaption

Version 2.2

Appendix 1:
These diagrams show which status fields from tables VBUK and VBUP have been transferred to which
document tables:
Fields from table VBUK

Cookbook for VBUK/VBUP adaption

Version 2.2

10

Fields from table VBUP

Cookbook for VBUK/VBUP adaption

Version 2.2

11