Delta postings

Hi all,
What are delta postings/Feeds in FI module.
Thanks
Zaf

Delta postings are those that occur after a point in time. For example each new posting daily would be delta. It is the change. In BW it is the postings that have not yet been pulled into BW.
pls assign points to say thanks.

Similar Messages

Delta from Flexible Planning LIS InfoStructure

Hello experts,
Is it possible to have delta updates for a custom InfoStructure where the updates are from flexible planning?
It appears that delta postings are only generated from the regeneration of the standard update rules and the planning updates do not add values to the delta tables (SXXXBIW1 and SXXXBIW2).
Please confirm if it is possible to get delta from flexible planning and what setup is required if it's possible.
Thanks.

I sent a customer message to SAP and here is the answer from them:
Unfortunately, the functionality you are looking for is not available in the current Plug-in/BW releases. Also, it does not appear that this functionality is currently being developed.
The flexible planning transactions do not utilize the LIS delta tables so the data will not be included in the delta updates.
You may consider extracting the data via a generic extractor to an ODS object or other data target.

Parallel Account SAP Document

Dear Sir,
Can you please forward me any SAP document showing how to configure Parallel Accounting in SAP. We are using SAP ECC6 without activating NEW GL module.
What is the difference in "Complete Posting and Difference Posting" in context of parallel accounting.
Can you please clarify whether we need to activate NEW GL for using Parallel Accounting or the parallel accounting can be used without activating NEW GL module.
Thanks in Advance.

Hi,
Complete Postings versus Difference Postings
Postings that differ depending on the accounting principle applied can be posted either as a difference posting for the posting in the general ledger (as a delta posting) or as a complete posting. Only the application component Asset Accounting (FI-AA) supports delta postings.
SAP recommends implementing the delta method for postings from Asset Accounting because, for complete postings, you have to subsequently filter out the valuations of valuation area 01 from the additional ledger
In the new General Ledger, you can display the parallel accounting using parallel accounts (as in R/3) or using parallel ledgers. The FI standard functions and reports are available for all parallel ledgers.
regadrs,
Santosh kumar

Revaluation material using Alternative valuation run

Hi friends!!
My question is the next:
I´m want to use the Aternative valuation Run to do a Revaluation of consumption of several periods.
The issue is that I can´t find the option "Revaluate material" in the Costing cockpit of the Alternative valuation Run.
Do you must run the "Costing Cockpit: Actual Costing·" for each month to do the revalutate of ending inventory with the PIP??.
I would like to revaluate the ending stock with the Periodic internal price using the Alternative valuation run if this colud be possible..
Thanks!!!
Best Regards!!
Manuel

Hi Manuel,
It depends how you want to use the AVR.
The 'Determine Delta Postings' and 'Post Closing' steps are optional
steps. They are only displayed if the AVR run is defined as a 'posting run' in the settings of the AVR.
SAP recommends to run the post closing with the periodic actual costing and post a delta with the AVR functionality.
This delta is AVR actual price - periodic actual price.
The system post the revaluation amount to the material BSX account and the delta posting calculated by the AVR to
the BSD account.
A different option would be to carry out a total post closing only via AVR according to note   633010. In this case,
the system doesn't revaluate materials with the new actual price but post the total revaluation to a LKW account.
In this case the periodic costing run can never be used. For this new posting logic you should use the parameter
AVR_POSTING_NO_DELTA in the CKMLMVADMIN table.
I hope the explanation helps to clarify the problem.
Kind regards,
MLM
p.s. If you are satisfied with the help please pariticipate in our forum giving points!

Problem when loading from ODS to the CUBE

Hi Experts,
I am facing an unusual problem when loading data from ODS to the cube.
I have a first level ODS where the delta postings are updated. I have checked the active table of the ODS and the data is accurate.
I have deleted the entire data from the Cube and trying to do a full load from ODS to the CUBE.
I am sure when I run a full load the data goes from Active table of the ODS.
After the full load the the keyfigure values are 0. I have tried doing the testing by loading couple of sales documents and still the keyfigure values are 0.
I wonder when I load the full. The data should be picked exactly the way it is in active table of the ODS.
I also dont have any fancy routines in the update rules.
Please help me in this regard.
Regards
Raghu

Hi,
Check the procedure did u do that exactly or not. just follow the the laymen steps here:... and let me know ur issue
o     First prepare a flat file in Microsoft excel sheet for master data and transaction data and save it in .CSV format and close it.
o     First select info objects option and create info area then create info object catalog then char, & key figure. Then create id in Char, Name as attribute activate it then in key figures create no and activate it.
o     In info sources create application component then create info source with direct update for master data and flexible update for transaction data. The flat files would be created for master data create info package and execute it.
o     For transaction data go to info provider then select the file right click on it then select option create ODS object. Then a new screen opens give the name of the ODS and create other screen opens then drag character to key fields.
o     Activate it then update rules it will give error to it then go to communication structure and give 0Record mode then activate it then go to update rules it will activate it.
o     Then go to info source then create info package then external data then processing update, Data targets then the scheduling then click start then the monitor.
o     Then other screen opens there we can see if we doesnt able to see the records then come back to the info provider right click on it then other screen opens then select the option activate data in ODS then a screen opens.
o     so select the option QM where it would be in a yellow co lour then by double click then another screen opens then select green color option then click continue it and it comes to the previous screen then select the option and click save it would be underneath of it just click it up and close it.
o     Then come back to the main screen to the info source to the info package go to the package and right click on it then a screen opens then click schedule without distributing any of the tab directly click the monitor tab. Then refresh it until the records come to the green.
o     Once it is green the click the data target and see the file executed.
o     Now go to the info provider then a right click on the file name then create info cube. Then a new screen opens and gives the name and activates it. The drag the key figures to the other side, time characteristics to the other side, and chacetristics to the other side.
o     Then create the dimension table then assign it and activate it .Then go to file name right click on it then select the option create update rules select ODS option and give the file name and activate it .
o     Then come back to the main screen and refresh it. Whenever you see 8 file names you will know that it is undergoing the data mart concept.
o     In the main screen click ODS file right click then a pop up screen opens select the option update ODS data target. Then another screen opens in that we are able to see 2 options full update, initial update then select initial update.
o     Then another screen opens info Package there the external data , data targets , scheduler select the option later in background option then a another screen opens just click immediate then click save automatically it closes then click start option.
o     Then select monitor option then the contents then the field to be elected then the file to be executed.
regards
ashwin

Reinit steps

Hi Experts,
When i do a reinit, in LBWE b4 initialisation what update should I check for job control,?
and also
after init and b4 doing delta what update method shld i select?/
Thanks
DV

Hi DV
You don't need to change update modes at every stage. Please select the approriate update mode before you load the delta postings.
Read following
This is where you specify the type of update used to update the data in delta postings :-
a) Serialized V3 Update
This is the conventional update method in which the document data is collected in the sequence of attachment and transferred to BW by batch job.
The sequence of the transfer does not always match the sequence in which the data was created.
b) Direct Delta
This is where the extraction data is transferred directly from the document postings to the BW delta queue.
The data is transferred in the order in which was created.
c) Queued Delta
In this mode, extraction data is collected from document postings in an extraction queue from which the data is transferred into the BW delta queue using a periodic collective run.
The transfer sequence is the same as the sequence in which the data was created.
d) Unserialized V3 Update
This method is largely identical to the serialized V3 update. The difference lies in the fact that the sequence of document data in the BW delta queue does not have to agree with the posting sequence. We therefore recommend this method only when the sequence that data is transferred into BW does not matter (due to the design of the data targets in BW).
Most commonly used update mode is Queued delta also supported by it's advantages.
Regards
Pradip

Upgradition issue

Hello All,
Could you please any one give me solution for this.
One of our upgrade consultants asked whether our R/3 system uses a periodic process to enter updates into the delta queue, or whether updates are enqueued as they are committed. Do you know the answer to that? Do you know how to determine the answer?
The point of the question relates to situations like the upgrade and support packs where we lock out users to prevent data updates while we're upgrading the system. How long do we have to wait before we run the delta updates if we don't want to miss any data updates?
Thanks In advance,
Reddy.

Hi,
How long do we have to wait before we run the delta updates if we don't want to miss any data updates?
After locking all the users you can start extracting delta data,best way is shutdown system once after locking all users and then pull delta since there may be posting happens with background users using programs.
For LO Data sources you can clear the entire delta postings after locking all the users within few minutes( Based on the number of applications you have used).
For FI and CO, You will be having a safety period of 1 day and for custom data sources it will work based on the time limit u mentioned .
After Upgrade of R3 system, you just carryout the delta extraction as a normal processs, You need to replicate and activate the transfer rules in BI system and then do the delta loading,
This will work fine if your upgraded system uses same logical system name and copied with all the contents of old system.
Otherwise you you will loose data for FI, CO data sources max of one day and You have to recover the same.
Regards,
Rangz
Edited by: Ranganath Kodiugane on Mar 30, 2009 3:20 PM

Postings in SAP HR for creating delta records for Time Management

Hi Experts,
I am trying to test delta load for SAP HR Time Management Datasources. I am fairly new to SAP HR and need some help.
Where do we create postings in SAP HR for creating delta records which can be imported to BW. This is for the data sources 0HR_PT_1 and 0HR_PT_2.
Any help is appreciated. Will assign full points
Regards
Sunil Kumar.

Hi,
In order to test the above data sources you need to have some employee enter his time details or change the entered time details. That will create some delta records for the planned or actual times. CAT2 transaction should help entering the time details in SAP.
Hope it helps.

K7N2 Delta L Won't Post

Specs:
MB - K7N2 Delta L FSB 400
CPU - AMD Athalon XP 2800+
Video - GeForce 2 MX400 (PCI)
Hard Drive - (When attached) Maxtor 160GB 7200RPM 8MB Cache
RAM - Kingston 256 MB DDR400 CL2.5 (KVR400X644C25/256
PSU - AXIO 480W
3.3V - 28A
+5V - 37A
12V - 21A
-5V - 0.3A
-12V - 0.8A
+5VSB - 2.0A
D-Brackett Lights are 1-Red 2-Red 3-Green 4-Green (Processor Damaged or Not Installed Properly).
I installed the Processor onto a MSI KT4AV (Everything Else same specs) and it booted and ran the OS and several apps without a problem. I re-seated it on the K7N2 Board several times without getting past this error on the D-Bracket.
I have read several of the postings and have checked, and re-checked for possible shorts on the MB. I even removed the brass Mounting screws and replaced them with plastic.
I have also checked (and tried changing) the J10 and J11 Jumpers.
All Peripherals have been removed except for the RAM, Video and D-Brackett. And I still am not even POSTing. I have tried booting without a Video card installed as well (still same error message on the D-Bracket).
My Question:
Can you tell me anything else to try before I RMA this MB?
Thanks,
IBskweak

Bonz,
Thanks for the quick response.
I went and tracked down the following RAM this morning to try:
Mushkin 2x256MB PC3200 Level II Black Line
Corsair 1x512MB PC3200 CL2.5 -L FSB @444MHz 8-2-2-2.5 @ 2.7MHz
Crucial 2x256MB PC3200 HiPerf -ILSR w/IGP 1:1 DC 5-2-2-2
Even after trying each set I got the same results as before.
Still won't even POST. Same results as original message
Unless someone else has a good idea, I'm going to RMA the two MBs that I purchased.
-IBskweak

Delta Records not coming from sm13 to rsa7

Hi,
We have found that for the application 02, delta records are coming in RSA7(delta queue) even if these are coming in sm13.
It appears that some protocol responsible for bringing the delta records from sm13 to rsa7 is failed.
Fact is that for the data sources related to application 02 (purchasing: LO Cockpit), we did some enhancements through LBWE.
But before transporting the relavant requests to production, we did not delete sm13 and rsa7 entries and also at the time of transpoting the requests in production, postings were made by several users and the entries for those were appearing in sm13.
Thing to notice is that whatever fields were shifted in LBWE, those changes have successfully appeared in production after transporting ( LBWE and relavant Extract Structure in Production are containing the required changes)
Now each time to load the data in BW, we have to delete and refill the set up tables and schedule full update which is taking a lot of time and not advisable.
Each time when we are running job control in LBWE, it is throwing dump in ST22 with the heading CONNE_IMPORT_WRONG_STRUCTURE.
It appears that some internal problem has occured in the structure of rsa7/sm13 for application 02.
Also it is written in the dump that:--
When attempting to import data, the structure of the complex object
"MC02M_0ITM_TAB"
was not compatible with the target object. The error occurred with
component no. 24.
Try to find out why the structure of the object is unsuitable.
There are several possible reasons:
|
--- In the ABAP Dictionary, the structure of the imported
|   object has changed. Make sure that the structure of the imported
|   object matches that of the Dictionary structure.
|
|   If the data could not be restored from another source, this data
|   must be read with the "old" structure, then converted and exported
|   back with the new structure, so that future IMPORTs always work
|   with the new structure.
|
--- A new program version is active, and it no longer matches the
    dataset. Try to solve the error by generating the program "SAPLMCEX" again
    as follows:
    In the SAP System, choose the transaction SE38. Enter the program
    name "SAPLMCEX". Then choose the "Activate" function.
Now how to make the things back on track so that delta records come in rsa7 from sm13 so that we schedule delta update in info package.
Is there any OSS Note or Standard SAP Report which we have to run for getting the solution.
If not, please suggest the solution.
Thanks in advance,
Tarun Brijwani.

Hi,
1. Check whether your Extractor will support Early Delta Inti or not..
See this link for Early Delta Initia...
http://help.sap.com/saphelp_nw04s/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm
Minimize downtime for delta intia..
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d51aa90-0201-0010-749e-d6b993c7a0d6
Perform this activity on Weekends,
Also see 436393 - Performance improvement for filling the setup tables
Note 753654 - How can downtime be reduced for setup table update
2. Obviously Background job.
BG jobs can be monitored thru SM37 and maintain Logs thru SM21 and can be easier for administration
Thanks

Delta issue on a Generic Datasource

Hi
   I had a Generic Datasource on a Z table.
   The Z table had a Date field on which Delta is based.The Postings are performed manually.
How to solve the delta issue in the below scenario.
Ex; A user made a manual posting with a date 09AUG2010 today and delta is extracted to BW.
    But tommorow a used made another posting with a date 14JULY2010....
Currently that record is not being extracted....how can i resolve this
Thanks

Hi,
Once the data source is created you will extract the data till that date and as the delta is set it will fetch the newly updated records .But i dont think one can post with the back dates in R/3 side.
If i'm not wrong if you are asking regarding record got missed out them wht need to be done?
Then do the repair full request and pull the missed delta records and it wont effect the delta settings.
Regards
KP

Emptying Delta queues before filling a setup table

How do I empty the delta queues? I want to carry out this task just prior to filling a setup table. Thanks

Hi Sekhar,
Thanks for that, I was on a flight anyway, just got home. I was thinking on the plane about the previous point that you mentioned wrt the collection run. I think I understand the point that you were trying to make is this a correct understanding
1) System is locked
2) Do a collection run - the reason for this is that there may be postings which have not been placed on the RSA7 queue since the last collection run
3) Do Delta load twice
Does that make sense. The points that you have raised otherwise, I will post a question otherwise on the steps I will look to take just to get confirmation I am not missing anything

Direct Delta behaviour in a BI 7.0 Upgrade

Hi all,
We are in an BI Upgrade process and a doubt raises regarding DIRECT delta.
Scenario:
The BW 3.1 will upgrade to BI 7.0 but the R/3 4.7 will remain the same.
There are some r/3 logistics extractors with DIRECT delta enabled.
Considering the Upgrade best practices is recommended to stop the V3 process in r/3 side, but the Direct Delta has no V3 process, so, which are the reccomendations for upgrade process considering DIRECT-DELTA ?
Can R/3 Direct-delta remain active during the BI Upgrade or should we stop the current delta and re-initialize 'without any data' after upgrade ?
Best Regards,
Mauro.

Kedar,
Most of the cases, the BI Upgrade process takes from 2 to 4 days, so is very difficult to keep the productive r/3 system sttoped for the logistic processes.
Our plan is :
     1) block the users in r/3 side until the delta queue has been emptied.
     2) load from r/3 to BW all Delta data from delta queue.
     3) make sure all delta load were made and the QM status are green in the BW side.
     4) unblock the users in r/3 side after the step 3. (Delta queue is free to new postings)
     5) initialize the PREPARE phase for BI migration.
     6) Execute the Upgrade
     7) Restablish the r/3 source system
     8) Execute the delta loads from r/3 (to obtain the delta data since step 4)
Do you think that will it work ?
Regards,
Mauro.

Delta drain in R/3 for FI data sources

Hi Experts,
As part of EHP4 upgrade on the R/3 side we need to drain the delta queue in R/3.
We took the downtime in R/3 and
I triggered the delta infopackages for 0fi_gl_4, 0fi_gl_6, 0fi_aa_12, 0fi_ar_4 for 5 iterations.
Please clarify the following doubts:
1. For all the iterations I got the same number of records.
Can anyone please clarify why it fetched same no of records each time .
2. Against these data sources in RSA7, the count is not becoming '0'. As I remember it is showing 2 or 3 even after each iteration.
Please explain why these data sources are not showing '0' even after a couple of iteratioins.
Note: Postings are blocked at this time.
Need ur inputs here.
Regards,
Naveen V.

Hi,
Regarding 1, I think in system settings are done for FI datasources where it will fetch data from system time 2:00 am for each delta. This way same records are fetched again and again for whole day. You can confirm this by looking at your data in PSA.
http://help.sap.com/saphelp_nw04/helpdata/en/41/4b73415fb9157de10000000a155106/content.htm
Regarding 2, Im afraid RSA7 baffles me too. I have read that for some datasources it isnt records but LUWs that are shown. In any case if postings are stopped, then it shouldnt have created LUWs.
Edited by: Parth Kulkarni on May 3, 2011 11:47 AM

Early Delta Initialization option in Production system

Hi Experts,
I have seen some threads related to Early Delta initialization in this forum. I have a question regarding this option.
To minimize the downtime/block users in the R/3 production system during set up tables fillup I would like to use the Early delta option. Please give your suggestions on the following procedure:
For Sales Orders, billing and Deliveries
1. Initialize Early delta in the BI system.
2. Go and fill setup tables
3. Do a full load to BI
4. Run delta job in R/3 (LBWE)
5. Run delta job in BI Info package
Do we miss any documents in this process for e.g. during set up tables fill up changes to existing documents or newly created sales orders.
I feel we won't miss. All changes will be reflected in Delta queue. And even newly created orders also will be coming to delta queue.
Please let me know if I am wrong.
Thank you.

Need Clarification on this thread,
According to my understanding, during the filling of set up table if a user does any posting, then the data available in BW will be incorrect.
am i right?
In your sequence the 4th step
4. Run delta job in R/3 (LBWE), this means you are using queued or unseriallized v3 update.
Early delta iniliazation essentially of no advantage because, as conventional initialization procedures, you can readmit document
postings after successfully filling the setup tables.
can anybody clear my doubt. is it possible during setup table filling user can post a document.
I know the documents will be collected in the queue. But the data loaded to bw will be incorrect right?
Regards,
Anand.
Edited by: araj123 on May 26, 2010 11:41 AM

Delta postings

Similar Messages

Maybe you are looking for