Best practice to use source time field for 0CAL...

| SCN Page 1 of 7

Getting Started Newsletters Store

Hi, Guest Log On Join Us Search the Community

Products Services & Support About SCN Downloads

Activity Communications Actions
Industries Training & Education Partnership Developer Center

Lines of Business University Alliances Events & Webinars Innovation Browse

10 Replies Latest reply: Oct 16, 2013 1:53 PM by Martin Grob

Share 0 Tweet Like 0

Michael Rau Oct 2, 2013 12:41 PM

Best practice to use source time field for

0CALDAY in SD Cube 0SD_C03 (0CREATEDON
vs. 0ST_UP_DTE)
This question has been Answered.

Hi experts,

we are using BW Standard SD Cube 0SD_C03 (Sales: Overview).

Are there any best practice proposals to use the Update Date Statistics (0ST_UP_DTE) as source for
0CALDAY?

ECC BW
MCVAP-ERDAT 0CREATEDON
MCVAP-VDATU 0ST_UP_DTE

Example:

Sales order item was created on 15.01.2013 with a net value of 1,000.00 $. So we expect an Incoming
Order value of 1,000.00 $ in periode 01.2013. One month later, e.g. on 25.02.2013 the sales order item
was changed and the net value of the sales order item is 750.00 $.

Now we expect an incoming order value in periode 01.2013 of 1,000.00 $ and in the periode 02.2013
of -250.00 $. So in total (periode 01 + 02) that we have an Incoming Order value of 750,00 $ for this
sales document item.

Everything works fine.

But the curiosity is, if we change only a time-irrelevant information (e.g. invoice date, payment
conditions, etc. not quantity or price) in the sales document item, the Update Date Statistics is affected.

We want to use the Update Date Statistics (0ST_UP_DTE) as source for 0CALDAY, but only for
specific changes (e.g. quantity, price, etc.) in the sales order item.

Should we implement any conclusion criteria in the transformation routine or what kind of prerequisites
we have to check?

Many thanks in advance!

best regards,
Michael

Correct Answer
by Michael Rau on Oct 16, 2013 1:15 PM

Hi all,

we have solved our Issue!!!

The problem in our specific case was, that we have a incorrect key combination in the line item
DSO.

We have use 0DOC_NUMBER (Doc. Number) and 0S_ORD_ITEM (Doc. Item Number) -> As the
result of this DSO key combination we always got one single data record (see screen in above
comments) from the DataSource 2LIS_11_VAITM.

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 2 of 7

But, to use the Update Date Statistics in a complete and correct way it´s absolutely necessary to
become all the changed data records from the DataSource.

Finally and to solve the issue, we have changed the key fields in the DSO! Now we use
0DOC_NUMBER (Doc. Number), 0S_ORD_ITEM (Doc. Item Number) and 0ST_UP_DTE (Update
Date Statistics).

Now our BEx Query result looks like pretty good and we can report the periodic specific Incoming
Order value with the correction bookings (positive ord negative) each day.

In summary we can say it was only a DSO topic -> In DataFlows (3.x) without the use of DSOs (only
DataSource -> InfoCube) it´s not a problem.

Thanks a lot for your responses!

Regards,
Michael

Helpful Answers by Martin Grob, Rajat Chowdhry

939 Views Tags: 0calday, 0st_up_dte, update_date_statistics

Average User Rating

(0 ratings)

Michael Rau Oct 7, 2013 9:55 AM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03 (0CREATEDON vs.
0ST_UP_DTE)

Any ideas or proposals?

Thanks and regards,

Michael

Like (0)

Michael Rau Oct 9, 2013 3:33 PM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03 (0CREATEDON vs.
0ST_UP_DTE)

Please find attached the help.sap.com source with the topic "Specific Definition Using Update Rules"

and the note of the two possible situations (A = MCVBAP-ERDAT vs. B = MCVBAP-VDATU)

Source:
http://help.sap.com/saphelp_45b/helpdata/en/f9/6bec6eb435d1118b3f0060b03ca329/content.htm

As stated above we want to use MCVBAP-VDATU (situation B).

But how we should setup the settings, that the VDATU updates only for specific changes in the sales
order item (e.g. change of the quantity and price).

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 3 of 7

Thanks in advance!
Regards,
Michael

Like (0)

Martin Grob Oct 9, 2013 5:44 PM (in response to Michael Rau)

Helpful Answer Re: Best practice to use source time field for 0CALDAY in SD Cube
0SD_C03 (0CREATEDON vs. 0ST_UP_DTE)

Hi Michael

We use 0ST_UP_DTE as update for 0calday but for all characteristics. If you plan on using this
both ways with 0created on and 0ST_UP_DTE you either have to create rule groups (assuming
you migrated to a transformation) or if it's still a 3.x dataflow as ours you need to tell the system
that this derive from 0ST_UP_DTE or 0createdon only applies to certain keyfigures.
You can only do it specific for keyfigures not chars.
hope that helps
Martin

Like (0)

Rajat Chowdhry Oct 10, 2013 8:27 AM (in response to Michael Rau)

Helpful Answer Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi Michael,

As per the attached SAP helpnote and Martin's comment above, you might well have understood that
the field MCVBAP-VDATU will not store the date of changes on a specific characteristic which in
your case is the keyfigure of your choice, the field is a statistical date and is set to current date with
any changes to the document and hence if you make any changes in the document for e.g. an invoice
date or any other time irrelevant characteristic, this field will get affected. As for your case if you use
are using a DSO as the target of the datasource transformation your change gets logged into the
Active Log of DSO automatically. If you still want to show the changes of your data date wise I advise
you to use the Order No key of the target structure, this way whenever any change occurs on a
particular order no It's final value is reflected in the DSO irrespective of the period

Let's say you've certain Order No: 123456 created on 01.01.2013 with order quantity 1000 if you
change the same order on 01.02.2013 with changes to order quantity 750. Thus when you report the
data on this DSO the final value of the field will always show 750 for the complete period from 01.2013
to 02.2013. As the changed value of 250 is stored in a seperate row of "-250" against the same order
no in the active log of DSO.

Like (0)

Michael Rau Oct 11, 2013 3:04 PM (in response to Rajat Chowdhry)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi Martin, hi Rajat,

thanks for your reply.

I have created a test sales document order two days ago on 09.10.2013.

Details to the test sd doc. item 10

- creation date on 09.10.2013, quantity 10 pieces, net value 10.400 EUR

- change date on 10.10.2013, quantity 9, net value 9.360 EUR
- change date on 11.10.2013, quantity 10, net value 10.400 EUR.

Now, I expect the following net values each calendar date:

Doc. number Position 09.10.2013 10.10.2013 11.10.2013

33155 10 10.400 EUR - 1.040 EUR 1.040 EUR

 

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 4 of 7

But, the reality is as following:

PSA-Table of DataSource 2LIS_11_VAITM

DSO Sales Doc. Item data (target of InfoSource 2LIS_11_VAITM / DataSource

2LIS_11_VAITM)

InfoCube Sales Overview (0SD_C03)

BEx Query Result

Here I expect an periodic specific net value with the use of the update date of statistic (MCVBAP-
VDATU)

I use the DataSource field VDATU as source for InfoObject 0ST_UP_DTE (in InfoSource and
DSO) and finally 0ST_UP_DTE as source for 0CALDAY in the Cube.

By the way, the aggregation mode of all key figures is "Summation" in the key figure
Transformations between InfoSource and DSO:

Any ideas?

Many thanks and regards,

Michael

Like (0)

Michael Rau Oct 13, 2013 2:26 PM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi

any ideas or suggestions?

The BEx Query result above shows or seems like that any changes (e.g. invoice date = not
value relevant changes, ) of the sales doc. item affects that the incoming order value (net
value) writes in the relevant date of change

Thanks in advance and regards,

Michael

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 5 of 7

Like (0)

Michael Rau Oct 14, 2013 10:00 AM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi experts,

today we have changed our Test sales doc. item by edit a header data information (field in
tab Additonal data A).

After the change we loaded the data again into BW.

Even though we have only changed a header information, the net value is generated in the
14.10.2013. On that day, we have not change the net value in ECC.

Any ideas!

Thanks and regards,

Michael

Like (0)

Rajat Chowdhry Oct 14, 2013 10:30 AM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi Michael,

It seems you basically want to track the changes in your Sales Document, Please note
that whenever one changes a particular document in ECC system, those changes are not
recorded in the same table as that in which the final values of the document is stored,
thus if you change the quantity of the sales order from 10 to 9 and then again make some
other changes, the transaction will only store your final value in the back end in its table
and not the previous value, also thus when you extract the same into your BW system,
the changes are not captured. Thus when you extract and transform your data the
change cannot be calculated at run time for each sales document as that would increase
the load on the system. Thus SAP gives you two different tables namely CDPOS and
CDHDR which sill store the changes in your document, for eg. If you change the quantity
in your sales order from 10 to 9 the table CDPOS will store the two values new and old
in two different columns and thus if yiu need o compare them, you can thus extract the
data from there and perform your calculation of the change in the transformation (or
transfer rules), when extracting the data from these tables, you can create a generic
datasource for the same and thus extract the same, All the changes in a sales document
get stored under the OBJECTCLASS of VERKBELEG in the same table, please refer
the following document in order to extract data from these tables, which might better
guide you to extract data from these tables.

LINK: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/50dd3fb9-0dad-
2d10-0ea7-cbb0bb8b391b?QuickLink=index&overridelayout=true

Like (0)

Michael Rau Oct 14, 2013 11:20 AM (in response to Rajat Chowdhry)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi Rajat,

thanks for your reply!

We expect the following net value (incoming order value) day by day:

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 6 of 7

Doc Item 09.10. 10.10. 11.10. 14.10.

33155 10 10.400 EUR -1.040 EUR 1.040 EUR 0 10.400 EUR

DSO Data Output (Doc. Item Data, Target of PSA 2LIS_11_VAITM)

Only one Data record with the update date Statistics 14.10.2013!

PSA Data Output (DataSource 2LIS_11_VAITM)

Thanks and regards,

Michael
 

Like (0)

Michael Rau Oct 16, 2013 1:15 PM (in response to Michael Rau)

Correct Answer Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

Hi all,

we have solved our Issue!!!

The problem in our specific case was, that we have a incorrect key combination in the line item DSO.

We have use 0DOC_NUMBER (Doc. Number) and 0S_ORD_ITEM (Doc. Item Number) -> As the
result of this DSO key combination we always got one single data record (see screen in above
comments) from the DataSource 2LIS_11_VAITM.

But, to use the Update Date Statistics in a complete and correct way it´s absolutely necessary to
become all the changed data records from the DataSource.

Finally and to solve the issue, we have changed the key fields in the DSO! Now we use
0DOC_NUMBER (Doc. Number), 0S_ORD_ITEM (Doc. Item Number) and 0ST_UP_DTE (Update
Date Statistics).

Now our BEx Query result looks like pretty good and we can report the periodic specific Incoming
Order value with the correction bookings (positive ord negative) each day.

http://scn.sap.com/thread/3432246 8/21/2016
Best practice to use source time field for 0CAL... | SCN Page 7 of 7

In summary we can say it was only a DSO topic -> In DataFlows (3.x) without the use of DSOs (only
DataSource -> InfoCube) it´s not a problem.

Thanks a lot for your responses!

Regards,
Michael

Like (3)

Martin Grob Oct 16, 2013 1:53 PM (in response to Michael Rau)

Re: Best practice to use source time field for 0CALDAY in SD Cube 0SD_C03
(0CREATEDON vs. 0ST_UP_DTE)

that's a tricky one to find through SCN

glad you found the issue
Martin

Like (0)

Share 0 Tweet Like 0

Site Index Contact Us SAP Help Portal

Follow SCN
Privacy Terms of Use Legal Disclosure Copyright

http://scn.sap.com/thread/3432246 8/21/2016