on 09-25-2012 10:32 AM
Hi all,
I would like to display the current assignment between sales document items and the respective commission recipients (Partner Function Y1, Y2, Y3).
For this purpose, I initially have extended (ERP >> transaction code "SBIW" >> Postprocessing of DataSources) the DataSource "2LIS_11_VAITM" (Sales Document Item Data), Extract Structure "MC11VA0ITM" by a append with three new fields (ZZ_PARVW_Y1, ZZ_PARVW_Y2, ZZ_PARVW_Y3).
In a second step I fill the new fields (ZZ_PARVW_Y1, ZZ_PARVW_Y2, ZZ_PARVW_Y3) of the DataSource "2LIS_11_VAITM" per ABAP-code (ERP >> transaction code "CMOD" >> EXIT_SAPLRSAP_001 >> INCLUDE ZXRSAU01) from the table "VBPA" (Sales Document: Partner).
The INITIAL filling of the fields works successful. I could test the correct assignment between sales document items and the commission recipients by using the Extractor Checker (ERP >> transaction code "RSA3").
However, the problems arise when on the ERP-side, the commission recipients are subsequently changed or recorded at the sales document header level. In this case, an entry in the outbound queue (LBWQ) is not made.
Therfore I cannot load the DELTA and cannot display the current assignment between sales document items and the respective commission recipientsin the BW.
In a test scenario I changed the field "Order reason (reason for the business transaction)" at the sales document header level. In this case, there will be an entry in the outbound queue (LBWQ). Consequently, after I run trough the test scenario, I can load the DELTA and can display the current assignment between sales document items and the respective commission recipientsin the BW.
Are there any means to cause a delta entry in the outbound queue (LBWQ) once the commission recipients are changed or recorded at the sales document header level?
Thanks in advance
Michael
Hi Michael,
In my opinion you should always try to add the missing fields in the communication structure in the Logistic Cockpit (t/code LBWE). From here you execute the subsequent steps. Appending custom (ZZ) fields to the extract structure and then using the SAPI enhancement or SAPI BAdI to supplement these fields during extraction will cause problems with delta processing.
Please also check out SAP Note 576886 - Change to user-defined fields not extracted.
It explains why it's crucial to enhance the communication structure in the right way and moreover it gives some information on how to proceed (under Solution).
Best regards,
Sander
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sander,
thanks for your detailed answer.
My scenario look like this:
The commission recipients are recorded over the respective partner function (Y1, Y2, Y3) at the sales document header level (VA03 > display document header details > tab "Partners").
See "screenshot_va03.png"
The persistent allocation between sales document number and the partner is configured in the table VBPA (Sales Document: Partner).
The relevant fields are VBPA-VBELN (Sales and Distribution Document Number), VBPA-PARVW (Partner Function) and VBPA-KUNNR (Customer Number 1).
See "screenshot_vbpa.png"
Because I need the assignment between sales document items and the commission recipients in the BW, I read the relevant information from the table VBPA to the DataSource 2LIS_11_VAITM (CMOD >> EXIT_SAPLRSAP_001 >> INCLUDE ZXRSAU01).
See "screenshot_zxrsau01.png"
My problem: Any changes in the field VBPA-KUNNR do not cause a delta entry in the Outbound Queue (LBWQ).
Thanks in advance
Best regards,
Michael
Hi Michael,
SAP Note 576886 exactly describes why this approach won't work. It has to do with the delta mechanism using a "before image" and "after image". This will trigger a delta for all fields known at that point in time.
What you are trying to do is supplementing the custom fields at the time of extraction, i.e. after the delta has been pushed to the delta queue. This is too late. Here is the problem, the custom fields will never trigger a delta since they are not part of the communication structure.
The note suggests two solutions:
I have a third solution which is in my opinion preferable from an enterprise data warehousing perspective: extract all single objects (i.e. DataSources) and store the data in BW. If SAP doesn't offer an extractor, then create your own generic extractor. In BW you can execute the enrichment rather than creating a kind of DataMart already in the source. This is a much more generic and reusable approach.
Last but not least: in case you would have to use an extraction enhancement (enhancement RSAP0001 or BAdI RSU5_SAPI_BADI), consider performance aspects. The advise is to never use SELECT SINGLE in a LOOP statement. The suggested approach is to first do an array fetch into an internal table (preferable of type HASHED) and then do a READ TABLE within the LOOP. Furthermore use FIELD-SYMBOLS as much as possible.
Please see an example below.
* Local data declaration
types:
begin of ty_vbak,
vbeln type vbeln_va,
vkorg type vkorg,
end of ty_vbak.
data:
l_t_data type standard table of mc11va0sth,
l_th_vbak type hashed table of ty_vbak
with unique key vbeln.
field-symbols:
<data> type mc11va0sth,
<vbak> type ty_vbak.
* Initialization
refresh:
l_t_data,
l_th_vbak.
* Fill table with sales document and sales organization
l_t_data = c_t_data[].
sort l_t_data on vbeln.
delete adjacent duplicates from l_t_data comparing vbeln.
select vbeln vkorg from vbak
into corresponding fields of table l_th_vbak
for all entries in l_t_data
where vbeln = l_t_data-vbeln.
* Enhance data package with sales organization
loop at c_t_data assigning <data>.
read table l_th_vbak assigning <vbak>
with table key vbeln = <data>-vbeln.
if sy-subrc = 0.
<data>-zzvkorg = <vbak>-vkorg.
endif.
endloop.
However, once again: the extraction enhancement is in this case definitely not the preferred solution !!
Best regards,
Sander
Hi Sander,
Thanks for your reply. I have fixed the Issue with my developer colleague.
We have built a generic DataSource based on a generic Function Module.
The table CDHDR (Change Document Header) is the central
Source of our generic Function Module.
As a result we become already the current partner of the Sales Document Item in the BW.
Best regards,
Michael
This message was moderated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
83 | |
10 | |
10 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.