Episode 1: Weblog: Logistic Cockpit Delta Mechanism

Hi,
I just completed reading this document (Logistic Cockpit Delta Mechanism – Episode 1) by Roberto and I will appreciate if you can clarify these for me:
1. The entire document(Episode 1) is about V3 Update, the Serializer but if the superior Update mode “Unserialzed V3” discussed Episode 3 replaces the Serializer in earlier version, why the need to even learn about the Serializer?  Any reaction to this comment?
2. On page 2 of this document, Roberto had a Fig and 2 paragraphs beneath it.
The para 2 discusses that “V3 collective run” is transferred to the “BW delta queue” from which data is retrieved by means of (delta) requests from BW.
But the para 1 suggests that with “V3 Updates” (the technology for collective update) is first collected in “R3 Update table” before it is transferred to the “interface”.
What interface was he referring to?
3. The two paragraphs appear to be explanations to the figure which shows a flow: “Application Document”  to “LIS Comm. Structure” to “Extract Structure” to “Central Delta Mgmt” and to “DataSource”
Strangely, in the Fig, “BW System Delta Queue” did not appear. Where does this “BW System Delta Queue” come in the figure?
Also, is this entire flow obsolete because of the new “Unserialized V3 Update” discussed in Episode 3?
4. If I get it right, V1 Update, V2 Update and V3 Update are processes(or technologies?) being used in the Update Modes: Direct Delta, Queued Delta and Unseriazed V3 Update. Right?
So, regardless of the Update Mode(Direct Delta, Queued Delta and Unseriazed V3 Update) that we are discussing, one of the processes V1 Update, V2 Update and V3 Update will be in the underlining process.
Is this statement valid? Please correct me.
Thanks

Not getting any help yet ... I will review some old documents and if it is still not helpful, I will break the question up and re-post.

Similar Messages

  • Delta Mechanism for LO Extraction.... urgent plz

    hi experts,
    Could you plz.. give me the details below for LO EXTRACTION DELTA MECHANISM.
    for the first time load i have done initialize with data transfer. what should i do if i want to extract the new data(Changed Records) from r/3. what are all the settings i need to give. i am using BI7.
    plz provide me the documentation for LO EXTRACTION DELTA MECHANISM.
    regards
    vadlamudi

    Hi,
    After initialization you need to check the deltas in RSA7 after the load.
    For further explanation check these blogs by Roberto Negro:
    Episode one:
    /people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
    Episode two:
    LOGISTIC COCKPIT DELTA MECHANISM - Episode two: V3 Update, when some problems can occur...
    Episode three:
    LOGISTIC COCKPIT DELTA MECHANISM - Episode three: the new update methods
    Also check
    Gist of LO Cockpit Delta
    Assign points if this helps........
    Rgs,
    I.R.K

  • How to make added custom field Delta mechanism work for LO Cookpit?

    We appended a new custome field into extraction structure of the LO Cookpit datasource 2LIS_02_ITM through RSA6. And then run CMOD to write the exit code to populate the value and it works fine. But after we read Roberto's Weblog:
    /people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it , find the enhancement we did can't make the Delta mechanism works if only this new field gets changed in a record, and the change cannot be reflected on BW.
    In order to make the Delta mechansim works, one option is to append the custom field into one of the LIS Communication Structure MCEKKO of  2LIS_02_ITM extraction structure and then write the enhancement code to this LIS Communication Structure.  In this way, the custom field can be treated like standard field that whenever it gets changed, the Delta mechanism or the user exit will be triggered.  The enhancement for this LIS Communication Struture is LEINS001. 
    Now we've got two problems when doing the above enhancements of the LIS Communication structure:
    1.  Maintain extraction structure problem in LBWE:
    We added a custom field, e.g., called ZZZ in LIS Communication structure MCEKKO (Purchasing Document Header) by creating a new custom append structure and add the field ZZZ into it, then activate the new append structure, but get warning msg like "Field name DUMMY is reserved (Do not use structure as include in DB table)".
    We do find a field called DUMMY in the structure MCEKKO. How to get rid of the warning msg and successfully activate the new custom append structure with the new field ZZZ?
    You could say that we can ignore the warning msg, but why the new custom field appended can not be seen from the right side pool of the Maintain Extract Structure in LBWE?  We need to make the new custom field shows up in the right side pool and then drag it over to the left side frame and to activate the extraction structure to change it.  But now it doesn't show up in the right frame pool!
    2. Refer to Sanyam's weblog
    /people/sanyam.kapur/blog/2005/04/30/custom-fields-and-bw-extractors-making-a-mixed-marriage-work-part-ii, there is a sample code inside this article which tells us how the sample code looks like to write this LIS Communicaton structure enhancement to make the Delta mechanism works, below is the code we modified to suit our needs, but don't know if it would work?
    DATA: i_t_ekko LIKE ekko   OCCURS 1 WITH HEADER LINE.
    DATA: ebeln LIKE ekpo-ebeln,
          it_ekko TYPE TABLE OF ekko WITH HEADER LINE,
          old_val(50) TYPE c.  "For storing the value from the Field Symbol
    FIELD-SYMBOLS <fs> TYPE ANY TABLE.
    CASE zeitp.
      WHEN 'MA'.                            "When creating a purchase order
        MOVE '(SAPLEINS)T_EKKO[]' TO old_val.
        ASSIGN (old_val) TO <fs>.
        i_t_ekko[] = <fs>.
        LOOP AT xmcekko.
          ebeln = xmcekko-ebeln.
          IF xmcekko-supkz = '1'.            "Old Value ?
            SELECT SINGLE * FROM ekko INTO it_ekko WHERE ebeln = ebeln.
            xmcekko-ZZZ = it_ekko-ZZZ.
          ELSE.                              "New Value ?
            READ TABLE i_t_ekko WITH KEY ebeln = ebeln.
            xmcekko-ZZZ = i_t_ekko-ZZZ.
          ENDIF.
          MODIFY xmcekko.
        ENDLOOP.
    EndCase.
    Share your ideas and we will give you reward points!

    Hello Kevin
    We have exactly the same problem. Did you solve it? If you did, could you please tell us how you did it? We neither see our field in LBWE. Our field is a Z field from a Z table.
    I hope you could help us. We just have this issue to finish our project.
    Thanks a lot in advanced

  • Where does Delta Mechanism acts in LO?

    Hi,
    Where does Delta Mechansim(V3 Update) acts in LO-Extraction?

    Hi,
    Hope this weblog series by Roberto helps-
    /people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
    Regards,
    Disha

  • Logistic Cockpit

    In Logistic Cockpit, I know that we would need to schedule the various jobs so that it will move all the delta into RSA7. i.e. of the following 2LIS DataSource:
    2LIS_11_VASCL
    2LIS_12_VCITM
    2LIS_13_VDITM
    Questions:
    1) How do we know what is the job name of each 2LIS DataSource?
    2) When new document has been posted/existing trasaction is changed and saved, where exactly this delta is stored in the system/table? This delta will then be picked and transferred into RSA7 right?
    3) I see there is Update Mode in LBWE, we have 3 options: Direct Delta, Queue Delta and Unserialised V3 Update. What is different of this? Which one we should use? Does it has any impact to the Job that we schedule for the 2LIS Datasouce?
    I know that this is very complicated and difficult but appreciate your help!     
    Please advice, thank you in advance.

    Hi,
    Roberto Negro's blogs dealing with LO Cockpit are a good starting point...
    /people/roberto.negro/blog
    Rgds

  • LBWE : Logistic cockpit:  Help needed

    Hi All,
       I wish to know whether you have any documentation (pdf) etc available to understand the scope of LBWE transaction.
       For example, I would like to know
       1> How do I change the datasource/underlying prog to add/change/delete some field from the standard delivered logistic datasources for Sales, delicery and billing(2LIS_11, 2_LIS_12 and 2LIS_13* ).
       2> All I know is trandsaction RSA5, RSA6 enables the data source and data extraction to BW. I am not quite getting the point for the transaction LBWE.
       Thanks
    Arunava

    hi,
    check Roberto's weblog
    /people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it

  • 0FC_BP_ITEMS: ERP customizing and delta mechanism

    Hi BI fans
    I have two questions:
    1.) The following link describes how to make the settings for delta enabling of datasource 0FC_BP_ITEMS:
    http://help.sap.com/saphelp_nw70/helpdata/en/27/42073e774a4329b6dd6bab21eef613/frameset.htm
    Prerequisites-
    "...If you want to use the delta method, you first have to activate it in the Implementation Guide for Contract Accounts Receivable and Payable ->  Integration Business Intelligence -> Maintain Central Settings in the clients of the OLTP system..."
    But I cannot find the setting for "Maintain Centrall Settings" in the implementation guide!
    Any idea from your side?
    What I see are entries for:
    Define Fields for the Extraction of Items
    Define Grid for Grouping of Items
    2.) What is the exact delta logic of this extractor (working through function module)?
    Which fields are relevant for the delta logic?
    Thanks
    BEOplanet

    Hi Andrea
    First of all I activated the whole content (datasource, BW content, etc.).
    Regarding the pseudo-delta on CPUDT I have designed a BEx variable on a DATS 8 time characteristic, e.g. 0NETDUEDATE. It is a BEx variable feeded by a customer exit, you will find a sample coding below. Furthermore an interval variable, mandatory input.
    Screen for BEx variable properties:
    Assign this BEx variable into your infopackage for intended use of pseudo-deltas, type OLAP-variable:
    The sample coding below gives you an idea about our pseudo-delta mechanism, from 1st. of last month until sy-datum.
    Data wa1 like line of e_t_range.
    data d1 type d.
    data fdate type d.
    data fyear type d.
    data ldate type d.
    data fmonth type d.
    case i_vnam.
    when 'ZL2MTDY'. "BEx variable on 0NETDUEDATE or any other DATS 8 time characteristic
    d1 = sy-datum.
    fdate = d1 - 31.
    fdate+6(2) = '01'.
    ldate = sy-datum.
    wa1-opt = 'BT'.
    wa1-sign = 'I'.
    wa1-low = fdate.
    wa1-high = ldate.
    append wa1 to e_t_range.
    ENDCASE.

  • Delta Mechanism Issue in BI 7

    Hi All,
      We are facing a problem using BI7.0 Delta Mechanism using DTP.
    We have an ODS that gets data from R/3 to BW which is a daily Delta.
    Now from this ODS, the load goes to a PSA and then to a cube(say Cube 1)  daily at 7:00 PM as full load into PSA and then Delta into Cube 1.
    From the same ODS using a diffrent infopackage, the load goes to a PSA & then different Cube (say Cube 2) at 10:00 PM as a delta into PSA and then as Delta into Cube 2.
    The problem we are facing is: the delta load into Cube 2 is loading the FULL LOAD request that got loaded into PSA as part of Cube 1 load. This is causing our data mismatch.
    If there is a way to deal with such a scenario where the data load into Cube 2 takes only the data that got loaded into PSA when the Cube 2 related Infopackage is scheduled. can you please post your suggestion.
    Thanks in advance,

    ODS to PSA???
    Infopackage loading data into data targets in 7.0???
    Edited by: Raj Coppar on Aug 11, 2008 4:41 PM

  • Delta mechanism setting on R/3 side for a datasource from the FI area

    Hi,
    How to activate delta data transfer on the R/3 side for a FI related datasource?
    For sales and logistics related datasources, there's LBWE where you can activate the delta mechanism.
    I have a datasource called 'Committment line items for Funds Management' that comes under FI Management. What is the procedure to activate the delta mechanism for this datasource?
    Thanks
    Edited by: Sanjeev Koganti on Mar 21, 2008 2:07 PM

    Hi,
    Financial Accounting line items are read by extractors directly from the tables in SAP R/3.
    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 stored in a time stamp table.
    The delta dataset is transferred to BW directly, without records being transferred to the delta queue in SAP R/3 (extractor delta method).
    The FI Extractors are typically function module extractors. The function module for the extractors are as follows:
    0FI_TX_4 - BWFID_GET_FITAX_ITEM
    0FI_GL_4 - BWFID_GET_FIGL_ITEM
    0FI_GL_2 - FBIW_DATA_TRANSFER_GL_2
    0FI_GL_1 - FBIW_DATA_TRANSFER_GL_1
    0FI_AR_3 - FBW4_DATA_TRANSFER_AR_3
    0FI_AP_4 - BWFID_GET_FIAP_ITEM
    0FI_AP_3 - FBW4_DATA_TRANSFER_AP_3
    Refer.
    FI-SL Extraction
    http://www.jt77.com/business-warehouse/work-flow-13393.html
    http://www.saptutorials.com/list/1/,B,BW,xhtml
    Steps to move data from SAP r3 into BW
    http://www.jt77.com/business-warehouse-q/index20.html
    http://jt77.com/business-warehouse/work-flow-15111.html
    http://help.sap.com/saphelp_sm32/helpdata/en/f9/eb7641b61b5858e10000000a1550b0/RN_353_e.pdf
    CO-PA and FI-SL EXTRACTIONs
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/FISL/FISL.pdf
    http://help.sap.com/saphelp_47x200/helpdata/en/66/bc7d2543c211d182b30000e829fbfe/frameset.htm
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a7f2f294-0501-0010-11bb-80e0d67c3e4a
    Re: Which tables for LO and FI...
    http://help.sap.com/saphelp_nw04/helpdata/en/af/16533bbb15b762e10000000a114084/frameset.htm
    Difference between FI and LO extraction
    Extraction Steps for FI Data Sources
    FI-GL Extraction steps
    Re: FI Extraction Steps
    http://help.sap.com/saphelp_bw32/helpdata/en/af/16533bbb15b762e10000000a114084/frameset.htm
    Thanks,
    JituK

  • Agentry Delta Mechanism - Detecting changes in nested objects?

    Hi all,
    I have some experience with the Agentry Delta mechanism directly on a SQL backend (Update / Exchange Tables, Triggers, etc.). Now I am trying to find the right documentation, examples and stuff for that mechanism in the "Work Manager for SAP 6.0".
    Maybe, someone could outline a solution to the following "gap" in the Standard Work Managers exchange mechanism?
    A notifications in the "Work Manager" is updated, when the description of the notification has been changed in SAP.
    However, a notification is not updated, when the description of the functional locations of the notification has been changed in SAP. Now, the question is, how to extend the exchange mechanism to listen to the functional locations description?
    Thanks in advance for any hints you might have.
    Regards, Daniel

    Note: I reposted this question in its own discussion. Please do reply there if you can contribute to this topic. Thank you!
    Hi,
    its me again. I did some reading and I found something called "Exchange Object Linkage Settings" that sounds like it should be used for the use case above. The problem is, that it does not seem to work as I would expect.
    Here is some description from the smp_agentry_sap_framework.pdf, page 78:
    Exchange Object - Linkage Settings The Linkage Settings tab allows the exchange objects that are linked together to communicate with each other. The communication is one-directional, with the exchange object sending information to the object(s) listed in the Linked Exchange Objects List. When there is a value change to the exchange object, that value change information is passed on to the linked exchange objects. The linked exchange objects then go through additional processes related to the value change.
    In the Config Panel, one can see that in the Standard Work Manager, there is a linkage between Functional Location and Workorder:
    (Note that I started this discussion with an example on Notifications and Functional Locations. This is still where I want to go, but I wanted to stay within the Standard Workmanager Setup to make the - hopefully - ongoing discussion easier to follow.)
    According to the above description, I would expect that, when changing the Functional Locations description, that information is passed to all Workorders with that Functional Location.
    BUT HOW? It is not entirely clear to me how and what information is passed where. I would expect, that in the end, all related entries in the workorder exchange table will be updated with a new time stamp. (How else could the client get the information that the workorder is to be updated?)
    This is not what I can see! When changing the Functional Locations description in SAP, I see that the Functional Locations exchange table entry is updated, but the corresponding Work Orders exchange table entry is not changed.
    Does anybody have an idea how this feature is supposed to work? Maybe, there are some configuration steps necessary? Any input on the would be highly appreciated.
    Regards, Daniel

  • COPA Delta Mechanism

    Hi All,
    Can any one explain about Delta Mechanism in COPA ie.,
    How delta works in COPA,
    From where the delta record are picked,
    When the Delta Queue is filled,
    what is Safety Delta,
    What is Relignment and when we go for that, etc.....
    Thanks in Advance,
    Regards
    Ramakrishna Kamurthy

    Hi Ramakrishana,
    Up to and including Plug-In Release PI2003.1, a DataSource is only
    defined in the current client of the R/3 System. This means that a
    DataSource can only be extracted from this client. The DataSource has a
    timestamp for the delta method, and this timestamp is only valid for th
    current client. This timestamp is managed by Profitability Analysis.
    With Plug-In Release PI2004.1 (Release 4.0 and higher), timestamp
    management was converted to a new method, called generic delta. This
    method works in connection with an SAP BW system with Release 2.0 and
    higher. With this method, timestamp management is no longer performed b
    Profitability Analysis, but instead by the Service API (interface on th
    R/3 side between Profitability Analysis and SAP BW). Exclusively in
    Release 3.1I, Profitability Analysis continues to support timestamp
    management.
    Compared to timestamp management in Profitability Analysis, the generic
    delta allows for several enhancements:
    o   You can apply the delta method simultaneously using the same
         DataSource from more than one R/3 System client because a separate
         timestamp is saved for each logical system.
    o   You can apply the delta method for the same R/3 System client
         simultaneously using the same DataSource from several SAP BW
         systems.
    o   You can perform several initializations of the delta method with
         different selections using the same DataSource from a given SAP BW
         system for the same R/3 System client.
    o   The DataSource commands the Delta Init Simulation mode. With
         timestamp management in Profitability Analysis, this mode had to be
          implemented using the Simulate Delta Method Initialization function
          (see SAP Note 408366).
      For more information on the generic delta, see Delta Transfer, whereby
      the steps of the Specify Generic Delta for a DataSource section are
      performed automatically for Profitability Analysis when a DataSource is
      created. For this, the field determining the delta is taken as the
      timestamp for Profitability Analysis (TIMESTMP), and the timestamp is
      stored for summarization levels and line item tables. However, in
      contrast to generic DataSources, the TIMESTMP field is not generated in
      the extraction structure because this is not necessary for DataSources
      in Profitability Analysis. As with timestamp management in Profitabilit
      Analysis, an upper limit of 30 minutes is set as the safety interval.
      You find the timestamp of a DataSource for the delta method in the
      current logical system either in the Header Information for the
      DataSource using the IMG activity Display Detailed Information on
      DataSource or using the IMG activity Check Delta Queue in the Extractor
      IMG. The timestamp is shown here when you choose the selection button i
      the Status column for the combination of DataSource and SAP BW system.
      DataSources created after implementing PI2004.1 automatically apply the
      new method. DataSources that were created in Plug-In releases prior to
      PI2004.1 still continue to use timestamp management in Profitability
      Analysis but can be converted to the generic delta. For this, an
      additional selection option Convert to Generic Delta appears in the
      selection screen of the IMG activity Create Transaction Data DataSource
      when a DataSource with timestamp management in Profitability Analysis i
      entered. Conversion from the generic delta to timestamp management in
      Profitability Analysis is not supported.
      Conversion is only possible for DataSources that are defined in the
      current client of the R/3 system and for which the delta method has
      already been successfully initialized or for which a delta update has
      successfully been performed. This is the case once the DataSource has
      the replication status Update successful. Furthermore, no realignments
      should have been performed since the last delta update.
    For the conversion, the timestamp for the current R/3 System client is
    transferred from Profitability Analysis into the timestamp of the
    generic delta. In this way, the transition is seamless, enabling you to
    continue to perform delta updates after the conversion. If delta updates
    are to be performed from different R/3 System clients for this
    DataSource, you first need to initialize the delta method for these
    clients.
    The conversion must be performed separately in each R/3 System because
    the timestamp information is always dependent on the current R/3 System
    and is reset during the transport. If, however, a converted DataSource
    is inadvertently transported into a system in which it has not yet been
    converted, delta extraction will no longer work in the target system
    because the timestamp information is deleted during the import into the
    target system and is not converted to the timestamp information of the
    generic delta. If in this instance no new delta initialization is going
    to be performed in the target system for the DataSource, you can execute
    program ZZUPD_ROOSGENDLM_FROM_TKEBWTS from SAP Note 776151 for the
    DataSource. This program reconstructs the current time stamp information
    from the information for the data packages transported thus far and
    enters this time stamp information into the time stamp information for
    the generic delta. Once this program has been applied, delta extraction
    should work again. Normally, however, you should ensure during the
    transport that the DataSource uses the same logic in the source system
    and the target system.
    After the conversion, the DataSource must be replicated again from the
    SAP BW system.
    A successful conversion is recorded in the notes on the DataSource,
    which you can view in the IMG activity Display Detailed Information on
    DataSource.
    Since the generic delta does not offer any other log functions apart
    from the timestamp information (status: Plug-In Release PI2004.1),
    Profitability Analysis still logs the delta initialization requests or
    delta requests. However, the information logged, in particular the
    timestamps, only has a statistical character because the actual
    timestamp management occurs in the generic delta. Since the delta method  can be performed simultaneously for the same R/3 System client using the
      generic delta from several SAP BW systems, the information logged is
      stored for each logical system (in R/3) and SAP BW system. When a delta
      initialization is simulated, only the timestamp of the generic delta is
      set; Profitability Analysis is not called. Consequently, no information
      can be logged in this case. Messages concerning a DataSource are only
      saved for each logical system (in R/3). You can use the IMG activity
      Display Detailed Information on DataSource to view the information
      logged.
      Another enhancement from Plug-In Release PI2004.1 means that you can no
      longer exclusively perform full updates for DataSources of the Extractor
      Checker of the Service API that have recently been created or converted
      to the generic delta. The following update modes are possible:
      o   F - Full update: Transfer of all requested data
      o   D - Delta: Transfer of the delta since the last request
      o   R - Repeat transfer of a data package
      o   C - Initialization of the delta transfer
      o   S - Simulation of the initialization of the delta transfer
      In the case of all update modes other than F, you have to specify an SAP
      BW system as the target system so that the corresponding timestamp
      and/or selection information for reading the data is found. The Read
      only parameter is set automatically and indicates that no timestamp
      information is changed and that Profitability Analysis does not log the
      request.
      Update mode I (transfer of an opening balance for non-cumulative values)
      is not supported by Profitability Analysis.
    Assign Points if useful
    Regards
    Venkata Devaraj

  • How Delta mechanism works for the datasource 0CRM_SALES_ACT_1 in CRM .

    Hi all,
    How Delta mechanism works for the datasource 0CRM_SALES_ACT_1 in CRM .
    I mean timestamp, date etc? And how I can check that
    Appreciate u r response.
    Thanks
    Pramod

    Hi,
    in your system, goto rsa1->tools->assign source system id....
    regards
    Siggi
    PS: I strongly recommend to use the search functionality. This has been asked already a few times.

  • Delta mechanism for 0fi_gl_14

    Hi,
    We are using 0fi_gl_14 DS for extracting leading ledger's line item data.
    But when I checked table BWOM2_TIMEST, there is no entry for the above data source.
    Could someone help me understand delta mechanism for 0fi_gl_14?
    Is it not similar to 0fi_gl_4 delta?
    What is the difference between 0fi_gl_4 and 0fi_gl_14?
    Regards,
    Shravani

    Hi,
    Most of the extractors (specially one in question 0FI_GL_14) in FI related extractors work on pull mechanism via Extraction method: F1 (function module (complete interface))
    Extractor: FAGL_GET_SI_DATA
    1. 0FI_GL_14 extractor, considers all data from the tables FAGLFLEXA (or similar customer tables), BKPF, BSEG, and BSEG_ADD. we use this extractor if New GL configuration done in ECC or otherwise 0FI_GL_4 still holds good.
    2.Coming to Delta are picked from BWFI_AEDAT table where all the changed documents/new are maintained as part of changed status.
    Hope i have addressed your question!
    Regds,
    Karunakar P

  • FISL Extraction Delta Mechanism

    Hi Experts,
    Can any one explain the Delta Mechanism in FISL, i mean ver the timestamps are maintained in R/3 side and how to extract the delta record.
    I created FISL DS and loaded the init load successfully all records are successfully loaded. Now i want to pick the delta records. So wht are the steps to go ahead to create the delta environment to pick the delta records.
    If possible plz provide the document about FISL Delta mechanism.
    Thanks in Advance
    Regards
    Ramakrishna Kamurthy

    Hi,
    For FI-SL DELTA MECHANISM please follow this link below:-
    http://help.sap.com/saphelp_nw04/helpdata/en/c9/fe943b2bcbd11ee10000000a114084/frameset.htm
    http://help.sap.com/saphelp_nw2004s/helpdata/en/28/5ccfbb45b01140a3b59298c267604f/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/41/65be27836d300ae10000000a114b54/frameset.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/ee/cd143c5db89b00e10000000a114084/frameset.htm
    Hope this helps you.
    Regards,
    Anand Tej.

  • Delta Mechanism for LO Cockpit

    Hi All,
    Currently I am having an issue with an implementation on Sales Order. As understood from Generic DataSource that is available in transaction code SBIW. We are able to create a datasource with the ability to trace the changes that is occuring in a particular transaction by using either addtive delta or new status for changed record.
    In Data Source, 2LIS_11_VAITM, which is only available in LO Cockpit, is it possible to have the same tracing too? As I know in LO Cockpit, we have the queued delta, direct delta and the unserialized v3 update, but this is not the delta that we would want.
    Really need help urgently on this matter.
    Thanks.

    It works with the Business content datasource (because it is built in the extractor logic), eg 2LIS_11_VAITM.
    This is what is confusing to many people. And it is same as file source system. In the file based DS, you do have an option of specifying whether it is a additive delta (in the datasource editor screen, at least it was till 3.5). This doesn't mean that the file will be read and system will compare from ? PSA or earlier load of the file and determine the delta to be pushed to BW. It means that we are saying that the file already contains delta.
    Same here. When we specify additive delta, we are saying that the table/view already contains additive delta (and not that the generic extractor will apply the logic to derive the delta values for the KF).
    Let us take an example, say you are storing stock market quotes in a spreadsheet or a table, and you want to move it to BW using generic extractor which loads the current prices to an ODS/Cube.
    Let us say the data is like this
    STOCK-ID--CLOSING_PRICE--
    Movement_since_last_price
    NYDE -
         60                         -  -
      3.5
    HWP  -
          125                  -
      -1.25
    and so on.
    Now, if from this table (or file), you push STOCK_ID, and CLOSING_PRICE using your generic extractor, it is a 'new image' and that is what you should specify.
    But, you can also instead push STOCK_ID and 'MOVEMENT' in which case it is an 'additive delta' and you should specify your DS as such.
    If you only had STOCK_ID and MOVEMENT data in your table, your DS would have to be 'additive delta'.
    I hope you understand it now. Your table data determines what delta type the generic DS is, you can not just specify it as you wish.
    Why this setting is there - it tells BW what type of DS it is, so it can warn you if you are trying to load it to incompatible target. For example, if you had a 'new image' type DS, and you tried to load it directly to a cube, the system will give you a warning/error about it being incompatible.

Maybe you are looking for