2LIS_13_VDITM keys

We have just gotten a duplicate key error in our overnight delta for this extractor. (using the map_cdc operation)

This means either:

  1. There is a bug somewhere is ERP and/or Data Services, or
  2. We have the wrong key defined.

Out key is defined as:
VBELN (SD Document number)
POSNR (Item Number of the SD Document)
PERIV (Finsal year variant)

Firstly, does anyone know if we have the right key here ?
Secondly, is there a reliable source of what the keys are for the extractors ?

Thanks.

UPDATE: I decided to remove the key and see what comes through. It looks like AEDAT is whats causing the duplicate, but is that correct ? Shouldn’t this come through as an update ? Or is it valid to have two entries. They look the same apart from the date, so i’m leaning towards a bug…


Leigh Kennedy :australia: (BOB member since 2012-01-17)

We have verified that the problem is on the ERP side. My gut feeling is its a bug somewhere between the extractor and the ODP API. We have similar issues with the 2LIS_11* extractors last year and had to replace them with custom extractors.

What had happened is a billing document was created and then cancelled in the same day. The second record should have been mapped to a delete but for some reason was mapped to an insert.

Is anyone successfully using the 2LIS series with data services ? They don’t seem to be able to handle documents being created and modified on the same day…


Leigh Kennedy :australia: (BOB member since 2012-01-17)

So we have been working through this with Support for the last few months. We have found similar issues with other 2LIS extractors and have gotten pretty good at reproducing the issue.

We have now gotten SAP to accept that it doesn’t work properly. It seems the ODP API is returning data in the wrong order, so Data Services receives:

Delete
Insert
Insert (the second insert violate the primary key as it should)

When it should receive:
Insert
Delete
Insert

The problem is the ODP team say its ‘by design’ Which is the biggest load of BS i’ve heard in a while, and the DS team say there is nothing they can do.

Surely as a customer we can expect SAP to stop passing the buck and fix this ? How do we get this taken seriously ?

SAP support had the hide the suggest we hire a consultant to develop a work-around !

Not happy…
:reallymad:


Leigh Kennedy :australia: (BOB member since 2012-01-17)

We use 2LIS Extractors for Purchase Orders and Inventory.

Are these in trouble too?

Also, the one you mentioned is supported by default in ROOSATTR or you made a manual entry?


ganeshxp :us: (BOB member since 2008-07-17)

The issue only arises when you have same day changes to orders. Its possible there is something a bit different about our business processes that causes it to occur.

I believe they are supported extractors.


Leigh Kennedy :australia: (BOB member since 2012-01-17)

We almost converted our extractor loads into direct table loads except for inventory (BF Extractor)

We are tired of unraveling the mystery of the extractor’s behaviors. So we decided to do the logic in our warehouse.


ganeshxp :us: (BOB member since 2008-07-17)

We have had to in some cases also. It increases our TCO though - The lack of support for Extractors has been a huge disappointment to us - SAP seems to be pretty poor when it comes to different parts of the company working together.

In the Case of the 2LIs extractors, many of the underlying tables lack the relevant modified dates to allow us to do tables pulls efficiently though.


Leigh Kennedy :australia: (BOB member since 2012-01-17)