Direct delta and Quedue delta

Hi,
Direct delta :extraction data is directly loading into BW Delta queue.
Does this deltas will be loading BW delta queue or SMQ1?
In BW where it will be loading as first step and how abt Queue delta mechanism?

hi,
1. Direct delta.
When a Document is posted it first saved to the application table and also directly saved to the RSA7 (delta queue) from here it is being moved to BW.
so u can understand that for Delta flow inR/3 Delta queue is the exit point.
2. Queued Delta
When a document is posted it is saved to application table, and also saved to the Extraction Queue ( here is the different to direct delta) and you have to schedule a V3 job to move the data to the delta queue periodically and from their it is moved to BW.
hope this help you
regards
harikrishna N

Similar Messages

Direct delta and Qued delta.............

Hi Gurus !
Both Direct delta and Qued delta in LO are independent of the success of the V2 Update process( Roberto Negro too mentioned this in his weblog).This means that V2 update Exists both in Direct and qued delta( Am I correct?).
As the data is written in the Delta que within V1 Update
for the case of direct delta, in Extraction que in Qued delta , where does the V2 Update come into the Picture?
Pls can anyone help in this regard.
Regards
Durai

Hi !
I am very eager to know the answer.
Regards
Durai

Can anyone give me an example of direct, queued and unserialized delta?

hi all,
Can anyone give me an example of direct, queued and unserialized delta for fi and sd applications.
thanxs in advance
regds
hari

hi,
Update Methods,
a.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
a. Update methods: (serialized) V3
Transaction data is collected in the R/3 update tables
Data in the update tables is transferred through a periodic update process to BW Delta queue
Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
V2 Update errors can lead to V3 updates never to be processed
Update methods: direct delta
Each document posting is directly transferred into the BW delta queue
Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Less monitoring overhead of update data or extraction queue
Cons:
Not suitable for environments with high number of document changes
Setup and delta initialization have to be executed successfully before document postings are resumed
V1 is more heavily burdened
Update methods: queued delta
Extraction data is collected for the affected application in an extraction queue
Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Suitable for environments with high number of document changes
Writing to extraction queue is within V1-update: this ensures correct serialization
Downtime is reduced to running the setup
Cons:
V1 is more heavily burdened compared to V3
Administrative overhead of extraction queue
Update methods: Un-serialized V3
Extraction data for written as before into the update tables with a V3 update module
V3 collective run transfers the data to BW Delta queue
In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
V2 update has to be successful
hope it helps
partha

Differences between FULL, DELTA and REPEAT DELTAs

Please distinguish Full, Delta and Repeat Delta loading from R/3 to BW/BI and give some example for their uses
Your answer would be appreciated.
Cheers,
Nari

please search in SDN before posting Novice questions

R/3 extraction.{direct delta and queued delta and V3}

Hi,
I am new to BW.Can anyone explain me about R/3 extraction in detail and steps to extract from R/3 to BW.
I understood direct delta.But i couldn't understand queued delta.Can anyone please explain queued delta and also V3.Are queued delta and V3 same?
Detail explanation or links will help a lot.
Thanks,
Sunny.

Hi Sunny,
Procurement - MM :
MM is a part of SCM. There are several section in this, say Procurement, manufacturing, vendor evaluation etc... All can be found under follwoing link.
Please find the procedure and important links for LO extraction..
LO'S Procedure:
Go to transaction code RSA3 and see if any data is available related to your DataSource. If data is there in RSA3 then go to transaction code LBWG (Delete Setup data) and delete the data by entering the application name.
Go to transaction SBIW --> Settings for Application Specific Datasource --> Logistics --> Managing extract structures --> Initialization --> Filling the Setup table --> Application specific setup of statistical data --> perform setup (relevant application)
In OLI*** (for example OLI7BW for Statistical setup for old documents : Orders) give the name of the run and execute. Now all the available records from R/3 will be loaded to setup tables.
Go to transaction RSA3 and check the data.
Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.
Go to BW system and create infopackage and under the update tab select the initialize delta process. And schedule the package. Now all the data available in the setup tables are now loaded into the data target.
Now for the delta records go to LBWE in R/3 and change the update mode for the corresponding DataSource to Direct/Queue delta. By doing this record will bypass SM13 and directly go to RSA7. Go to transaction code RSA7 there you can see green light # Once the new records are added immediately you can see the record in RSA7.
Go to BW system and create a new infopackage for delta loads. Double click on new infopackage. Under update tab you can see the delta update radio button.
Now you can go to your data target and see the delta record.
Re: LO-Cockpit V1 and V2 update
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
Also Refer this link:
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Inventory.. dwload go thru it
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
*Steps*:
1st delet the septup table----lbwg(for application 3)(need to cleanup the setup tables in r/3 side by using (LBWG for AC:03)
1) Fill setup table (fill up the set up tables BX, BF and UM by using (MCNB,OLI1BW and OLIZBW).
for BX(Open stock)-tcode--MCNB,
for BF Tcode(oli1bw)
for UM tcode(olizbw)
after that pull data to BW with (Once the data is ready in RSA3, then in BW you have to set up compression for zero marker update for the Cube (coz is related to Noncummulative Keyfiger scenario) then load BX data. onces its completed load normally the BF and UMs.
BW side:-
make the compression
for BX load normally
and BF&UM(step table data):-compression with zero mark update(select that check box option)
after completion of compression do delta(Note: for deltas follow the compression normally)
http://help.sap.com/saphelp_nw2004s/helpdata/en/29/79eb3cad744026e10000000a11405a/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/c5/a26f37eb997866e10000009b38f8cf/frameset.htm
SD - Enterprise Sales and Distribution
SD comes under CRM application component (ERP Analytics).
sd flow
salesorder:
VBRK - header
VBAP - item
VBEP - scheduling
delivery:
LIKP - header
LIPS - item
billing:
VBRK - header
VBRP - item
shipement
VTTK - header
VTTP - item
customer data
SD links FI table
salesarea data general data companycode data
knvp kna1 knb1
material master data
SD link to MM table
salesdata Basic data salestext data
MARC MARA STXH(Textfile header)
MVKE MAKT STXL
process:
1.sales reresntive enter sales order in R/3 system, it sotres the transaction into three
SD tables.
2.delivery due list is executed for all sales orders and delivers are created in table LIKP, LIPS.
A goodsissue updating MKPF & MSEG.
3.invoice due list is then executed for all deliviers. after an invoice is created, which creates an acct.doc ( BKPF & BSEG, FI TABLES) and set up the receivalbe in table BSID (open tem).
4.The receivalbe is cleared when paymen check is required. anoher acct.doc is created ( BKPF & BSEG) the open receivable is cleared and table BSAD (closed line item) is updated
First u select application component.. SD,MM,FI,PM
then got to rsa5.. u can install data source...
after next step RSA6-Display data sources
Then select our ds which we need to enhance then click on the
append structure (application tool bar)
u can see start with ZAGTFIGL_4 ( fi example)
u given component name and component type ( here given to existing
data element)
save + activate....
then go to the t code CMOD...>there select the project
name--> go to the exit in RSAP0001->
or also u can goto tcode se37 fuction module.. EXIT_SAPLRSAP_001
transactional data
click on display...
then u can see INCLUDE ZXRSAU01( program ) double click it.....
then u can change option click it.
So please follow the link below:
http://help.sap.com/saphelp_nw70/helpdata/en/c5/bbe737a294946fe10000009b38f8cf/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/17/cd5e407aa4c44ce10000000a1550b0/frameset.htm
Check these links,
http://help.sap.com/saphelp_47x200/helpdata/en/dd/55f33e545a11d1a7020000e829fd11/frameset.htm
http://www.sapbrain.com/TUTORIALS/FUNCTIONAL/SD_tutorial.html
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/MYSAP/SR_MM.pdf
http://sap-img.com/materials/what-is-the-dataflow-of-mm.htm
http://www.erpgenie.com/abap/tables_sd.htm
http://www.erpgenie.com/abap/tables_mm.htm
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
/people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
Re: LO-Cockpit V1 and V2 update
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Regards
CSM Reddy

Difference between RDA delta and normal Delta

Hi All
I have some doubts regarding the RDA [Real Time data Acquisition] process I am aware that RDA enables us to get the data every minute with help of Daemon process.What is the diffrence between th delta mechanism that is followed in RDa and normal dataflow.
Thanks & Regards
Santosh Varada

Hi Varda ,
RDA is Real Time Data Acquisition . In this We can retrieve Live data . While using Normal DTP We can t pull live data
For example :- Today We have Create a 50 orders . This 50 order information pulled after completion of sales order creation . we can t see live . But RDA process pulled the data at the point of sales order creation it self ,It support only Stranded DSO .It will use Some industries like FMCG.Retail,banking sector they want to know current data information from BI Side then RDA.
Please Find below link for Demonstration of Real-Time Data Acquisition (RDA) for SAP BI 7.0 using Web Services API.
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00db64ee-82f0-2b10-01b0-fe9543dc227e?quicklink=index&overridelayout=true.
Real-Time Data Acquisition (RDA) for SAP BI 7.0 using Web Services API
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/20f704bd-b6e8-2c10-569e-d726784388ce?quicklink=index&overridelayout=true
Thanks & Regards,
Praveen Yagnamurthy,
SAP BI Consultant,
Blue Marlin Systems-INDIA.
http://www.bluemarlinsys.com/
http://bluemarlinsys.com/bi

Question regarding deltas and filling of setup tables

Hello Friends,
We are using the Sales Order Item Datasource 2LIS_11_VAITM. We have transported it to BI Production. We have initialized the delta and the deltas are running for the past 3-4 months.
Now we had a new requirement which was getting satisfied by the Sales Order Header and Sales Order Header Status DataSources, 2LIS_11_VAHDR & 2LIS_11_VASTH respectively.
Now we wan to transfer both these (header & header status) DataSources to BI Procution. My question is:
1) Do we have to refill the setup tables again in R/3 for the Sales (11) application?
2) Do we have to reload the entire Sales data again from scratch.
3) Is there any way to transport the 2 new DataSources to BI Production and without disturbing the already running deltas of Sales Order Item Datasource?
Regards,
Prem.

Hi,
1) Do we have to refill the setup tables again in R/3 for the Sales (11) application?.
Yes you need to refill the setuptables, because if you want to load deltas, you need to do Init then deltas, other wise first time when you are filled setup tables, (first load init with the existing data in setuptables) from that day to till date you can do full then you can set delta.
It is better and good to fill setup tables and load.
2) Do we have to reload the entire Sales data again from scratch.
Any way you need down time to load the other 2 datasources, and also for 11 application you are filling setuptables.So for perfectness it is better to load from first.
3) Is there any way to transport the 2 new DataSources to BI Production and without disturbing the already running deltas of Sales Order Item Datasource?
If you transport the new datasources then delta won't distrub in BW. If you did any changes to DataSource and trying to transport it to production then it will give error, because LBWQ and RSA7 will have data so first you need to clear it and then transport it.
Thanks
Reddy

Difference between Direct delta and delta Queue

Hi,
1.ease explain me the concept of Direct delta and delta queue in LO extraction
2.Why set up tables are used and initially why the data is deleted for th setup tables.
3.Please explain me the LO extraction with an example.
Thanks
Alok

Dear Aloka,
1.
Direct delta:
transactional data or application posting will be directly available in the delta queue table with out any intermediate tables. then that data will be extracted from r/3 to bw.
Each document posting is directly transferred into the BW delta queue
each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Less monitoring overhead of update data or extraction queue
Cons:
Not suitable for environments with high number of document changes
Setup and delta initialization have to be executed successfully before document postings are resumed
V1 is more heavily burdened
Queued delta:
first the data posting will available in the extraction queue table. then there periodic job run take that data to queued delta table.
Extraction data is collected for the affected application in an extraction queue
Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Suitable for environments with high number of document changes
Writing to extraction queue is within V1-update: this ensures correct serialization
Downtime is reduced to running the setup
Cons:
V1 is more heavily burdened compared to V3
Administrative overhead of extraction queue
2.
Setup tables are used for Full/Initial Update.
Instead of pulling data from DB Tables directly, we r filling Setup tables and extracting data from the Setup tables, which dont have performance impact on DB Tables.
Setup tables are application specific.
It is cautious method to delete Setup tables before filling it for a specific DataSource.
3.
Re: LO-Cockpit V1 and V2 update
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Regards,
Ram.

Diffrence between Direct Delta,Que Delta and Un searlised v3 update

Dear All,
Can any one explain the diffrence between Direct Delta,Que Delta and Un searlised v3 update and in which situation to which update mode.
Thanks in advance

Dear Friend,
Transaction posting lead to:
1. Records in transaction tables
2. For an initial load a setup needs to be executed which reads the transaction data and stores the data in a setup table
3. These setup tables are read during an initial or full load
4. Further transactions are posted into the transaction tables and also caught into Update tables / Extraction Queue.
5. A periodically scheduled job transfers these postings into the BW delta queue
6. This BW Delta queue is read when a delta load is executed.
a. Update methods: (serialized) V3
u2022 Transaction data is collected in the R/3 update tables
u2022 Data in the update tables is transferred through a periodic update process to BW Delta queue
u2022 Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
u2022 Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
u2022 V2 Update errors can lead to V3 updates never to be processed
u2022 Details in SAP Note 505700
b. Update methods: direct delta
u2022 Each document posting is directly transferred into the BW delta queue
u2022 Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
u2022 Extraction is independent of V2 update
u2022 Less monitoring overhead of update data or extraction queue
Cons:
u2022 Not suitable for environments with high number of document changes
u2022 Setup and delta initialization have to be executed successfully before document postings are resumed
u2022 V1 is more heavily burdened
Note: Con 2: a delta queue has to present to collect the document postings. This queue is only available after a successful delta initialization.
c. Update methods: queued delta
u2022 Extraction data is collected for the affected application in an extraction queue
u2022 Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
u2022 Extraction is independent of V2 update
u2022 Suitable for environments with high number of document changes
u2022 Writing to extraction queue is within V1-update: this ensures correct serialization
u2022 Downtime is reduced to running the setup
Cons:
u2022 V1 is more heavily burdened compared to V3
u2022 Administrative overhead of extraction queue
d. Update methods: Un-serialized V3
u2022 Extraction data for written as before into the update tables with a V3 update module
u2022 V3 collective run transfers the data to BW Delta queue
u2022 In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Note: i. Pro 2: In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each Data Source into the BW delta queue, depending on the application.
ii. Pro 4: Even without a successful initial load and thus no BW delta queue yet available, document postings are already collected in the extraction queue.
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
u2022 Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
u2022 V2 update has to be successful
Hope this will be helpful.
Please respond back if there is still any query.
Varun

ALE and IDOC Delta loads

ALE Delta is used for all Master data delta extracts and referencing change pointer tables
IDOC Delta Loads are used for transactional delta and access source system queues
Are the above statements correct? Thanks

Nitesh
As you know there are two types of Transfer Methods (PSA & IDOC). Info Idoc are used for both the types of Transfer Methods. Only ALE is used to transfer InfoIDocs.
The Transfer Method only determine how the data is transfered.
IN PSA Transfer Method Trfc is used to transfer data directly from Source system to BW.
Thanks
Sat

Delta and LBWE

Hi Gurus
I have understood the delta mechanisam for LO extraction ( LBWE >>>Job control ) where we first have to select direct delta ( for full load ) and queued delta ( for subsequent delta load ) Am i right?
now when we load the data we create 3 info pkg.
1.full load
2.Init
3.delta load
so would you pl tell me whats the difference between update mode we are giving on infopkg level and the things we are doing in LBWE under job control.? Pl help me to clear this doubt.
second thing is when we do extraction other then LO ( may be generic / from table / from FM ) why are we not going to LBWE and how we are managing delta in those case as job control will not there as we are not using LBWE.
pl help.

Hi krishna,
For the first question,
The update mode in the infopackage tells the system to identify the way it can bring the data into BW that is, if you select the full load it brings all the records or if you specify initialize delta process, it brings in all the history data and if you specify delta process, it brings in only the changed or recently created records.
The selection of the queue delta or direct delta in LBWE is to tell the system how to store the transaction data in the BW delta queue in source system(like R3)like if you say queue delta, then all the sales orders which you have created in OLTP system(R3 system)gets piled up in delta queue in the order in which they are created.So, setting in LBWE is totally different from setting in Info package.
For the second question, Only for Logisitics we use LBWE like for eg. Materials management , sales and distribution, etc and in other areas like FI and CO,there are standard settings through which you can get delta and i think you shall set up once those settings in source system and the delta is taken care of.
Hope it helps.
Message was edited by: Rao

BW Delta and Full load

Hi !
This is a simple question with BW 3.5 :
A standard extractor with Delta is extracting everyday delta to 1st level ODS -> 2nd level ODS -> Cube.
Now i want to add 2 ODSes in same flow and they should also catch all these delta. Along with that I want to load for remaining period of this month (ex. Full load from 1st to today of the month and then onwards delta)
So new structure would be
0CRM_SALES_ACT_1 -> Level 1 existing ODS delta -> Level 2 existing ODS Delta
-> New level 1 ODS with delta -> New Level 2 ODS with delta
Can you please let me know how to do that ?
Full , delta info package ?
(FYI - i loaded full load for history and then tried delta, but delta failed saying Full load is already there in system)
Please do not post duplicate threads
Edited by: Pravender on Apr 12, 2011 7:08 PM

Partik,
My suggestion is load data from exiting Level 1 DSO to 2 New DSO's instead of loading directly from source to New DSO's.
To do that... removed initialization from Level1 DSO to 2nd level DSO and Re-Initialize WITHOUT data transfer by considering new DSO's also and continue delta's.
Use full load infopackages to load historic data from Level 1 DSO to 2 new DSO's.
Flow now should be:
0CRM_SALES_ACT_1 -> Level 1 existing ODS delta -> Level 2 existing ODS Delta
Level 1 existing ODS delta -> New DSO's
If FULL loads already there in DSO's further delta's wont work. Convert FULL loads to repair full load using Program: RSSM_SET_REPAIR_FULL_FLAG.
Then continue delta's.
Hope it Helps
Srini

What is the difference between qued delta update and serialized delta upda

what is the difference between qued delta update and serialized delta update?

Hi Ks Reddy,
Queued Delta:
In case of Queued delta LUW's are posted to Extractor Queue (LBWQ), by scheduling the V3 job we move the documents from Extractor queue to Delta Queue(i.e. RSA7) and we extract the LUW's from Delta Queue to BW side by running Delta Loads. Generally we prefer Queued Delta as it maintain the Extractor Log which us to handle the LUW's which are missed.
Direct Delta:
In case of Direct Delta LUW's are directly posted to Delta Queue(i.e. RSA7) and we extract the LUW's from Delta Queue to BW side by running Delta Loads. If we use Direct Delta it degrades the OLTP system performance because when LUW's are directly posted to Delta Queue (RSA7) the application is kept waiting untill all the enhancement code is executed.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
https://websmp102.sap-ag.de/~sapdownload/011000358700007535452002E/HOWTOCREATEGENERICDELTA.PDF (need id)
http://help.sap.com/saphelp_bw33/helpdata/en/3f/548c9ec754ee4d90188a4f108e0121/frameset.htm
Business Intelligence Performance Tuning [original link is broken]
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
How to load data
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
Delta Types and methods;&#57245;
Hope this helps.
****Assign Points if Helpful*****
Regards,
Ravikanth

2LIS_04_P_COMP and 2LIS_04_P_MATNR delta issue

Hi experts,
I am having problems with 2LIS_04_P_COMP and 2LIS_04_P_MATNR delta extraction.
I run the init, it is ok. I create an order and then I run DELTA expecting to get more record(s).
DELTA will bring no records. But if I delete set up tables LBWE, initialize them again, and then run the init again, the new records will be available.
Has someone had the same issue? I can't find the reason why the delta extraction does not bring the new records, if I don't re-setup the tables in LBWE.
Thanks in advance for your help,
Best Regards,
André Oliveira

Thanks for your help.
In job control window I do not have the green check button, only the cancel (red cross). When I try to schedule the job it gives me an error "error creating a job", so only I can do is save a start date and periodicity in job parameters. Is this ok?!
I also wrote sap a message because I am trying to enhance it with two fields (they are in LBEW), but same happens... I just see a cancel button, never a green check to validate and accept. I have done all the recomendations. I put the message I wrote below hoping you can give me some insight on this issue:
am trying to do an enhancement to extractor 2LIS_04_P_COMP.
+I go to LBWE and select these 2 fields:
MCAFKO GAMNG Qtd.teór.
MCAFKO GMEIN UM básica
The problem is that in the selection window to select these fields from
pool (scroll down box) to selection criteria (scroll down box) the
button to accept these changes does not appear (I mean the button with
the green check). So it is impossible to add this fields to the
structure. Is there any reason for this not to appear?
I think I have done everything that was needed:
LBWG: delete setup tables for 04 (production application)
RSA7: delete 04 queues
LBWQ: delete 04 queues
LBWF: check for active maintenance logs (does not exist any)+
Some points already assigned.
Best regards,
André Oliveira
Edited by: Andre Oliveira on Feb 23, 2010 12:01 PM

0MATERIAL and 0CUSTOMER Delta error

Hi Gurus,
I have a problem regarding the 0MATERIAL and 0CUSTOMER Delta. It stopped due to an error in source system. When I tried to do a Repeat Delta, the system did not permit me because the Infosources does not allow update mode R (repeat). I checked previous SDN topics and found the solution.
1. Delete 'Delta Init' in Delta Channel (InfoPackage)
2. Do a Init load.
My questions are:
1. Is this the proper process or did I misinterpret the posts.
2. Would creating a new Init for the InfoSource not affect the data in the Cubes?
3. Do I have to create a Delta right after the Init?
Please advise,
Jake

Hi Jake,
1. Is this the proper process or did I misinterpret the posts.
>>Solution suggested by you is fine,
2. Would creating a new Init for the InfoSource not affect the data in the Cubes?
>> It should not affect the cube data, remember to activate your master data ( customer & material) after data load ( right click -->activate)
3. Do I have to create a Delta right after the Init?
>> you need to create delta Infopackage whenever you wish to take delta from R/3. When you do the intialization system starts tracking delta for you irrespective of whether you create delta infopackage in BW or not.
hope it helps
regards
VC
Message was edited by: VC

Direct delta and Quedue delta

Similar Messages

Maybe you are looking for