계속 있을 때마다 업데이트 할 예정 

SAP의 장점 중 하나는 데이터의 신뢰성이다.

데이터를 추가,수정,삭제를 하면 일반적으로 로그가 남고, 이러한 이력들은 나중에 감사자료에 사용이 된다.

이런 철저한(?) 시스템 때문에 SAP를 사용하는 회사의 재무제표는 신뢰도가 높다.

SAP는 원칙적으로 데이터(특히, 운영서버)를 삭제하지 말라고 한다. 

하지만 프로젝트나 운영업무를 하다보면 데이터를 삭제해야 하는 경우가 생긴다. 그럴 때 SE16N EDIT 모드 등을 사용하여 데이터를 삭제한다. (회바회, 케바케)

데이터를 삭제하는 방법들 중에 어떤 것들은 변경 로그를 남기고 어떤 것들은 변경 로그를 남기지 않는다.

이게 나중에 감사에서 큰 이슈( 재무제표 조작가능성 의심 등)가 된다. 특히, 현업이 운영서버에서 직접 데이터를 수정 / 삭제 하는 것은 정말 큰일이기 때문에 외주사에 데이터 삭제를 요청하거나 증빙을 남긴다. (회바회, 케바케)

오늘은 그런 어쩔 수 없는 상황에서 데이터를 삭제하려고 할 때, 하는 방법에 대해서 정리했다.

여러가지 방법들 중에 많이 사용하는 방법은 3가지이다.

1. &SAP_EDIT
2. SE16N 디버깅으로 편집모드 접속
3. CALL FUNCTION SE16N_INTERFACE 사용

하나씩 살펴보자.

1. &SAP_EDIT (S/4HANA 불가)

T-CODE: SE16N 에 접속해 테이블 명을 검색한다.

좌측 상단에 &SAP_EDIT을 입력 후, ENTER를 누르면 우측의 엔트리 유지보수에 체크표시가 생긴다.

만약에 아무 반응이 없거나 권한 에러가 뜬다면, 그것은 S/4HANA를 사용해서 생기는 문제이다.

실제로 노츠에서 찾아볼 수 있는데 S/4HANA 이후로 데이터의 정합성을 유지하기 위해서 “&SAP_EDIT”를 활용하여 데이터를 수정하는 부분을 비활성화 했다는 것이다. 단, 특정 권한 오브젝트가 있는 사람에게는 사용을 허락할 수 있다고 한다. ( 해결 방법은 노츠에 있으니 필요하면 찾아보도록 하자. )

그래서 사람들이 가장 많이 사용하는 방법이 SE16N 디버깅 방법이다.

2. SE16N 디버깅으로 편집모드 접속

T-CODE : SE16N 에 들어가고 테이블 명을 입력해준다.

CBO 테이블은 바로 편집모드로 들어가지고, 스탠다드 테이블은 디버깅에서 EDIT 모드로 접속해야 한다. 

먼저 CBO 테이블의 경우,

F8 실행시키면 편집모드로 바로 들어가진다.

애초에 엔트리 유지보수에 체크가 되어있다

빨간색 박스 부분처럼 편집 기능인 행 추가, 삽입, 삭제의 버튼들이 존재한다.

그러면 스탠다드 테이블을 봐보자.

대표적인 스탠다드 테이블로 BKPF로 예시를 들어보자.

스크린 샷을 보면은 엔트리 유지보수가 비활성화 되어있다. F8 을 눌러서 실행시키자.

실행 화면에서 ALV의 버튼 중 편집 기능의 버튼들이 존재하지 않는다.

스탠다드 테이블의 경우, 데이터의 정합성이 더욱 중요하기 때문에 그렇다.

그래서 보통 비공식 방법으로 편집모드를 들어가는거다.

방법은 정말 간단하다.

명령에 필드에 디버깅 ‘/H’ 를 입력하고 ENTER를 누른다.

그러면 아래에 디버깅을 설정했다는 메세지가 뜬다.

이후 F8 또는 시계 모양을 통해 실행시키면 디버깅 모드로 진입하게 된다.

디버깅 모드에 들어왔으면 아래 빨간색 박스에다가 편집모드 명령어를 입력해줄거다.

화면처럼 입력해주면 된다.

GD-EDIT 입력 후 ENTER         → 연필 클릭 → X 입력 후 ENTER

GD-SAPEDIT 입력 후 ENTER → 연필 클릭 → X 입력 후 ENTER

입력을 다했으면 F8 키를 누르거나 사진의 빨간색 박스 부분을 클릭한다.

그러면 편집 모드로 들어오고, 원하는 데이터를 클릭하고 삭제한 뒤 저장 버튼을 클릭하면 된다. 

저장 버튼을 클릭하면 변경 내역을 알려주고, 체크 박스를 누르면 저장이 완료된다. 

3. CALL FUNCTION SE16N_INTERFACE 사용

마지막으로 펑션 모듈 사용법이다.

보통 SE16N에 권한이 없는 경우 사용한다. 

이 펑션모듈에서 수행된 모든 변경 사항은 SE16N_CD_KEY 및 SE16N_CD_DATA 테이블의 기록이 된다. 

변경 로그가 기록되기 때문에 담당자와 상의하고 사용해야 한다. 

해당 Function에는 여러개의 Import가 존재한다. 빨간색 박스로 표시한 3개의 매개변수를 사용하면 된다. 

사용하기 위해서는 Z프로그램으로 하나의 CBO 프로그램을 만들면 된다. 

START-OF-SELECTION을 써주고 그 아래에 Function을 적어준다. 

이후, 프로그램을 실행하면 SE16N 편집모드와 동일한 결과를 볼 수 있다. 

하지만, BKPF처럼 수십만건이 조회될 수 있는 스탠다드 테이블의 경우 조건을 걸고 싶을 수도 있다. 

그럴 때는 SE16N_SELTAB 를 사용하면 된다.  

필드는 레인지 변수와 동일하다. 나 같은 경우는 SE16N_SELETAB의 TABLE TYPE을 사용하였다. 

위처럼 SELTAB에 원하는 조건을 추가하면 된다.

해당 코드는 회사코드가 1000번이고, 회계연도가 2024년~2025년 사이인 데이터들이 조회하기 위한 조건이다. 

오늘도 파이팅이다! 

 SAP FI 주요 용어

내가 보려고 정리한 T-CODE

ㅁ 전표 처리 관련 T-code

* 반제 전표 역분개 처리 순서

• 1단계: FBRA – 반제 전표의 반제 상태를 재설정
• 2단계: FB08 – 해당 전표를 역분개 처리하여 취소

ㅁ 마스터 데이터 관리: 고객 / 공급업체 / G/L 계정

참고:
FS01~FS03은 개별 작업용이며, FS00은 SAP ECC 시절부터 존재하던 통합 관리용 T-code이다.
S/4HANA 이후에는 단일 관리화가 강조되며 FS00 중심으로 활용되는 추세이다.

ㅁ 원가요소 / 코스트 센터 / 그룹 관리

ㅁ 명세 조회 / 잔액 확인

FI 모듈에 대한 Table의 종류가 많아서 한번 정리를 하려고 한다. 

해당 사진처럼 많은 테이블이 존재한다. 

먼저 가장 기본적인 Table에 대해서 봐보자. 

1. 전표 TABLE

1) BKPF

- 전표의 Header 정보가 저장되는 테이블 ( 전표유형, 증빙일, 전기일, 회계기간,역분개여부 등)

- 전표에 대한 제목을 담는다고 생각하면 된다. 전표를 치면은 BKPF 1개와 1개 이상의 BSEG로 구성되어있다.

- 정규전표(실전표), 임시전표(BKPF-BSTAT) = ‘V’)가 존재한다.

* 정규전표(실전표)와 임시전표

- 정규전표(실전표) : 재무제표에 금액이 반영되는 전표

- 임시전표 : 재무제표에 금액이 반영되지 않는 전표 (상신을 받기 전의 전표)

• 상신 승인시 임시전표가 정규전표로 전환(정규 전표가 된 순간 재무제표에 금액이 반영된다.)
• 회사의 프로세스에 따라 임시전표가 존재하는 곳이 있고,  존재하지 않는 곳이 있다.

2) BSEG

-정규전표(실전표)의 개별항목만 관리된다.

-FI 전표의 개별항목(Line item) 정보(차변과대변)가 저장되는 테이블이다.

- 계정과목, 금액 등을 확인할 수 있다. 

3) ACDOCA

- S/4HANA가 도입이 되면서 새로 추가된 테이블이다.

- 목적은 FI-CO의 통합 데이터 관리이다. 그렇다보니 BSEG에 있는 참조필드 1,2,3 등 불필요한 필드가 존재하지 않는다.

- 가끔씩 BKPF와 BSEG에 조회가 되지 않는 전표는 ACDOCA에서 조회가 가능하다.

- 설정 등록에서 역분개 시에 차변에 - 표시로 처리되게 할 수도 있다. 

2. 미결 및 반제 관련 전표 TABLE

미결(Open Item)은 거래는 발생했으나, 돈을 아직 받지 못한 상태이다. 회계 분개로 따지면 아래와 같은 상황이다. 

• 외상 매출금 500 / 매출 500

* 매출이 발생했지만 돈의 거래가 이루어지지 않음

반제(Clearing Item)는 실질적으로 돈이 들어와 거래가 종결되는 것을 의미한다.

그래서 거래 종결 전표라고 부르기도 한다. 회계 분개 상으로 아래와 같은 상황이다. 

• 현금 500 / 외상매출금 500

* 현금을 지급 받으면서 외상매출금이 없어짐

해당 표에서 BSID를 예시로 설명을 하자면, BSID는 AR 미결에 대한 전표만 조회가 된다.

예를 들어, FB01에서 전표를 생성하면 BKPF와 BSEG / ACDOCA에만 반영이 되는게 아니라,

고객과 관련된 전표면은 BSID / 구매처는 BSIK 이런식으로 함께 추가가 된다. 

만약에 고객관련 전표를 찾는다면은 BSEG와 ACODC보다 BSID를 보는 것이 빠르다. 

여기서 반제를 하게 된다면, BSID의 데이터는 삭제되고 BSAD로 넘어간다.

# S/4 HANA의 ACDOCA의 영향

S/4 HANA 전환 이후로 미결과 반제관련 테이블은 ACODC 기반의 CDS VIEW다.

ACDOCA는 HANA 전환의 핵심 존재다. 기존의 FI-CO의 복잡성을 하나의 테이블에서 통합시키기 위해 도입되었다. 

그로 인해 중복 저장 제가하고 리포트 성능을 극대화 시킬려는 목적이 있었다. 

3. 임시전표 TABLE

-임시전표를 관리하는 테이블은 ‘V’라는 영문이 붙는다. ( BKPF-BSTAT = ‘V’ )

4. BP(Business Partner)관련 TABLE

- BP 또한 S/4 HANA로 전환되면서 BUT0000이라는 BP 마스터에 하나로 통합되었다. 

# 고객

# 공급업체 

5. 자산 관련 TABLE

6. 그 외 TABLE

처음에 CTS 릴리즈와 운영서버 반영이라는 게 쉽지 않았다. 

한번도 해보지 않았고, 혹시나 운영서버를 잘못 건드릴까봐 무섭고 긴장되었다.  

그래서 나같은 사람을 위해 CTS 릴리즈와 운영 반영 방법에 대해서 정리해보려고 한다.

# CTS 릴리즈

일단 CTS 릴리즈든 이관이든 CTS 보내주세요든 다 똑같은 말이다.

처음에는 CTS 개념이 어렵고 헷갈렸는데 이제는 이해가 되었다.

내가 딱 정의를 내린 건, CTS 릴리즈은 고가의 물건 배송이다.

이 예시를 이해하기 위해 먼저 일반적인 SAP 서버 구성을 봐보자.

개발(D) - 품질(Q)- 운영 (P)

대부분의 SAP 서버는 위와 같이 구성되어있다.

SAP Logon의 시스템 ID를 보면은 D,Q,P 라는 문자가 포함이 되어있다.

D가 포함되면 개발,

Q가 포함되면 품질,

P가 포함되면 운영이다.

실무에서 각 서버의 역할은 다음과 같다. 

ㅁ 개발(D) 서버

말 그대로 개발 및 TEST를 진행하는 서버이다. 여기서 TEST 데이터도 만들어보고 현업 요청사항에 맞게 이것저것 개발한다.

ㅁ 품질(Q) 서버

개발서버에서 수정한 코드를 품질서버에 반영하고 TEST를(현업 or 개발자) 한다.

'왜 TEST를 또 해?' 할 수 있지만 이유는 크게 2가지이다.

1) 현업 담당자가 직접 TEST를 하는 경우

- SAP 관리를 외주에 맞기는 경우 현업은 품질과 운영에만 권한이 있는 경우도 있다.

- 또한 프로그램의 실 사용자는 현업이기 때문에 프로세스에 맞게 수정되었는 지, 문제가 없는 지 빠르게 확인할 수 있다. 

2) 실 데이터(운영서버 데이터)가 개발서버에 없고 품질에 있는 경우

- 운영 서버의 데이터는 하루에도 많게는 수십만개가 생성될 수도 있다. 해당 데이터를 매번 개발에 반영을 하는 것도 비용    이다.

- 일반적으로 BC팀에게 비용을 지불하고 주기적으로 품질서버에만 운영 데이터를 업데이트 하는 경우가 많다.

어떻게 보면은 IT 전공자들에게는 당연할 수 있다. 품질서버의 결론은 코드에 대한 검증을 하는 곳이다.

쉽게 말해, 실제로 운영에 넘겨도 문제가 없는 지 확인하는 절차다.

* 하지만 품질 서버가 없는 경우도 존재한다. (서버도 곧 돈이기 때문에… )

   그럴 경우에는 개발에서 개발과 품질의 역할을 둘 다 한다. )

ㅁ 운영(P) 서버

실제 현업이 사용하는 서버다. 흔히 회계 감사, 재무제표 등 모든 것들은 운영 데이터를 토대로 한다.

코드 수정 / 데이터 변경 및 삭제 등 대부분 로그가 남기 때문에 모두가 민감하게 받아 드리고 조심스러운 것이다.

운영서버에 이러한 로그들이 생기면 감사에서 문제가 되기 때문이다.

SAP를 사용하는 많은 이유 중 한 가지는 '신뢰성'이다. 

운영서버의 데이터들을 통해 실제 회사의 재무상태표가 만들어진다. 로그들이 다 남기 때문에 감사에서도 충분히 확인할 수 있고 그만큼 신뢰성 있는 재무상태표가 되기 때문에 대기업에서도 SAP를 사용한다. 

근데 만약에 운영서버를 수정했다?? 감사 때 재무상태표를조작에 대한 의심을 가질 수 밖에 없다.

그렇다보니 잘못 건들여서 데이터가 문제 생기면 현업에서는 직접 수정을 하기 어렵다. (현업 ID로 로그가 남으니까) 결국에는 외주사에게 수정을 요청하는데 이것도 다 비용(공수 시간에 포함) 이다.

또한 외주사도 잘못 수정하면 책임을 질 수 밖에 없기에... 운영서버는 왠만해서 절대 건들지 않는 편이다. 

그런 일이 없도록 개발과 품질에서 현업과 함께 철저하게 검증을 하는 것이 중요하다.

나중에 이슈가 생기면 '너(현업)가 문제 없다고 해서 운영에 반영한거야!' 라는 보호막을 만드는 역할도 한다.

이제 다시 고가의 주문제작 물건을 파는 회사에 예시를 들어보려고 한다. 

약간 억지 예시이긴 한데...

만약 어마어마한 금액의 자체제작 물건을 판다고 해보자. 먼저 고객의 요구사항을 정확하게 파악해야 한다.

그리고 금액이 큰 만큼 고객의 요구사항이 잘 반영되었는 지 중간 체크를 하고 최종적으로 고객에게 배송하는

신기한(?) 회사라고 생각해보자.

이 상황을 SAP랑 대입에 대입하면 나는 이해하기 좀 수월했다.....

주문 제작(개발서버)

1. 고객에게 주문 (현업 요청 사항)이 들어왔다.

2. 생산직 직원(개발자)은 그 주문(요청 사항 - 개발 or IMG 세팅) 꼼꼼히 확인하고 공장(개발 서버)에서 맞춤 제작을

    시작한다.

3. 생산직 직원(개발자)은 해당 제품의 불량, 작동여부, 마감처리 등(데이터 오류 검증) 나름의 품질 검사(TEST)를 한다. 

중간 검사 (품질서버)

4. 우리는 고가의 맞춤제작 회사이기 때문에 고객의 요구사항 대로 맞춤 제작(개발)을 했을지라도 고객에게 한번 중간 점검을 해야한다. 

- 이 사람이 나는 노란색이 좋아! 했지만 이 노란색이 아니라 옅은 노란색! 찐한 노란색! 이럴 수도 있으니까... ( 개발서버의 실 데이터가 없는 경우, 데이터가 다른 경우, 원했던 요구사항이 아닌 경우, 막상 보니까 새로운 문제가 있는 경우 등등의 문제를 방지하는 거다. ) 

5. 고객(현업)을 품질공장(품질서버)으로 불러서 '맘에 드세요??'(TEST 요청)하는 거랑 똑같다. 

6. 고객이 맘에 든다고 '이렇게 해줘요!(운영반영)' 라고 말하면 우리는 그 물건을 고객의 집으로 배송한다. (문제가 생겨도 책임 소지가 명확해진다.)  

고객 전달 (운영 서버)

7. 품질 검사를 통과하면 고객(현업)에게 전달(운영서버 반영)한다.

이해가 잘 될 지는 모르겠지만! 나름 고민했던 예시다…..ㅠ

대부분 블로그에는 개발 → 품질 → 운영 이런 순서의 설명이 많다보니,

SAP를 글로 배운 나는 실제 CTS 릴리즈 시 착각을 했었다. ( 나같은 사람이 세상에 존재하지 않을까 싶어 공유한다...)

개발서버의 CTS를 품질서버로 릴리즈(전송)

→ 품질서버에 개발서버의 CTS 반영

→ 품질서버의 CTS를 운영서버로 릴리즈(전송)

→ 운영서버에 품질서버의 CTS 반영

실제로는 저런 과정이 아니라, 아래 과정이다. 

개발서버 CTS 릴리즈

→ 품질서버의 개발서버 CTS 반영

→ 엇? 문제가 없네?

→ 운영서버에 개발서버의 CTS 반영

품질서버에서 따로 CTS를 또 만드는 것이 아니라, 개발서버에 CTS에 수정된 코드가 반영되어있으니, 품질서버에서 TEST하고 해당 CTS를 그대로 반영을 하면 되는 거였다. ( 지금 생각하면 당연한건데... 왜 그땐 그랬을까...)

어쨌든... 서론이 너무 길었지만 CTS의 대한 설명은 이정도로 하고 실제로 방법에 대해서 봐보자. 

1. CTS 릴리즈하기 (T-CODE: SE09)

SE09에 들어가면 다음과 같은 화면이 나온다.

수정가능은 아직 전송을 안한 CTS, 릴리즈는 이미 전송한 CTS 를 조회하는 조회 조건이다.

원하는 조건을 선택하고 Display를 누른다.

그러면 해당 화면처럼 조회가 된다.

내가 생성한 CTS를 찾고, CTS 번호 옆의 + 폴더 파일을 클릭한다.

그러면 한개 이상의 CTS가 하위 노드로 보일거다.

여기서 중요한거는 CTS 릴리즈는 Tree의 아래부분(하위노드)에서 위부분(상위노드) 순서대로 릴리즈를 해줘야 한다. 

제일 하위 노드인 1번의 CTS를 클릭하고 3번 버튼(릴리즈)을 클릭한다.

그러면 옆과 같은 체크박스 표시가 생길거다.

그다음에 2번(상위 노드 CTS) 을 클릭하고 3번을 한번 더 누른다.

그러면 화면 우측 하단에 타이머(?)가 돌아가면서 기달리면 아래와 같은 화면이 나온다.

예시 사진이 마땅한 게 없어서 노션에서 찾아왔는데 빨간색 네모 두 부분만 보면 된다.

CTS 릴리즈가 되면 위 화면처럼 빨간색 배경의 CTS 넘버가 보일거다

처음에 나는 내가 뭐 잘못한 줄 알고 땀이 흘렀는데…. 당연한 증상이니 전혀 두려워할 필요 없고 좌측 상단의 새로고침 버튼을 눌러주자.

그러면 하늘색으로 돌아오고 정상적으로 CTS 릴리즈가 된 것이다.

2. CTS 반영 여부 확인하기

그러면 이제 릴리즈는 알았으니 반영 여부는 어떻게 확인해야 할까??? 

총 세 가지 방법이 있는 것 같다.

1) 개발서버 SE09에서 CTS 로그를 통해 확인하기 

2) 반영된 서버의 STMS에 접속하여 반영 여부를 확인하기

3) 내가 수정한거 해당 서버에 들어가서 바뀌었는 지 확인

솔직히 3번은 예를들어, 프로그램 코드를 고쳤으면 직접 ABAP Editor가서 변경된 코드가 있는 지 확인하면 되는거다. 

나는 처음에 이렇게 했다... 하지만 반영된 서버에 못들어가는 경우도 있을 수도 있으니...?? 또, 1-2번이 전문적인(?) 느낌이 나니까 알아두자. 

2-1. 개발서버 SE09에서 CTS 로그를 통해 확인하기

개발서버에서 확인하는 방법은 간단하다.

기존의 CTS 로그화면이 반영전과 이후가 다르다.

다시 SE09에 들어가 Display를 누르자. (이때 조회조건 꼭 릴리즈 체크하자)

그러면 릴리즈 내역에 내 CTS가 뜰거다.

CTS에 마우스클릭 한번을 하고, 빨간색 박스의 안경잽이를 클릭하자.

저 안경잽이는 CTS 전송 로그를 볼 수 있게 해주는 기능이다.

해당 사진은 이미 반영된 CTS의 로그이다. (예시 캡쳐본이 없다..)

빨간색 박스 부분이 존재한다면, 반영이 된거다. 

빨간색 박스의 상위 노드가 'P'가 포함되어있으니 해당 시스템은 운영서버라는 것을 확인할 수 있고,

하위 노드 내역처럼 여러개가 조회가 되고 성공적으로 완료라고 써져있을 거다. 

이걸 보고 아 현업에서 반영 했구나! 생각하면 된다. (개발자가 직접 반영하는 고객사도 있다.)

2-2. 반영된 서버의 STMS에 접속하여 반영 여부를 확인하기 ( T-CODE :STMS )

반영한 서버로 sap 로그인을 한다. -> 해당 T-CODE를 들어간다.

예시 이미지는 품질 서버로 들지만, 운영도 방법은 똑같다.

좌측 상단의 트럭을 클릭하기

빨간색 박스의 ‘큐’라는 부분을 보면은 서버의 종류가 나온다.

개발/품질/운영을 사용하는 회사라면은 3개의 큐가 조회가 될 거고,

품질이 없다면 개발과 운영 2개의 서버만 조회 될 것이다.

만약 품질에 반영했다면

품질서버 로그인 → 품질서버(Q가 포함된)의 큐 더블클릭

만약 운영에 반영했다면

운영서버 로그인 → 운영서버(P가 포함된)의 큐 더블클릭

반영된 서버를 더블클릭하면 2가지 화면이 나온다.

# 필터가 걸려있는 경우,

해당 필터를 클릭하여 요청 기준으로 필터를 잡고 CTS 번호를 입력해주면 된다.

# 필터가 안 걸려있는 경우,

CTS 번호 컬럼을 기준으로 필터를 걸면 조회가 된다.

* 내 CTS 번호로 필터를 걸었는데 조회가 안된다?!

내가 릴리즈를 분명히 했는데 CTS가 조회가 안될 때 있다.

 그때는 당황하지말고 좌측 상단의 새로고침을 클릭해주면 된다.

* 그래도 안된다?!

그러면 필터 값에 공백이 포함되어 있을 가능성이 높다.

CTS가 정상적으로 반영이 되었다면 ICON이 초록색이다.

반영이 되지 않았다면은 RC 부분이 다음과 같은 ICON으로 표시된다.

이렇게 확인하면 된다.

원래 CTS 릴리즈와 반영 방법을 한 번에 포스팅하려 했지만,

생각보다 내용이 길어져서.... CTS 반영 방법은 추후에 올리도록 하겠다...!

오늘도 모두 파이팅! 

VALUE문은 NEW SYNTAX의 핵심 중의 핵심이라고 할 수 있다.

누군가 나에게 실무에서 가장 많이 본 NEW SYNTAX가 뭐냐고 물어본다면, 

나는 고민도 없이 VALUE 였다고 말할 것 같다. 기존에 APPEND와 INSERT의 기능과 여러 타입의 변수에 값을 할당 하는 기능을 한다. 

긴 코드를 간략하게 바꿀 수 있다는 것이 개발자에게 정말 편한 구문이다. 그만큼 가독성이 좋아 유지보수가 더 쉬워진다. 

얼마나 편하길래? 라는 궁금증이 들 수도 있으니, 아래 내가 경험한 코드를 봐보자.

가장 먼저 내가 SYNC 교육 과정을 하면서 했었던 방법이다. 물론 예시이기 때문에 4건의 데이터 밖에 없지만 실제로 6개 이상 노가다 하면서 썼었다. 이게 은근 정말 귀찮다. 

기존의 ECC 버전에서 많이 볼 수 있는 방법이다. 물론 해당 코드가 문제가 있다는 것이 아니다. 

어떤 사람은 이게 더 가독성이 좋다고 이야기할 수 도 있다. 

이 코드에 VALUE 문법을 사용하면 어떻게 될까? 

Old Syntax의 30줄 길이의 GT_FCAT이 단 4줄의 코드로 줄어든다. 

무엇보다 한줄이 하나의 데이터처럼 보여, 4건의 스트럭쳐를 테이블에 넣었구나를 빠르게 확인할 수 있다. 

테이블의 필드도 가로로 정렬되서 보기도 편하다. 

이정도면은 충분히 가독성의 차이를 느꼈을테니, 자세히 이야기를 해보자 .

# VALUE

VALUE는 간단하게 ECC 버전의 ‘=’ 코드를 쉽게 만들어준다고 생각하면 된다. 그로인해 개발자는 불필요한 변수 선언과 가독성 있는 코드를 짤 수 있다. 

내가 찾아보고 직접 해본 결과 VALUE는 아래 4가지로 설명할 수 있을 거 같다.

1. VALUE 구문
2. 스트럭쳐의 값 넣기
3. 테이블의 값 넣기
4. 변수의 값 넣기

그래서 해당 목차대로 하나씩 이야기해보려 한다.

1. VALUE 구문 

VALUE는 아래와 같은 구문들을 쓸 수 있다.

1. VALUE #
2. VALUE TYPE
3. VALUE ~ BASE
4. VALUE ~ OPTIONAL

1-1. VALUE # 이란? 

내가 VALUE를 처음 만난건 SYNC 교육 과정을 듣기도 전에 SAP JOY에서 NEW SYNTAX 세미나를 시청했을 때 였다.

‘#’ 표현이 들어가면서 VALUE 구문을 굉장히 어렵게 느껴졌고 더군다나 비전공자였던 나에게 괴리감이 있었다.

VALUE의 ‘#’은 쉽게 설명하기 위해서는 인라인 선언이라고 생각하면 쉽고 그냥 TYPE 의 또 다른 표현이라고 생각하자.

# 을 쓰면 TYPE을 써주지 않아도 알아서 앞의 변수를 참고해서 TYPE을 받는다.

정확하게는 VALUE [ Type ] 이 문법이다. 할당할 변수의 TYPE을 받겠다는 것을 #으로 표현한다. . 

아래의 예시를 봐보자. 

우리는 여기서 LS_SCARR을 인라인 선언하면서 GT_SCARR의 타입을 그대로 받아온다는 것을 알고 있다.

그거랑 똑같다. 할당 받을 데이터의 타입을 그대로 참조한다.

VALUE #도 똑같다. 

자동적으로 SCARR 타입을 받는다. 사람들은 대부분 편하니 #을 많이 사용한다.

하지만! 중요한 점이 있다. 

만약에 VALUE 뒤에 지정해줄 수 있는 TYPE이 존재한다면, #을 써주는 것보다 TYPE을 명시해주는 것이 퍼포먼스에 좋다.  그게 바로 2번 내용의 VALUE TYPE이다.

1-2. VALUE TYPE 이란? 

말 그대로 TYPE을 지정해 주는 것이다.  퍼포먼스의 차이를 알아보자. 

예를들어 1번과 2번의 구문이 존재한다. 

데이터가 수십만 건이 존재한다면 2번 방법이 퍼포먼스 적으로 유리하다. ( 대부분의 회사는 수십만건의 데이터는 가볍게 가지고 있다...! )

왜냐하면,  #을 써주는 순간 SAP 시스템 상에서 GS_SCARR의 타입을 확인하기 위한 과정이 생겨버린다. 

해당 과정을 보면은 

# 1번의 코드의 경우

엇? Type이 #이네? -> GS_SCARR이 뭐지?( Type 확인)  →해당 타입에 알맞게 값넣기

# 2번의 코드의 경우 

Type이 SCARR 이구나? -> 해당 타입에 알맞게 값넣기

잘 이해될 지 모르겠는데 1번의 빨간색 글씨처럼 할당할 변수의 TYPE을 확인하는 과정이 생기기 때문에, 

만약 TYPE을 입력해줄 수 있다면 입력해주는 것이 좋다. 

1-3. VALUE BASE

BASE 문은 기존 데이터를 유지하면서 데이터를 추가하는 방법이다. 한마디로 APPEND 다. 

예를 들어, 우리가 많이 쓰는 INTO 이런식의 표현은 기존에 있는 데이터를 없애고 새로운 데이터를 집어 넣는 방식이다.

기존의 데이터를 유지하면서 데이터를 추가하는 방식이다. 해당 코드처럼 GT_DATA에 이미 데이터가 존재한다면

BASE를 써서 GT_DATA의 기존 데이터를 데이터를 유지하고~ 이 값을 넣어~~ 라는 식의 표현이 될 수 있다.

1-4. VALUE OPIONAL

이거는 이전의 READ TABLE 할 때, 했던 내용이랑 똑같다. 덤프 관련의 내용이다.

OPTIONAL은 특정 조건에 데이터가 없어도 덤프를 안나게 막아준다.

* 해당 게시글에 자세하게 나와있다.

2025.03.07 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX #2 - 테이블 표현식(Table Expressions)

아래와 같은 상황이 존재한다. 

만약 이 과정에서 GT_DATA의 1번 INDEX가 존재하지 않는다. 라고 가정해보자. 

그러면 OLD 구문은 덤프가 나지 않고 SY-SUBRC 4로 떨어지면서 넘어간다.

하지만 VALUE 구문은 바로 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors가 생긴다.

이런 경우에는 OPTIONAL을 사용해주거나 Try Catch을 사용해야 덤프가 안난다. 데이터가 존재할 수도 있고 안할 수도 있다면 OPTIONAL을 추가해서 덤프를 나지 않도록 방지해주자. 

2. 변수에 값 할당

기존의 OLD 방식으로 하는 방법을 NEW 방법으로 사용이 가능하다.

3. Structure에 값 할당

스트럭쳐에 하나씩 값을 넣을 때는 아래와 같이 사용하면 된다. 

조건에 맞는 테이블의 ROW를 INTO 하는 상황.

4. TABLE에 값 할당

코드길이를 줄이는 것은 물론 가독성까지 좋게 만들 수 있다.

해당 사진들은 모두 다 #으로 표기했지만, 

실제 상황에서는 꼭 TYPE을 써주는 것 잊지 말자!! 

오늘도 파이팅! 

CONV란?

CONV 연산자는 데이터 타입을 변환하는데 사용된다.

한 타입의 변수를 다른 타입으로 변환할 수 있다.

CONV type( [let_exp] dobj )  형식으로 사용되며, 아래와 같이 사용할 수 있다.

CONV #(     

CONV I(       

 CONV STRING(

내가 느낀 것은 인라인 선언과 함께 사용할 때나, CLASS 나 FUNCTION의 파라미터를 입력할 때 편하다고 느꼈다.

예제를 통해서 하나씩 봐보자.

1. TYPE 변환

두 가지 타입이 다른 경우가 있다.

LV_VALUE는 TYPE C 이고 LV_INT는 TYPE I 이다.

CONV 연산자는 데이터의 TYPE을 변환해준다. 

해당 코드는 LV_VALUE의 값을  TYPE 'I' 로 변환해 LV_INT에 할당하라는 코드이다. 

실제 프로그램에서는 CHAR 와 INT 타입은 SAP 스탠다드 설정으로 자동 변환되어 CONV를 사용하지 않아도 정상적으로 실행된다. 

저렇게 사용한다는 것만 참고하자.

2. FUNCTION 에서 사용

- CONV는 TYPE 변환 연산자라고 했다. 우리가 TYPE 변환을 많이 사용하는 FUNCTION MODULE에서의 사용법이다.

해당 FUNCTION은 DAY_IN이라는 파라미터가 날짜타입이다. 우리는 여기에 문자형을 넣을거다.

그러면 당연히 파라미터와 TYPE이 맞지 않아 덤프가 뜰거다.

위의 코드는 TYPE 불일치로 덤프가 나오는 코드이다. 

나는 과거에 교육 과정 프로젝트에서 TYPE 생각을 안하다가 덤프를 마주한적이 간혹 있었다.

Function Module의 파라미터와 변수가 TYPE이 맞지 않아 덤프가 뜬다. 

이럴 때마다 나는 해당 TYPE에 맞는 변수를 새로 생성해주고 TYPE을 변환시켰었다. (근데 이게 은근 귀찮다....)

하지만 이제는! CONV를 써서 간편하게 TYPE을 변환할 수 있다. 

CONV 연산자를 사용해 LV_VALUE를 TYPE D로 변환하는 코드이다. 

근데 여기서도 한가지 의문이 생겼다. 

대부분 CONV 연산자에 예시로 TYPE I, TYPE STRING 등만 있어서

CONV SFLIFHT-FLDATE (LV_VALUE) 처럼 TABLE의 필드도 사용되는지 궁금했다.

정상적으로 프로그램이 실행되고 LV_VALUE가 BKPF 테이블의 BLDAT TYPE으로 변환된다. 

3. CLASS

만약에 아래와 같은 클래스가 있다고 치자.

I_INT1과 I_INT2는 I 타입이다.

만약 LV_F가 F 타입이기 때문에 CONV 없이 그냥 들어간다면 FUNCTION 때 처럼 덤프가 발생할 거다.

하지만 CONV # 을 사용하면은 CLASS의 파라미터 타입으로 변환되어 덤프가 뜨지 않는다.

그러면 여기서 CLASS의 CONV # 과 FUNCTION의 CONV랑 차이가 궁금할거다.

CONV #

• CLASS에서만 사용 가능
• 자동적으로 파라미터의 TYPE을 받아준다 ( VALUE # 과 동일 )

CONV TYPE

• Function 에서 사용 시, CONV 뒤에 타입을 꼭 지정해줘야 한다. (CONV # 불가능 )
• TABLE의 Field로도 TYPE을 받을 수 있다. 

만약에 왜 CLASS에서는 #이되고, Function에서는 #이 안되는 지 궁금하다면, 

내가 이전의 데이터 인라인 선언 게시글에 정리하였으니, 그거를 참고하면 된다!

# 데이터 인라신 선언 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

4. 응용 방법

1)  TABLE의 라인 수를 이용하여, 메세지 출력 또는 TITLE 에 사용

2) CLASS에서 사용 

해당 응용 방법 말고도 많은 방법이 존재하니, 잘 활용하기를 바란다.

오늘도 파이팅 입니다. :)

오늘은 NEW SYNTAX의 2번째 Table Expressions, 테이블 표현식이다! 

READ TABLE을 대체할 수 있는 신 문법으로, 내부 테이블이나 표준 테이블의 특정 행에 직접 접근할 수 있다.

기존에 없었던 새로운 접근 방식으로, 개발자가 코드를 더 간결하고 읽기 쉽게 만들 수 있도록 돕는다.

지난 포스팅에서 정리한 데이터 인라인 선언 방식을 적용하여, 함께 사용한다면 코드가 더 간결해 질 수 있다.

# 데이터 인라신 선언은 이전 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

일단은 늘 하던대로, 얼마나 간결해지는 지 예시부터 보자. 

READ TABLE은 SAP 개발을 하면서 많이 쓰는 구문 중의 하나이다. 우리가 자주 쓰는 구문이 사진의 NEW SYNTAX처럼 사용을 할 수 있다. 기존의 4줄의 코드는 데이터 인라인 선언과 테이블 표현식을 사용하여 1줄이 되었다. 

테이블 표현식의 코드를 해석하면 LV_CARRID2를 만들고, GT_DATA 테이블의 1번 INDEX(첫줄)를 찾고 1번 INDEX의 CARRID 값을 넣어라! 가 된다. 이런식으로 간결하게 표현할 수 있는게 큰 장점이다.

해당 예시는 여러가지 경우에서 변수에 값을 넣는 부분이지만 내가 공부하면서 느낀 거는 다양한 코드들을 정말 간결하게 표현할 수 있는 것 같다. 

하지만,

이 테이블 표현식을 사용하려면 우리는 아래의 2가지 사항을 정확하게 숙지해야 한다. 

1. 값을 할당할 때, 테이블에 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 발생한다.
2. SY-SUBRC 는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다.

자세한 내용은 아래에서 예시와 함께 보자.

1. READ TABLE INDEX

처음 예시랑 똑같은 내용이다.

테이블에 데이터를 스트럭쳐로 옮기는 경우 해당 코드를 작성할 수 있다.

하지만!! 가장 중요한 사항은 해당 INDEX에 대한 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 생긴다.

테이블 표현식은 데이터가 존재하지 않는다면 무조건 덤프를 낸다. 

"근데 우리가 개발하다 보면은 TABLE에 데이터가 존재할 수도 있고, 없을 수도 있는데 그런 상황에서는 쓰지 못할까? "

그래서 열심히 구글링과 SAP docu을 찾아봤다. 

역시 해결 방법이 존재했었다. 

1) TRY-CATCH를 이용하여 해결하기.

해당 코드는 TRY-CATCH를 이용해 데이터가 없을 경우, CATCH 로 빠지게 했다. 

프로그램을 실행시키면

덤프가 나지 않고 CATCH로 빠지게 된다. 

TRY-CATCH를 이용해 데이터가 없는 경우에 대한 로직을 작성하여 이 부분을 해결 할 수 있었다. 

그러나 만약 반복되는 코드일 경우 TRY-CATCH로 인해 가독성이 더 안좋질 수도 있다. 

그래서 두번째 방법이 존재하더라... 

2) VALUE와 OPTIONAL 이용하여 해결하기.

VALUE 구문은 NEW SYNTAX에서 핵심 중에 핵심이다. 제일 많이 본 것 같다. 

스트럭쳐와 변수에 데이터를 집어넣는 과정이다. 

OPTIONAL의 역할은 테이블에 원하는 데이터가 없을 때, CX_SY_ITAB_LINE_NOT_FOUND 예외가 발생하지 않도록 막아준다. 이녀석의 정확한 역할은 값이 있으면 넣고 없으면 패스~ 느낌인거 같다. 

그렇기 때문에 데이터가 없을 가능성이 있다면 잊지말고 항상 써줘야 한다. 

2. READ TABLE ~ WITH KEY.

WITH KEY 뒤 조건에 맞는 스트럭쳐를 테이블에서 가져오는 구문이다. 

WITH KEY를 입력하지 않고 대괄호([ ]) 사이에 해당 조건을 바로 나열해주면 된다. 

3. TRANSPORTING NO FIELDS.

우리는 원하는 조건의 데이터가 있는 지 확인하기 위해 TRANSPORTING NO FIELDS를 사용했다. 

그리고 IF SY-SUBRC를 이용해 데이터 존재 여부를 체크했었다. 

하지만 테이블 표현식을 사용할 때는 처음에 주의사항으로 이야기했던 

2. SY-SUBRC는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다 

이거를 기억해야 한다.

내가 직접 테스트 해본 결과, 데이터가 들어가도 이녀석들은 무조건 SY-SUBRC 4를 내뱉는다. 

그러면 같은 상황에서 데이터 핸들링을 하려면 어떻게 해야 할까? 

그래서 테이블 표현식에서는 두 가지 키워드가 존재한다.

# LINE_EXISTS와 LINE_INDEX.

1) LINE_EXISTS.

LINE_EXISTS는 조건에 맞는 테이블의 데이터 존재 여부를 확인해준다. 한마디로 ‘IF SUBRC = 0’ 이랑 같은 의미를 지낸다.

해당 조건에 DATA 여부를 확인하고, 존재하면 IF 문을 타게 된다.

2) LINE_INDEX.

LINE_INDEX는 해당 조건에 맞는 INDEX 값을 반환해준다.

인터널 테이블에 조건에 맞는 데이터가 몇번 INDEX에 있는 지 반환을 하게 된다.

기존에는 SY-TABIX로 인덱스 값을 확인했다면, 

테이블 표현식은 LINE_INDEX 키워드를 사용해서 조건에 맞는 데이터의 인덱스 값을 추출할 수 있다. 

실행 결과를 보면 CARRID가 FJ라는 데이터는 6번 INDEX에 존재하는 점을 알 수 있다. 

만약 데이터가 없는 경우는 0 값을 반환한다. 또한 INDEX가 존재할 수 없는 Hashed Table이나 Hashed Secondary Key를 사용한 경우에는 -1을 반환한다.

4. FIELD-SYMBOL ASSIGN.

필드심볼에 할당에 대한 테이블 표현식이다.

OLD 버전에서 IF조건문이 없고 데이터가 존재하지 않아도 덤프가 나지않는다. 

하지만 테이블 표현식은 데이터 없으면 가차없이! 덤프나기 때문에 무조건 IF 조건문으로 감싸줘야한다.

이렇게 반겨준다. 

25번에 데이터가 존재하지 않는 경우, 두 경우에 덤프 에러가 뜨지 않는다 .

근데 여기서 중요한 점은

SAP에서 해당 테이블 표현식을 쓸 때, IS ASSGIN 말고 SY-SUBRC를 사용하라고 권장을 한다. (SY-SUBRC 사용 못한다고 할때는 언제고…?)

이 경우에는 놀랍게도 기존에 4값만 들어오던 SY-SUBRC가 0값이 들어오게 된다........ 

이 부분에 대해서 찾아봤는데 필드 심볼의 할당은 ASSIGN을 사용하는 방법이 올바르지만, 여러 개발자의 유지보수 등을 고려하여 SY-SUBRC를 권장하는 거라고 한다. ( 어떤 개발자든 직관적으로 성공! 실패! 를 구분할 수 있다나 머라나.... ) 

# 응용

4-1. TABLE에서 데이터 변경

MODIFY로 인터널 테이블에서 값을 수정하는 과정을 간단하게 바꿀 수 있다.

NEW SYNTAX를 해석해보면 GT_SCARR테이블의 CARRID가 ‘AA’인 ROW의 CARRNAME을 ‘비행기’로 변경해라 가 될 수 있다.

다만 여기서도 해당 조건의 데이터가 없다면, ITAB_LINE_NOT_FOUND 가 반긴다는 것...

그렇기 때문에 나는 위 사진처럼 LINE_EXISTS를 사용하여 덤프를 방지 시킨다.

물론 TRY CATCH도 가능하다.

4-2. 2개의 테이블 데이터 핸들링.

GT_SCARR 의 특정 데이터의 값을 LT_DATA에 APPPEND 하는 상황이라고 가정.

둘 다 동일한 값을 가진다

4-3. F4 서치헬프 함수로 띄우는 과정에서 적용하기

실제 내가 적용했던 방법이다.

서치헬프에서 클릭한 값을 받아서 CALL FUNCTION 'DYNP_VALUES_UPDATE’에 사용하는 상황이다.

잘 참고하면 좋겠고 도움이 되었으면 좋겠다! 

올바르고 정답이 있는 코드는 없다고 생각한다. 

잘못된 코드는 있지만 올바른 코드는 없다! 각자 상황에 맞게 잘 활용하기를 바란다!