Consolidating DSOs

Hi Guys,
I need to merge two DSOs A&B in to third DSO C. I have same key fields in each of this DSO.When I create two transformations , Iam unable to see the consolidated data. In change log of DSO C , its showing both DSOs A & B Data one after other. Like if my DSO A has 200 records and B has 300 records C is showing 500 records. If the DSO A and DSO B has the same company code , Doc Nr and Fiscal Year it should match in C and should display it as one single record ...What to do for this in BI. I worked this same kind in BI 3.5 with update rules overwrite option. But here in 7.0 what to do can any one advice?
Thanks a lot in advance

Well, actually you created a outline view.
Open a new blank document, click View->Outline->Show Document->Insert, insert a document including pictures, and then click
unlink, Close Outline View->save this document. Reopen it, pictures are still here. Did I miss something?
If you mean you can't see pictures in outline view, you can refer to the thread below :
http://answers.microsoft.com/en-us/office/forum/office_2010-word/bug-in-outline-view-it-is-not-possible-to-see-the/4ee6246e-1dad-45de-b976-0ffb92bc0a54?page=2
Wind Zhang
TechNet Community Support

Similar Messages

Reporting on DSO for Broker's Statement (Line Item Reporting)?

Dear experts,
I need to create a BW report based on data from FS-CD and ICM for a client in the insurance industry. The report is broker's statement which has in total 3 sections/pages (or in 3 levels). The requirements are as follows:
1. Overview of the total commissions (grouped by different categories) earned by a broker for a specific month
2. When the broker clicks on the "commission group", it will jump to another page showing each commission items of that group
3. Details for each commission item (line item in DSO) can be drill-downed in another separate page
Currently, I have a consolidated DSO for the commission line items. The data will be loaded to an InfoCube followed by a MultiProvider for reporting.
I am new to BI and I assume that I should follow the following approach:
1. Use RRI for the jumps between different details levels
2. Use DSO for reporting the line item on third page
3. Use Report Designer for the layout because the reports are formatted like Balance Sheet
Is it possible that I report on the InfoCube via MultiProvider for the 1st and 2nd levels whereas DSO for the 3rd level?
Could anyone please give me some suggestions on this?
Thanks in advance.
Regards,
Joon

Hi,
any updates? I read that the RRI capability of the query is not supported in BEx report. Is it true?
If so, is there any workaround to enable this?
Regards,
Joon

Header and Item consolidation delta

Hi all,
If I do a lookup on header DSO while loading into a consolidated DSO from a item level DSO, how do we make sure that deltas are managed if only changes occur in the header DSO?
In this case since the driver is the item level DSO, I would imagine that the delta won't be picked up. Any thoughts?
Thanks.

Yes, you still have to do a lookup to the header DSO (in the flow DSO item -> DSO consolidated). You already have this one.
In the flow DSO header -> DSO consolidated, you have to split the header into the different items existing for this header (kind of "look up" to the item DSO).
Regards,
Fred
[edit] : this is why sometimes we put the header data in a master data (no more delta problem of this kind).
Edited by: FCI on May 7, 2010 6:06 PM

Linking Sales Order Header and Item into a DSO

I am trying to combine my Sales Order Header and Item into a DSO.
I created individual DSOs for each extractor and loaded successfully. I then created a new DSO with the Document number as the key field and loaded the data. However, when I check the new DSO, the data is not combined but seperated on one line.
To make it clearer
DSO1
CH1 CH2 CH3 KF1
DSO2
CH1 CH4 CH5 KF2
In my new DSO3, I used CH1 as the key field and when I load data, I expect to see
CH1 CH2 CH3 CH4 CH5 KF1 KF2
But I get
CH1 CH2 CH3 KF1
CH1 CH4 CH5 KF2
Is there something I'm doing wrong?

Hi Siggi
I'm not sure what you mean.
What I am trying to achieve on the long run is to combine Sales Order and Billing into a cube. But first i need to get the orders into a DSO and also Billing into another DSO. And then combine into a consolidated DSO before going to a cube. Please correct if this approach is wrong.
In the meantime, I am trying to combine the sales order item and header into one DSO.

Replacing DSO with InfoObject for storing time-dependent master data

Hi Gurus,
currently I am storing time-dependent contract items in a DSO. The posting items are enriched with this master data as well as some other transaction data into another consolidated DSO, which includes the time-dependency (valid from & valid to) as well for better performance. But this means that we will have a large number of records, because 1 new posting item could end up with few posting items more due to the versions of contract item.
Since there are many posting items (>50 millions yearly, daily peak 1-2 million) and the complexity with delta management, I am considering whether to use an InfoObject for storing the contract items. The number of contract items are not many, about 300,000 after migration and about 10,000 each month.
Hence, I would like to ask whether this approach is feasible? Is there a size limit for a master data InfoObject?
Thanks in advance.
Regards,
Meng

hi,
The Time dependent MD object will create the same number of records for the contract item (maybe more) as each contract item will have different record for different time frame.
this can be better explained with example.
let us say you have 1 contract item with 2 entries one valid from 2007-2008 and the other from 2008 onwards.
In DSO this will create 2 records, in time dependent MD object it would also create 2 records.
In the infopackage for the MD you would need to provide the interval (time range) for the MD.
if you provide it as 2007 till 2999 then two records will be created one with 2007-08 and other valid from 2008-999.
However as there would be other contract items which would have lower date say 2006 then this contract item would create 3 rows, 1 row for 2006-07 with blank values, 2nd for 2007-08 and 3rd for 2008-999. This way it has more number of records than the DSO.
In case of MD object you may not be able to delete data as well in future if the object is used in some other place.
There will be many pros and cons of the approach you are thinking and you would have to weigh them and decide.
regards,
Arvind.

Getting Double values in Purchasing cube

hi experts,
I m getting double values for 0po_items and ocontr_item in purchasing data cube 0pur_c01.
i have also applied the test rule in routine ,that values are fine.
but in cube values are getting double.
please help..........

Hi,
It seems like you are loading data into cube using 2 DataSource and there is no (consolidated) dso in between.
If the KF say (qty) you are mapping from both the datasource to the cube, it is going to be doubled in report as 2 records will be found in cube.
I suggest try to load a single valid record (PO and lien item) one by one into the cube and do check the values in cube for each process. You will get good idea how cube behave while loading data from diff. sources.
Also try to bring in the one dso where you consolidate the data as per report requirement and then move that data into Cube, will give you required output.
Thank-You.
Vinod

Fact Table and Dimension Tables

Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
Please help me with this on how I should address this.

hi,
The exact data will be hard to give however you can reach at a round figure in your case.
You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
For example, let us say we want to combine data for sales order and deliveries in a DSO.
Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
regards,
Arvind.

Problem with subsequent deltas after converting Full requests to Repair.

Hi All,
We are working on changing an existing system from loading from multiple extractors directly to a cube to loading each extractor to its own DSO and then combining the data in a 'consolidated' DSO and then on the the cube.
To avoid downtime in the production system when we do the cut-over we have decided to do full loads of historical data up to Sept 2007 and then do delta loading from then on.
So the steps so far have been:
1) Full load of data to low-level DSO's. to 09 2007.
2) Full load of data to 'consolidated' DSO.
3) Convert Full requests in consolidated DSO to Repair Full Requests (see SAP Note 689964).
4) Initialise Without Data Transfer to the 'consolidated' DSO.
5) Delta Initialise from 10 2007 from the source system to the low-level DSO's.
6) Delta from low-level DSO to consolidated DSO.
My problem is with step 6 - no records are loaded into the consolidated DSO after delta load of data to the low-level DSO - the load process runs correctly but tells me that there was no data available.
Can anybody see if there is a problem with my approach - I thought this was the correct way to convert from full loading to delta loading ?
A Merry Christmas and a Happy New Year to you all
Graham

Hi Siva,
Thanks for the reply.
I understand that there is only an active table with a write-optimised DSO - but delta processing should still be possible at the request level
(SAP Help on Write-Optimized DataStore Objects http://help.sap.com/saphelp_nw2004s/helpdata/en/b6/de1c42128a5733e10000000a155106/frameset.htm)
Since write-optimized DataStore objects do not have a change log, the system does not create delta (in the sense of a before image and an after image). When you update data into the connected InfoProviders, the system only updates the requests that have not yet been posted.
In my case the 'new' request loaded into the DSO have not been loaded into the connected InfoProvider, so it should be processed.
Regards
Graham

Maximum Number of Objects in Local History does not work

In our Production system, I have configured the Maximum Number of Objects in Local History to be '10'. I do not see any queries in the dropdown. I have executed and changed queries since I made this change. None of the users can see a history log.
In our Dev system, the Maximum Number of Objects in Local History is working as expected.
Is there a system-wide setting that overrides my personal setting?
Thanks.

you could have a consolidated DSO with the keys alone and see if you can have an alternate design using an infoset instead....

Details from fact table as dimension - solution review needed

Hi experts,
I found a convinient way to display details from fact table, as a dimension and need your opinion. Do you see any potential issues about this solution?
Context
- I use vertical federation in OBIEE 11.1.1.6
- all aggregated measures are in OLAP
- there is a need that user drill down to lowest level details (single fact row) -> this information is in relational database
- we decided to use dedicated presentation hierarchy column and let users drill to lowest level detail (just 2 hierarchy levels "All" -> "Detail")
- always add this column at the right side of report table and after all other dimension drills are in place (other table columns are also presentation hierarchy), user can drill to contract ID (the detail)
Solution (I tested it and it seems to works ok)
- create "dummy" relational table with just 1 row ("All" level in hierarchy), linked to fact table (to "dummy" ID column in fact table)
- create "dummy" dimension in Analytic Workspace
- in BMM create logical table with 2 data sources: OLAP for hierarchy level "All" (linked to dummy OLAP dimension) and relational for hierarchy level "Detail" (using relational fact table)
- so in BMM we have additional logical dimension with 2 levels - one "All" that read from OLAP, and does not impact performance, and second "Details" that is the only information at all that is obtained from relational database when user expand "All"
- Why created "dummy" dimension? -> because OBIEE won't let me create logical dimension from fact table columns, but can create a dummy dimension with just "All" level and add to it column from fact table
Any comments are welcome.

hi,
The exact data will be hard to give however you can reach at a round figure in your case.
You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
For example, let us say we want to combine data for sales order and deliveries in a DSO.
Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
regards,
Arvind.

Merging item and condition records

Hi All,
I have a requirement to merge item and conditon data . I am using 2LIS_11_VAITM & 2LIS_11_VAKON .
The key for booking DSO are document number, item number AND calendar day. I am concerned that we cannot easily link up the records from one DSO to the other, since they are date and even activity dependent. For example, if more than one change is made to the value of the item in one day, then the condition values will also be different for each change.
Please suggest on how to go ahead .
Thanks

The best thing is to load these datasources to 2 DSOs and then to a Cube.
One option could be having a consolidation DSO on top of these two, having multiple rule groups to convert the data model from Account based to Key figure based for Conditions data. You will have multiple condition records for a Sales order item. Order, item & condition type should ideally be the key for the DSO). When loading Conditions to the Consolidation DSO (this would have Order, item as key) you would have multiple transformation rule groups so that key figure from each condition record is updated to one key figure in the DSO. There could be may condition records and there could be new additions in ECC, then you would have to change the objects again. This, I guess is not a good model.
Enhancing VAITM is not a good option as there would be many condition records for an order item.
Edited by: Murali Krishna K on Jul 28, 2011 12:01 PM

Selective data load to InfoCube

Dear All,
I am facing the following problem :
I have created staging DSOs for billing item (D1) and Order item (D2). Also i have created one InfoCube (C1) which requires combined data of order and billing and so we have direct transformation with billing DSO (D1-->C1) and in transformation routines we had look up from Order item (D2) DSO.
Now all the deltas are running fine. But in today's delta particular Order has not retrieved, say 123, but corresponding Billing document, say 456, has been retrieved through delta.
So now while DTP ran for C1 cube it has not loaded that particular billing doc (456) and corresponding Order details(123).
I thought of loading this particular data by creating new Full DTP to Cube C1. Is this approach ok?
Please help on the same.
Regards,
SS

Hi,
Yes you can do a full load. Just make sure the selection condition in your DTP is EXACTLY THE SAME as selective delete on C1.
I'd suggest put a consolidation DSO D3 in the position of C1. And you can always use delta update C1 from D3. In my company there are similar cases and we love the consolidation DSO.
Regards,
Frank

Do we need generate export datasource in BI

Hi
We are loading 3 standard datasources to PSA and PSA to 3 DSOs and 3DSOs to one consolidated DSO and we have not generated export datasources we are able to load the data, my question is when we use generate export data source.
Thanks
Kore

Hi
As per the business requirement for a multiple BI connections we need DATAMART technology and for standalone BI we donu2019t need Datamart technology (generate export datasource)
check these thread .
What is GENERATE EXPORT DATASOURCE
https://forums.sdn.sap.com/click.jspa?searchID=10732071&messageID=4737568
Generate Export datasource BI 7
Regards
Padmanabha

Sales data flow

Hello Experts,
This is my first post in this forum. Kindly help.
In my sales data flow, I have header and item data for deliveries, orders and billing. What should be my best data flow if I am trying to build a EDW?
a. Orders, Deliveries and Billing, say each have two DSO's, one for header and one for item. That means for the three areas, 6 DSOs. Consider Orders only now. Should I load the order header and order item into two seperate cubes and then join them by a multiprovider to get a multiprovider for Sales Order. And create similar cubes for deliveries and billing. And if I wanted to consolidate all three areas, then could I have a multiprovider with 6 cubes (2 each for order, delivery and billing - header and item) ?
b. Or should I have a Consoliadtion DSO on top of Orders header and item so that I have a DSO with order information with header information stamped on each of the item records? and have similar consolidation DSO's for deliveries and billing? (that means extra data loads) and then load an order cube with data from the consolidation order DSO? and similarly two more cubes for biiling and dels? and then have a MP on top of these three cubes?
c. Or should I have just one cube with all order, delivery and billing information, loaded from three different consolidation DSOs?
For all of the above, how does delta changes impact the cube load? where should I use write optimzed DSOs?
Sorry for a long question, but I want to seletc the best design and would like your help
I will give points
Yanz Zemik

SD
The sales documents you create are individual documents but they can also form part of a chain of inter-related documents. For example, you may record a customers telephone inquiry in the system. The customer next requests a quotation, which you then create by referring to the inquiry. The customer later places an order on the basis of the quotation and you create a sales order with reference to the quotation. You ship the goods and bill the customer. After delivery of the goods, the customer claims credit for some damaged goods and you create a free-of-charge delivery with reference to the sales order. The entire chain of documents the inquiry, the quotation, the sales order, the delivery, the invoice, and the subsequent delivery free of charge creates a document flow or history. The flow of data from one document into another reduces manual activity and makes problem resolution easier. Inquiry and quotation management in the Sales Information System help you to plan and control your sales.
In Simple steps
The flow is something like this:
1. A sales order is created in R/3 by 'va01'.
2. A check on credit limit is carried out by the system (if configured)
3. In case credit limit is exceeded by creation of this order then the same needs to be subjected to approval.
4. On approval, order picking and delivery document is created wrt to the order document - this is equivalent to selecting ordered material from warehouse and stocking in the loading bay of the warehouse - inventory of inished goods reduces at this point of time.
5. Subsequently a billing document is created - this step realises the fact that revenue is generated.
6. There is a concept of open orders - basically anything in the order document that is partially serviced ( due to non-availability of stocks ) -
the delivery and billing
Transaction Codes:
Inquiry - VA11/VA12/VA13
Quotation - VA21/VA22/VA23
Sales Order - VA01/VA02/VA03
Delivery - VL01N/VL02N/VL03N
Billing/Invoicing - VF01/VF02/VF03
Also please check this links.
http://www.sapgenie.com/sapfunc/sd.htm
http://www.sap-basis-abap.com/sapsd.htm
http://www.sapgenie.com/abap/tables_sd.htm
Check this link:
Basic Functions and Master Data in SD Processing
http://help.sap.com/saphelp_47x200/helpdata/en/90/758534c960a134e10000009b38f83b/frameset.htm
SD Tables
http://www.sapgenie.com/abap/tables_sd.htm
Please check this SD online PDFdocuments.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CAARCSD/CAARCSD.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/MYSAP/SR_SD.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCBMTWFMSD/BCBMTWFMSD.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/LOLISPLN/LOLISPLN.pdf
Also please check this SD links as well.
http://help.sap.com/saphelp_47x200/helpdata/en/92/df293581dc1f79e10000009b38f889/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/dd/55f33e545a11d1a7020000e829fd11/frameset.htm
http://www.sap-basis-abap.com/sapsd.htm
http://www.sap-img.com/sap-sd.htm
http://www.sapgenie.com/abap/tables_sd.htm
http://searchsap.techtarget.com/featuredTopic/0,290042,sid21_gci961718,00.html
http://www.sapbrain.com/TUTORIALS/FUNCTIONAL/SD_tutorial.html
All help ebooks are in PDF format here
http://www.easymarketplace.de/online-pdfs.php
Hope it helps

Data Fields & Key Fields IN DSO

Hi Guys,
Can any one tel me what exactly key field holds & Data field hold in DSO.
Thanks,
Venkatesh

Hi,
A DSO serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level. This data can be evaluated using a BEx query.
A DSO contains
Key fields (such as document number, document item) and data fields that, in addition to key figures, can also contain character fields (such as order status, customer). The data from a DataStore object can be updated with a delta update into InfoCubes (standard) and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.
Key fields : It will contains both Chars and KeyFigures.
Data Fields : Based on this i.e. the charecterisctics which you will keep in this Data Fields, the DSO will over write the Data in DSO.
Overwriting functionality will works based on Data Fileds.
http://help.sap.com/saphelp_nw2004s/helpdata/en/f9/45503c242b4a67e10000000a114084/content.htm
Thanks
Reddy

Consolidating DSOs

Similar Messages

Maybe you are looking for