'Inforamtion Technology'에 해당되는 글 281건

ERP란 이미 개발되어진 프로그램을 각 회사에 맞게 Customizing하는 형태로 Project이 진행된다.

따라서 개발 시스템에서 각 회사의 특성에 맞게 Parameter값을 설정한 후 기능 테스트를 한다.

테스트 후 문제가 없을 경우 개발시스템에 설정한 Parameter값을 다시 영시스템에 설정하는 것이 아니라 개발시스템의 값을 운영에 넘겨야 한다.

이때 이러한 기능을 담당하는 것이 CTS(Change request Transport management System)이다.

SAP시스템에서 각 Parameter를 설정을 할 경우 아래와 같이 Change request 번호가 부여된다.

다음 "STMS" 화면에서 운영시스템으로 직접 전송을 하면 각 Parameter값이 반영이 된다.

[출처] CTS 절차|작성자 늦깍이

MRP를 간단하게 정리해보았습니다. 혹시 잘 못된 점이 있으면 리플 달아주세요.^^

** 각 업무별 사용 Table 내역

1. 자재마스타 관리 Table
- MARA Material Master: General Data
- MARC Material Master: 자재에 대한 플랜트데이타
- MARD Material Master: Storage Location/Batch Segment
- MAKT Material Descriptions
- MBEW Material Valuation
- MVKE Material Master: Sales Data
- MARC_WERK
- T132 Status definition
- MBEWH 기초재고관리 TABLE
- MARM 자재별 단위 conversion rule

2. BOM 관리 Table
- MAST : Material to BOM Link
- STKO : BOM Header
- STPO : BOM Item
- STPU : BOM Sub-Item
- STAS : BOMs - Item Selection

3. INFO Record 관리 Table
- A018 Material Info Record
- EINA Purchasing Info Record - General Data
- EINE Purchasing Info Record - Purchasing Organization Data
- KONH Conditions (Header)
- KONP Conditions (Item)

4. Quota Arrangement 관리 Table
- EQUK Quota File - Header
- EQUP Quota File - Item

5. Source List 관리 Table
- EORD Purchasing Source List

6. Vendor Master 관리 Table
- LFA1 Vendor master (general section)
- LFB1 Vendor master (company code)
- LFBK Vendor master (bank details)
- LFM1 Vendor master record purchasing organization data

7. Inspection Plan 관리 Table
- MAPL Allocation of task lists to materials
- PLKO Task list - header
- PLMK Inspection characteristic
- PLMW MAPL-dependent characteristic values (inspection plan)
- PLPO Task list - operation/activity

8. Customer Master 관리 Table
- KNA1 General Data in Customer Master

9. Quality Management 관리 Table
- MAPL Allocation of task lists to materials
- QDQL Quality level
- QALS Inspection lot record
- QAMR Characteristic results during inspection processing
- QAMV Characteristic specifications for inspection processing
- QAVE Inspection processing: Usage decision
- QMAT Inspection type - material parameters

10. Kanban Master 관리 Table
- PKHD Control cycle header

11. Purchase Requisition 관리 Table
- EBAN Purchase Requisition
- EINA Purchasing Info Record - General Data
- EINE Purchasing Info Record - Purchasing Organization Data
- LFM1 Vendor master record purchasing organization data
- T001K Valuation area
- T001W Plants/Locations
- T024E Purchasing Organizations
- T160 SAP Transaction Control, Purchasing
- T161A Linkage of Requisition Doc. Type to Purchasing Document Type
- T161W Order Types for Stock Transfer

12. Purchase Document 관리 Table
- EKKO Purchasing Document(RFQ,CONTRACT,PO) Header
- EKPO Purchasing Document(RFQ,CONTRACT,PO) Item
- EKET Delivery Schedules
- EKBE History of Purchasing Document
- EKKN 계정지정 구매문서 관련 테이블

13. Sales Order 관리 Table
- KNA1 General Data in Customer Master
- VBAK Sales Document: Header Data
- VBAP Sales Document: Item Data
- VBEP Sales Document: Schedule Line Data

14. SOP (Sales & Operation Planning) 관리 Table
- S076 Sales & Operations Planning
- S076E S076 - Structural Information
- SAUF SOP Orders
- P445G Parameters for PLOB Version_Key Figure
- P445X LIS Planning Versions Table
- P44V Planning Versions

15. Demand Management 관리 Table
- PBIM Independent requirements for material
- PBED Independent requirements data
- PBHI Independent requirements history

16. Work Center 관리 Table
- CRHD Work Center Header
- CRCO Assignment of Work Center to Cost Center
- KAKO Capacity Header Segment
- TC31A Key for performance efficiency rate

17. Cost Center 관리 Table
- CSKS Cost center master
- CRCO Assignment of Work Center to Cost Center

18. Routings 관리 Table
- MAPL Allocation of task lists to materials
- PLAS Task list - selection of operations/activities
- PLKO Task list - header
- PLPO Task list - operation/activity

19. Complete Confirmation 관리 Table
- AFRU Order completion confirmations

20. Planned Order 관리 Table
- PLAF Planned order
- MKAL Production Versions of Material

21. Production Order 관리 Table
- AFKO Order header data PP orders
- AUFK Order master data
- AFPO Order item
- AFVV DB structure of the quantities/dates/values in the operation
- AFVC Operation within an order
- AFRU 확정번호를 키로 해서 액티비티 값을 가지고 있는 테이블

22. CRP (Capacity Requirement Planning) 관리 Table
- KAKO Capacity Header Segment
- KBKO Header record for capacity requirements
- KBED Capacity requirements records

23. Reservation 관리 Table
- RKPF 예약문서:헤더
- RESB Reservation/dependent requirements
- JEST Object status

24. 구매조직 관리 Table
- T024 Purchasing Groups
- T024D MRP

25. Storage Loc. 관리 Table
- T001L Storage Locations

26. 화폐단위 관리 Table
- TCURX Decimal places in currencies
- TCURR Currency exchange rates

27. Goods Receipt/Issue 관리 Table
- MKPF Header: Material Document
- MSEG Document Segment: Material
- MSLB Special Stocks with Vendor
- S031 기간(월..)별 입출고 합계수량/금액
- S032 재고이동이나 송장검증 또는 자재금액변경 등의 transaction이 발생할 때

이 정보구조에 반영.기간이 없다.
- S033 일 기준으로 재고이동이나 송장검증, 자재금액변경 등의 transaction이 발생할 때

이 정보구조에 반영. transaction 개개별로 update가 된다.

28. Message관리 Table
- T100 Messages

29. Plant 관리 Table
- T001 Company Codes
- T001W Plants/Locations
- T001L Locations정보

30. User 관리 Table
- USR01 User master record (run-time data)
- USR02 Logon data
- USR03 User address data
- USR04 User master authorizations
- USR05 User Master Parameter ID

31. SAP R/3 프로그램 관리 Table (SAP & CBO)
- DD02V Generated table for view DD02V
- TRDIR System table TRDIR

32. SAP R/3 테이블 관리 Table (SAP & CBO)
- DD02L SAP tables
- DD02T R/3-DD: SAP Table Texts
- DD02V Generated table for view DD02V
- TADIR Catalog of R/3 Repository objects

33. MRP 관련 Table
- MKPF Header: Material Document
- MDSM Simulative dependent requirements
- MDTB MRP table
- MDVM Entry in MRP File
- MDKP Header data for MRP document

34. Vendor Evaluation관련 Table
- ELBK 가중키,Overall score(업체별)
- ELBP scores for main/subcriteria(업체별)
- S013 업체평가관련 통계테이블(업체-자재별)
- T147K customizing의 채점방법관련 테이블

35. Invoice Verification관련 Table
- RBKP Header 관련
- RSEG Item 관련
- BKPF 회계전표:Header 관련
- BSEG 회계전표:Item 관련

36. Batch관련 테이블
- MCHA Batch
- MCH1 Batch (플랜트간 Batch 관리일 경우)
- MCHB Batch재고
- MCHBH Batch 재고: 이력

36. Archive관련 테이블
- ADMI_RUN Object name : MM-EBAN(for Purchase Requisitions)
MM-EKKO(for Purchasing Documents)

37. Classification관련 테이블
- ZSD001V object별 특성값

38. AUTOPOSTING관련 테이블
- T030

39. 세금관련 테이블
- BSET
- T007S 코드와 내역

40. 이동유형(Customizing) 관련 테이블
- t156 이동유형관련 Customizing 테이블

41. 업체주소관리 테이블
- ADRC 업체명,주소,전화번호 관리 테이블
벤더마스타와 구매문서의 ADRNR필드와 ADRC-ADDRNUMBER가 키로 되어 있음.

MRP(Material Requirement Planning)는 우리 말로 '자재소요계획'이라고 불립니다.
MRP는 최종 제품(Final Product 또는 End Product)이 필요한 시점으로부터 해당 제품의 제조 또는 조립에 필요한 하위 부품들이 필요한 시점을 역으로 계산해내는 시스템 또는 방법을 가리키는 말입니다. MRP의 계산 로직에 대해서는 이후에 자세히 설명드릴 것입니다. 그에 앞서, MRP가 생산 관리 시스템 중에서 어떠한 위치에 있는지(어떠한 역할을 하는지) 살펴보도록 하겠습니다.


[그림 2.1] 생산계획 및 통제의 기본 구조
위의 그림은 생산계획 및 통제의 기본 구조를 나타낸 것입니다. 위의 그림은 어떠한 기업이 제품을 만들게 되기까지의 과정 중에서 생산 관리와 밀접한 관련을 가지고 있는 부분의 흐름을 도시화한 것입니다. 위의 그림에는 수요예측, 생산계획, 기준생산계획, 자재소요계획, 현장관리, 구매와 같은 기능 또는 업무들과 MRP의 기준 정보라고 불리우는 자재구조명세서(BOM), MPS/MRP 레코드, 자재명세서(Item Master), 재고 레코드 등이 있습니다. 각각의 기능 또는 정보에 대해서는 추가로 설명하도록 하겠습니다. 먼저, 간략하게라도 흐름을 파악하는 것이 필요하다고 생각되기에, 위의 그림을 기준으로 생산 계획의 흐름에 관한 설명을 드리도록 하겠습니다.

생산계획 및 통제의 구조를 간략하게 살펴보도록 하겠습니다.

1) 기업에서는 어떠한 제품이 기간별로 얼마만큼이나 팔릴 것인지를 예측한 자료를 활용하여 생산계획(Production Plan)을 수립하게 됩니다. 생산 계획 단계에서는 제품 단위의 계획을 수립하기도 하지만, Make-to-Stock 환경하의 기업에서는 대개 제품군 단위(Product Family 또는 Product Group)로 생산계획을 수립하는 것이 일반적입니다. 생산 계획 활동에서는 생산 용량( 기계 용량, 인력 )의 조정까지를 계획 범위에 포함시키는 것이 상례입니다.

2) 생산 계획에 기준하여 제품의 주(week)별 생산 계획량을 수립하는 활동이 기준계획수립(Master Production Scheduling)입니다. 기준 계획을 수립하기 위해서는 제품별 수요예측치와 현 재고량에 대한 데이터가 필요합니다. 기준 계획은 일반적으로 최종 제품(End Item 또는 Final Product)을 대상으로 수립되지만, 필요에 따라 중간 제품(sub-assembly 또는 component)을 계획의 대상에 포함시키기도 합니다.

3) MPS(Master Production Schedule)는 최종 제품에 대한 생산 계획(재고 계획)이기 때문에, 제품을 구성하는 부품 단위의 생산 계획(또는 재고 계획 수립)이 필요하게 됩니다. 제품을 구성하는 제품(부품)의 종류 및 그 수량에 대한 정보를 가지고 있는 BOM(Bill of Material) 데이터, 제품(부품)별 주문 방법 및 주문량에 대한 정보를 가지고 있는 Item Master Data, 각 부품 및 제품별 재고에 대한 정보를 가지고 있는 재고 데이터(Inventory Record) 를 이용하여 각 부품별 소요량을 시점별로 계산할 수 있으며, 이 결과는 MRP 레코드에 저장됩니다.

4) 이제 각 부품별로 어느 시점에 얼마만큼 필요한 지가 계산되었습니다. 기업에서는 이러한 계획치 중에서 가까운 장래의 계획을 고정(Firm Planned)시킨 후에, 제조가 필요한 부품에 대해서는 제조 명령(Production Order)를 내리고, 구매가 필요한 부품에 대해서는 구매 명령(Purchase Order)를 생성하여 처리하게 됩니다. Production Order는 현장에서 적절한 스케쥴링 등의 과정을 통하여 제품의 생산에 이용되며, 생산된 제품 또는 부품은 재고 창고에 입고되게 됩니다. 재고 창고에 입고되면, 재고 레코드의 데이터는 갱신되게 됩니다. 구매 명령은 구매 부서에 수령된 후에 적절한 구매 절차를 통하여 구매로 이어집니다. 구매가 이루어진 부품들은 재고 창고에 입고된 후에 재고 레코드에 반영되게 됩니다.

생산 계획 및 통제에 대한 기본 흐름은 이제 이해하실 수 있으리라 생각됩니다. 이상의 설명은 사실 매우 기초적인 부분에 지나지 않습니다. 뿐만 아니라, 설명이 때로는 부족하다고 느끼실지도 모르겠습니다. 보다 자세한 설명은 Logistics 분야에서 드리도록 약속드리고, 생산 계획 및 통제의 구조 설명 가운데 언급되었던 '단위 기능'과 '중요 데이터'들에 대해서는 본 절 이후에 추가로 설명드리겠습니다.

출처 : http://ultra.snu.ac.kr/erp/ver3/erp/erp_2_1.html

다음 프로그램을 디버깅하면서 이해할 수 있습니다.

  *&---------------------------------------------------------------------*
*& Report  ZTEST_it_01ERNAL_TABLE
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT  ZTEST_it_01ERNAL_TABLE.

tables : kna1.

* Header가 있는 internal Table 선언
DATA : BEGIN OF it_01 OCCURS 0,
  vbeln like vbak-vbeln,
  matnr type matnr,
  cnt type I,
  end of it_01.

* 특정 table과 같은 구조로 선언
data : it_02 like kna1 occurs 0 with header line.

* it_01 Table에 data를 append한다.
it_01-vbeln = 'A'.
it_01-matnr = 'AA'.
it_01-cnt = 1.
append it_01.

it_01-matnr = 'AB'.
it_01-cnt = 2.
append it_01.

it_01-vbeln = 'B'.
it_01-matnr = 'BB'.
it_01-cnt = 3.
append it_01.

it_01-vbeln = 'C'.
it_01-matnr = 'CC'.
it_01-cnt = 4.
append it_01.
clear it_01.


write : /'it_01에 값을 확인'.
LOOP AT it_01.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.

write : /'int-vbeln = A 값을 확인'.
LOOP AT it_01 where vbeln = 'A'.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.

write : /'Read commend(with key) 사용 : IF sy-subrc = 0.을 사용하여 data를  확인'.
read table it_01 with key vbeln = 'A'.
  IF sy-subrc = 0.
      write : / it_01-vbeln,it_01-matnr,it_01-cnt.
  ENDIF.
write : /.

write : /'Read commend(index) 사용 : IF sy-subrc = 0.을 사용하여 data를  확인'.
read table it_01 index 3.
  IF sy-subrc = 0.
      write : / it_01-vbeln,it_01-matnr,it_01-cnt.
  ENDIF.
write : /.


* index가 3인 it_01에 insert
write : /'insert후  값을 확인'.
it_01-vbeln = 'D'.
it_01-matnr = 'DD'.
it_01-cnt = 5.
insert it_01 index 3.
  clear it_01.
  LOOP AT it_01.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.

* 기본 적으로 append와 같이 마지막에 추가되는 것은 같으나 이미 저장된 record중에 character type의 field를 비교하여
* 같은 값으로 이미 저장되어 있는 record가 있으면 수자타입의 필드는 기존의 필드에 현재 header에 있는 값은 더한다.

write : /'collect후   값을 확인'.
it_01-vbeln = 'A'.
it_01-matnr = 'AB'.
it_01-cnt = 2.
collect it_01.
  clear it_01.
  LOOP AT it_01.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.


* it_01의 index가 3인 record를 수정한다.
write : /'modify후   값을 확인'.
LOOP AT it_01.
  it_01-vbeln = 'Z'.
*  modify it_01.
  modify it_01 index 3.
  clear it_01.

ENDLOOP.

  LOOP AT it_01.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.

* it_01의 contents를 비운다.
  write : /'refresh 후   값을 확인'.
refresh it_01.
  LOOP AT it_01.
  write : / it_01-vbeln,it_01-matnr,it_01-cnt.
ENDLOOP.
write : /.

write /'end Program'.

사용예)  OPEION이 'BT'이면 LOW 값과 HIGH값이 모두 설정되어야 하면 범위값을 가진다.
                         'EQ'는 LOW 값만 존재하면 된다.                        
 
select-option :  화면에서 입력 파라미터 받아서 할때 사용
Range          :   코딩중 내부적으로 다중 조건을 만들어야 할 경우
                       IN 으로 조건을 주기 전에 Range변수 선언해서 조건을 주고 IN으로 select

출처 :  http://blog.naver.com/hjk535/120063868214

Internal Table에 대한 설명입니다.

의외로 이 개념에 대하여 혼돈을 일으키시는 분들이 많으시더군요. 그래서 이것에 대한 개념을 명확히 해야겠다고 생각이 들어서 비록 명령문의 설명 중간이지만 이 개념을 설명하고자 합니다.

Table에 대한 개념은 다들 아시죠? (설마 이것두 모른신다면…????)

맞습니다. Table은 데이터들을 저장하는 곳이죠. 데이터베이스를 배우지 않으셔도 전산을 한달 이상만 하셨다면 다들 아시는 내용입니다. 그럼 Internal Table에 앞서 조금 더 Table에 대한 개념을 잡고 넘어가겠습니다.

SAP R/3에서는 테이블에 데이터를 입력하거나 변경하고자 할 때에는 Header라고 부르는, 또는 Header의 기능을 수행할 수 있는 Working Area에 일단 데이터를 가져온 다음 그 데이터를 수정하고, 변경된 데이터를 다시 테이블에 적용하는 방법을 가지게 됩니다. 자 그러면 Header라는 것은 무엇인가? 테이블의 레코드와 동일한 Size와 Type을 가지는 존재를 말합니다. 즉 테이블에 들어갈 수 있는 하나의 레코드라고 보시면 됩니다. 따라서 Header의 기능을 수행하는 Working Area라고 하는 것은 테이블의 레코드와 동일한 Size와 Type을 가지는 존재인 것이 되겠죠. 다시 한번 말씀드리지만 SAP R/3에서는 TABLE에 데이터를 변경, 삽입하는 것은 Header의 기능을 수행할 수 있는 Working Area가 있어야 합니다.

자 이제 SAP R/3에서의 데이터가 삽입/변경되는 과정을 이해 하셨으면 INTERNAL TABLE이 무엇인지를 확인 해야겠죠? 테이블은 물리적인 존재입니다. 즉 하드디스크 상에 영구적으로 존재하는 것이죠. INTERNAL TABLE은 프로그램이 실행되고 있는 동안 생성되는 TEMP의 성격인 테이블입니다. 물론 이것도 하나의 테이블로 취급됩니다. 즉 앞에서 설명한 TABLE에서의 삽입/변경과정이 동일하다는 것이죠.

정리하겠습니다.

메모리 영역과 하드디스크(DBMS)영역에 테이블이 존재할 수 있습니다. 메모리 영역에서 생성되는 테이블은 프로그램이 실행되면 생겨나는 것이며 하드디스크 영역에 있는 테이블은 프로그램의 실행과는 무관하게 존재하는 테이블입니다.

메모리 영역에서 사용하는 테이블은 INTERNAL TABLE이라고 부르며 하드디스크에서 사용하는 테이블은 TABLE또는 TRANSPARENT TABLE이라고 부릅니다. 메모리 영역이든, 하드디스크 영역이든 모든 테이블은 삽입/변경하는 과정은 HEADER라고 부르는 특별한 존재를 통하여 가능합니다. 하드디스크의 Table을 사용하려면 Tables명령으로 Header를 선언하여 처리합니다. Internal Table은 Data문을 통하여 Header를 선언하여 처리합니다. 하드디스크 영역에 존재하는 테이블을 생성하기 위해서는 SE11 Transaction을 통하여 생성해 주셔야 합니다. 물론 DBMS Level에서 SQL문을 통하여 생성할 수 있습니다.

다음의 그림은 SE11 Transaction의 화면입니다.

[그림 1-1: SE11화면]

하지만 메모리 영역의 Internal Table은 프로그램의 Data문에 의하여 생성됩니다.

다음은 Data 명령문을 통한 Internal Table 생성 예제입니다.

Header Line이 있는 것과 없는 것을 구분하여 설명드립니다.

Tables: MARA. “MARA의 Header 역할을 하는 Working Area생성.

Data: BEGIN OF IT_MARA OCCURS 0.

INCLUDE STRUCTURE MARA.

Data: END OF IT_MARA. “ Header가 기본적으로 생성됨.

Data: IT_MARA_N LIKE TABLE OF MARA. “ Header가 없는 Internal Table.

Data: IT_MARA_H LIKE TABLE OF MARA WITH HEADER LINE.

“ Header가 있는 Internal Table.

[출처] Chapter2. Internal Table|작성자 와니

RANGES : 개발자가 프로그램 내에서 직접 핸들링 할 수 있다.
SELECT-OPTIONS : 시스템이 관리하는 변수

select-option으로 선언된 변수하고 ranges 로 선언된 변수의 구조를 디버깅해서 봐봐.. 둘다 구조가 똑같애.

이것도 일종의 인터널 테이블이라고 생각하면 되지

select-option s_vbeln for vbak-vebln. 요놈하고

ranges s_vbeln like vbak-vbeln. 이렇게 한거하고 변수 구조로만 보면 똑같다는 거야... 단지 두개의 용도가 다른거지..

select-option 실행할때 입력받는 화면에 나타나는 변수고

range로 선언하면 그냥 프로그램안에서 변수처럼 사용한다는 차이가 있어.

range는 말그대로 범위라는 의미라서 특정 범위 from ~ to 값으로 데이터 추출하고 할때 쓰는거고

그런 범위 개념으로 사용할수 있는 변수를 range 변수라고 말하는거야....

니가 짠 펑션에서는 sales order 번호 한개만 입력받아서 그 정보를 리턴하는건데.....
너처럼 select-option으로 선언된 변수로 하게되면

사용자가 s/o번호를 1 에서 10까지 입력할때 어떻게 처리할거지? 상식적으로 생각해봐....
이럴땐 1에서 10까지의 s/o 번호를 루프로 한번씩 돌려서 펑션을 콜해야 하는거지......

그럴려면 펑션 콜하기전에 입력한 s/o번호를 itab에 담아서 그놈을 루프돌리며 s/o 번호 하나씩 넣어가며 콜하면 되는거야....

help 찾아보면 이렇게 나오는데 요렇게 인터널 테이블 선언한거랑

DATA: BEGIN OF rtab OCCURS 0,
sign TYPE c LENGTH 1,
option TYPE c LENGTH 2,
low LIKE dobj,
high LIKE dobj,
END OF rtab.

ranges s_vbeln like vbak-vbeln. 이렇게 ranges로 선언한거랑 똑같은 구조야.....

s_vbeln 이 변수 이름이라고 하면 아래와같은 구조의 인터널 테이블로 변수가 생성되는거고

사용자가 1 ~ 10 으로 범위값을 입력하면 이 변수에 값이 이렇게 들어가.....

sign option low high

----------------------------

'I' 'BT' '1' '10'

sign은 그냥 'I' 가 무조건 들어간다고 생각하면 되고.....

option 의 BT는 Better Then의 약자야 1부터 10까지... 라는 의미고

low는 화면의 필드에서 앞에 입력한 값이고 high는 뒤에 입력한 값

사용자가 앞의 필드에 특정 번호 하나만 입력하고 실행하면 이렇게 들어가.. EQ = Equal 같은..이라는 뜻

sign option low high

----------------------------

'I' 'EQ' '1'

개념을 알라나 몰라...

아무튼 그 펑션으로 수행하려면 이렇게 짜면 되지.....

빨간색이 내가 추가한 로직이야......

DATA : BEGIN OF ITAB OCCURS 0.
INCLUDE STRUCTURE ZSDSVBAK_VBAP.
DATA : END OF ITAB.

VBELN LIKE VBAK-VBELN,

END OF IT_SO.

SELECT-OPTIONS : S_VBELN FOR VBAK-VBELN.

SELECT VBELN INTO CORRESPONDING IT_SO

FROM VBAK WHERE VBELN IN S_VBELN.

LOOP AT IT_SO.
CALL FUNCTION 'ZSD_VL_DISPLAY_2' EXPORTING

* I_VBELN = S_VBELN
I_VBELN = IT_SO-VBELN
TABLES
LS_VBAK_VBAP = ITAB.

SELECT 구문 최적화

SAP R/3 구조 이해하기

R/3 구조를 이해하기 위해 아래와 같이 VBAK 테이블에서 데이터를 1000건 SELECT 하는 프로그램을 작성해 보자.

읽어올 정보는 다음과 같다.

- VBAK-VBELN: 오더 번호

- VBAK-AUART : 오더 종류

- VBAK-BNAME : 오더 이름

- VBAK-KUNNR : Sold to party

일반적으로 아래와 같은 방식으로 SELECT 문장을 작성할 것이다.

REPORT ZSAMPL E1. TABLES : vbak . SELECT * FROM vbak . IF sy-dbcnt > 1000. EXIT. ENDIF. WRITE : / vbak-vbeln , … ENDSELECT.

위 구문은 VBAK 테이블의 모든 칼럼을 한 건씩 읽어 가면서, WRITE 하는 구조로 되어 있으며, SY-DBCNT를 확인하여 1000건이 넘으면 EXIT하도록 되어 있다.

그럼 다음 단계에서 왜 위 문장이 비효율적인지 알아보자.

SAP R/3 구조와 실행시간

R/3 는 아래 그림과 같은 구조로 이루어져 있다.

R/3 는 위의 그림과 같이 3 계층 구조로 되어 있다.즉, 사용자가 시스템에 특정 데이터에 대한 요청을 하면, Application Server가 중간에서 사용자의 요청을 가공한 후, DB Server에 데이터에 대한 요청을 보내고, DB Server로부터 데이터를 받아, 다시 가공하여 사용자에게 보내는 방식으로 처리한다.

따라서, 앞과 같이 SELECT * 하게 되면, 문제에서 제시한 네 개 필드 외에 해당 레코드의 모든 필드를 가져오게 된다. 즉, VBAK 테이블의 한 레코드 크기가 대략 575바이트인데, 1000건을 가져와야 하므로 총 575,000 바이트를 DB Server에서 Application Server로 전송해야 하며, 한번 전송할 때의 패킷 크기가 32,000 바이트인 경우(시스템에 따라 다를 수 있음), 총 20여 회의 네트워크 트래픽이 발생하게 된다. ( 575,000 / 32,000 )

다음 단계에서 앞 문제의 해답과 이유를 알아보자.

SELECT * 개선

SELECT * 형태의 문장을 COLUMN Selection 이용하여 아래와 같이 개선할 수 있다.

SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT.

위와 같이 사용하려는 네 개의 Column만을 가져오도록 할 경우 네트워크 트래픽은 다음과 같다.

즉, 네 개 Column 크기의 합이 59 바이트이므로 1000건을 읽는다 해도 59,000 바이트의 데이터만 DB Server에서 Application Server로 전송되면 된다. 패킷의 크기가 역시 32,000 이라면, 이 경우에는 두 번의 트래픽만 필요하게 된다.

BSEG, VBFA 같은 SAP Cluster Table에 대해서는 Column Selection 을 할 수 없다(Column Selection을 하도록 작성해도 내부적으로는 전체 Column을 읽는다.). 이러한 테이블을 Column Selection으로 읽고 싶은 경우에는, 시스템을 내리고, 테이블 형태를 Cluster Table에서 Transparent Table로 바꾼다.

데이터 건수 확인 요령

아래 방법은 SY-DBCNT를 이용한 데이터 건수 확인 문장을 UP TO n ROWS 구문을 이용하여 개선하는 예를 보여준다.

*-- 개 선 전 SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak . IF SY-DBCNT > 1000. EXIT. ENDIF. WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT. *---------------- ------------------------------------------------------* *-- 개 선 후 SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak UP TO 1000 ROWS. WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT.

위의 예에서 첫 번째 문장은 데이터 1000건을 건건이 DB Server에서 Application Server로 전송하는 반면, 두 번째 문장은 DB Server에서 1000건을 읽은 후 일괄적으로 Application Server로 전송하는 방식 으로 동작한다. 따라서 두번째 문장이 훨씬 좋은 성능을 나타낸다.

WHERE 조건 없이 데이터 한 건만을 가져오는 경우라면, 차이가 더욱 두드러진다. 한 건을 가져올 경우 전자의 경우 150,000ms, 후자의 경우 1,500ms 시간이 걸린다.

CHECK 구문 개선

아래 예는 CHECK 문장에 들어가는 조건을 SELECT 문장에 포함하여 개선하는 방법 이다.

PARAMETERS : par am1. DATA : BEGIN OF search_string, FIRST(9) VALUE ‘_________ ’, PARAM, END OF search_string. *-- 개 선 전 SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak . CHECK vbak-vbeln+9(1) = param1. WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT. *----------------------------------------------------------------------* *-- 개 선 후 search_string-param = param1. SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak WHERE vbeln LIKE search_string. WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT.

Vbak 테이블에서 57,000건을 가져오는 것을 비교한 경우

SELECT & CHECK 27,958,000ms

SELECT WITH WHERE condition 3,065,000ms

가능하다면 어떠한 경우라도, CHECK 조건은 WHERE 절 안에 들어와야 하며 이것은 SELECT SINGLE에도 적용된다.

SELECT SINGLE vbeln auart …INTO (vbak-vbeln, …) FROM vbak

WHERE vbeln = ‘0090000090 ’AND bname = ‘smith ’.

위 구문에서 vbak 테이블의 키 필드는 vbeln이지만, bname을 CHECK로 빼지 않고, WHERE 절에 포함시킴으로써, DB Server와 Application Server 간에 쓸데없는 네트워크 트래픽을 줄일 수 있다.

그러나, CHECK 절이 매우 까다롭고 복잡한 경우에는 오히려 DB Server에서 일단 데이터를 받아오는 것이 빠를 수도 있다. 이것은 SQL Trace를 이용하여 실제로 어떤 것이 빠른지 조사해보고 결정하여야 한다.

ORDER BY 구문 개선

아래 예는 SELECT 구문에서 사용되는 ORDER BY를 Internal Sort를 이용하여 개선하는 방법을 보여준다.

*-- 개 선 전 SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak WHERE bname IN so_bname OR DER BY bname DESCENDING . ENDSELECT. *----------------------------------------------------------------------* *-- 개 선 후 SELECT vbeln auart bname kunnr INTO TABLE it_vbak FROM vbak WHERE bname IN so_bname . SORT it_vbak BY bname DESCENDING.

많은 양의 DB를 DB Server에서 정렬하는 것은 그 시스템을 사용중인 모든 사용자에게 영향을 미친다. 하지만 ABAP/4 프로그램 내에서 처리하게 되면 해당 Application Server에만 영향을 미친다.

하지만 SELECT 구문 내에서 ORDER BY를 이용하여 정렬하고자 하는 필드에 INDEX가 적절하게 구성되어 있다면, DB Server에 해롭지 않다.

APPEND 구문 개선

아래 예는 APPEND 구문을 이용하여 내부 테이블에 건건이 데이터를 추가하는 것을 INTO TABLE을 사용하여 개선하는 방법을 보여준다.

*-- 개 선 전 SELECT vbeln auart bname kunnr INTO ( it_ vbak-vbeln, it_ vbak-auart, it_ vbak-bname, it_ vbak-kunnr) FROM vbak WHERE bname IN so_bname . APPEND it_vbak. “추가 작업. ENDSELECT. *----------------------------- -----------------------------------------* *-- 개 선 후 SELECT vbeln auart bname kunnr INTO TABLE it_vbak FROM vbak WHERE bname IN so_bname . LOOP AT it_vbak. “추가 작업. ENDLOOP.

내부 테이블의 내용을 한 번에 전송하는 것이 더 효과적이다.

데이터를 내부 테이블로 한 번에 읽어 들이는 방법의 또 다른 효과는 처리시간이 매우 짧다는 것이다.

SELECT .. ENDSELECT. 내에서 많은 처리를 할수록 ORAO155 Snapshot too old( rollback segment too small ) 오류를 만날 확률이 높다.

수행시간이 긴 SELECT 문장은 동일한 작업 대상 테이블에 대한 INSERT/UPDATE 문장과 I/O Contention을 일으킬 확률이 높으며, 이럴 경우, DB Server가 반드시 read consistency를 보장한다고 단언하기 어렵다 .

VIEW를 이용한 Nested SELECT 개선

아래 예는 여러 개의 테이블에서 데이터를 가져올 때, view를 이용하여 NESTED SELECT를 개선하는 방법을 보여준다.

*-- 개 선 전 SELECT vbeln auart bname kunnr INTO (vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr) FROM vbak WHERE vbeln IN so_vbeln. SELECT po snr matnr kwmeng meins INTO …FROM vbap WHERE vbeln = vbak-vbeln. WRITE : / vbak-vbeln, vbak-auart, vbak-bname, vbak-kunnr. ENDSELECT . ENDSELECT . *----------------------------------------------------------------------* *-- 개 선 후 SELECT * FR OM zv_vbak “VIEW WHERE vbeln IN so_vbeln. WRITE : / … ENDSELECT.

VBAK : 716건, VBAP 2779건의 데이터를 대상으로 테스트 한 결과는 아래와 같다.

개선 전: 3,892,184 microseconds(약 4초)

개선 후: 981,385 microseconds(약 1초)

Nested SELECT 대신에 VIEW를 이용하여 두 개의 테이블을 JOIN한 다음, VIEW에서 데이터를 읽어오는 것이 훨씬 수행 속도가 빠르다.

그러나, DB VIEW는 버퍼를 경유하지 않고 바로 DB에서 데이터를 읽어 오기 때문에 두 개의 테이블 중 하나가 버퍼링이 되고 있는 경우, 버퍼링의 장점을 살리지 못하여, 늦어지는 경우가 아주 가끔 발생할 수도 있다 . 이런 경우는 SQL Trace를 이용하여 실제로 수행시간을 측정하고 결과가 좋은 것을 사용하도록 한다.

DB Dictionary 의 DB VIEW는 항상 INNER JOIN이다.

VIEW생성시 MANDT열을 가져오도록 정의한 테이블을 가장 먼저 읽는다.

SELECT FOR ALL ENTRIES를 이용한 OUTER JOIN

아래는 SELECT FOR ALL ENTRIES를 이용하여 ABAP에서 OUTER JOIN을 구현한 예이다.

*-- 개선 전. SELECT vbeln auart …INTO …FROM vbak WHERE …. SELECT posnr matnr …INTO …FROM vbap WHERE vbeln = vbak-vbel n. … ENDSELECT. ENDSELECT. *----------------------------------------------------------------------* *-- 개선 후. SELECT vbeln auart …INTO TABLE it_vbak FROM vbak WHERE vbeln IN so_vbeln. SELECT vbeln posnr matnr …INTO TABLE it_vbap FROM vbap FOR ALL ENT RIES IN it_vbak WHERE vbeln = it_vbak-vbeln. “vbeln과 it_vbak-vbeln은 같은 형과 길이여야 한다. LOOP AT it_vbak. READ TABEL it_vbap WITH KEY vbeln = it_vbak-vbeln BINARY SEARCH TRANSPORTING NO FIELDS. LOOP AT it_vbap FROM sy-tabix. … ENDLOOP. ENDLOOP.

OUT ER JOIN을 할 경우 위처럼 FOR ALL ENTRIES IN 구문을 이용하여 SELECT한 후, 내부 테이블에서 처리하도록 한다 .

SQL 함수 사용하기

SELECT구문에서 LOOP를 돌면서 처리하는 형태의 합, 평균을 구하는 방법을 SQL 함수를 이용하여 개선하는 예이다.

DATA : BEGIN OF vbqty OCCURS 0. matnr LIKE vbap-matnr, kwmeng LIKE vbap-kwment, meins LIKE vbap-meins. *-- 개선 전. SELECT matnr kwmeng meins INTO vbqty FROM vbap WHERE …. COLLECT vbqty. ENDSELECT. *----------------------------------------------------------------------* *-- 개선 후. SELECT matnr SUM ( kwmeng ) meins INTO TABLE vbqty FROM vbap WHERE … GROUP BY matnr meins.

10,000건의 데이터를 처리하였을 경우, 아래와 같은 성능 차이가 나왔다.

개선 전: 2,370,000 microseconds

개선 후: 1,574,000 microseconds

GROUP BY 절은 Pool Table이나 Cluster Table에는 사용될 수 없다(BSEG, VBFA).

WHERE 없는 SELECT 구문은 피하라.

아래와 같이 WHERE 조건 없이 SELECT 구문을 사용하는 것은 매우 위험하다.

SELECT col1 col2 …INTO …FROM vbak. PERFORM cal_rtn. ENDSELECT.

특히 다음과 같이 빠른 속도로 크기가 증가하는 테이블에는 절대로 사용하지 말 것

BKPF, BSEG, COBK, COEP, LIPK, LIPS, MKPF, MSEG, VBAK, VBAP, VBPA, VBFA

테이블의 모든 데이터를 읽어 작업을 수행하려 한다면 다음과 같이 EXEC SQL 구문을 이용한 native sql을 구사하여 Application Server를 Bypass 하도록 한다. 그렇지 않으면 Application Server가 Where 절에 MANDT 조건을 붙여, Full Table Scan이 되지 않고 인덱스를 이용하게 되어 최악의 결과를 초래하게 된다.

EXEC SQL. SELECT /* rule */ Vbeln INTO : ivbak-vbeln FROM vbak WHERE mandt || ‘’ =: sy-mandt ENDEXEC.

DML 구문 최적화

효과적인 UPDATE 기법

SELECT 와 ENDSELECT 사이에서 순환을 하면서 UPDATE 하는 형태는 아래와 같이 WHERE 절을 이용하여 개선할 수 있다.

*-- 개선 전. PARAMETES : pa_vkbur LIKE zvbak-vkbur. SELECT-OPTIONS : so_vbeln FOR zvbak-vbeln. SELECT * FROM zvbak WHERE vbeln IN so_vbeln. zvbak-vkbur = pa_vkbur. UPDATE zvbak. EDNSELECT. *----------------------------------------------------------------------* *-- 개선 후. UPDATE zvbak SET vkbur = pa_vkbur WHERE vbeln IN so_vbeln. IF sy-subrc = 0. COMMIT WORK. ELSE. ROLLBACK WORK. ENDIF.

zvbak 1000건을 대상으로 한 결과는 다음과 같다.

SELECT .. UPDATE .. ENDSELECT. 1.8초

UPDATE .. SET 0.3초

위의 예제에서 COMMIT WORK 또는 ROLLBACK WORK 구문은 논리적인 작업 단위가 끝나면 반드시 기술해 주는 것을 잊지 말자. COMMIT WORK나 ROLLBACK WORK를 빠뜨리면 DB Server가 수정 정보를 계속 rollback segment에 가지고 있어야 하기 때문에 System에 overload로 계속 남아있게 된다.

효과적인 INSERT 기법

데이터를 테이블에 INSERT 하고자 할 경우, LOOP를 돌면서 처리하는 것보다 아래의 예처럼 한꺼번에 INSERT 하면 효과적이다.

*-- 개선 전. LOOP at it. MOVE it TO z100. INSERT z100. ENDLOOP. *----------------------------------------------------------------------* *-- 개선 후. INSERT z100 FROM TABLE it.

아래 결과는 건수 당 테스트 결과이다.

1,000건 입력 시.

한 건씩 : 2.58초

한꺼번에 : 0.72초

5,000건 입력 시.

한 건씩 : 9.66초

한꺼번에 : 1.59초

10,000건 입력 시.

한 건씩 : 20.00초

한꺼번에 : 2.47초

효과적인 DELETE 기법

SELECT 와 ENDSELECT 사이에서 순환을 하면서 DELETE 하는 형태는 아래와 같이 WHERE 절을 이용하여 개선할 수 있다.

*-- 개선 전. SELECT-OPTIONS : so_vbeln FOR zvbak-vbeln. SELECT * FROM zvbak WHERE vbeln IN so_vbeln. DELETE zvbak. EDNSELECT. *----------------------------------------------------------------------* *-- 개선 후. DELETE FROM zvbak WHERE vbeln IN so_vbeln. IF sy-subrc = 0. COMMIT WORK. ELSE. ROLLBACK WORK. ENDIF.

zvbak 1000건을 대상으로 한 결과는 다음과 같다.

SELECT .. DELETE .. ENDSELECT. 3.0초

DELETE FROM 1.2초

개선 전 코딩은 거의 최악의 코딩이다. 개선 전 경우 DB Server는 대상 데이터를 찾아서 모두 Application Server로 보낸다. 데이터를 받은 Application Server는 아무 일도 하지 않고, 받은 데이터를 다시 DB Server로 보내고, DB Server에서는 이 데이터를 삭제한다.

그러나 개선 후의 경우는 데이터의 발췌 및 삭제 작업이 DB Server에서만 발생하게 되므로, Application Server와 DB Server사이에 데이터 전송 작업이 전혀 일어나지 않는다.

효과적인 Internal Table 작업

Nested LOOP 처리

Nested LOOP는 BINARY SEARCH를 이용하여 아래와 같이 개선할 수 있다.

DATA : ivbak LIKE VBAK OCCURS 0, Ivbap LIKE VBAP OCCURS 0. SORT : ivbaK BY vebln, ivbap BY vbeln. *-- 개선 전. LOOP AT ivbak. LOOP AT ivbap WHERE vbeln = ivbak-vbeln. WRITE : / … ENDLOOP. ENDLOOP. *-- 개선 후. LOOP AT ivbak. “Work Area에 아무 값도 넘기지 않음. Sy-subrc, sy-tabix를 설정하기 위함. READ TABLE ivbap WITH KEY vbeln = ivbak-vbeln BINARY SEARCH TRASPORTING NO FIELDS. LOOP AT ivbap FROM sy-tabix. IF ivbap-vbeln <> ivbak-vbeln. EXIT. ENDIF. WRITE : / … ENDLOOP. ENDLOOP.

Ivbak : 5,000 ivbap : 20,000 일 때.

Nested LOOP with WHERE : 5분.

LOOP/READ BINARY SEARCH/LOOP : 15초.

효과적인 LOOP 처리

특정 조건을 만족하는 데이터가 몇 건인지를 알고 싶은 경우에는 다음과 같이 한다.

LOOP AT it1 TRANSPORTING NO FIELDS WHERE bname = ‘smith ’. ADD 1 TO counter. ENDLOOP.

특정 조건을 만족시키는 데이터가 있는지 알고 싶다면 아래와 같이 하라.

LOOP AT it1 TRANSPORTING NO FIELDS WHERE vbeln > ‘003000000100 ’. EXIT. ENDLOOP.

내부 테이블 간 데이터 복사

동일한 구조를 가지는 두 개의 내부 테이블 간에 서로 데이터를 복사하고자 할 경우 아래와 같이 한다.

DATA : it1 LIKE eban OCCURS 100 WITH HEADER LINE, It2 LIKE eban OCCURS 100 WITH HEADER LINE. *-- 개선 전. REFRESH it2. LOOP AT it1. MOVE it1 TO it2. APPEND it2. ENDLOOP. *-- 개선 후. It2[] = it1[].

내부 테이블의 데이터 APPEND

동일한 구조를 가지는 두 개의 내부 테이블간에 서로 데이터를 APPEND 하고자 할 경우에는 아래와 같이 개선한다.

DATA : it1 LIKE eban OCCURS 100 WITH HEADER LINE, It2 LIKE eban OCCURS 100 WITH HEADER LINE. *-- 개선 전. LOOP AT it1. MOVE it1 TO it2. APPEND it2. ENDLOOP. *-- 개선 후. APPEND LINES OF it1 TO it2.

내부 테이블의 데이터 삭제

여러 건의 데이터를 내부 테이블에서 삭제하고자 할 경우 LOOP를 돌지 말고 아래와 같이 한다.

*-- 개선 전. LOOP AT ivbak WHERE bname = ‘smith ’. DELETE ivbak. ENDLOOP. *-- 개선 후. DELETE ivbak WHERE bname = ‘smith ’.

내부 테이블의 중복 데이터 삭제

DELETE ADJACENT DUPLICATES FROM itab [COMPARING field1 field2 …].

위 방법을 사용하기 위해서는 비교조건 필드를 기준으로 정렬되어 있어야 한다. 비교조건이 없다면, 모든 필드로 정렬되어 있어야 한다.

내부 테이블 데이터 개수 알아내기

DESCRIBE TABLE itab LINES n.

도메인 값 얻어오기

SELECT SINGLE ddtext FROM dd07v INTO p_text “CHAR 60 WHERE domname = p_domain “도메인 이름 AND domvalue_l = p_value “도메인 값 AND ddlanguage = sy-langu.

통화키 얻어오기

SELECT SINGLE ktext FROM tcurt INTO p_waerstxt WHERE waers = p_waers AND spras = sy-langu.

내부 테이블을 파일로 다운 받고 파일 열기.

call function ' DOWNLOAD ' exporting filename = filename filetype = filetype mode = mode importing act_filename = act_filename tables data_tab = down_itab. call function ' WS_EXECUTE ' exporting program = act_filename inform = '' exceptions prog_not_found.

Data Type

RFC Destination

DATA : rfcdest LIKE rfcdisplay-rfcdest.

Transaction Code

AbapDocu: ABAP 프로그래밍 예제.

Search_sap_menu: 메뉴 찾기.

ST05 :시스템 –유틸리티 –성능 추적.

STMS: CTS 관리자 .

SE09: CTS 요청.

SE30: 프로그램, 함수 성능 검사.

SQ01: ABAP QUERY.

SM50: 실행 중인 프로그램 목록 보기 .

SU01: 사용자 등록정보(암호 변경 가능) 바꾸기.

ST22: Dump 조회.

AL11: 서버 폴더 목록

함수

입력한 날의 달 마지막 날 구하기.

RP_LAST_DAY_OF_MONTHS

소수점이 포함된 문자를 숫자로 바꿔주기.

CHAR_FLTP_CONVERSION

음수일 때 –앞에 붙이기 ( 1,000,000 - -1,000,000 )

CLOI_PUT_SIGN_IN_FRONT

새 창을 열어 Transaction 코드 실행하기

NAVIGATION_EXECUTE_OBJECT

OBJECT_NAME “T-code

REPORTTYPE = ‘TR ’

NEW_WINDOW = ‘X’

숫자 뒤쪽의 –를 앞으로 보내기

CLOI_PUT_SIGN_IN_FRONT

함수의 파라미터 목록 얻어오기

RFC_GET_FUNCTION_INTERFACE