Skip to Content

Batch Determination – Debug Tips


Issues with batch determination are very common. Sometimes only a simple customizing setting is missing which can impact the whole determination process.

The batch determination itself is not difficult to configure, however, we must have an extra attention, specially in the strategy, search procedure and the selection criteria.

It’s also easy to find the root cause of many common issues using the DEBUG, of course, if we know the right place to debug. This is idea of this document, give you some tips about the correct points and what information we can extract using the DEBUG tool.

First of all, there is one main function to execute the batch determination, it is called during in the production order, process order, sales order, delivery and a few other areas. The logic inside of the function is the same, what makes difference are the parameters used when it is called.

The Function Module name is VB_BATCH_DETERMINATION, it can be accessed using transaction SE37. I’ll go through the decisive points, where the important information can be found.

There are three main routines that are executed in sequence to make a proper batch determination:

1. SELECT_BATCH_DB - Select all the available batches;

2. SELECT_BATCH_CL - Sort and restrict according to the selection criteria;

3. SELECT_ BATCH_AC - Check the stock according to the availability check settings.

If you check in the source code, you’ll see that the sequence is not exactly the same as showed above. However, internal table XFS is the one that stores the sequence and executed the correct sequence.


The first routine executed is to select the batches. It will select all batches available, it does not consider the batch stock but select all available batches according to the restrictions imposed by the business (sales order, process order, goods issue, etc). The parameters used to read the batches are mainly the material number (MATNR), plant (WERKS) and storage location (SLOC).

The internal function used to read the batches is VB_BATCH_READ.

If we check the source code in detail, we can see that there are many different SELECT statements for transparent table MCHB and also from V_CF_MCHB which is a view that contains three tables (MCHB, MCHA and MCH1).

It’s not difficult to conclude that performance issues can happen if table MCHB have a huge amount of data and the SELECT statements in VB_BATCH_READ do not use more parameters to restrict the selection.

This is the reason why we always recommend executing the archiving of the MCHB old records. It will improve the performance significantly. The object used to archive is MM_SPSTOCK (transaction SARA).

It’s also possible to create our own logic to select the batches. It can be achieved using BADI VB_BD_SELECTION. The methods PRESELECT_STOCKS and PRESELECT_BATCHES can be used to create a custom code to select only the batches wanted. It’s possible to suppress the VB_BATCH_READ if the BADI is active, it facilitate if a specific batch selection must be done.

The internal table that stores the result of the batch selection is YDB_MCHB.


After the batch selection, the batch search strategy should “decide” which batches are selected according to characteristics defined in the classification data. If the batch is not classified (classification tab in batch master), it won’t be selected. So, it is very important to classify the batches many users forgot to do it.

The function modules that select the class and the characteristics don’t belong to the Batch Determination (LO-BM) itself but belong to classification (CA-CL). There are 2 key functions, one select the class and characteristics assigned to a batch (CTMS_DDB_HAS_VALUES) and the other select the values (CUSL_BATCHES_SELECTION).

It’s also possible to create your own logic for the selection criteria using BADI VB_BD_SELECTION_CRITERIA or the userexit EXIT_SAPLV01F_001. I always recommend using BADIs as Userexits have some particular problems, specially because the “freedom” we have to change the variable and internal tables resulting, sometimes, in corrupt entries saved in the database and incorrect data displayed. In the following screen, you can see the source code where both can be choose.

The internal table that stores the result of the batches after the selection criteria is YCL_MCHB.


If the Availability check is active, it will restrict the batches according to its customizing. If it’s not active, it will only exclude the batches with no stock and continue the VB_BATCH_DETERMINATION execution.

The Function module AVAILABILITY_CHECK_CONTROLER is the key for the availability check. If the function is executed, it means that availability check is active. We can check the result in internal table XATPCS, which stores the available quantity calculated inside of availability check. The field that must be checked is VMENG, if it’s zero, there is no available stock for a specific batch. It can also be checked in transaction CO09.

After the execution of AVAILABILITY_CHECK_CONTROLLER, the batches with stock zero will be excluded from the final result.

The table that stores the result of the batch selection after the availability check is YAC_MCHB. This internal table is the one that will contain the final result of the batch selection. It will not contain the batches sorted yet. The sort happens in Form SORT_BATCH.

Keep in mind that this document covers the most common batch determination scenarios, there are specific scenarios, for example, in Warehouse Management which uses specific routines and restrictions that are not covered by this document.