DIFFERENCE

[Former Member]

HI ALL,

what is the difference b/w matster data and transaction data.

[Former Member]

Hi,

Master Data : The data which is updated or stored in the tables rerely. These tables having master data is called as master tables.

Example : MARA - Material master table

Transaction data : This is the data we upadte in a regular basis by refering the master data. The table contains many records corresponding to the master data.

Example : MSEG - daily transactions (Goods transfer data)

Thanks,

Reward If Helpful.

[former_member223537]

Hi Srinivas,

Master data eg. : SAP USer ID & Their Authorization Data, Plant Data, Material Data, Company Code data, Document Type, Country Key, Currency data, Tax data etc.

THis data doesnt change with time. It is usually constant.

Transaction Data : Sales Order, Delivery, Invoice data, Purchase Order Data, Notification Data is transaction data.

This data keeps on changing.

Best regards,

Prashant

[Former Member]

hi srinivas,

Master data: it is not changes all the time.

Ex: customer master which contains cust name, Address etc.,

Transactional data: is which changes frequently.

Ex: item data like items he has purchased, quantity etc..

<b><i>Reward points if useful</i></b>

[Former Member]

Master data: it is data that remains unchanged over a period of time. It contains information that is always needed in the same way. For example, all personal attributes can be stored in various SAP standard infotypes as records with specific validity which are called Master data.

Transaction data:

Data relating to the day-to-day transactions

-

---

karthik

[former_member189059]

lets take an example

you are getting your raw materials from 5 different companies

the details of those companies are your master data

the details of every order sent to them is your transaction data

[Former Member]

hi

Transaction Data

If a planner requests transaction data in change mode the system locks the requested data exclusively for this user. BW-BPS uses the SAP lock server to do this. However it uses it in a particular way so that multidimensional data can also be locked using selection tables. This lock concept will now be explained in more detail.

Locks are created independently of the existing transaction data. The system locks exactly that data that is covered by the selection in the planning package and, where applicable, the planning layout (see below in the section “examples”).

The data that is to be locked is specified in a selection table. The selection table is created from the planning package and, where applicable, from selections from the planning layout. Every characteristic that does not exist in the planning level is therefore locked generically as summarization is performed on this characteristic. The selection table contains selections for the characteristics from the planning level. These are single values or intervals of characteristic values. However the selection cannot be restricted for one characteristic. The following rules apply:

· If variables are contained in the planning level, in the parameter groups of functions or in the planning layout these are replaced when the selection is determined.

Replacing variables always leads to a (potentially empty) quantity of single values or intervals. In Customizing take into account that replacing variables of type hierarchy node, attribute, and authorization can lead to a very large number of characteristic values:

¡ Hierarchy nodes: The system calculates all characteristic values from the leaves of the selected subtree for hierarchy basis characteristic und puts these in the selection.

¡ Attribute: The system reads all characteristic values for attribute selection and puts these in the selection.

¡ Authorization: The system determines the authorized characteristic values. These are included in the selection table individually.

· In manual planning the selection of characteristics in the header area is taken from the planning package. This is also the case for the characteristics in the lead columns, as long as the rows in the lead columns are not defined individually.

For data columns and individually defined rows in the planning layout (and also for comparison rows or columns) the selection comes from the planning layout.

· Key figures that are used in manual planning or in a planning function are also relevant in terms of locking: The key figures are seen as characteristic values for characteristic '_BKENNZAHL'.

Selection tables are stored on the lock server in compressed form. So that an adequate number of users can work in planning the system limits the number of records possible in a compressed selection table. The limit is currently 999.

If a user requests new data in change mode the selections already stored on the lock server are read, decompressed and compared with the new selection. During this process no other user in BW-BPS can request locks for transaction data from the basic planning area in question. To this end, the lock server itself is locked for the basic planning are in question with lock structure 'UPC_YS_LOCK_ENQSERVER' and lock entry 'SEM_BPS_TRANSACTION_DATA'. Transaction data in multi-planning areas is always locked using the basic planning areas.

Exceptions to the Lock Concept

In particular circumstances a scenario may occur where the system cannot lock the requested data. For the user, this means that s/he is not able to edit the data. The system analyzes the causes and produces lock messages accordingly.

Case 1: The data requested for a planning area (planning level, planning package) is already locked by another user.

Proposed solution: To avoid this lock situation, Customizing has to be modeled so that different users work with independent data records. If this is not possible, the user who is waiting can notify the user who has set an exclusive lock for the requested data. As soon as this user leaves the planning transaction the locks will be removed.

Case 2: The requested data is covered by a selection table that already contains more than the highest permitted number of records in its compressed version on the lock server. The requested data cannot be locked for this reason.

Proposed solution: Make sure that the selections, and therefore the selection tables, are simplified.

Case 3: The lock server is currently processing other lock requests for the required planning area and can therefore not answer this new lock request. The system renews the lock request after a certain amount of time (seconds). This lock request may also fail if the lock server is overloaded.

Ensure, using transaction SM12, that a lock 'SEM_BPS_TRANSACTION_DATA' is visible for lock structure 'UPC_YS_LOCK_ENQSERVER'. This situation points to complex Customizing:

· A large number of users are using manual planning or planning functions; the planning functions are being executed online.

· Different data is constantly being selected from the database in change mode, for example, by a large number of planning functions within one planning sequence.

· The individual selections are extremely complex; they contain several hundred or even thousand single values or intervals.

Proposed solution: In most cases it is possible to solve the problem by simplifying Customizing. The following points are important:

· Planning sequences that run for a long time should run in background processing.

· The number of records on the lock server must be kept as low as possible. Ensure that selections are simplified. Use intervals in selections whenever possible. Intervals can be locked exactly so that whole areas can be locked by a few records in the selection.

For more information, see Customizing with Reference to the Locking Concept.

If you cannot avoid these problems despite having checked the Customizing, BW-BPS provides an infrastructure that allows you to determine per planning area those characteristics that are to be consulted when setting locks. Normally just a few characteristics are enough to make different users’ selections disjunctive. In cost center planning this could be the cost center (and the controlling area).

For more information, see SAP Note 635244.

First thing to do is to use transaction RSA3 in SAP R/3 for the data source in question and execute to see if the extractor is working in first place. If you manage to see the output, the error is more in transmission of records.

Second, is to look at the IDOC lists in R/3 ( transaction we07). If there are any application or basis errors, it will be listed as error IDOCs, you can use this to find the error.

Third, execute the extraction using the infopackage and log into R/3 using your normal user id and jump to transaction sm50 or sm51 (depending on no. of servers) and monitor the process for user "aleremote". you will notice the process progress. If the read is very slow, depending on the database there could be number of simple performance enhancers which Basis can help

you with.

Fourth, make sure the network connection between R/3 and BW is OK.

Fifth, if everything is alright and docs arrive in PSA and if it takes long time in PSA, then it is a pure PSA update issue. Have you checked the shortdump overview (ST22 ) or read the system log "SM21" ? This should give you clues.

The application data of a database instance are all the rows of all base tables and all the index entries created for the base tables

Master/transaction (application) data: select this option, for example, if you want to set up a test system from the production client.

Application data depends on customizing data, so it can only exist consistently together with it. Application data is therefore always deleted from the target client, exception for copies with SAP_USER. Application data is generally in tables with delivery class A.

The amount of data and thus the memory required and copy time for productive clients can be considerable. In this case you should not copy application data, you should create the required test data e.g. with CATTs (Computer Aided Test Tool).

Transactional data is changed frequently while Application Data is changed rarely but accessed frequently.

We define Data Class in table properties for different type of data.

Below are different data classes

APPL0 Master data

APPL1 Transaction data

APPL2 Organizational and customizing data ( data which is defined when the system is initialized and then rarely changed )

thanks...

Reward all helpfull answer

Message was edited by:

Velmurugan