题记：忽然想到这么个问题，后勤数据源和非后勤数据初始化有何区别，然后进行周边的拓展，所以就形成了下文。大部分知识源于TBW350和SAP SDN。
1) Main reason is HUGE VOLUMES OF LO data.
2) To avoid interdependency, while still making changes transactional tables in R/3.
3) Customized cluster and pool tables enhancing extraction easier.
1、Based on your delta updated mechanism, it will be either V1 or V2 or V3
2、Delta tables will be based your delta updated process ,it will be either Extraction queue or Update tables and the collective run will be either extraction collective run or V3 collective run
所谓的V1、V2、V3有如下解释，这个东西在激活LO数据源的信息结构时可以看到：
下图源自LBWE：
这里三种简单的说一下，更新方式的解释详见附件：Gist of LO Cockpit Delta，据说本来还有个Serialized V3，7.0后就被取缔了。
来张图，解释下整个过程：
我们的R/3系统提供了这么一种功能，来标记新旧数据的差别，可以通过Time stamp，Calendar Day，Numeric Pointer来标注。
设置方法：
只要在建立数据源的时候设置增量的特定字段，选取时间标记。这里拿ZMAT_ATTR做例子，选的是Calend. Day，Safety Interval Upper Limit是1Calend. Days，New Status for Changed Records，这么说来，就会每天跑一次，每次跑前两天的数据，而且以最后更改的记录为准（这个在下面会说到）。
这样做的效果可以在RSA7里看到，点Generic Delta：Current Status：
很简单，当前的Time stamp。
Notes：为什么不是所有的都有呢？因为这个叫做Generic Delta，可以简单的看一下，LO的数据源一个都没有，那种比较BT，一般来说非后勤和主数据还有自建的数据源都是Generic Delta。
看几张表：ROOSPRMSC，222系统
要了解这张表，还需要知道一个概念叫做LUW，
LUW is logical unit of work. The qRFC outbound queue controlled using an Outbound Scheduler (QOUT Scheduler). The QOUT Scheduler prompts the transfer of a LUW to a target system when all previous LUWs in this queue have been processed. When one LUW has been executed, the QOUT Scheduler automatically executes the next LUW in the queue.
In other words when we request delta load from BW, Source system will identify the last delta records which are in form of TID's by using ROOSPRMSC table and it will delete previous confirmed LUWs(repeat delta table) and Process new LUWs(delta table)
另外，想看这些请求号，可以到表RSREQDONE，这个要在200系统里。
Notes：咱们用的Time stamp叫做UTC Time Stamp，什么是UTC，等同于GMT，就是世界时，咱们要+8:00，也就是说这个DTP的时间是2009.03.13,08:36:26。
PS：不过和222那边有那么10s的时间差（RSREQDONE表里的时间小10S），我也不知道怎么回事儿，后来查了下03_BF的，也是有10s的差，知道的同志可以告诉我呀。。。当然这些并不重要
接下来几张表：
ARFCSSTATE
ARFCSDATA
TRFCQOUT
不多做解释，参照附件BW_DELTA-QUEUE-详细说明，第11页
这个可以用两张表来做解释：
第一个：
ROOSOURCE
这里的四个数据源，分别是LO（后勤），FI，主数据和自建数据源，各有不同。
这里的Delta Process共有20种，于是需要第二张表：
RODELTAM
这里的几个列，控制了Delta方式对镜像的操作，序列化方式，Delta处理类型等等。
需要着重的是DeltaType：
D Generic Delta for Service API
E Extractor Delivers OLTP Source Delta——这种方式叫做PULL
means the delta data records are determined during the delta update by the data source extractor, updated to the delta queue and passed on to BI directly from there.
一般来说：
下面简述下AIE和ABR的区别：
最后还要说明一下，FI与其他模块的数据抽取方式不太一样。
另外，关于FI的Delta方式，有如下解释：节选自SAP HELP，另外附件里还有一些Notes，有兴趣可以看下
Delta Method
Delta extraction enables you to load into the BW system only that data that has been added or has changed since the last extraction event. Data that is already loaded and is not changed is retained. This data does not need to be deleted before a new upload. This procedure enables you to improve performance unlike the periodic extraction of the overall dataset.
Financial Accounting line items are read by extractors directly from the tables in the SAP R/3 system. A time stamp on the line items serves to identify the status of the delta data. Time stamp intervals that have already been read are then stored in a time stamp table. The delta dataset is transferred to the BW system directly, without records being transferred to the delta queue in the SAP R/3 system (extractor delta method).
The Financial Accounting line items are extracted from the SAP R/3 system in their most recent status (after-image delta method). This data method is not suitable for filling InfoCubes directly in the BW system. To start with therefore, the line items must be loaded in the BW system in an ODS object that identifies the changes made to individual characteristics and key figures within a delta data record. Other data destinations (InfoCubes) can be provided with data from this ODS object.
