How to eliminate # and not assigned from report level

[sri_pamarthi]

hi team,

i have a data flow like this

DS1(data source)->DSO1-> cube1

DS2(data source)->DSO2-> cube1

ds1 structure is:

sdocno.  Netwr.  erdat.             Cuky

1567.       250.00 15.12.2015.   Inr

ds2 structure

matno.    Qty.      unit

m3145.   25.      Kg

after loading to infocube...

in the report level I'm getting data Like this

Sdocno.            Netwr.  erdat.                   Cuky.                   Matno.        Qty.    unit.

1567.                 250.00 15.12.2015.           inr                    Notassigned.  #.     Not assigned

Notassigned.     #.        Notassigned.         Notassigned.   M3145.          25.     Kg.

actually  requirements is to be displayed both in one record...

Please help me on this issue...

THanks & Regards

P Sriram.

[Former Member]

I agree with Song Wang, You have to have some common characteristic in both the DSO to combine the data. Or else there is possibility you get wrong result. You should find some common field in both DSO, map to IC and then load the data. You will get desired result.

Thanks,

Manali Patel

[Former Member]

Unfortunately I think your requirement could not be reached.

There is no same field name between DSO1 and DSO2.

So system is not able to combine the records.

[sri_pamarthi]

IS THERE ANY PSEUDO CODE THAT HELPS TO THESE KIND OF SITUATION..

[former_member185132]

There could be pseudocode to help with this - but to design the pseudocode we need to understand the relationships in your data. If we don't know the business logic, what do you expect the code to achieve?

I'm not asking this for idle curiosity - a clear requirement is the starting point before you write any pseudocode/code.

[former_member186445]

YES THERE IS

[sri_pamarthi]

please provide solution for that..

[former_member186445]

Hello PAMARTHI wrote:

please provide solution for that..

please provide necessary info so i can prepare my invoice...

there are a billion threads on start routine with the necessary coding... you could try to search before asking copy/paste ready code...

[former_member285534]

Hi,

That's what happens when not all InfoCubes's dimensions are loaded in the same transformation. Two  entries are created in the cube, one coming from each flow, the non-loaded characteristics from DSO1 produce some Not Assigned characteristics and the non-loaded ones from DSO2 produce the other ones.

The solution is to load all the cube's characteristics on a single transformation.  You could choose DSO1 --> cube1 or DSO2 --> cube2 indistinctly.  The important thing is that some ABAP coding inside this transformation will be necessary to join DSO1's characteristics with DSO2's ones.  This way the cube will end up with a single entries with all their dimensions filled.  No more Not Assigned values will be there provided they aren't present from the DSO's.

Best regards,

Fernando

[sri_pamarthi]

Hi Fernendo,

Thanks for replying,

I guess it would be lookup in between the active table of one of the dso to the info cube right..

Is there any chance can i have a pseudo code for these kinds of issues.

Please assist me ..

Thanks & Regards.

P Sriram.

[former_member185132]

Hi,

The coding for this will be tricky. DSO1 seems like a Sales Order DSO and doesn't contain the Material Number, while DSO2 looks like a Material DSO which doesn't have a Sales Order Number. So there's no logical relationship between these DSOs.

In the general case, Sales Orders and Materials don't have a 1-1 or even 1-N relation, they have an N-M relation. What that means is that your expected output is rather illogical. If I have 20 records (i.e. Sales Orders) in DSO1 and 3 records in DSO2, how would you determine which record of DSO1 is related to which record of DSO2? And what happens to the key figures of both DSOs? If 1 record in DSO2 matches multiple records in DSO1, will you enter the same Quantity value for all records, or will you "split" the quantity?

I'm not talking about ABAP or coding here, I'm talking about how the business would want those records to be related. That's the key.

So please first figure out or explain the business relationships between the two DSOs. Coding can be done after that.

Regards,

Suhas

[former_member285534]

Hi,

As others have written, the most important thing is that a set of characteristics or common key that relates DSO1 and DSO2 exists.  If it doesn't, something's wrong with the design.  Consider redesigning...

If it exists then write a start routine in the transformation of the most detailed DSO to query the other's ("lookup DSO") values.  Place the resulting data set in an internal table searchable by the common key.   Then fill all the SOURCE_PACKAGE's fields that aren't obtained from the transformation itself.  Do this looping SOURCE_PACKAGE row by row.  Use the lookup internal table (search by the common key) to get each row's corresponding values.

Refer to documents or discussions where start routines are explained.  I'm attaching a link to a good one.

I hope you find this helpful.

Fernando

[sri_pamarthi]

Thanks Fernando..

That would be helpful

[sander_vanwilligen]

Hi,

This works as designed. There are limited work-arounds like diplaying a text of the Characteristic; make the text for # (unassigned) blank. Suppress 0 (zero) in the BEx Query Designer.

If this is not sufficient, then you will have to prepare your data during data staging. Some ABAP coding could be necessary in this case.

Best regards,

Sander