How to analyze incorrect data in the sales

information system (SD-IS)

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

TABLE OF CONTENT
INTRODUCTION ............................................................................................................................................... 3
ANALYZING INCORRECT INFO STRUCTURE DATA ................................................................................... 3
Initial Situation ................................................................................................................................................. 3
Checking actual info structure data .............................................................................................................. 5
Checking update simulation ........................................................................................................................... 5
Checking update group assignment ............................................................................................................. 8
Checking updating rules ............................................................................................................................... 10
Further things worth checking ..................................................................................................................... 18

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

The purpose of this document is to help in analysing issues within info structure updating and to
describe the most common causes for incorrect or missing info structure updates.

INTRODUCTION
To present the different ways for analyzing info structure update issues, this document uses an exemplary
info structure S915. However, the steps described in the document are generally valid for any info structure
from the SD-IS area. That is, S001 S006, S126 S128, as well as customer owned info structures that
belong to application 01. Of course, for other info structures than the exemplary S915, the specific steps
need to be adjusted according to the actual info structure definition / usage.
The example info structure has the following characteristics and key figures:

ANALYZING INCORRECT INFO STRUCTURE DATA

Initial Situation
When you look at statistical data in a standard analysis, you are seeing unexpected results.
For example, no data is shown at all, e.g.:

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

While there is actually a sales document existing, which you expect to be shown in the analysis, like for
example:

Or the data shown in the analysis is incorrect, for example the analysis shows the following values:

While the actual sales order looks as follows:

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Checking actual info structure data

In such a situation you should first of all check whether the data is only shown incorrectly in the analysis or
whether the data is actually stored incorrectly on the data base. For this you need to check the info structure
values directly in SE16 using the same selection criteria you used to display the data in the analysis.
If you are not sure to which info structure the analysis belongs, you can find this out for example by pressing
the Selection log button in the analysis:

This will give you information about the relevant info structure:

This info structure is the one you then need to check in SE16:
If the data shown in SE16 is correct, there is no problem with the update of statistical data but with the
analysis being used to display the data. However, in this document we will not focus further on this case,
as the standard analyses themselves belong to the LO-LIS area and not to the SD-IS area. Still, generally
it is recommendable in such cases to check whether there are any customer owned formulas for list
enhancements. Furthermore it might be helpful to search for SAP notes in the LO-LIS area for the specific
symptom.
If the data in SE16 is also incorrect, please go on as described in section Checking update simulation.

Checking update simulation

You have found out that the info structure data is incorrect already on the database. Now you want to check
this in more detail.
Regarding our example info structure S915, lets assume the following situation:

That is, for document 11763 there is data stored in the info structure, but the data is incorrect. And for
document 11764 there is no data stored in the info structure at all.
A good way to continue the analysis in such a case is to do an update simulation. This can be done via
transactions MCVR (for sales orders), MCVT (for deliveries) and MCVV (for invoices). Depending on the
result of the simulation you can then go on.
If the update simulation shows the correct result, this means that a statistical setup will update the info
structure with the correct data for the document.

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

For example for our example document 11763, the updating simulation in MCVR shows

This is the correct data as it is existing in the sales document. Thus, after a new statistical setup the data
in the info structure will be correct.
Please see SAP note 1597097 for more details on how to correct the info structure data in such a case.
Please also note that to find out why the data in such a case was initially updated incorrectly into the info
structure a reproducible example for the creation/change of such a document is necessary, refer SAP
note 978089. However, you could have a look at section Further things worth checking for some more
hints on what could be the cause for wrong updating in online mode (i.e. from transactions VA01, VA02,
VL01N, etc) while the statistical setup leads to a correct result.
If the update simulation shows an incorrect result, too, you need to analyze further. Possible cases are:
The update simulation shows no result at all.
For example, for our example document 11764 the update simulation shows the following result:

That is, the info structure S915 is not even mentioned here.
Then you should first of all check, whether the info structure is activated for updating at all. You can do
this in transaction OMO1. There double click on the info structure in question. This opens a pop up
window, where you need to check the setting in section Updating. Here either Synchronous
updating (1) or Asynchronous updating (2) resp. Asynchronous updating (3) has to be set.

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

If the info structure is activated for updating, but still the update simulation shows no updating, there is
usually some problem with the update group assignment. To further analyze this, please proceed as
described in section Checking update group assignment.
The update simulation shows a result for the relevant info structure, but for the key figure in question
no updating is shown.
For example:

Then you can set the cursor first on the key figure in question and afterwards press button Key
figure. This will give you more information about why the info structure is not updated for the
specific key figure.
For example a result like

means that there is a requirement defined in the updating rule, which prevents the info structure from
updating. In this case you need to have a closer look at the requirement to find out the reason for the
missing update. Please see section Checking updating rules for more information on this.
Another result might be

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

So in this case updating would generally be possible, but the value which was calculated for the key
figure is zero. In this case, too, you need to have a closer look at the updating rules to find out more
about the reason for this. Again, please see section Checking updating rules for more information on
how to analyze updating rules.
Lastly, it could also be possible, that the update simulation shows a result, but this is not the value you
expect.
Also in this case it is necessary to have a closer look at the updating rules. Please see section
Checking updating rules on how to continue.
Checking update group assignment
The update group is stored in the field STAFO of database tables VBAK, VBAP, LIKP, LIPS, VBRK and
VBRP. This field is not shown in the transactions VA0x, VL0xN or VF0x, it is only stored in the database. So
if you want to check the field for a document, you need to look at the relevant table content in SE16.
Documents can only be updated into SD-IS info structures, if an update is group available for the document
header and/or item.
For the example document 11764, SE16 shows the following:

As you can see, both in VBAK and VBAP the field STAFO is empty for this document. This is the reason,
why the document was originally not updated into the info structure and why also MCVR shows no updating
of this document for S915.

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Therefore the next step would be to check why there was no update group assigned to the document.
Please have a look at SAP note 406294, which describes in detail how update groups are assigned and
where the customizing for correct assignment needs to be done.
You could also use the analysis functionality in MCVR, MCVT and MCVV to find out more about STAFO
assignment.
However, please be aware that this functionality shows a simulation of STAFO assignment with the current
customizing settings. So it is possible, that this functionality shows a STAFO assignment happening,
although in the actual document there is actually no STAFO assignment.
Coming back to the example document 11764, MCVR initially shows the following:

Then after pressing button Analysis:

And finally after double clicking on line Update group for document header:

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Here it is shown that the sold-to party has no statistics group assigned. So this is the reason for the missing
update group assignment. Thus it is necessary to maintain a statistics group in the customer master to be
able to update this document into the info structure.
After assigning the statistics group for the sold-to party correctly, the analysis shows the following:

That is, for new documents within this sales area, with this document type and this sold-to party, the system
will now be able to find an update group. However, this does not mean that now automatically also the old
document 11764 will be updated into the info structure.
To update the STAFO field for existing documents a statistical setup is necessary as it is described in SAP
note 64636. It is very important that the flags Redetermine update group and Update documents are set
when doing the setup. Only with those flags being set, the STAFO values in VBAK and/or VBAP will be
updated as per the new customizing during the setup.
Checking updating rules
You can check the updating rules existing for an info structure in transaction MC26. The updating rules are
dependent on the update group, so you need to know the updating group assigned to the document (items).
You can see the updating group for example in MCVR

or also directly on the database (see section Checking update group assignment for more information on
this).
In MC26 you can check the updating rules assigned to each key figure.

10

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

For the example info structure S915 and update group 1, this looks as follows:

By setting the cursor on a specific key figure and pressing one of the buttons Rules for Key Fig or Rules
for Charact you can check the details of the updating rules for each key figure.
For example, if you find a document is being updated into an info structure using unexpected characteristics,
you would need to check the update rules for the characteristics to find out how the characteristics are
supposed to be determined. If in contrary a key figure has an unexpected value, you would need to check
the updating rules for this specific key figure.
Characteristics can be updated using source fields or using formulas.
Key figures can be updated using source fields, formulas or routines. Furthermore requirements can be used
to control the updating.
For example in the example info structure S915 the key figure Incoming orders is updated as follows:

11

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Characteristics:

Key figures:

If only a source table and source field is maintained, this means that simply the value from the source field is
taken over into the info structure. So usually you can easily check, whether the value in the info structure is
correct, by just comparing the info structure value with the value in the corresponding document table.
In the example key figure Incoming orders is updated from source field MCVBAP-NETWR. This means that
to check whether the info structure value is correct it is necessary to compare the value of VBAP-NETWR
with the info structure value or respectively with the value shown in the update simulation. In particular as the
info structures often contain cumulated values, it might be more helpful to compare the value shown in the
update simulation for a document with the value in the document table.
For example, in info structure S915 the item number is not a characteristic. So the values shown in S915 for
Incoming orders for a document will be cumulated over all items of a document. While in MCVR, the
updated values will be shown per item and thus it will be easier to check whether the updated values fit the
respective item values.

12

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Here is a new example document 11779:

For this document S915 contains the following data:

While MCVR shows the following:

So comparing with VBAP

13

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

it can be seen that the actual values that will be updated into S915 with a new setup do exactly fit the VBAP
values. Furthermore the cumulated value currently shown in S915 also fits the sum of the values for both
items. So in this case the values updated into the info structure exactly fit the defined updating rules.
If still another value should be expected in the info structure, the updating rules would need to be adjusted.
Another issue mentioned earlier was the following:

Here the update simulation shows that no value was updated due to a requirement. You can check the
requirements by double clicking on the requirement number in MC26 and on the next screen double clicking
on the requirement number again. This will open up the ABAP editor, showing the coding of the requirement.
In this example requirement 900 has the following coding:

Within requirements RETURNCODE = 0 means that the key figure will be updated, while RETURNCODE =
4 means that the key figure will not be updated.
Now the example requirement 900 sets RETURNCODE to 4, if the field MCVBAP-ABGRU is empty.
Therefore it is necessary to check the corresponding value in table VBAP to find out how the system is going
to work in this case.
VBAP for example order 11765 looks as follows:

14

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

So field VBAP-ABGRU is empty, which means the requirement 900 will return with RETURNCODE 4 and
thus no Incoming orders value will be updated into S915 for this item, because the requirement is not
fulfilled.
The other earlier example was

So here a formula 999 is used for the updating and this causes the actual key figure value to be 0.
You can look at formulas the same way as requirements, that is, by just double clicking on the formula
number in MC26 and in the screen following double clicking on the requirement number again. Then the
ABAP editor opens.
In the example formula 999 has the following coding:

The result of a formula is stored in variable FORMULA_VALUE.

Now in this example, the formula always sets FORMULA_VALUE to 0, so every key figure where this
formula is used will always have value 0, which means that actually no updating occurs. This is the
explanation for what could seen in MCVR earlier.

15

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

Of course in reality coding in formulas could be much more complicated. So in most cases it will be
necessary to check some table values to compare the actual formula result with the result shown in the info
structure / in the update simulation and with the expected result.
Lastly, earlier the case was mentioned that the update simulation shows some value, but this is not the value
you would expect to be updated into the info structure. In such a case, too, you first of all need to check
whether the key figure (or characteristic) is updated from a source field only, or whether a formula is used.
If only a source field is used, you again can in most cases simply compare the corresponding database table
value with the data shown in the update simulation. For example, if a source field from MCVBAK is used, you
can check the corresponding value in table VBAK. The same is valid for example for MCLIKP, MCLIPS,
MCVBRK, MCVBRP, etc. where you can check corresponding fields in LIKP, LIPS, VBRK, VBRP, etc.
However, please be aware that there are fields existing in the MC.-structures, where no corresponding
field is available in the document table. For example the key figure Open orders quantity in the example
info structure S915 is updated for a sales order from field MCVBAP-OAUME. But table VBAP does not
contain a field OAUME. This means that the value of this field is only calculated and available while the
document is actually being processed, but the value is not stored in the document table.
So in this case the actual updating routine would need to be checked / debugged to find out more about the
issue. For this you first of all need to find out the corresponding program, in which the updating routines for
the info structure are stored. For Standard info structures Sxxx, the updating program is RMCSSxxx. For
customer owned info structures, you can get the updating program for example from table TMC2Q. Enter
info structure and update group as selection criteria MCINF and STAFO, then you will find the corresponding
updating program in result field FPROG.
To find the coding responsible for a specific key figure, search for the technical name of the key figure within
the updating program. (You can get the technical name of key figures, or also characteristics, by double
clicking on the key figure, or characteristic, in MC23.)
For example, if you want to check how the info structure field with technical name OAUME is updated, in
Standard updating programs search for comments like

Or in customer owned updating programs search for comments like

Then you can set breakpoints after those comments. By this you should be able to debug the filling of the
key figure value into the info structure. Additionally, please be aware that depending on the updating rules
definition, there might be more than one such comment within the updating program, as you can define
several updating rules for one key figure.
For example in the updating rules for S915, the key figures Open orders and Open orders quantity are
updated both at event VA and VC:

16

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

In such a case, you will find two places in the updating program where field S915-OAUWE or S915-OAUME
is updated. However, as you can see above, the comment normally contains the event, so you can see
which updating routine in the coding belongs to which updating rule in MC26.
Finally, in this context there is one other example/issue to be aware of.
In this example the assumption is that MCVR shows the following result:

This means, a statistical setup will update the key figure Incoming orders twice for one sales order item.
Now there could be a good reason for this, namely two updating rules being defined for the key figure for
event VA.
For example the following updating rules would cause such an MCVR result:

17

HOW TO ANALYZE INCORRECT DATA IN THE SALES INFORMATION SYSTEM

If, however, the updating rules look as follows

and you still see two rows for Incoming orders for one item in MCVR, this indicates that there could be an
inconsistency in the control tables for the updating. In this case you need to check the control tables for
inconsistencies as described in SAP note 1002904.
Further things worth checking
If you want to analyze updating during online processing (i.e. transactions VA01, VA02, VL01N etc.) and
you dont want to directly debug the updating rules as described in section Checking updating rules (as
in online processing this mostly needs to be done via update debugging), it could be helpful to use the
updating protocol via transaction MC30. In this protocol it can be seen after each document saving which
data was updated into the info structures. Please see SAP note 77427 on how to activate and work with
the updating protocol. The results shown in the protocol can then be analyzed as described in the earlier
sections of this document.
If the wrong updating only happens during online processing, but not in the updating simulation or in the
statistical setup, the issue could be caused by incorrect user exit coding. In particular modifications of the
UPDKZ field in the internal X-/Y-tables can cause severe issues regarding info structure updating. Thus,
in such cases please check your user exits thoroughly as described in SAP note 216448.

18

www.sap.com

2011 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,
SAP BusinessObjects Explorer, StreamWork, and other SAP products
and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and
other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase, Inc. Sybase is an SAP company.
All other product and service names mentioned are the trademarks
of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies (SAP Group)
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.