본문 바로가기

SAP CO/깊숙한 개념

법인 간 거래와 Group Valuation - (2) 세팅

 

 

지난 글에서는 법인 간 거래 자재를 대상으로 표준원가를 사전 계산하는 방법을 살펴봤다. 이제는 실제 물류 흐름에 대해서 살펴보려고 하는데, 그 전에 세팅하는 방법부터 봐야할 것 같다. 이 부분 세팅이 (CO 입장에서는) 생소한데다가 길고 복잡하기 때문에 나중에 찾아보기 위해서라도 기록해두려고 한다. 나도 여기까지 해보는 데 많이 고생했다.

 

이 부분 세팅이 어려운 이유는 SD, MM, CO, FI의 내용이 모두 엮여 있기 때문이다. 사실 Group Valuation을 고려하지 않으면 더 일이 쉽게 풀릴 수 있는데, 이 요건까지지 충족하려다보니 더 어려워졌다. 다시 말해 그냥 SD/MM 요건만 고려하면 쉬운데 CO 입장에서 하고 싶은 것까지 하려니 어려웠단 말이다.

 

세팅에 앞서 간단히 비즈니스 시나리오부터 살펴보자.

 

 

비즈니스 시나리오

 

우리 예시는 한국 법인에서 미국 법인으로 내부거래가 일어나는 상황이다.

 

이 때 한국에서 미국으로의 운송은 선박을 이용하며 운송비는 미국 법인에서 물대와 함께 한국 법인으로 지불하고, 한국 법인이 다시 운송 업체로 납부해주는 방식이다.

 

한국에서 미국으로의 운송이 하루 이틀만에 되는 일은 아니기 때문에 운송중재고(Stock-in-Transit)가 생길 수 있다. 우리 사례에서는 FOB 조건으로 선적 이후의 재고는 받는 쪽 법인의 자산으로 잡기로 한다.

 

위 시나리오를 세팅하려면 우선 크게 아래와 같은 항목들이 정의되어야 한다.

 

 

  • (FI/SD/MM) 관계사 코드 생성, 관계사 BP 세팅
  • (CO) 자재원장의 Group Valuation 활성화, 그룹 평가용 표준원가 릴리즈, 법인 간 거래 연결 계정 설정 
  • (MM) 구매 오더의 STO 관련 세팅
  • (SD) 판매 오더 및 물류 실행의 STO 관련 세팅
  • (EDI) SD 빌링 문서로부터 MM 송장을 자동 생성할 수 있도록 세팅

딱 봐도 만만치 않아보인다. 하나씩 천천히 격파해보자.

 

 


1. (FI/SD/MM) 관계사 코드 생성, 관계사 BP 세팅

관계사 코드 생성(OX15) → 관계사 BP 세팅(보내는 쪽)(BP) → 관계사 BP 세팅(받는 쪽)(BP)

 

FI 세팅은 크게 특별할 것은 없다. 컴퍼니를 생성하고 이를 내부 관계사 코드로 사용한다. 내부 관계사 BP를 구성하고 컴퍼니와 연결하면 된다.

 

 

(1) 관계사 코드 생성(OX15)

관계사 코드 생성(OX15) → 관계사 BP 세팅(보내는 쪽)(BP) → 관계사 BP 세팅(받는 쪽)(BP)

 

 

T-CODE: OX15(내부 관계사 세팅)

 

다른 글에서 언급했던 것처럼 SAP에서 '회사'와 '회사 코드'는 다르다. 여기서 말하는 관계사 코드는 '회사'를 말하는 것이다. 나는 그냥 "컴퍼니"나 "트레이딩 파트너"라고 부른다. 

 

우리 예시에서는 회사코드와 컴퍼니를 1:1로 연결했다. 각각은 모두 하나의 관리회계 영역 안에 있다. Group Valuation을 위해서다.

 

 

(2) 관계사 BP 세팅(보내는 쪽)(BP)

관계사 코드 생성(OX15) 관계사 BP 세팅(보내는 쪽)(BP) → 관계사 BP 세팅(받는 쪽)(BP)

 

우리 환경은 S/4HANA이므로 BP를 이용해 고객과 공급업체를 생성한다. ECC였다면 T-CODE: XK01, XD01 등을 이용했을 것이다.

 

 

T-CODE: BP(비즈니스 파트너 유지보수) FI 공급업체 롤, 일반 데이터, 관계사 번호 세팅

 

공급 업체 BP에서 FI 공급 업체 롤을 선택한다. '제어' 탭에 있는 '관계사 번호'에 아까 생성했던 관계사 코드를 연결하면 된다. 이렇게 하면 이 BP는 우리 내부의 회사 중 하나가 된다.

 

 

T-CODE: BP(비즈니스 파트너 유지보수) FI 공급업체 롤, 회사코드 데이터, 조정 계정 세팅

 

미국 법인에서 사용할 조정 계정을 입력한다. 우리 예시에서는 '외상매입금 - 관계사'라는 계정을 썼다. 지급 조건도 입력한다. 여기서의 지급 조건 값은 MM 공급 업체 롤의 값과 맞춘다.

 

 

T-CODE: BP(비즈니스 파트너 유지보수) MM 공급업체 롤, 일반 데이터, 플랜트 지정

 

MM 공급 업체 롤에서는 '일반 데이터' 탭에서 '플랜트'를 연결한다. 이렇게 하면 이 BP를 사용하는 거래는 플랜트 1100(보내는 쪽 플랜트임)에서 출하가 일어나게 된다.

 

 

(3) 관계사 BP 세팅(받는 쪽)(BP)

관계사 코드 생성(OX15)  관계사 BP 세팅(보내는 쪽)(BP) 관계사 BP 세팅(받는 쪽)(BP)

 

 

T-CODE: BP(비즈니스 파트너 유지보수) FI 고객 롤, 회사코드 데이터, 조정 계정 세팅

 

FI 고객 롤에서는 한국 법인에서 사용할 조정 계정을 입력한다. 우리 예시에서는 '외상매출금 - 관계사'라는 계정을 썼다. 

 

 

T-CODE: BP(비즈니스 파트너 유지보수) SD 고객 롤, 일반 데이터, 관계사 번호 세팅

 

받는 쪽 BP는 SD 고객 롤에서 관계사 번호를 연결한다. 이렇게 하면 이 BP는 우리 내부 회사 중 하나가 된다.

 

 

T-CODE: BP(비즈니스 파트너 유지보수) SD 고객 롤, 판매 데이터, 출하 탭 세팅

 

'출하' 탭에서는 납품 플랜트, 출하 조건 등의 정보를 입력한다. 여기서 '납품 플랜트'란 보내는 쪽인 한국 법인 입장에서의 플랜트다. 받는 쪽 플랜트가 아님에 유의하자.

 

그리고 'POD 관련'에 체크했다. 우리 예시는 내부거래 시 운송중재고에 있던 항목을 POD를 통해 동시 출하/입고하는 시나리오이기 때문이다. POD는 Proof Of Delivery의 약자로, 이 프로세스를 따르면 출하된 수량이 정상적으로 납품되었는지를 점검하게 된다.

 

만약 '보내는 쪽 법인'에서 운송중재고를 잡을 필요가 있다면 POD를 사용해야 한다. 우리 예시에서는 운송중재고를 잡더라도 '받는 쪽 법인'에서 잡을 거기 때문에 굳이 찍을 필요는 없다.

 

 

T-CODE: BP(비즈니스 파트너 유지보수) SD 고객 롤, 판매 데이터, 청구 탭 세팅

 

'청구' 탭에서는 인코텀스와 지급 조건을 입력한다. 우리는 FOB를 선택했다. 나중에 이 조건에 따라 운임을 다르게 설정할 수도 있다.   

 

 

 


 

2. (CO) 자재원장의 Group Valuation 활성화, 그룹 평가용 표준원가 릴리즈, 법인 간 거래 연결 계정 설정

자재원장의 Group Valuation 활성화(생략) → 그룹평가용 표준원가 릴리즈(생략) → 법인 간 거래 연결 계정 설정(8KEN)

 

지난 글을 보셨으면 아시겠지만, 자재원장의 Group Valuation 활성화와 그룹 평가용 표준원가 릴리즈는 엄청나게 지난한 단계다. 각각 다른 글로 정리했으니 그 글을 보고 와주시기 바란다.

 

 

2022.02.21 - [SAP CO/기본 개념] - CO 관련 원장, 통화, 평가뷰 - (3) 평가뷰

 

CO 관련 원장, 통화, 평가뷰 - (3) 평가뷰

통화유형과 원장에 대해서 살펴봤다. 이어서 평가뷰도 이들과 뗄래야 뗄 수 없는 항목이어서 함께 이야기하고자 한다. 평가뷰는 재고를 여러 방식으로 평가하고 싶을 때 사용한다. 이 글은 아래

ckm3.tistory.com

 

2022.04.04 - [SAP CO/깊숙한 개념] - 법인 간 거래와 Group Valuation (1)

 

법인 간 거래와 Group Valuation (1)

지난 글인 『CO 관련 원장, 통화, 평가뷰 - (3) 평가뷰』에서 기본 개념을 봤었던 Group Valuation에 대해서 알아보고자 한다. 이번 편에서는 우선 그룹 평가를 이용해 법인 간 거래가 발생하는 자재를

ckm3.tistory.com

 

 

(1) 법인 간 거래 연결 계정 설정(8KEN)

자재원장의 Group Valuation 활성화(생략) → 그룹평가용 표준원가 릴리즈(생략) → 법인 간 거래 연결 계정 설정(8KEN)

 

 

T-CODE: 8KEN(평가차이 손비처리에 대한 계정 결정)

 

법인 간 거래 시 내부거래이윤을 차감하여 전달할 계정을 설정한다. 이 설정을 각각의 회사코드에 모두 세팅한다.

 

이 계정은 Group Valuation에서만 표시되는 계정이다. 원가요소로 생성하면 안 되고, 일반 손익 계정(N)으로 설정한다. 또한, 자동 전기만 가능한 계정으로 설정해야 정상적으로 세팅이 가능하다.

 

 

 


 

3. (MM) 구매 오더의 STO 관련 세팅

플랜트와 BP, 영업 영역 연결(IMG) → 플랜트별 납품 유형 및 가용성 점검 절차 구성(IMG) → 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정(IMG) 

 

 

(1) 플랜트와 BP, 영업 영역 연결(IMG)

플랜트와 BP, 영업 영역 연결(IMG) → 플랜트별 납품 유형 및 가용성 점검 절차 구성(IMG) → 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정(IMG) 

 

IMG PATH: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 플랜트의 출하 데이터 정의

 

 

IMG: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 플랜트의 출하 데이터 정의

 

보내는 쪽 플랜트인 1100에는 영업 영역을 설정하고, 받는 쪽 플랜트에는 고객 번호와 연결한다.

 

 

(2) 플랜트별 납품 유형 및 가용성 점검 절차 구성(IMG)

플랜트와 BP, 영업 영역 연결(IMG) → 플랜트별 납품 유형 및 가용성 점검 절차 구성(IMG) → 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정(IMG) 

 

IMG PATH: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 플랜트별 납품 유형 및 가용성 점검 절차 구성

 

 

IMG: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 플랜트별 납품 유형 및 가용성 점검 절차 구성

 

구매문서유형과 플랜트 조합에 따라 지정될 납품 유형과 가용성 점검 절차를 지정한다. 여기서 납품 유형은 'NLCC'(회사 간 보충)으로, 가용성 점검 절차는 'B'(SD 납품)으로 선택한다. 이렇게 하면 구매문서유형 'NB'(표준)으로 납품 플랜트 1100에 대해 NLCC, B를 사용하게 된다.

 

 

(3) 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정(IMG)

플랜트와 BP, 영업 영역 연결(IMG) → 플랜트별 납품 유형 및 가용성 점검 절차 구성(IMG) → 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정(IMG) 

 

IMG PATH: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정

 

 

IMG: 자재관리 > 구매 > 구매 오더 > 재고운송오더 설정 > 문서 유형, 원 스텝 절차, 미달 납품 허용 한도 지정

 

보내는 쪽 플랜트와 받는 쪽 플랜트를 입력하고 어떤 구매문서 유형을 사용할지 지정한다. 여기서도 'NB'(표준)를 입력한다. 다음으로 '원 스텝'이라는 게 체크되어 있는데 이게 체크되어 있으면 나중에 일정라인범주에서 '이동 유형 원 스텝'에 지정된 이동 유형을 쓰게 된다.

 

기본적으로 법인 간 거래에서 사용하는 일정라인범주인 'NC'에서는 원 스텝인 경우 이동 유형 '645', 투 스텝인 경우 이동 유형 '643'을 쓰게 되어 있다. 원 스텝으로 설정한 경우 나중에 출하/입고가 동시에 일어나게 되고, 투 스텝으로 설정하면 출하와 입고를 각각 따로 처리하게 된다.

 

미달 납품 허용 한도는 출하 시 납품 수량이 미달되었을 때의 허용한도를 쓸지 말지를 결정하는 키인데 우리는 그냥 체크해두고 넘어가자. 

 

 

 


 

4. (SD) 물류 실행과 판매 오더의 STO 관련 세팅

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

(1) 출하 지점 지정(IMG)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

IMG PATH: 물류 실행 → 출하 → 기본 출하 기능 → 출하 지점 및 입고 지점 결정 → 출하지점설정

 

 

IMG: 물류 실행 > 출하 > 기본 출하 기능 > 출하 지점 및 입고 지점 결정 > 출하지점설정

 

출하조건, 적재그룹, 플랜트에 따라 지정될 출하지점을 세팅한다. 출하조건, 적재그룹, 플랜트는 자재 마스터에 세팅된 값이다.

 

 

(2) 납품 유형 정의(0VLK)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: 0VLK(납품 유형 세팅)

 

법인 간 거래용으로 사전에 스탠다드로 설정된 납품 유형이 있다. 'NLCC'(회사 간 보충)이다. '오더 필요'라는 항목에 보면 "구매문서가 요구됨"으로 설정되어있다. 이렇게 하면 이 납품 유형 'NLCC'는 구매문서로부터 납품 문서를 만들 수 있게 된단 뜻이다.

 

 

(3) 납품의 품목 범주 정의(0VLP)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: 0VLP(납품 품목 범주 세팅)

 

품목 범주도 사전에 스탠다드로 설정된 게 있다. 'NLC'(회사 간 재고이전 품목)이며 이걸 그대로 쓰면 된다.

 

 

(4) 납품의 품목 범주 결정 정의(0184)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: 0184(납품 품목 범주 결정)

 

납품 유형, 품목 범주 그룹, 용도에 따라서 품목 범주를 매핑한 화면이다. 여기서 품목 범주 그룹은 자재 마스터 일반 탭과 영업 2 탭에서 관리하는 코드이다. 용도 'V'는 '판매 관리'란 뜻이다. 우리는 'NLC'로 매핑되게끔 설정했다.

 

 

(5) 납품 일정라인범주 정의(VOV6)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: VOV6(일정라인범주 유지보수)

 

여기서 기본 설정은 'NC'(회사 간 보충)이다. 이 경우 아까 원 스텝으로 설정했으면 이동 유형 '645'로, 투 스텝으로 설정했으면 이동 유형 '643'을 쓰게 된다.

 

그렇지만 우리 예시에서는 FOB 선적조건으로 미착 관리를 사용할 것이기 때문에 NC가 아니라 N1을 봐야 한다.

 

 

T-CODE: VOV6(일정라인범주 유지보수)

 

일정라인범주 'N1'(입고 CST)을 사용하면 이동 유형 '683'으로 출고하고 이동 유형 '107'으로 운송중재고로 입고된다. 이 운송중재고는 나중에 T-CODE: MIGO를 통해 정리하면 이동 유형 '109'로 가용 재고로 입고되게 된다.

 

일정라인범주 'N2'(츨고 CST - 입고 플랜트)를 사용하면 이동 유형 '681'로 출고하면서 보내는 쪽의 운송중재고로 입고된다. 이 때는 Sale Order Stock으로 자재원장에 기록된다. 이후 POD를 통해 입고처리하게 되면 이동 유형 '685'로 출고되면서 동시에 이동 유형 '101'로 입고된다.

 

나중에 우리 예시에서는 'N1'으로 했을 때로 살펴볼 생각이다.

 

 

(6) 납품 일정라인범주 지정(IMG)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

IMG PATH: 판매 관리 > 매출액 > 판매 문서 > 일정 라인 > 납품 일정라인범주 지정

 

 

IMG: 판매 관리 > 매출액 > 판매 문서 > 일정 라인 > 납품 일정라인범주 지정

 

품목범주가 'NLC'일 때 납품 일정라인범주는 어떤 걸로 지정할지 세팅하는 화면이다. 원래는 'NC'로 되어 있었으나 이 부분을 'N1'으로 변경했다.

 

  

(7) 가격결정절차 세팅(V/08)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: V/08(가격 결정 절차 유지보수)

 

법인 간 거래에서 기본으로 사용하는 가격결정절차는 'ICAA01'이다. 일반 판매 오더에서 사용하는 'RVAA01'과는 다르다. 여기서 조건 유형들을 살펴보면 'KW00'라는 게 있다. 이게 바로 그룹 평가 기준의 릴리즈된 표준원가이다.

 

법인 간 내부이체가격은 'IV01'에 입력한다. 추가로 운임도 'KF00'에 입력하면 된다. 해당 조건의 값 입력은 다음 글에서 살펴보도록 하겠다.

 

각 조건 유형에는 '조건'이라는 필드가 있는데 "22"로 입력하면 법인 간 거래에서 사용할 수 있게 된다. 계정키 필드는 T-CODE: VKOA에서 G/L 계정과 연결할 수 있다.

 

  

(8) 가격결정절차 지정(OVKK)

출하지점 지정(IMG) → 납품 유형 정의(0VLK) → 납품의 품목 범주 정의(0VLP) → 납품의 품목 범주 결정 정의(0184) → 납품 일정라인범주 정의(VOV6) → 납품 일정라인범주 지정(IMG) → 가격 결정절차 세팅(V/08) → 가격 결정절차 지정(OVKK) → 품목 범주에 POD 지시자 세팅

 

 

T-CODE: OVKK(판매 문서의 가격 결정 절차)

 

영업영역과 가격결정절차를 연결한다. 여기서 문서 분류 'I'가 '회사 간 청구'이다. 여기에 아까 정의했던 가격결정절차를 지정하면 된다.

 

 

 


 

5. (EDI) SD 빌링 문서로부터 MM 송장을 자동 생성할 수 있도록 세팅

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

EDI에 대한 설정이 가장 길고 빡세다.

 

왜 EDI를 구성할 수밖에 없는가? SD 빌링 문서를 어떤 식으로든 참조해서 MM 송장을 그냥 만드는 게 낫지 않을까? 그런데 바로 우리가 원하는 Group Valution 때문에 그렇지가 않다. SAP Note 『2376845 - C+884 error while posting an invoice』 에 따르면 EDI를 통해 송장을 만들어야 그룹 평가 정보를 제대로 전달해줄 수 있다고 한다. 

 

 

(1) 출력 유형 설정(V/40)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: V/40(출력 유형 설정)

 

어플리케이션 'V3'(빌링)에 대해 출력 유형 'RD04'를 세팅한다. 여기서 파트너 역할을 'EDI', 기능을 'BP'로 한다. 이렇게 하면 빌링 문서를 출력해서 EDI를 통해 타 부문에 MM 송장으로 전자문서를 전달해주게 된다.

 

 

(2) 파트너 기능에 출력 유형 지정(IMG)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

IMG PATH: 판매 관리 > 기본 기능 > 출력 결정 > 출력 결정 > 조건 기법을 사용하여 출력 결정 > 대금청구 문서에 대한 출력 결정 유지보수 > 파트너 기능에 출력 유형 지정 

 

 

IMG: 판매 관리 > 기본 기능 > 출력 결정 > 출력 결정 > 조건 기법을 사용하여 출력 결정 > 대금청구 문서에 대한 출력 결정 유지보수 > 파트너 기능에 출력 유형 지정

 

여기서 RD04(송장 수량 MM), 6(EDI), BP(청구처)을 세트로 만든다. 결국 T-CODE: V/40에서 설정했던 내용과 같다.

 

 

(3) 출력 결정 절차 유지보수(IMG)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

IMG PATH: 판매 관리 > 기본 기능 > 출력 결정 > 출력 결정 > 조건 기법을 사용하여 출력 결정 > 대금청구 문서에 대한 출력 결정 유지보수 > 출력 결정절차 유지보수 

 

 

IMG PATH: 판매 관리 > 기본 기능 > 출력 결정 > 출력 결정 > 조건 기법을 사용하여 출력 결정 > 대금청구 문서에 대한 출력 결정 유지보수 > 출력 결정절차 유지보수

 

여기서 절차 'V40000'(회사 간 대금청구)의 값을 확인한다. 기본으로 'RD00'와 'RD04'가 연결되어 있을것이다.

 

 

(4) 출력 결정 절차 지정(V/25)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

T-CODE: V/25(대금청구문서유형 출력결정절차 지정)

 

빌링 타입 'IV'(회사 간 청구)에 아까 봤던 절차 'V40000'과 출력 유형 'RD04'를 연결한다.

 

 

(5) 출력 유형을 영업조직/고객번호에 지정(VV31)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

T-CODE: VV31(출력 생성 - 조건레코드 송장수령 MM)

 

출력 유형 'RD04'를 영업 조직 '1000', 고객 'BP2100'(미국 법인)으로 연결했다.

 

(6) 청구: 문서 유형 확인(VOFA)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

T-CODE: VOFA(청구 - 문서유형 설정)

 

빌링에 대한 문서 유형인 'IV'에 지정된 파라메터들을 확인한다. 기본적으로 우리가 앞서서 확인했던 지정 사항들이 다 표시된다.

 

 

(7) 공급업체 지정(WEL1)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

T-CODE: WEL1(EDI: EDILOGADR에 대한 인터페이스송장)

 

논리주소에 따라 타겟이 될 회사코드와 공급업체를 읽어온다. 이 로직은 펑션 모듈 'IDOC_OUTPUT_INVOIC_IV_MM'에서 테이블의 값을 가져올 때 사용된다.

 

 

ABAP Debuger 화면(펑션 모듈 IDOC_OUTPUT_INVOIC_IV_MM)

 

디버깅을 통해 확인해보면 이런 방식이다. 깊게는 몰라도 된다.

 

 

(8) IV에서 CO로 계정 지정 요소 교환(VOFC)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: VOFC(대금청구문서 IV에서 CO로 계정요소교환)

 

IG와 IV가 체크되어 있다. 확인하고 넘어가자.

 

 

(9) 송장<->회사코드 이름 지정(OBCA)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: OBCA(EDI: 송장<->회사코드 이름 지정)

 

파트너 유형이 'LI'(공급 업체)이고 공급 업체 BP 코드가 'BP1100'일 경우 회사코드는 무엇으로 할지를 결정한다. 우리 사례에서는 2000(미국 법인)으로 했다.

 

 

(10) 세금코드 변환(OBCD)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: OBCD(EDI: 외부세율 <-> 세금코드 변환)

 

이번에는 빌링 시의 세율과 송장 처리 시의 세율 간 매핑을 입력한다. 우리 사례에서는 세금까지 신경쓰긴 귀찮아서 각각의 세율은 모두 0%로 맞춰놨다.

 

 

(11) 프로그램 매개변수 구성(OBCE)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: OBCE(EDI-INVOIC 프로그램 매개변수 구성)

 

송장 처리 시 전기 키와 전표 유형 관련 정보를 세팅한다.

 

 

(12) IDoc 포트 구성(WE21)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: WE21(IDoc 처리 포트)

 

EDI를 전송할 IDoc의 포트를 구성한다. 우리 예시에서는 동일한 시스템의 동일한 클라이언트 내에서 전송하는 것이므로, '트랜잭션 RFC'를 선택하고 연결 대상을 동일 클라이언트로 지정해주면 된다.

 

 

(13) IDoc 파트너 프로파일 설정(WE20)

출력 유형 설정(V/40) → 파트너 기능에 출력 유형 지정(IMG) → 출력 결정 절차 유지보수(IMG) → 출력 결정 절차 지정(V/25) → 출력 유형을 영업조직/고객번호에 지정(VV31) → 청구: 문서유형 확인(VOFA) → 공급업체 지정(WEL1) → IV에서 CO로 계정 지정 요소 교환(VOFC) → 송장<->회사코드 이름 지정(OBCA) → 세금코드 변환(OBCD) → 프로그램 매개변수 구성(OBCE) → IDoc 포트 구성(WE21) → IDoc 파트너 프로파일 설정(WE20)

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 KU(고객)

 

우선 파트너 유형 'KU'(고객)부터 세팅한다. 미국 법인의 BP 코드를 입력하고, 아웃바운드로 파트너 역할과 메시지 유형을 설정한다.

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 KU(고객), 아웃바운드 매개변수

 

여기서 파트너 역할은 'BP', 메시지 유형은 'INVOIC', 메시지 코드는 'MM'으로 설정한다. 아웃바운드 옵션에는 포트는 아까 설정했던 포트를 입력하고, 기본 유형은 'INVOIC01'로 입력한다.

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 KU(고객), 아웃바운드 매개변수, 메시지 제어 탭

 

메시지 제어 탭에서는 어플리케이션은 'V3'(청구), 메시지 유형은 'RD04'(송장수령 MM), 프로세스 코드는 'SD08'(INVOIC: 내부 할당)으로 입력한다. 여기서 SD08을 더블 클릭해보면

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 KU(고객), 아웃바운드 매개변수, 메시지 제어 탭, 프로세스 코드 SD08

 

펑션 모듈 'IDOC_OUTPUT_INVOIC_IV_MM'이 지정되어 있다. 바로 여기서 ABAP으로 구성된 코드에 따라 로직이 흐르게 된다. 이 펑션을 통해 빌링 문서의 내용이 송장 처리를 위해 필요한 데이터로 변환하여 전자 문서로 전달된다.

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 LI(공급업체)

 

이어서 파트너 유형 'LI'(공급 업체)를 본다. 한국 법인의 BP 코드를 입력한다. 여기서는 아웃바운드가 아니라 인바운드로 파트너 역할과 메시지 유형을 설정한다.

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 LI(공급업체), 인바운드 매개변수

 

인바운드 옵션에서 프로세스 코드인 'INVL'을 더블 클릭해보면

 

 

T-CODE: WE20(파트너 프로파일 설정) 파트너 유형 LI(공급업체), 인바운드 매개변수, 프로세스 코드 INVL

 

펑션 모듈 'IDOC_INPUT_INVOIC_MM'이 지정되어 있다. 여기서는 아까 빌링에서 받았던 전자 문서를 인풋으로 하여 실제로 MM 송장 문서를 만들어내는 로직이 담겨 있다.

 

 

 


 

6. 이어서...

 

여기까지 세팅은 끝났다. 세팅만 해도 굉장히 많고 어렵다. 이제 실제 물류 트랜잭션을 처리하면 어떤 모습으로 나타나는지 다음 글에서부터 살펴보자.