cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with standard extractor 2LIS_02_ITM which will supply the PO Item data along with Transaction Key (Process Key)

Former Member
0 Kudos

Hello All,

We are using an extractor 2LIS_02_ITM which will supply the PO Item data along with Transaction Key (Process Key).

In BW system, we use a Standard DSO as a target with key fields “PO Doc Number, PO Item and Process Key”

I will explain the issue with a normal purchase order:-

Process Key definition:

a) Document type: Purchasing order

- Normal purchasing order - BWVORG = 001

b) Document type: Goods receipt

- Normal purchasing order - BWVORG = 002

c) Document type: Invoice receipt

- Normal purchasing order - BWVORG = 003

  1. 1. Whenever the PO is created, the delta process is replicating the data into BW system and data looks like in DSO as below

PO Doc Number

Item

Transaction Key

Plant

Material

31151627

10

001

FI31

MX1012345

  1. 2. Once the Goods receipt is done, the delta process is replicating the changes to BW system and data looks like in DSO as below

PO Doc Number

Item

Transaction Key

Plant

Material

31151627

10

001

FI31

MX1012345

31151627

10

002

FI31

MX1012345

In my case, there is a change in Plant or Material after creation of PO and before Goods receipt is done.

The changes are not captured via extractors and they are replicated into BW system whenever the goods receipt is done (with next transaction).

The record in BW system is looks like this.

PO Doc Number

Item

Transaction Key

Plant

Material

31151627

10

001

FI31

MX1012345

31151627

10

002

CN14

PY99999238

I am not sure whether this is a standard behaviour or a failure in the delta process.


If I execute full repair request, then I could see the data is updated correctly into BW system.

Before Performing Full Repair:

PO Doc Number

Item

Transaction Key

Plant

Material

31151627

10

001

FI31

MX1012345

31151627

10

002

CN14

PY99999238

Result after performing full repair:-

PO Doc Number

Item

Transaction Key

Plant

Material

31151627

10

001

CN14

PY99999238

31151627

10

002

CN14

PY99999238

Can someone please clarify me on this?

Thanks

Dinesh

Accepted Solutions (0)

Answers (1)

Answers (1)

karthik_vasudevan
Active Contributor
0 Kudos

Hi Dinesh

You have the answer for your question!

"In BW system, we use a Standard DSO as a target with key fields “PO Doc Number, PO Item and Process Key”"


The above point gives the reason for the problem.


The way you change the plant before GR is something different, I hope. Standard DSOs will not work as per our expectation. They are created for their own purpose. You could try using the cube 0PUR_C01 which is also standard and could load directly from the mentioned datasource. This might also help.


Else create a new DSO with Plant, material etc as well in key field, that should do the magic for you.


Hope this helps



Regards

Karthik

Former Member
0 Kudos

Hello Karthik,

I agree with your inputs.

But the problem is, failures in the delta replication during the changes to Plant or Material after PO creation and before GR is done. The changes are carried out as per the standard process.

Changes are captured and updated into BW system only when the GR is done.

Thanks

Dinesh

karthik_vasudevan
Active Contributor
0 Kudos

Hi Dinesh

It could be a standard process functionally. Hope you will agree that BI will not work the same way as the source. Also a DSO will never replace data based on data fields.

So the solution will work if you have material/plant in key fields or replace the DSO with a cube and check the solution.

Regards

Karthik