Why we use crmd_link table ........?

Hi,
I am new bee in CRM. I am doing my first program in crm . Can any one explain me why we use CRMD_LINK table.
Why we pass guid in guid_hi and get guid_set ? what is diffrent between them ?
Help will be rewarded ...
Regards
Gurprit Bhatia

A CRM transaction (e.g. contract) data info is not contained in a single table. We need to use different tables for the same.
guid_hi and guid_set are used for different categories of data like partner info, billing info, etc.
Some numeric ids are there for guid_hi and guid_set
Using help, u can find out which id stands for which category of data.

Similar Messages

Why we use Cluster Tables in SAP Hr

hai friends, i am new to ABAP-HR and SAP HR, Actually i am core abaper ( working on SD, MM and Fi Modules ) , can any one explain me why and what is the use of Cluster tables in SAP HR, why we use in SAP HR function Module ?
Thnx in advance
Vijaya

Hi Vijaya,
This may help for ur question..
Why cluster table:
Cluster tables combine the data from several tables with identical (or almost identical) keys into one physical record on the database.
Data is written to a database in compressed form.
Retrieval of data is very fast if the primary key is known.
Cluster tables are defined in the data dictionary as transparent tables.
External programs can NOT interpret the data in a cluster table.
Special language elements EXPORT TO DATABASE, IMPORT TO DATABASE and DELETE FROM DATABASE are used to process data in the cluster tables.
PCL1 - Database for HR work area; (long text, etc)
PCL2 - Accounting Results (time, travel expense and payroll); (payroll results)
PCL3 - Applicant tracking data;
PCL4 - Documents, Payroll year-end Tax data (change logs, etc)

Why we use PCLn tables only in HR ?

Hii
Kindly explain me why we use special PCLn tables for storing data in data clusters ,This kind of storing data is not used in other modules such as SD MM etc why only in HR module ?
That too in cluster tables we store specific data like Payroll data why ?
Please help.
Thanks
Ajitabh Pradhan

Hi,
maybe ask directly SAP
Cluster table is not really usefull, I prefere transparent table for development. But, you have cluster table like STXL, STXBITMAPS, ... for special requierement.
Why do you want to use cluster tables ?
Rgd
Frédéric

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 frameset? Why not use a table?

Why do we need to use the framesets?
I think that we should use the tables because the framesets
do not show you the border sizes and background colors on the
source (code window). The tables show you everything including the
background color codes so that you would know where to find it on
the source window. Although, a frameset is a big risk.
If you think that I'm wrong, then can you please explain it
to me. I respect your opinion.

"jeffeyer" <[email protected]> wrote in message
news:ectmha$shq$[email protected]..
> Why do we need to use the framesets?
>
> I think that we should use the tables because the
framesets do not show
you
> the border sizes and background colors on the source
(code window). The
tables
> show you everything including the background color codes
so that you would
know
> where to find it on the source window. Although, a
frameset is a big
risk.
>
> If you think that I'm wrong, then can you please explain
it to me. I
respect
> your opinion.
>
You are right. Tables and/or css are preferable to a frames
layout.
Though I can understand why somebody would want to use
frames, certainly if
it is their first time out in web design. I myself was drawn
to the lure of
having that immutable left hand menu frame with my right hand
side being
able to change.
But then I discovered templates and server side includes.

In BAPI's why the structures are used in table parameters?

Hello sir,
what is BAPI sir? In BAPI's why the structures are used in table parameters? table parameters they are using structures but not using any customized tables ?
regards
rachu.

Hello Rachu
BAPIs provide RFC-enabled interfaces to SAP business objects (e.g. like customer, sales order, purchase order, etc.).
A BAPI does basically the same like you would need to do calling the corresponding transaction (e.g. BAPI_SALESORDER_CREATE -> VA01).
Since they are RFC-enabled they can be called from external systems.
BAPIs represent an external interface for the outside world. Very often you will find within the BAPI that there is a mapping done to the (SAP-)internal structures at the beginning of the coding and vice versa at the end of the coding. Thus, you will (almost) never find any DB table name used as type of a BAPI TABLES parameter.
Regards
Uwe

Why we use Tables statement in case of using SELECT-OPTIONS:

hi all,
Why we use Tables statement in case of using the following coding in an ABAP program ...
tables: vbak.
SELECT-OPTIONS: s1 for vbak-vbeln.
here if we dont provide the tables statement why it does not work ????
pls answwer ....???

Hi
This statement is not allowed in classes and declares a data object table_wa as a table work area whose data type is adopted from the identically named structured data type table_wa from the ABAP Dictionary. table_wa must be defined as a flat structure in the ABAP Dictionary. You can specify database tables or Views for table_wa.
Work table areas declared with TABLES are interface work areas and should only be declared in the global declaration section of a program for the following purpose:
reward if usefull
The statement TABLES is required for exchanging data between screen fields that were defined in a program screen when transferring from the ABAP Dictionary and the ABAP program. For the screen event PBO, the content of the table work area is transferred to identically named screen fields; for PAI, the system adopts the data from identically named screen fields.
In executable programs, flat table work areas can be used for adopting data that were provided for the event GET table_wa from a linked logical database. TABLES is synonymous with the statement NODES for this purpose.
Work table areas declared with TABLES behave like the data declared with the addition COMMON PART, meaning the data are used by the programs of a program group.
Table work areas declared with TABLES can be declared in subroutines and
function modules. However, this is not recommended. A table work area declared in a procedure is not local but belongs to the context of a framework program. The table work area can be viewed starting from the declaration in the framework program and lives as long as the framework program. In contrast to normal program-global data, the content of the table work areas declared in subroutines and function modules is stored temporarily when these subroutines and function modules are called. Value assignments that were made during runtime of the procedure are preserved until the procedure is completed. When exiting the procedure, the table work areas are filled with the contents that they contained when the procedure was called. Table work areas declared in procedures behave like global data to which the statement LOCAL is applied in the procedure.
The form TABLES * is obsolete.

Why do we really use External tables in Oracle?

I looking why do we exactly use external tables in oracle and if you can help me please give me a scenario also.

Before External tables (long ago in a galaxy far, far away) we would have had to load the text file into the database, most likely using SQL Loader before we could 'read it'.
External tables allow us to define the text file in the Create table syntax and read that file over and over via SQL from the databse - In summary, I can access that text file (in parallel = fast) without loading it into my database, I just saved a step in my integration. I can also swap the file for a new file (same definition) and auto-magically access by new content.
Here is a good link with a scenario for you :
External Tables: An Introduction – All Things Oracle
Of course with ODI - the complexity of SQL Loader control files is hidden, we just define the text file, use the LKM File to SQL and load it in, but where is the fun in that?
Best check with your Solution Architect about what the best practises are for this in your organization.
Rgrds
Alastair

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***

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

Hi experts why we use set up tables in LO cockpit

please forward to my personal mail id
[email protected]

The logistic cockpit extractors are different from the others. They use setup tables and delta queues for initial loading and delta loading respectively. The delta queues act as a buffer area which is detatched from the business logic of the applications' operations (ref. <a href="/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146 COCKPIT DELTA MECHANISM - Episode one: V3 Update, the serializer</a>).
The other extractors read the application tables directly, both during the initial loading and during the delta loading. This means that whenever BW requests the data, a function module extracts the data from the R/3 tables.
I wonder why there is such a technological difference between the 2 classes of extractors. Could someone please shed some light on this? What considerations may have led to this kind of architectural choice? Is the number of transactions occurring in the applications covered by the LO extractors significantly greater than that occuring in other applications (e.g. FI, CO, etc.)? In this case, the ERP system could certainly benefit from a delta management buffer area.
Thanks&Regards, Davide

Why we use INTO CORRESPONDING FIELDS OF TABLE

why we use INTO CORRESPONDING FIELDS OF TABLE

INTO CORRESPONDING FIELDS OF TABLE is transferring the value from select clause to itab where the field names are same.
suppose you have
data : begin of itab occurs 0,
         matnr like mara-matnr,
         menge like mseg-menge,
        lgort   like mard-lgort,
       end of itab.
select matnr lgort into table from mard where....
it may give an error because you are not filling menge here or it may fetch the value in matnr and menge field.
but if you use INTO CORRESPONDING FIELDS OF TABLE then it will fetch the data to matnr and lgort field only.
INTO CORRESPONDING FIELDS OF TABLE is only matching by name not by datatype be careful.
regards
shiba dutta

Using internal tables in BI 7 Start routines

Hi All
I tried searching for using internal tables in a start routine in BI 7 could not find the right pointers.
This is what I am trying to do is the following:
In a DSO ZSD_O01 I have a sales order and sales order item number and this DSO also contains the Contract number and the contract Item number.
The DSO structure is as follows:
/BIC/AZSD_O0100
DOC_NUMBER
ITEM
CONTRACT
CITEMNUM
I want to read the data in this DSO into a internal table. But the key fields in this DSO is DOC_NUMBER and ITEM so I want to read this data into a internal table only for the first data package into the internal table. Thereafter I want to lookup into the internal table given the doc_number and ITEM to find the CONTRACT and CITEMNUM.
Can any of you kindly show me how to :
- Read data from a DSO into a internal table
- Read the internal table for the first data package
- How do I make the access in the internal table fast when my lookup in the internal table is not on the
DSO key columns but on a different key column
Appreciate your help
Thanks
Karen

Hi Karen ,
It will be helpful if you tell your requirement as the approach you suggested is not looks convincing .May be their is some easy way and we can suggest you better approach
-how to check for source_package = 1
You need to hard code it .
We decide package size at DTP level so you can declare a global variable .let say you have 50000 size of your package then use global variable as counter and read only when record_count is <= 50000 .
-how to declare the internal table so the values in it exists between different data packages
Declare a global table and select data into it .A global table retain data across the packages .
- The key on which I need to lookup in the internal table is not the key fields as in the DSO
Its ok .Let say you are doing lookup on A B and C field of DSO1 and the values may duplicate in your source .then you just need to read the internal table having data from DSO2 with key field A B C .
Better if you set them as semantic keys at DTP level so that all duplicate entries of A B C will appear in same package .
global Declarations
In your start routine you will have this following code :
TYPES:
 tyt_SC_1 TYPE STANDARD TABLE OF tys_SC_1
 WITH NON-UNIQUE DEFAULT KEY.
$$ begin of global - insert your declaration only below this line -
... insert your code here
$$ end of global - insert your declaration only before this line -
One question
Why you want to populate values for 1 source package only not for all ?This will be helpful to understand your requirement and may be we can fulfill it in some other manner .
Regards,
Jaya Tiwari

Import invoices using interface table

Dear all ,
I want to import invoice from legacy system to oracle EBS R12 , and i use interface table to import the invoice.
The problem is when i run Payable open interface import concurrent program to import the invoices , it didn't import any invoices
and the report output didn't show any error or any data according to the invoices.
Report output :
Report Date: 27-JUN-2010 11:25
Page: 1
Payables Open Interface Import Report
Hold Name:
Source Name: Manual Invoice Entry Hold Reason:
Group: GL Date:
Purge: No
Summarize Report N
Report Date: 27-JUN-2010 11:25
Page: 2
Payables Open Interface Import Report
Hold Name:
Source Name: Manual Invoice Entry Hold Reason:
Group: GL Date:
Purge: No
Summarize Report N
So i go to the db and open the interface table and the status was null ,
i dont know why????????

Hi ,
100% org_id problem Please check. Same i faced after i update the org_id it is working fine and showing the output with inovice and rejection details also
Thanks
Venkat

Why we use crmd_link table ........?

Similar Messages

Maybe you are looking for