Difference between COPA and Logistic Delta Mechanisam

Question

Dear All,
May i knw the difference between the COPA and Logistic Delta Mechanisam h it works.
In our Production system, when ever a logistic delta fails we take action and repeat it then it will featch the delta on the same day,
where as in COPA delta, when it fails we take action and when we repeat it will fetch zero records and in the next day the delta will come.
What is the difference in both
What exactly is happeing in R/3 for these both delta mechanisam.
Thanks in advance,
K Janardhan Kumar

Answer 1

Hi Guru,
I will explain about  delta extraction with timestamp in general with an example:
timestamp is generally in  yyyymmddhhmmss format
let's assume delta runs daily at 09:00 morning.Last delta ran at 09.00 yestreday.And today when delta runs it picks the data ranges between
09:01 (yesterday's) to  09:00(today).
if one record is posted at 09:10 today,then it will not be picked by today's delta(coz' it is posted after 09:00)
Hope now you are clear about timestamp.........
In case of COPA ,we are using timestamp as a tool to identify delta
now COPA delta mechanism has one more concept "saftey delta ":let's put a question to ourselves ,why we should use this;
SAP answer is "The reason for the selection of the safety delta is that there are possible level differences of the clocks on different application servers. If the delta is selected on a level that is too low, it is possible that records
are not taken into account when uploading into the BW."
'Safety delta' usually will be set to 30 mins during the initialization /delta upload(default).
This means that only records that are already half an hour old at the starting point of the upload are loaded into BW
Ex:
we have made following settings for copa
timestamp=09:00
safety delta=30 mins
now when you run daily delta,it picks data ranges between (current timestamp-safety delta) i.e 08:30 instead of 09:00(yesterday's)
to 09:00 today
check this oss notes  502380 for better understanding on COPA delta mechanism
Symptom
There is some confusion about how the delta process works with CO-PA DataSources and the old logic (time stamp administration in the Profitability Analysis) or there are data inconsistencies between the BW and OLTP systems.
As of PlugIn Release PI2004.1 (Release 4.0 and higher), a new logic (generic delta) is used during the delta process. Old DataSources can be converted to the new logic. New DataSources automatically use the new logic. With the new logic, the time stamp administration is located in the Service-API and no longer in the Profitability Analysis.
This note refers only to DataSources with the old logic.
Reason and Prerequisites
Administration of the delta process for CO-PA DataSources partly occurs in the OLTP system. In particular, the time up to which the data was already extracted is stored in the DataSource control tables (old logic).
Solution
Since the control tables for the delta process for the extractor are managed in the OLTP, the following restrictions apply:
1. There should only ever be one valid initialization package for a DataSource. Data inconsistencies may occur between BW and OLTP if, for example, you schedule an Init for various selections for the same DataSource and data is posted between the individual initializations to the Profitability Analysis. The reason for this is that each time the time stamp for the DataSource is initialized in the OLTP, the current value (minus the safety delta, see note 392876) is reset. Records from a previous selection are therefore no longer selected with the next delta upload if they were posted before the last initialization run with another selection.
2. Initialization can always only be carried out from one system. Inconsistencies may occur if the same DataSource is used from several BW systems and if data is posted between the initialization runs. This is because the time stamp for the replication status is reset for every initialization or delta upload in the OLTP. Records may therefore be missing in the system that was first updated if updates were made in the result area before the Init or delta run. In the system that was the second one to be updated, the records that were loaded into the first system are missing for a delta upload.
In the case of large datasets, you should therefore perform initialization either using several DataSources or with a combination of one or more full uploads and an init upload. Full uploads without errors are possible for closed periods/fiscal years because no additional changes are made to this data. Initialization should be performed, for example, from the current fiscal year. The full updates for the closed periods can also be split in time. If required, more characteristics, for example, the action type, can also be used for the selection. For information on the period selection, see note 425844
Hope you are clear now!!!!!!!!!
Cheers
Swapna.G
Message was edited by:
        swapna gollakota