Extractor 2LIS_02_SCL --> behaviour when ELIKZ is set

[Former Member]

Dear BI-colleagues,

we are actually facing an issue with the standard extractor 2LIS_02_SCL - schedule line Level of purchase orders.

Our system setup:

The data of this extractor needs to be used to measure a supplier service sevel based upon single schedule lines. My predecessor actually changed the standard definition of this extractor in the System (which might be a reason for our issue?!).

In the BW-System, one standard staging DSO has been created with the folling key:

- PO document number

- PO document position

- PO document schedule line

- field BWVORG --> process key to distinguish between purchasing, goods receipt and invoice receipt data

Coming to the issue....

We are using the following fields to measure the (on time) Service Level:

SLFDT statistical delivery date           = "to be" date

BUDAT booing date of GR / IR           = "as is" date

--> whenever the BUDAT is higher than SLFDT, the delivery was not in time

In case a purchase order position has more than one schedule line, we get into trouble using this logic. When the final delivery indicator (field ELIKZ) is set on position level, there are update records passed to the BW for all schedule lines of this position showing as BUDAT the date when ELIKZ was set. Example:

Record      Record date     Sched. line     SLFDT               BUDAT               Comment        

1               01.04.2014          1                    01.04.2014     01.04.2014          on time    

2               10.04.2014          2                    10.04.2014     10.04.2014          on time

3               15.04.2014          3                    15.04.2014     15.04.2014          with this partial delivery the ELIKZ was set

4               15.04.2014          1                    01.04.2014     15.04.2014          not in time

5               15.04.2014          2                    10.04.2014     15.04.2014          due to record 3, a new BUDAT arrives for line 2 --> not in time

Unfortunately it's not as easy as e.g. just deleting incoming records having the same BUDAT as the last schedule line, as there are some intended processes which can lead to a later BUDAT (e.g. cancellations, corrections...)

Does anyone know if this is the Standard behaviour of this Extractor? How can I solve my issue?

Thank you in advance,

Andre

[former_member186399]

Dear Andre

This is not the standard behavior of 2lis_02_scl. If you have the scheduline as the key in the DSO and the GR BUDAT are against these individual scheduline then your Record 1,2 & 3 will remain intact with whatever BUDAT that has  got posted.

There might be some routines written at the BW side to trigger the update whenever ELIKZ is updated for PO line item.

Now is your requirement that the Record 1 ,2 & 3 should not be changed with respect to ELIKZ BUDAT ?

Regards

Gajesh

[Former Member]

Dear Gajesh,

thank you for your remark.

Yes indeed the schedule line is in the key of the staging DSO. But as already said, the issue is that there are update records coming for ALL schedule lines whenever the ELIKZ is set on Position Level. From my Point of view the correct behaviour would be to deliver only update records for the last schedule line (the latest line). In my example the records 4 & 5 should never arrive in the BW system.

On BW side there are no modifications done for this Extractor.. the above mentioned examples are taken out of the PSA table, not from the DSO.

My requirement is either to stop transferring records 4 & 5 and/or to filter them somehow out in the BW-System, which is - from my point of view - almost impossible. I've already done a deep analysis of the incoming records in the PSA table and I couldn't find any way to separate these records from other, correct ones.

You said my example is not the standard behaviour... What would it be in this case (and how to restore standard)?

Thanks and best regards,

Andre

[Former Member]

Does anyone have an idea / proposal?

Thanks and best regards,

Andre

[Former Member]

Hi Andre,

Can you able to solve the issue?.

If not let me know the data flow for the same .

I suggest to do these logic in between the DSO  to Infocube... 

Regards,

Rajesh

[former_member201283]

Hi Andre

I propose that you contact SAP for 2 reasons

  a. To know the if this is really the behaviour of this Standard Extractor.

  b. Since a Standard Extractor might/has been changed, I THINK they ONLY have the authorization to       restore it.

Also I wish to add if you want to check what is exactly happening in your Extractor then you can go to RSA2 in your ECC system, give your Standard Extractor name and it will show the FunctionModule used for this Extractor.

Debug that FunctionModule and see what is the Functionality.

Regards
Mohammed Asif

[Former Member]

Dear Rejesh,

I couldn't solve the issue but at least I found a Workaround for the Goods Receipt data... the  Datasource 2LIS_02_SGR delivers the correct Goods receipt Dates per schedule line - setting the ELIKZ does not have any effect on this datasource. I'm reading the data from this datasource / from a staging DSO when loading data from 2LIS_02_SCL.

Anyway this is not a final solution, as we face similar issues for invoice receipt data (when additional delivery costs are booked, again additional records arrive for every schedule line..).

Regards,

Andre

[Former Member]

Dear Mohammed,

thanks for your answer. As stated above I found at least a workaround for the GR data.

Anyway I opened an OSS note questioning the current Extractor behaviour.

Thanks for the hint regarding Debugging the Extractor... As I'm not an ABAP expert, I'll first wait for SAP to answer my questions before investing (too much) time in trying to understand the logic of the function module. As far as I can see there are no modifications done there, therefore let's wait for SAP first...

Thanks and best regards,

Andre