Cookbook for Field Length Extension of VBTYP (Sales Document

Category) in S/4HANA

Cookbook for Field Length Extension of VBTYP (Sales Document Category) in S/4HANA...................... 1
Overview ........................................................................................................................................ 2
Constants........................................................................................................................................ 2
Identify affected Objects and Source Code ...................................................................................... 3
Adaption of DDIC Elements ............................................................................................................. 4
Views: ......................................................................................................................................... 4
Data Elements ............................................................................................................................. 4
Tables and Structures .................................................................................................................. 4
Adaption of Source Code ................................................................................................................ 5
Classes, Includes, Functions, Reports........................................................................................... 5
Interfaces .................................................................................................................................... 6
External Interfaces (BAPIs, RFC Function Modules, IDOCs) .............................................................. 7
BAPIs........................................................................................................................................... 7
Released RFC Function Modules ................................................................................................ 12
IDOCs ........................................................................................................................................ 12

Overview
This cookbook describes the adaption of custom code related to the field length extension of the
sales document category (data element VBTYP) in S/4HANA.
The sales document category has been extended from Char1 to Char4 in S/4 HANA.
Technically, all usages of the data element VBTYP (Char1) and its derivations like VBTYP_V, VBTYP_N,
and so on, have been replaced by the new data element VBTYPL (Char4), or derivations of the new
data element, such as VBTYPL_V or VBTYPL_N.
The data element VBTYP and its derivations are deprecated, but still exist technically with the old
length Char1.
All usages of the deprecated data elements in custom code have to be adopted as described in this
cookbook.
The field length extension of the sales document category has been implemented in all of S/4HANA.
There are a few single components left that still dont fully support VBTYP with length 4, for example,
ATP here, VBTYP with Length = 1 is still used for reasons of compatibility with APO.
In some tables, such as VBRK, a field VBTYP_EXT with length Char4 was introduced in SAP ERP 6.0
EhP7. This additional field was used to support additional code values for the sales document
category, for example, f001, f002, f003, f004, in component Commodity Management.
In S/4HANA, this additional field has been eliminated from all tables. All code values are stored in the
original table field for VBTYP, which is now longer in SAP S/4HANA.
During the conversion to S/4HANA, the content of both fields is merged automatically into the
extended field VBTYP.

Constants
The constants in the include RVVBTYP have been replaced by a constant in class:
IF_SD_DOC_CATEGORY. For combinations of VBTYP values, the constants are collected as methods
in class CL_SD_DOC_CATEGORY_UTIL. Take a look at the attached Excel document for a detailed list
of the constants and the corresponding replacement.

Microsoft Excel
Worksheet

Identify affected Objects and Source Code

1. Identification of the affected customer objects is carried out by the Custom Code Scan Tool.
2. For a more detailed source code analysis, the report RS_ABAP_SOURCE_SCAN may also be
appropriate.
You can search by using the names of the data elements that belong to domain VBTYP. For
example, if a data element has the name SD_DOC_TYPE, use this string as the search term.
One big advantage of the report is that you can jump directly from the results list to the
source code. If you are expecting a huge number of results, the report can be executed in the
background.

Adaption of DDIC Elements

Views:
Views dont need to be considered because, due to the change of the underlying table
structure, the view automatically receives the correct data type.

Data Elements
Before you adapt a DDIC Element, first adapt the referenced implementations (Classes,
Reports, Functions, Includes).
This reduces the number of syntax errors.
If a data element has the domain VBTYP with Length 1 assigned to it, reassign the data
element to the domain VBTYPL with Length 4.

Tables and Structures

Before you adapt a DDIC Element, first adapt the referenced implementations (Classes,
Reports, Functions, Includes).
This reduces the number of syntax errors.
To adapt a table or structure, change the referenced data element accordingly:
Old
VBTYP
VBTYP_N
VBTYP_V

New
VBTYPL
VBTYPL_N
VBTYPL_V

Adaption of Source Code

Classes, Includes, Functions, Reports
Check and adapt data declaration with the correct data element:
i. Old:
DATA: lc_vbtyp_wa(1) TYPE c.
ii. New:
DATA: lc_vbtyp_wa LIKE likp-vbtyp.
iii. Fallback: If no corresponding data element is found, make the declaration with data
element VBTYPL (DATA: lc_vbtyp_wa TYPE vbtypl.)
Check and correct all parameters:
i. Import / Export / Changing Parameters for Functions
ii. Method / Class / Interface Parameters for Objects
iii. Using / Changing Parameters for Reports and Forms

Replace literals with corresponding constants in interface IF_SD_DOC_CATEGORY:

i. Old: <ls_xlikp>-vbtyp EQ '7'
ii. New: <ls_xlikp>-vbtyp EQ IF_SD_DOC_CATEGORY=>DELIVERY_SHIPPING_NOTIF
Replace CA queries (CA = contains any) with corresponding constants in interface
IF_SD_DOC_CATEGORY:
i. Old: <ls_xlikp>-vbtyp CA '7'
ii. New: <ls_xlikp>-vbtyp EQ IF_SD_DOC_CATEGORY=>DELIVERY_SHIPPING_NOTIF
Note: Comparison with operator CA would return true if one character fits. For the
new Char4 field length, this logic is wrong, and the comparison operator must be
changed to EQ.
Replace ranges with the corresponding range in class CL_SD_DOC_CATEGORY_UTIL:
i. Old:
RV45C-VBTYP = VBTYP_VERK.
PERFORM R_VBTYP_FUELLEN.
select * from tvkk where vbtyp in r_vbtyp.

ii. New:

r_vbtyp = cl_sd_doc_category_util=>rg_any_sales( ).
select * from tvkk where vbtyp in r_vbtyp.

Loop Example: (Include

LV45LF0S)

i. Old: LOOP AT FXVBFA WHERE VBELV EQ I_VBELV

AND
AND
AND
AND

POSNV EQ I_POSNV
VBTYP_N CA VBTYP_AUFT
VBTYP_N NA VBTYP_RETOUR
STUFE
EQ 0.

ii. New:

LOOP
AND
AND
AND
AND

AT FXVBFA WHERE VBELV EQ I_VBELV

POSNV EQ I_POSNV
VBTYP_N in cl_sd_doc_category_util=>rg_any_order( )
not VBTYP_N in cl_sd_doc_category_util=>rg_any_retour( )
STUFE
EQ 0.

Replace queries on document types with corresponding query in

CL_SD_DOC_CATEGORY_UTIL:
i. Old: CHECK: VBAK-VBTYP CA VBTYP_VERK.
ii. New: CHECK: cl_sd_doc_category_util=>is_any_sales( iv_vbtyp
= vbak-vbtyp ).

Interfaces
Replace constants with the constants from IF_SD_DOC_CATEGORY.

Note: If the constant in an interface is redundant, it can be removed and the consumer can use the
corresponding constant in: IF_SD_DOC_CATEGORY

External Interfaces (BAPIs, RFC Function Modules, IDOCs)

In new releases of SAP ERP, changes to external interfaces must be compatible with previous
releases. This compatibility approach holds true for BAPIs, released RFC function modules, and
IDOCs.
The same principle applies for the conversion to S/4HANA.
To facilitate a smooth conversion, and to support interoperability of S/4HANA with other SAP
solutions such as SAP ERP, SAP CRM, and so on, external interfaces in S/4HANA are kept compatible
with SAP ERP.
In the context of external interfaces, Compatible means:
The data transfer in RFC calls and IDOC containers is based on binary parameter structures. Changes
or enhancements to these structures in a newer release or support package must keep the order and
length of existing fields identical.
Parameters of BAPI function modules, or of released RFC function modules that contain one or more
fields of type sales-document category, are extended (at their respective ends) with additional
_LONG fields. The original, short-length fields are kept in the structures as they are.
IDOC segments that contain one or several fields of type sales-document category are extended (at
their respective ends) with additional _LONG fields. The original, short-length fields remain
unchanged.

BAPIs
Outbound Reading data from a BAPI:
Take a look at the following BAPI as an example:
BAPI_BILLINGDOC_GETDETAIL
The export parameter BILLINGDOCUMENTDETAIL is of type BAPIVBRKOUT.
Structure BAPIVBRKOUT contains the field SD_DOC_CAT (SD Document Category).
In S/4HANA, the structure has been extended with field SD_DOC_CAT_LONG.

SAP ERP, status in EhP 7:

SAP S/4HANA:

If you call the BAPI from within or from outside the S/4HANA system, you need to consider the
following:

Field SD_DOC_CAT_LONG (Char4) always contains the correct value for the SD document
category.
Field SD_DOC_CAT (Char1) contains the value for the SD document category in all cases
where the code value fits into the length Char1. This ensures compatibility for all short code
values.

If the code value of the SD document category is longer than Char1, the field SD_DOC_CAT
(Char1) is empty.
This applies, for example, for the code values f001, f002, f003, and f004.
It will also apply in future releases, when additional code values will be delivered by SAP.
If you are interested in one or several concrete code values of short length (Char1), you can
still use the field SD_DOC_CAT.
If you are interested in at least one code value with a length that is bigger than Char1, or if
you want to treat all possible values generically, you have to adapt the BAPI call and use the
new field SD_DOC_CAT_LONG.

Inbound Creating or changing data via BAPIs:

Example: BAPI_BILLINGDOC_CREATEFROMDATA
The import parameter BILLING_DATA_IN is a table of type BAPIVBRK.
BAPIVBRK contains the field REF_DOC_CA (Document Category of Preceding SD Document).
In S/4HANA, the structure has been extended with field REF_DOC_CA_LONG.
SAP ERP, status in EhP7 SP 09:

S/4HANA:

If you call the BAPI from within or from outside the S/4HANA system, you have to consider the
following:

If the field REF_DOC_CA_LONG (Char4) is filled with a valid code value by the caller, it will be
carried over into the document persistency.
If the Field REF_DOC_CA_LONG (Char4) is empty and the field REF_DOC_CA (Char1) is filled
with a valid code value by the caller, the value from REF_DOC_CA will be carried over.
If both fields REF_DOC_CA and REF_DOC_CA_LONG are both filled, the values must be
identical. If they are not, the BAPI returns an error message and does not process the
document.
If your code passes only dedicated values with a short length (Char1), you may still use the
field REF_DOC_CA.
If you need to pass at least one code value with a length bigger than Char1, or if you want to
treat all possible values generically, you have to adapt the access and use the new field
REF_DOC_CA_LONG.

BAPI*X Structures
In most cases, a related BAPI*X structure exists for BAPI structures used in BAPIs that expose
functionality in order to change existing data. The change BAPI contains a pair of parameters, one
with the BAPI structure and a related one with the BAPI*X structure.
For each attribute field in the BAPI structure, the related BAPI*X structure contains a field with the
same name, but with data type BAPIUPDATE (Char1).
This procedure was introduced to enable the identification of cases in which a field value should be
changed to the initial field value, and to distinguish this case from the case in which a field value has
not been specified.

The value X in a field of the BAPI*X structure indicates that the value of the corresponding field in
the parameter typed with the BAPI structure should be applied as a change.
The value SPACE in a field of the BAPI*X structure indicates that no change of the corresponding field
in the parameter typed with the BAPI structure should be applied.
This is the standard behavior of change BAPIs according to the BAPI guidelines.
Fields added to a specific structure BAPI<struc> in S/4HANA are also reflected in the related structure
BAPI<struc>X.
Example: Structure BAPISDHD1X

Structure BAPISDHD1

[There are some differences for the key fields, therefore the number of fields is different.]
The implementation of a change BAPI using parameters with structures BAPISDHD1 and BAPISDHD1X
takes the field pair REFDOC_CAT/REFDOC_CAT_LONG into account if at least one of the two fields in
the structure BAPISDHD1X is filled with X.
This way, new BAPI calls can work with the new field REFDOC_CAT_LONG in the structure
BAPISDHD1X as usual (according to the BAPI guideline).
On the other hand, existing calls that are adapted to the new field REFDOC_CAT_LONG of
BAPISDHD1 still work if the original field REFDOC_CAT in the structure BAPISDHD1X is marked with
the value X. This slightly more robust and error tolerant for callers, because the two fields
REFDOC_CAT and REFDOC_CAT_LONG are treated as a common field pair in the implementation of
the BAPI anyway.
Remark:
BAPI structures for certain Business Objects are often reused for function modules that read data,
and for function modules that change data. Some of the structure fields that are supported and filled
in the read function are not considered in the changing function, for example, because the field value

is derived from context information.

Example: In the BAPI BAPI_CUSTOMERRETURN_CHANGE, the parameter RETURN_HEADER_IN is of
type BAPISDHD1, which contains the field SD_DOC_CAT. Because the SD document category of a
customer return is a fixed value (IF_SD_DOC_CATEGORY=>RETURNS = H), changes to the field
SD_DOC_CAT or SD_DOC_CAT_LONG are ignored.

Released RFC Function Modules

The same principle described for BAPIs is also valid for released RFC function modules.
For all released RFC function modules that contain the Sales Document category as a field of an
interface parameter, SAP has enhanced the interface structures while keeping them compatible.
The original field is kept, along with the original data type (VBTYP, Char1), and an additional _LONG
field has been added to the end of the structure.
Note that this does not apply for non-released function modules.
For non-released function modules, the adaption pattern was chosen depending on the usage of the
function module in SAP-SAP integration scenarios.
For cases in which a function module is used in integration scenarios between different SAP
solutions, a compatible enhancement has been implemented to decouple the transformation to
S/4HANA from adaptions in other SAP solutions.
If a function module is not used in such integration scenarios, it may have been adapted in a way that
makes it incompatible with SAP ERP. In this case, all usages within the ERP components of S/4HANA
have been adapted accordingly.

IDOCs
Enhancements of IDOC segments in S/4HANA have been implemented in a compatible manner,
similar to the extension of BAPIs.
The handling of the field pair in IDOCs is also very similar to the handling of a field pair in a BAPI
structure.

Example:
IDOC type SALESORDER_CREATEFROMDAT2
The IDOC type is generated from BAPI_SALESORDER_CREATEFROMDAT2.
The BAPI contains the BAPI structure BAPISDHD1.

The BAPI structure has been enhanced with the additional fields SD_DOC_CAT_LONG and
REFDOC_CAT_LONG.

In the IDOC segments, the BAPI structure is mapped to a corresponding segment structure.
The ALE container is a generic restricted character field with 1000 characters.
In case the length of the segment structure exceeds 1000 characters, additional fields are generated
into a child segment.
In case of BAPISDHD1, this leads to:
Segment structure E1BPSDHD1 with versions
E2BPSDHD1000
E2BPSDHD1001
E2BPSDHD1002
E2BPSDHD1003:

and child segment E1BPSDHD11 with versions

E2BPSDHD11000
E2BPSDHD11001: