1. Dialog transaction : These are the most common kind of transactions.

 The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called,

 the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than

 a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called.

 The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program

2. Report transaction
A report transaction is the transaction code wrapping for starting the reporting process.

The transaction code of a report transaction must be linked with the selection screen of an executable program.

 When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT

 more to come on that.

3. OO transaction
A new kind of transaction as of release 6.10.

The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called,

 the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.

4. Variant transaction
In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant.

 When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant.

 In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction,

 change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.

5. Parameter transaction
In the definition of a parameter transaction code, a dialog transaction is linked with parameters.

 When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.

https://forums.sdn.sap.com/message.jspa?messageID=8038775

Wow Bravo ~!!  정답이십니다 .

좋은 내용이네요.. ㅋㅋ 영어실력 뽀록나겠네용..

ㅁ 트랜잭션유형: 다이얼로그 트랜잭션
In a dialog transaction, the program flow is determined by the sequence of screens. The screens that you call within a transaction are all part of a shared module pool (program with type 'M').

You must specify the initial screen of the transaction when you define a transaction code.

ㅁ 트랜잭션유형: 레포트트랜잭션
In a report transaction, you start a program with type 1 using a transaction code. A report usually receives data at the beginning (using a selection screen), processes it (for example, using a logical database), and then outputs data (a list).

When you define the transaction code, you can specify a selection screen and a report variant.

ㅁ 트랜잭션유형: 오브젝트 트랜잭션
Starts a method of a class using a transaction code

ㅁ 트랜잭션유형: 변형트랜잭션
In the SAP Reference IMG, under "Basis Components" -> "Application Personalizaion" -> "Tailoring of Application Transactions",  you can define transaction variants. These allow you to preassign values to fields within a transaction, define field attributes, or hide entire screens.

To run a transaction variant, you define a variant transaction. On the next screen, enter the name of the transaction and the name of the variant.

Note

Variant transactions are client-specific.

If you try to start a variant transaction and the corresponding variant does not exist, the transaction runs without a variant.

ㅁ 트랜잭션유형: 매개변수트랜잭션
Parameter transactions allow you to preassign values to the fields on the initial screen.

If you supply all of the necessary entries for the initial screen in this way, you can suppress the screen when the transaction is executed.

(F1 Tech. Help)

간단하게.... 보자면...

1. program and screen ( dialog transaction ) -> 모듈풀 프로그램 티코드 생성용

2. program and selection screen ( report transaction ) -> 리포트타입 프로그램 티코드 생성용

3. method of a class ( OO transaction ) -> 아밥 오브젝트용 티코드 생성용

4. Transaction with variant ( variant transaction ) -> 변형을 이용해서 화면 필드 숨기거나 초기값지정해서 호출하는 개인화용 티코드 생성용

5. Transaction with parameters( parameter transaction ) -> 유지보수뷰나, 일반 프로그램이더라도 파라메터를 입력한 상태로 호출할때 쓰는 티코드 생성용;;;

도움이 될지 모르겠네요;;

Risky 님 설명과 카루이안님 설명이 좀 다른 것 같네요. 카루이안님의 1번 같은 경우의 모듈풀 프로그램은 협의의 의미로

보여집니다. 이유는 Risky님 설명대로라고 하면 프로그램에 dynpro(즉, modal process 를 따르는 flow logic 이 있는)가 있으면 어떤

유형의 프로그램이든지( type 1 - 일반적으로 report program, 또는 Module-pool, function-pool 등등) 메인프로그램과

화면이 있으면 1 번유형의 t-code를 만들 수 있습니다. 그게 좀 다른 것 같네요. ^^

생유yo