Yong Study

원인 : SMARTFORMS 에 텍스트를 추가하여 조건에 맞게 해당 텍스트를 보여주고자 하였으나, 해당 방법을 CODE를 통해 하려고 했었음.

위와 같이 회사 주소를 구매그룹별로 세팅해주고자 했었음.

---

이 방법이 아닌 Flow Logic -> Alternative 를 추가하여 

위와 같이 조건을 줌.

해당 조건에 맞는 True False에 따른 Text 를 생성하여 조건별로 생성가능하게 함.

분명 서브루틴을 잘 선언하고 사용도 되는데

가끔 더블클릭해서 해당 서브루틴으로 이동하려 하면 

이런식으로 없다고 뜰 때가 있음.

오브젝트는 이미 생성되어있는데...

그렇다고 실행오류가 발생하는것도 아닙니다.

이런 경우의 원인은 같은 펑션그룹내에 작업자가 여러명일경우

동시에 수정중일경우 이런일이 발생할 수 있음

Update Navigation Index 를 하여 업데이트를 하자!

나는 이것도 모르고... 인클루드 내부에 있는 오브젝트 순서때문인가...

클릭해서 안만들어서 그런가 하고 한참을 헤매었다..

파일 입력을 위한 타입 설정 후 해당 매개변수를 사용하는 펑션에서 지속적으로 덤프가 발생하였는데

타입명도 정확하게 설정했다고 생각했는데 덤프가 발생해서 한참을 헤메였다.

RLGRAP-FILENAME ( CHAR 128 )
- WS_DOWNLOAD, WS_UPLOAD, KD_GET_FILENAME_ON_F4 와 같은 펑션모듈등에 사용됨

IBIPPARMS-PATH ( CHAR 128 )
- RLGRAP-FILENAME와 유사

FILENAME-FILEINTERN ( CHAR 60, 뭔가 이상해서 찾아봤는데 정말로 CHAR 60자리임. )
- 실제 파일 경로가 아닌 논리 파일 이름에 사용 됨, 디렉토리 구조 변경시 그냥 파일 논리 경로 정의만 변경하면 됨.
단 길이가 짧음 60, FILE_GET_NAME과ㅣ 같은 펑션모듈에 사용됨

우선 내 실수는

FILENAME-FILENAME 으로 .. 선언해버린 어처구니 없는 실수였지만

그 덕에 각각의 차이점에 대해 살펴 볼 기회가 생겼다.

사용하는 혹은 할 펑션에 따라 타입을 취사 선택하면 될 것으로 보인다.

나중에 조금 더 세분화 된 차이점을 공부해야겠다.

고객번호 / 전표번호 / 거래시작일

을 타 Internal Table에서 가져왔다.

Untitled

위와 같은 데이터 값이 저장되어있는데

여기에서 거래시작일 중 가장 최초거래일만을 가져와야 했는데

ABAP에서 MAP 같은 개념을 알지 못하여

고객번호별로 Loop을 돌리며 거래시작일을 Loop 돌리고

지역변수 하나(LV_BUDAT)를 생성 거래시작일을 넣어주고 LOOP안에서 비교하며 낮은 값을 넣어주는 방식으로 고민하다

LOOP에 LOOP도 찝찝하고 좀 바보같은 방법이길래 다른 방법이 없을까 고민하며 생각했던 건

고객번호별 거래시작일로 SORT 이후

DELETE ADJACENT DUPLICATES FROM [INTERNAL TABLE] COMPARING [ 필드네임 OR ALL FIELDS ] 였다.

혹시라도 최초거래시작일이 아닌 최근거래시작일을 구하고 싶다면

SORT itab BY field1 ASCENDING field2 DESCENDING.

이런식으로 필드별로 오름차순 내림차순을 정해주고 중복을 제거하면 될것.

훨씬 코드가 간결하고 가독성도 높으며 부가적인 변수 선언도 없으고 프로세스도 덜 먹는것으로 보인다.

잊지 말자 DELETE ADJACENT DUPLICATES

참조테이블과 참조필드

CURR 금액이 표기되는 컬럼의 경우에는 반드시 참조테이블과 참조 필드가 설정되어야 한다.

이유는 발생매출, 채권잔액, 당월매출금액, 매출잔고 등등... 금액이 어떤 방식으로 표기되는지를 기재해야 하기 때문이다.

예를 들어

USD라면 1.00 과 같이 소수점자리까지 표기되고

KRW라면 12000 과 같이 소수점자리 없이 표기되게 되는데

이를 정해주는것이 참조필드이며 일반적으로는 통화키 WAERS 가 결정하기 때문에

일반적으로는 같은 테이블의 통화키 WAERS를 참조해주고 이 외에는 참조할 테이블의 통화키를 참조해주면 된다.

나는 이 방식을 전혀 모르고 어떻게든 오류를 잡겠다고 다른 테이블을 참조하다가 다른 테이블의 WAERS를 참조해버렸으니 문제가 있는 것.

운 좋게 참조한 테이블의 WAERS값이 일치했다면 다행이지만 절대 올바른 방법도 아니기에 이런 실수를 제거해야한다.

2-1 IF NOT ~ IS INITIAL.

IF NOT GT_ITAB[] IS INITIAL. 을 사용하였는데

때에 따라 이렇게 넣어줘야 할 때도 있지만

굳이 하위 FORM에서 이렇게 한 것은 리소스 낭비였다

때에 따라 사용 할 줄 알아야겠다.

2-2 MOVE-CORRESPONDING ~ TO ~

MOVE-CORRESPONDING IITEM TO GT_ITAB.

을 사용해서 IITEM에 있는 몇개의 컬럼을 ITAB으로 옮겼다.

물론 굉장히 편리하지만 이건 개발자만을 위한 편함이었다.

컬럼수가 어느정도 안된다면 사용하는 것을 자제하도록 하자.

READ 문에 KEY값을 주고 Binary Search를 했는데

READ TABLE CT_MSEG1 WITH KEY UPPER = GT_ITAB-MATNR
MATNR = GT_ITAB-IDNRK
BINARY SEARCH.

이런식으로 READ문을 날리고 이후에 SY-SUBRC = 0 이 되면 수량을 넣는 것이었는데...

SY-SUBRC가 4만 나오는 것이었다... 디버깅 하며 값을 각각각각 보는데 일치하게 값이 나오는데도

SY-SUBRC의 값은 4....

바보같이 DATA TYPE 때문인가도 고민해보고 하다...

결국 알아차린건

SORT :

를 하지 않아버리고 BINARY SEARCH를 해버렸다는거...

BINARY SEARCH... SORT.... 기억하기

바보같은실수 += 1

함께 읽기 좋은 글

m.cafe.daum.net/ABAP4/2m4n/115?q=D_q63L_X4PY8o0&