Why do we use Setup tables in LO

Hi All,
Can any body tell me that Why do we use Setup tables in LO.
Plz reply back me on [email protected]
Regards,
Kiran

Hi Kiran
GO through the following earlier forum
Re: LO Setup tables
Regards
RMK
***Assigning pointz is the only way of saying thanx in SDN***

Similar Messages

Why we use Setup Table.

Hi All,
Can u plz tell me why do we use setup table and what is flow of data from R/3 2 BI?
Please search the forum before posting a thread
Edited by: Pravender on Sep 16, 2010 11:45 AM

Hi Sonal
The kind of exractors largely depends on the application due to the way they were developed
/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/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
Check the above weblogs
Regards
Naveen
PS: Assigning point to the helpful answers is the way of saying thanks in SDN

Why to use setup tables in LO extraction

Hi gurus
please send me answer

Hi,
Think of the SAP application tables as Production system. Now why dont we directly do reporting on these tables or why cant we use these tables instead of ODS as these already have detailed data.
One of the major reasons is performance. If you want to load this data to BW directly with out setup tables, you cannot be sure that you have correct data in the BW system as these tables are changed by the transactions. If you still do not want to use setup tables, you should stop any changes to the tables, which is impossible (will impact the business).
I believe this is why SAP does not allow direct access to application tables and has brought in the concept of setup tables. The setup tables hold the data for us to transfer and any changes in the data records is moved to the delta queue.
Please correct me if I am wrong.
Hope this helps!
Regards,
Maddy

Why we are using cluster tables mainly HR

can any plz tell me why we are using cluster tables mainly HR???

Nice question -
Am making my guess based on whatever little I know;
PCLn are file systems and not a traditional (RDBMS) table system. Each File may contain one or more data clusters. SAP Defines data clusters thus -
A data cluster is a grouping of several data objects. Elementary fields, field strings and internal tables can be grouped in a data cluster.
Example:Clusters B1 and B2 in files PCL1 and PCL2 are relevant to time evaluation, as is cluster PS, which stores the generated schema.
The reason why file system of data storage is used instead of DB Table system may be for the purpose of storing voluminous data (Payroll and time) and ease of retrieval during processing (RDBMS may hv tough time in this). Also probably because of SAP's origin from Mainframe.
Why data clusters are used -? Probably data clusters are an offshoot (or part) of File system
Pls feel free to contradict the above. Actually DB experts can throw more light on this..
Regards
Chandra

Why do we delete setup tables?

Hi Experts,
While doing Standard LO extraction why do we delete setup tables?
Do we delete even for delta loads?
Thanks in advance,
Raj

Hi,
Normally the delta will happen through rsa7 and the full/init load will happen through setup tables.
The setup table deletion is done to avoid any duplicacy in the setup table. Before doing the full/init the data for that particular selection condition is checked in the ssetup table if completely not there the remainint data is deleted from teh SETUP table and again forthat selection parameters statistical run is done to fill in the setup table and then full/init is done to extract the data to BW.
Hope this helps
Assign points if helpful
Janardhan KUmar

Why on earth use nested tables?

Hi
I'm boning up on PL/SQL (again) in anticipation of getting a new job.
I have many years of experience in various data-related roles, many of which used Oracle.
On the issue of collections, I find myself asking, in the light of my experience, and not for the first time, why on earth would anyone want to do this:
create or replace type TEST_TT as table of varchar2(10);
create table TEST_TABLE ( X number
,Y test_tt)
nested table Y store as Y_TABLE; I really, really, can't think why we would want to store data like this. It seems to me to be unnecessarily complex, hiding a one-to-many relationship inside TEST_TABLE, which should instead be modelled and implemented as a separate table.
Furthermore, there are loads of tutorials on collections that tell us how to do the above (indeed I am reading Feuerstein at this very time) but nobody seems to say WHY we should do this.
Can anybody help me here?
Thanks.
Jason

>
I'm boning up on PL/SQL (again) in anticipation of getting a new job.
I have many years of experience in various data-related roles, many of which used Oracle.
On the issue of collections, I find myself asking, in the light of my experience, and not for the first time, why on earth would anyone want to do this:
I really, really, can't think why we would want to store data like this. It seems to me to be unnecessarily complex, hiding a one-to-many relationship inside TEST_TABLE, which should instead be modelled and implemented as a separate table.
Furthermore, there are loads of tutorials on collections that tell us how to do the above (indeed I am reading Feuerstein at this very time) but nobody seems to say WHY we should do this.
>
For As you have surmised, just because you CAN do it doesn't mean you SHOULD do it. If you are only working with your standard relational data, such as the example you provide, it has many drawbacks and few, if any advantages.
It is easier to understand why that capability exists from the viewpoint of the question: why SHOULDN'T you be able to store data like that?
In one sense it is just another object-oriented feature. You can create object types and pass them around to procedure/functions or external processes (e.g. JDBC) so why shouldn't you be able to store that set of related data as an encapsulated object?
Why do you need an object type that has a set of columns? You can just as easily put those columns into a table. But how do you manipulate a subset of the columns or rows of a table? How do you pass that data around as a controlled, coherant set of data? You can't.
With an object type you can, though most often don't, implement encapsulated business rules that ensure that any instance of that type MUST implement. Need ADDRESS information that is required to include a street address, city, state and zip? Create an object type with the right constructor methods and you can ensure that those attributes CANNOT be null.
Once you have functionality to create and manipulate objects why not be able to pass those objects around and stored them in a table? Doesn't mean you should always store them that way but why not be able to? There isn't any reason to limit that functionality simply because you don't think it is the best practice to use it all the time.
So if you have a small dataset and want all of that data to 'travel' together nest it. There is no child table to create or foreign key to create.
I put that functionality in the category of CAN DO but DON'T DO except in rare occasions and consider it a fallout of the move to object-oriented things in general. I like the fact that Oracle makes functionilty like that available when they have it.
Like dynamic sql, materializeds views, bitmap indexes and much other functionality it is often more important to know when NOT to use it than it is to know when to use it.
Relative to 'best practices' of why NOT to do that for your basic relational data see this part of the article that Justin referred you to:
>
Followup March 3, 2003 - 6am Central time zone:
1) they are parent child tables in disguise but ones that add:
a 16 byte raw with a unique constraint on the parent table. Most likely you ALREADY HAVE a primary
key on the parent table and most likely it is smaller.
a 16 byte raw that you need to index on the child (not auto-indexed, you need to know to do it).
This is the foreign key and is hidden from you.
The inability to put many types of constraints on the nested table..
They are simple parent/child tables - except you lose the ability to access the child table
directly.
2) you are NOT storing anything in a "single row". Physically they are a parent child table pair,
nothing more, nothing less
If you have my book "Expert one on one Oracle" - I write about them in there, describe their
implementation and talk about when I would use them.

Why we have setup tables in LO extraction and why not in CO-PA,Generic

Hi Friends
Why we have setup tables in LO extraction and why not in CO-PA,Generic
Please give me reply
****************Points are assured********************
Thanks&Regards
Revathi

Hi Revathi,
Please check the following Threads :
[why set up tables ?;
[Why LO only having Setup tables not Others.......?;
Regards
Hemant Khemani

Setup table in LO

Hi All
Why do we need setup tables in LO? Or What is the purpose of having setup tables in LO extraction?
Regards
Saddy

The purpose of the setup tables is to allow you the capability of loading historical data from R/3 to BW. You can use the setup tables for full loads or for establishing your initialization, but they are used independently of collecting delta data. Thus you can collect historical data for different applications (even different datasources within the same application) without affecting delta's already setup for other datasources.
Hope this helps.

No setup table concept in FI Module.

Hi Guys,
why there is no setup table concept in FI Module.Can any body explain in detail?
Thanks,
chinna
points will be awarded

Hi Chinna,
Go through this previous thread on the same issue
Why at all setup table
I hope this helps u...
Regards,
R.Ravi

Setup table

HI all,
why we dont have setup table for COPA, FI-SL, PS. Any of them can give valid reason

Hi,
Reason is FI/COPA Data sources are Company dependent and need to configure as per company and Organization. But all Logistic Data Sources are suitable for any kind of Company and Organization. And basic all FI/COPA DS's are less number of records if you compare LO DataSources, you you need setup tables for LO DS's.
Data will be fetched from application table to setup tables (In Lo extraction, the extractor won't allow the direct communication with the application tables) from here, data finally reaches the target
Financial Accounting data can be extracted directly from the tables.
Note :Full load: Incase of logistic application, Full/Initialization will extract the data from setup tables (contains only historical data).So if you have decided to go for full load, For full update the data will be taken from setup tables.
Check this link:
Why LO only having Setup tables not Others.......?
Regards
Chandra Sekhar T

2LIS_03_UM - FULL LOAD VIA SETUP TABLE NOT EQUAL TO DELTA

Hello,
I try to load stock data with 2LIS_03_UM.
When I extract data using setup table and full load I don't get the same records as I get with delta load. Although the key figures values are the same, the documents numbers are different. Most documents from delta load are ML (material ledger) documents while documents from full load (via setup table) are mainly FI documents.
What can be the reason? How can I fix it?
Thank you,
Hadar

Hi,
Delta load extracts data from Delta Queue based on your update mode selected in LBWE.
Full Load or Init load extracts data from Setup tables, here if you are extracting data from setup tables ? did you fill the setup tables now or not after deleting the existing data of the setup tables?
are you getting same values when compare to R/3 and BW data for some document numbers?

Why do they use flatfiles ???

Dear Experts....
In real world applications/warehouse....why do ppl use external tables for flat files ?
Is it because the data in flat file changes constantly ????
An reason...??? pls explain ?
rgds
s

Hi
Do you mean why use external table over SQLLoader? Oracle advises external table over SQLLoader, you can later the external table to point to another real file and read from it, you can also have many data files (configure external tables and add many data files) and read in parallel and also there are some cool features such as the pre-processor so you can read from compressed files or whatever (since the preprocessor can do whatever you want).
See the following on using the preprocessor with external tables in OWB 11gR1/10gR2
http://blogs.oracle.com/warehousebuilder/2009/06/file_staging_using_external_table_preprocessor.html
Or the following illustration using 11gR2;
http://blogs.oracle.com/warehousebuilder/2009/10/owb_11gr2_bulk_file_loading_-morefaster_easier.html
Cheers
David

How to prevent record from setup table from deletion if it is used in atabl

i have two table setup table and master table
the setup table contains data from countries and i use this countries in master table
i want to prevenet a user from deleting country if it is used in master table
i know i can do this if i make a foreing key in setup table
but in this cases the exception message are raised from the data base
can i make this from the jdeveloper by asscociation and view object and customise the message that are raised to the user
thanks in advance

The question is why to program this yourself if it's available by the framework?
You can customize the error message raised by the db in the framework (there is a whole chapter in the docs).
Timo

Why we give run name while filling setup tables

Dear Experts!!!
In LO Extraction , while performing setup tables filling, why we have to give some run name like zrun/ ztest ?
cant we do it without giving any run name for filling the setup tables.
Your help will be appreciated.
thanks in advance!!!

Hi Anil,
The run name is the name under which the determined data is saved.
If you restart a run that has been terminated, rather than executing a new run, it will use the data that has already been determined, i.e. the next run will be carried out with the data that was selected up to the specified termination date and time.
Regards,
Mansi

Why we have setup tables in LO extraction and why not in CO-PA,Generic,FI-S

HI Friends
Why we have setup tables in LO extraction and why not in CO-PA,Generic,FI-SL. Please clarify.
Thanks&Regards
Revathi
<removed by moderator>
Edited by: Siegfried Szameitat on Nov 13, 2008 12:07 PM

Hi revathi,
The R/3 database structure for accounting is much more easier than the Logistical structure.
Once you post in a ledger that is done. You can correct, but that give just another posting.
BI can get information direct out of this (relatively) simple database structure.
In LO, you can have an order with multiple deliveries to more than one delivery addresses. And the payer can also be different.
When 1 item (orderline) changes, this can have its reflection on order, supply, delivery, invoice, etc.
Therefore a special record structure is build for Logistical reports.and this structure now is used for BI.
In order to have this special structre filled with your starting position, you must run a set-up. from that moment on R/3 will keep filling this LO-database.
If you wouldn't run the setup. BI would start with data from the moment you start the filling of LO (with the logistica cocpit)
I hope I have been clear.
Udo

Why do we use Setup tables in LO

Similar Messages

Maybe you are looking for