선적·매출 기간귀속 다차원 분석 리포트 — 수출 매출이 어느 달에 잡혔는지, 통제 이전 시점 기준과 얼마나 다른지 요인으로 가르는 점검 화면

도입 포인트 — 이 앱을 사용해야 하는 이유

수출 회사의 월 마감 때 반복되는 질문이 있습니다. 이 매출은 어느 달에 잡아야 하나, 선적한 달인가 청구서를 낸 달인가, 지난달에 앞당겨 잡은 것과 이번 달로 미룬 것이 각각 얼마인가. 인코텀즈가 FOB·CIF 이면 선적 시점에, DAP·DDP 이면 도착 시점에 통제가 넘어간다고 보는 것이 보통인데, 청구 문서는 영업 사정에 따라 선적보다 먼저 나가기도 하고 한참 뒤에 나가기도 합니다. 지금은 이 답이 청구 문서 조회, 출하 문서 조회, 회계 전표 조회, 그리고 마감 때마다 만드는 엑셀에 흩어져 있습니다. 이 화면은 같은 수출 청구 데이터를 선적일·통제 이전일·청구 전기일 세 날짜와 함께 한 큐브에 모아 월별로 돌려 보고, 통제 이전 시점 기준과 어디서 얼마나 달라졌는지를 한 화면에서 답하도록 이어 붙입니다.

표준 화면(VA03 · VL03N · VF03 · FB03 · KE30)은 각자 맡은 문서를 정확히 보여 줍니다. 다만 “청구한 달 기준 인식액과 통제 이전한 달 기준 인식액이 얼마나 다르고, 그 차이가 어떤 이유로 생겼는가” 를 한 번에 가르는 자리는 표준 화면 사이에 있습니다. 이 앱은 표준 실행은 SAP 표준 T-code 에 그대로 두고, 그 사이를 조회·검증 관점으로 메웁니다. 판단은 숫자를 단정하지 않고 점검 필요 · 확인 필요로 남깁니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 청구한 달과 통제가 넘어간 달이 다를 때

검증용 샘플 데이터(2026년 1월~9월 수출 청구 2,975줄, 고객 14·제품 12·국가 8·통화 4)에서 장부 인식액은 28,221백만원, 통제 이전월 기준 인식액은 28,403백만원으로 총차이는 −183백만원입니다. 합계만 보면 0.6% 차이라 넘어가기 쉽습니다. 여섯 요인으로 가르자 모양이 달라집니다.

같은 달에 통제 이전과 인식이 함께 일어난 정시 인식률은 81.92%(기준 81.35%)이고, 월별 이동 비율은 14.2%에서 23.5% 사이를 오갑니다. 국가별로는 미국(−133)·독일(−102)·폴란드(−80)는 장부가 기준보다 적게, 베트남(+98)·중국(+47)은 많게 잡혔습니다. 월별로는 8월이 장부 2,959 대 기준 3,280(−321), 4월이 3,134 대 2,921(+213)로 가장 크게 벌어집니다. 이 화면은 원인을 단정하지 않고 선적 시점 청구를 점검해야 할 고객·국가·인코텀즈를 금액 순으로 올려 줍니다. 요인 합계가 총차이와 같은지는 매번 검산하며, 이 샘플의 대사 검사 78건은 모두 차이 0건입니다.

도입하면 달라지는 것

• 마감 회의의 주제 — “이 달 매출이 맞나” 가 아니라 “DAP·DDP 청구 시점을 어떻게 볼 것인가” 로 옮겨 갑니다.
• 보고 준비 — 인식액·기준·요인분해·사유·보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 다음 조회로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않아도 규칙에 걸린 항목이 받을 역할의 대기함에 올라옵니다.

이런 회사에 맞습니다

외화로 수출 청구를 내고 인코텀즈가 FOB·CIF 와 DAP·DDP 로 섞여 있어 통제 이전 시점이 계약마다 다른 제조·유통 회사에 맞습니다. 월말 선적이 많거나 서류·통관 확인 때문에 청구가 늦어지는 일이 잦은 곳, 수출 국가와 통화가 여럿이라 환율 효과를 시점 이동과 따로 읽어야 하는 곳일수록 효과가 큽니다. 수출 영업, 물류, 회계(결산) 담당이 같은 숫자를 놓고 이야기해야 하는 조직, 월 마감 전에 매출 인식 시점을 점검하는 회의를 여는 조직을 염두에 두었습니다. 반대로 수출 비중이 작아 월별 이동이 눈에 띄지 않거나, 통제 이전 시점 정책이 아직 정해지지 않은 회사는 정책부터 정해야 합니다.

실행 화면

사용 방법

1. 조회조건 입력 — 필수는 회사코드와 시작·종료 기간입니다(기본값 1000, 2026-01 ~ 2026-09). 비교 기준은 통제 이전월 기준으로 고정이고, 저장된 레이아웃 선택은 선택 사항입니다.
2. 조회 — 조회 단추는 조회조건 영역 오른쪽 끝에 있고, 회사코드 칸에서 Enter 키를 눌러도 같은 조회가 됩니다. 조회 전에도 레이아웃 보드와 피벗 틀이 먼저 보입니다. 기본 레이아웃에 자동 조회를 지정하면 화면을 열 때 조회된 채로 시작합니다.
3. 요약 확인 — 표 위의 역할별 요약에서 경영자 · 재무 책임자 · 영업 책임자 · 물류 책임자를 바꾸면 앞세우는 지표 네 개와 쪼개 보는 차원이 함께 바뀝니다. 다시 조회하지 않습니다.
4. 축 바꾸기 — 레이아웃 보드의 차원 단추를 쓰지 않는 차원 · 행 · 열 칸으로 끌어다 놓습니다. 행은 3단계, 열은 2단계까지이며, 서버를 다시 부르지 않고 브라우저가 가진 큐브를 바로 다시 묶습니다. 차원 필터 단추에서는 값을 여러 개 고릅니다.
5. 행·셀 클릭 상세 — 행의 화살표로 하위 차원까지 내려가고, 금액 칸을 누르면 그 금액을 만든 청구 문서 라인이 열립니다. 위쪽 기간별 요약 단추는 월별 요약을 보여 줍니다.
6. 계산항목과 기준 대비 — 조기 이동분 · 지연 이동분 · 이동 비율 같은 계산항목을 고르고 보기 방식을 단계 보기로 바꾸면 인식 단계가 행으로 펼쳐집니다. 기준 대비 스위치를 켜면 칸마다 장부 · 기준 · 차이 · 증감률이 붙고, 차이가 난 행에서 사유를 남기며, 차트의 차이 분해 탭에서 워터폴과 검산 줄을 봅니다.
7. AI 분석·에이전트 — 위쪽 AI 분석에서 현재 범위의 해설과 근거 표를 읽고, AI 에이전트에서 감시 규칙 · 받은 보고 · 실행 기록 탭을 오가며 실행합니다.
8. 내보내기·저장 — AI 분석 창의 보고서 단추로 PowerPoint 보고서를, 위쪽 CSV 단추로 현재 표(사유 포함)를 내려받습니다. 레이아웃 메뉴에서는 현재 배치를 이름 붙여 저장합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤과 직접 그린 SVG 차트로 짰고, 데이터는 OData V2 서비스 하나에서 읽습니다. 서비스 쪽에서 판정하는 일과 브라우저가 맡는 일을 아래처럼 나눴습니다.

앱 정보

실제 브라우저에서 검증용 샘플 데이터로 찍은 화면 28종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때 — 조회 전에도 틀이 먼저 보입니다

처음 열었을 때에는 아직 서비스를 부르지 않은 상태에서도 화면의 뼈대가 보입니다. 조회 직후 한 화면에 표 · 차트 · 요약이 함께 뜹니다.

회사코드 · 시작·종료 기간 · 비교 기준 · 저장된 레이아웃과 그 아래 레이아웃 보드가 조회 전에도 먼저 뜹니다. 조회 단추는 조회조건 영역 오른쪽 끝에 있고, 회사코드 칸에서 Enter 키를 눌러도 같은 조회가 됩니다. 기본 배치는 행 지역 › 국가이며 열은 비어 있습니다.

조회 한 번으로 장부 큐브 1,033건(원천 청구 2,975줄)을 읽어 표 · 차트 · 역할 요약을 그립니다. 경영자 요약은 장부 인식액 28,221백만원과 정시 인식률 81.92%를 앞세우고 각 값 아래에 기준과 대비를 붙입니다. 표 왼쪽 화살표로 지역 아래 국가를 펼치면 차트도 함께 바뀝니다.

조회 조건 영역을 접으면 회사 · 기간 · 행·열 구성 · 항목 · 기준 대비 여부 · 필터 수가 한 줄에 남고 표와 차트가 화면을 더 씁니다. 다시 펼치면 조건이 그대로 있습니다.

경영 요약 — 역할 네 개

같은 큐브를 역할마다 다른 눈으로 읽습니다. 역할을 바꿔도 다시 조회하지 않고 앞세우는 지표와 쪼개 보는 차원만 바뀝니다.

경영자 역할은 장부 인식액 · 기준 인식액 · 정시 인식률 · 이동 비율을 앞세우고 국가별로 쪼갭니다. 값마다 기준과의 대비가 붙어 “어디서 달라졌나” 를 첫 화면에서 읽습니다.

재무 책임자 역할은 마감에 직접 영향을 주는 이동분과 환율 효과를 앞세우고 고객별로 쪼갭니다. 기준과의 차이가 큰 고객이 먼저 보입니다.

영업 책임자 역할은 청구가 늦어진 몫(지연 이동분)을 국가별로 보여 줍니다. 늦게 잡힌 이유가 청구 지연인지 서류·통관 대기인지는 이동 사유 계산항목으로 이어서 봅니다.

물류 책임자 역할은 선적 전에 앞서 잡힌 몫(조기 이동분)을 인코텀즈별로 보여 줍니다. DAP · DDP 처럼 도착 시점에 통제가 넘어가는 조건에서 선적 시점 청구가 몰려 있는지 확인하는 자리입니다.

축 바꾸기 — 서버를 다시 부르지 않고 돌려 봅니다

차원 단추를 끌어다 놓기만 하면 브라우저가 가진 큐브를 바로 다시 묶습니다. 어떤 배치에서도 총합은 같아야 하고, 이 값이 갈라지는지를 배치 6가지로 시험했습니다.

열에 인식월을 올리자 월별 인식액이 나란히 서고 오른쪽 끝에 합계가 붙습니다. 이 동작이 서비스 호출 0건이라는 것, 그리고 합계가 28,220,585,809원으로 배치와 관계없이 같다는 것을 시험으로 확인했습니다.

차원 필터 단추에서 값을 여러 개 고릅니다. 같은 차원 안은 또는, 다른 차원끼리는 그리고로 묶이고, 큐브에 있는 값만 목록에 올라옵니다.

일본과 미국을 고른 결과 합계는 9,459,910,287원으로, 큐브에서 두 국가 값을 직접 합한 값과 같았습니다. 필터는 서버를 다시 부르지 않고 브라우저에서 걸립니다.

칸에서 청구 문서까지 — 세 날짜를 함께 봅니다

이 화면의 핵심 질문은 “이 금액이 어느 문서의 어느 날짜에서 나왔나” 입니다. 금액 칸을 누르면 바로 문서 라인이 열립니다.

금액 칸을 누르면 그 금액을 만든 청구 문서 라인이 열리고 칸 금액과 문서 라인 합계가 같은지 머리에 표시됩니다. 줄마다 선적일 · 통제 이전일 · 청구 전기일 · 이동 사유가 보이며 기본 500행씩 페이지로 넘깁니다. 칸 10개를 시험해 모두 일치했습니다.

위쪽 기간별 요약 단추는 월별 인식액과 이동분을 한 장으로 보여 줍니다. 월마다 정시 인식분과 이동분의 비중이 어떻게 달라지는지 훑는 용도입니다.

조기 이동분 · 지연 이동분 · 이동 비율 같은 계산항목을 고르고 보기 방식을 단계 보기로 바꾸면 인식 단계가 행으로 펼쳐집니다. 각 단계의 금액이 어떤 이동 사유에서 왔는지 한 표에서 읽습니다.

기준 대비 차이 — 어디가 얼마나 다른가

기준 대비 스위치를 켜면 칸마다 장부 · 기준 · 차이 · 증감률이 붙습니다. 인식 시점은 빠르다고 좋고 늦다고 나쁜 값이 아니라서 초록 · 빨강을 쓰지 않고 주황 한 색으로 점검할 칸만 표시합니다.

차이 금액이 1천만원 이상이고 증감률이 5% 이상인 칸만 주황으로 칠해집니다(이동 비율 같은 비율 항목은 0.5퍼센트포인트 이상). 샘플에서 색이 칠해진 칸 21개는 임계를 넘는 칸 21개와 일치했습니다.

차이가 난 행의 사유 단추로 사유를 적습니다. 사유는 조회 범위와 행 경로에 묶여 저장되며, 원인을 단정하는 문구 대신 담당자가 원천 문서로 확인한 내용을 남기도록 했습니다.

사유를 저장한 행에는 표시가 붙고, 축을 바꾸거나 다시 조회해도 그 행에 따라옵니다. AI 분석이 같은 행을 다시 짚을 때는 이미 기록된 행으로 건너뜁니다.

기준 인식액 28,403에서 장부 인식액 28,221까지 요인별 막대로 이어 보여 줍니다. 앞서 인식한 막대와 늦게 인식한 막대는 서로 다른 중립 색이고 빨강과 초록은 쓰지 않습니다.

요인 여섯 개의 합이 총차이 −183백만원(−182,900,056원)과 같은지 화면이 매번 검산 줄로 보여 줍니다. 합이 맞지 않는 것 자체가 오류 신호라서 말없이 넘어가지 않습니다.

AI 분석과 AI 에이전트 — 숫자는 서비스가, 글은 AI가

AI 분석은 서비스가 계산한 값을 문장으로 옮기는 규칙 기반 해설이고, 모델 연결은 설정 한 곳에서 켜는 선택 사항입니다(기본 꺼짐). 에이전트는 같은 계산 결과를 규칙에 대 보고 대기함에 올립니다.

현재 범위의 요약과 핵심 발견을 보여 줍니다. 총차이 −183백만원 가운데 도착 조건 선인식(−164)의 영향이 가장 크다고 읽되 원인은 단정하지 않고 점검 필요 항목만 제시합니다. 근거 표를 펼치면 같은 숫자를 확인할 수 있습니다.

규칙 다섯 개가 기본으로 들어 있고, 임계값과 받을 역할은 화면에서 바꿔 저장합니다. 임계는 숫자로 드러나 있어 왜 이 항목이 올라왔는지 설명할 수 있습니다.

규칙에 걸린 항목이 받을 역할별로 대기함에 쌓입니다. 보고에는 걸린 이유와 금액, 다음에 볼 화면이 적혀 있습니다.

실행은 하루 한 번만 허용되고(서비스가 판정) 걸린 항목이 없어도 활동 기록이 남습니다. 두 번째 실행은 하루 한 번 제한으로 건너뛰었다고 기록됩니다.

레이아웃 — 자주 쓰는 배치를 이름 붙여 저장합니다

행·열·필터·항목 구성은 이름을 붙여 서버에 저장하고, 기본 레이아웃과 자동 조회를 지정하면 다음 번에는 열자마자 같은 모양으로 시작합니다.

레이아웃 메뉴에서 현재 배치를 저장하거나 저장한 배치를 불러오고, 관리 창에서 이름 바꾸기 · 삭제 · 기본 지정을 합니다.

저장 창에서 이름을 적고 기본 레이아웃과 자동 조회를 지정합니다. 자동 조회는 화면을 열 때 곧바로 조회까지 실행하는 선택입니다.

화면을 새로 고쳤더니 기본 레이아웃으로 조회까지 끝낸 상태로 시작했습니다. 축 구성, 필터, 항목이 저장한 그대로 복원되는 것을 확인했습니다.

한계 — 일부러 둔 상한과 좁은 화면

큐브를 브라우저가 들고 있는 방식이라 상한을 일부러 두었습니다. 상한에 닿았을 때 말없이 잘라 내지 않고 안내를 띄웁니다.

행에 기간 · 고객 · 제품을 쌓자 행 조합이 514개가 되어 500개 상한을 넘었고, 표 대신 범위를 좁히라는 안내가 나옵니다. 열 조합은 36개를 넘으면 추가 자체를 막습니다.

폭 390px 에서 조회조건이 세로로 쌓이고 표는 가로로 밀어 볼 수 있습니다. 모든 화면 요소가 한 열에 놓입니다.

좁은 화면에서는 오른쪽에 있던 차트가 표 아래로 내려옵니다. 넓은 화면에서 표와 차트 사이 손잡이로 조절한 너비는 브라우저가 기억합니다.

인식 시점 판정과 차이 요인 규칙

화면이 장부 인식월과 통제 이전월을 어떻게 정하는지, 그 둘이 다를 때 어떤 이름을 붙이는지입니다. 아래 구분은 날짜 관계로 나눈 분류이며 원인을 단정하지 않습니다.

차이 모드의 색 판정과 6요인 산식

장부 인식액과 기준 인식액은 같은 조합(회사 · 고객 · 제품 · 인코텀즈)마다 한 행씩 비교합니다. 총차이(장부 − 기준)는 아래 다섯 이동 사유의 차이와 환율 요인으로 나뉘고, 합이 총차이와 같도록 식을 닫아 두었습니다.

AI 에이전트 감시 규칙

조회조건과 결과 구성

데이터 구성과 파일 구성

앱은 화면(view · controller) · 모델(피벗 · SVG 차트 · 보고서 · 레이아웃) · OData 서비스(엔진 · 서비스 · 메타데이터 · 샘플 데이터) · 소개 영상 · 설명서로 나뉘고, 검증 전용 자료는 별도 폴더에 두어 앱 본체가 참조하지 않습니다. 고객 · 제품 · 문서 번호 · 환율은 모두 가상 또는 가정값입니다.

SAP 표준 기능 확장 포인트

이 화면은 표준 T-code 를 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 같은 수출 청구 데이터를 조회·검증 관점으로 묶어 확장합니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 없애지 않습니다. 법정·감사·세무 신고 대응은 표준 화면과 표준 리포트에 그대로 남기고, 이 화면은 월 마감 전에 매출 인식 시점을 점검하는 용도로 나란히 씁니다. 두 화면의 합계가 어긋나면 어느 쪽이 틀렸다고 단정하지 말고 위 대사 지점부터 확인 필요로 놓고 맞춰 갑니다.

S/4HANA 분석 스택과의 자리

S/4HANA 는 CDS 뷰 위에 분석 쿼리를 올려 Fiori 분석 앱과 Analysis for Office 로 읽는 구조를 갖고 있습니다. 이 앱의 CDS 구성(아래 CDS 구성 절)은 같은 분석 쿼리 층에 올라가는 것이라, 운영에서는 같은 큐브와 쿼리를 표준 분석 도구가 읽고 이 화면이 끌어다 놓기·드릴스루·요인분해·AI 분석을 더하는 식으로 나란히 쓸 수 있습니다. 매출 인식 영역의 표준 분석 앱 이름과 제공 여부는 릴리스마다 달라 이 글에서는 이름을 적지 않으며, 도입 시 확인 필요 항목입니다.

확장 포인트 — 운영에서 실제로 손대는 자리

분석 지표 정의

CDS 구성

이 샘플의 화면은 청구 2,975줄(조회 기간분)을 큐브 1,033건으로 묶어 브라우저가 들고 있습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일은 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰의 층 구성과 코드입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로 그대로 붙여 넣기 전에 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 표준 CDS 뷰는 이름을 단정하지 않고 원천 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 매핑 테이블 — 현업이 늘리는 묶음

분석용 묶음(국가→지역, 자재→제품그룹)은 마스터에 없습니다. 이 테이블 한 장이 그 묶음을 맡고, 정하지 않으면 그룹 합계가 기존 보고서와 맞지 않습니다. 매핑이 없는 값은 아래 뷰에서 UNMAPPED 로 남겨 합계에서 사라지지 않게 합니다.

// ─────────────────────────────────────────────────────────────
// ZCUTF_MAP : 국가→지역, 자재→제품그룹 매핑 (기준)
// 하는 일 : 마스터에 없는 "분석용 묶음"을 현업이 직접 관리하는 테이블
// 이렇게 나눈 이유 : 새 국가·제품이 생길 때마다 뷰를 고치면 전송이 필요하다.
//   테이블이면 현업이 행만 추가한다. (국가·자재 마스터 필드는 확인 필요)
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '매출 기간귀속 분석 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcutf_map {
  key client   : abap.clnt not null;
  key map_type : abap.char(1) not null;     // C=국가→지역, M=자재→제품그룹
  key map_key  : abap.char(18) not null;    // 국가코드 또는 자재번호
  map_value    : abap.char(10);             // 지역 또는 제품그룹 코드
  map_text     : abap.char(40);
}

② 통제 이전 기준 테이블 — 인코텀즈별 시점과 운송일수

어떤 인코텀즈를 선적 시점에, 어떤 인코텀즈를 도착 시점에 통제가 넘어가는 것으로 볼지는 회사와 계약이 정합니다. 샘플은 FOB · FCA · CIF · CPT 를 선적 시점, DAP · DDP 를 선적일 + 운송일수로 가정했습니다. 이 가정을 코드에 박지 않고 테이블로 빼 두면 정책이 바뀌어도 뷰를 고치지 않습니다.

// ─────────────────────────────────────────────────────────────
// ZCUTF_CTRL : 인코텀즈별 통제 이전 기준 (기준)
// 하는 일 : 인코텀즈마다 통제 이전일을 어떻게 계산할지 정한다
// 이렇게 나눈 이유 : 통제 이전 시점은 회계 정책이라 개발자가 정할 일이 아니다.
// 확인 필요 : 계약별 예외를 어떻게 담을지(수주 단위 예외 테이블 등)
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '통제 이전 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcutf_ctrl {
  key client    : abap.clnt not null;
  key incoterms : abap.char(3) not null;    // FOB · FCA · CIF · CPT · DAP · DDP ...
  basis         : abap.char(1);             // S=선적일 기준, A=선적일 + 운송일수
  transit_days  : abap.int2;                // basis = A 일 때만 사용 (샘플은 가정값)
  valid_from    : abap.dats;
}

③ 기준 뷰 — 청구 품목 한 줄에 선적일과 인코텀즈

여기서 결정되는 것은 “어떤 청구를 수출 실적으로 볼 것인가” 입니다. 취소 문서 제외와 수출 청구 유형 한정 조건이 이 뷰의 where 에 들어가고, 이 조건이 달라지면 이후 모든 숫자가 달라지므로 운영에서 가장 먼저 합의합니다.

// ─────────────────────────────────────────────────────────────
// ZI_CutofBillItem : 청구 품목 한 줄 + 선적일 + 인코텀즈 (기준 뷰)
// 하는 일 : VBRK/VBRP 를 품목 단위로 평평하게 만들고 출하 문서의 실제 출고일을 붙인다
// 이렇게 나눈 이유 : 이 뷰 하나만 문서 구조를 알게 하고 위의 뷰는 평평한 줄만 본다.
// 확인 필요 : 취소 문서 제외(FKSTO), 수출 청구 유형, 출하 문서 연결 방식, 인코텀즈 필드
// ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 청구 품목(선적일 포함)'
define view entity ZI_CutofBillItem
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
    left outer join likp on likp.vbeln = vbrp.vgbel      // 출하 문서 (연결 방식 확인 필요)
    left outer join vbkd on vbkd.vbeln = vbrp.aubel and vbkd.posnr = '000000'
{
  key vbrk.gjahr                         as FiscalYear,
  key vbrp.vbeln                         as BillDoc,
  key vbrp.posnr                         as Item,
      vbrk.bukrs                         as CompanyCode,
      vbrk.kunrg                         as Customer,
      vbrk.fkdat                         as BillDate,        // 청구 전기일 = 장부 인식일
      likp.wadat_ist                     as ShipDate,        // 실제 출고일
      vbkd.inco1                         as Incoterms,       // 인코텀즈 (필드 확인 필요)
      vbrk.waerk                         as DocCurrency,
      vbrk.kurrf                         as ExchRate,
      vbrp.matnr                         as Material,
      vbrp.aubel                         as SalesOrder,
      vbrp.fkimg                         as Qty,
      vbrp.netwr                         as NetAmountFc
}
where vbrk.fksto = ''                    // 취소 문서 제외 (확인 필요)

④ 판정 뷰 — 통제 이전일과 이동 사유

화면이 가장 많이 신경 쓰는 뷰입니다. 통제 이전일을 정하고, 장부 인식월과 통제 이전월이 같은지 다른지, 다르면 어떤 이름을 붙일지를 날짜 관계로 판정합니다. 이름은 원인이 아니라 날짜 관계의 분류입니다.

// ─────────────────────────────────────────────────────────────
// ZI_CutofItemCtrl : 품목별 통제 이전일 · 통제 이전월 · 이동 사유 판정
// 하는 일 : 인코텀즈 기준 테이블로 통제 이전일을 계산하고 날짜 관계로 사유를 붙인다
// 이렇게 나눈 이유 : 사유 판정을 한 뷰에 모아 장부 큐브와 기준 큐브가 같은 판정을 쓰게 한다.
// 확인 필요 : 서류·통관 대기(2개월 이상)와 월초 일괄 청구(말일 전후)의 일수 기준
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '품목별 통제 이전 판정'
define view entity ZI_CutofItemCtrl
  as select from ZI_CutofBillItem as b
    left outer join zcutf_ctrl     as c on c.incoterms = b.Incoterms
{
  key b.FiscalYear, key b.BillDoc, key b.Item,
      b.CompanyCode, b.Customer, b.Material, b.Incoterms,
      b.BillDate, b.ShipDate,
      case c.basis
        when 'A' then dats_add_days( b.ShipDate, cast( c.transit_days as abap.int4 ), 'NULL' )
        else b.ShipDate
      end                                              as CtrlDate,
      substring( b.BillDate, 1, 6 )                    as PostPeriod,
      substring( case c.basis when 'A'
                   then dats_add_days( b.ShipDate, cast( c.transit_days as abap.int4 ), 'NULL' )
                   else b.ShipDate end, 1, 6 )         as CtrlPeriod,
      case
        when substring( b.BillDate, 1, 6 ) = substring( b.ShipDate, 1, 6 ) then 'ON'
        when b.BillDate <  b.ShipDate and c.basis = 'A'                    then 'TERM'   // 도착 조건 선인식
        when b.BillDate <  b.ShipDate                                      then 'PRE'    // 선적 전 조기 청구
        when substring( b.BillDate, 1, 6 ) - substring( b.ShipDate, 1, 6 ) >= 2 then 'DOC'  // 서류·통관 대기
        when substring( b.BillDate, 7, 2 ) <= '03'                         then 'BATCH'  // 월초 일괄 청구
        else 'BILL'                                                                      // 청구 지연
      end                                              as ShiftReason,
      b.ExchRate, b.Qty, b.NetAmountFc, b.DocCurrency
}

⑤ 장부 큐브 — 장부 인식월 기준 합산과 원화 환산

화면이 브라우저에서 하던 집계를 DB 로 내리는 뷰입니다. 사유별 이동분을 열로 나눠 담아 항등식(인식액 = 정시 인식분 + 이동분 5종)이 어떤 묶음에서도 성립하게 합니다.

// ─────────────────────────────────────────────────────────────
// ZI_CutofCube : 장부 큐브 (장부 인식월 · 고객 · 제품 · 인코텀즈)
// 하는 일 : 장부 인식월 기준으로 합산하고 정시/이동 사유별 열로 나눠 담는다
// 이렇게 나눈 이유 : 환산 규칙을 한 곳에 두고, 항등식을 뷰 정의에서 보장한다.
// 확인 필요 : 원화 환산 방식(문서 환율을 곱할지, 환산 함수를 쓸지)
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '매출 기간귀속 장부 큐브'
define view entity ZI_CutofCube
  as select from ZI_CutofItemCtrl
{
  key CompanyCode, key PostPeriod as Period, key Customer, key Material, key Incoterms,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( NetAmountFc * ExchRate )                                                   as Sales,
      sum( case ShiftReason when 'ON'    then NetAmountFc * ExchRate else 0 end )     as OnSales,
      sum( case ShiftReason when 'PRE'   then NetAmountFc * ExchRate else 0 end )     as ShPre,
      sum( case ShiftReason when 'TERM'  then NetAmountFc * ExchRate else 0 end )     as ShTerm,
      sum( case ShiftReason when 'BILL'  then NetAmountFc * ExchRate else 0 end )     as ShBill,
      sum( case ShiftReason when 'DOC'   then NetAmountFc * ExchRate else 0 end )     as ShDoc,
      sum( case ShiftReason when 'BATCH' then NetAmountFc * ExchRate else 0 end )     as ShBatch,
      sum( Qty )                                                                      as Qty,
      count(*)                                                                        as Lines,
      cast( 'KRW' as abap.cuky )                                                      as LocalCurrency
}
group by CompanyCode, PostPeriod, Customer, Material, Incoterms

⑥ 기준 큐브 — 통제 이전월로 다시 묶은 같은 키

같은 품목을 통제 이전월로 묶습니다. 키 모양을 장부 큐브와 똑같이 맞춰야 화면이 같은 칸끼리 비교합니다. 키가 어긋난 칸은 한쪽에만 걸린 조합으로 따로 보입니다.

// ─────────────────────────────────────────────────────────────
// ZI_CutofPlan : 기준 큐브 (통제 이전월 · 고객 · 제품 · 인코텀즈)
// 하는 일 : 장부 큐브와 같은 키 모양으로 통제 이전월 기준 인식액을 합산한다
// 이렇게 나눈 이유 : 키가 같아야 화면이 칸마다 장부 · 기준 · 차이를 붙일 수 있다.
// 확인 필요 : 통제 이전일의 환율(샘플은 가정값)
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '매출 기간귀속 기준 큐브'
define view entity ZI_CutofPlan
  as select from ZI_CutofItemCtrl
{
  key CompanyCode, key CtrlPeriod as Period, key Customer, key Material, key Incoterms,
      sum( NetAmountFc * ExchRate )                                                   as Sales,
      sum( case ShiftReason when 'ON'    then NetAmountFc * ExchRate else 0 end )     as OnSales,
      sum( case ShiftReason when 'PRE'   then NetAmountFc * ExchRate else 0 end )     as ShPre,
      sum( case ShiftReason when 'TERM'  then NetAmountFc * ExchRate else 0 end )     as ShTerm,
      sum( case ShiftReason when 'BILL'  then NetAmountFc * ExchRate else 0 end )     as ShBill,
      sum( case ShiftReason when 'DOC'   then NetAmountFc * ExchRate else 0 end )     as ShDoc,
      sum( case ShiftReason when 'BATCH' then NetAmountFc * ExchRate else 0 end )     as ShBatch
}
group by CompanyCode, CtrlPeriod, Customer, Material, Incoterms

⑦ 분석 쿼리 — 서비스가 노출하는 모양

화면과 표준 분석 도구가 읽는 층입니다. 차원과 측정값을 주석으로 구분하고, 지역 · 국가 · 제품그룹 같은 묶음 차원은 매핑 테이블에서 가져옵니다.

// ─────────────────────────────────────────────────────────────
// ZC_CutofQuery : 분석 쿼리 (차원 · 측정값 · 계산항목)
// 하는 일 : 큐브에 묶음 차원을 붙이고 정시 인식률 · 이동 비율을 계산항목으로 노출한다
// 이렇게 나눈 이유 : 화면은 이 모양만 알고 아래 뷰의 구조는 모른다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '매출 기간귀속 분석 쿼리'
@Analytics.query: true
define view entity ZC_CutofQuery
  as select from ZI_CutofCube as a
    left outer join zcutf_map   as m on m.map_type = 'M' and m.map_key = a.Material
{
  @AnalyticsDetails.query.axis: #ROWS
  key a.CompanyCode, key a.Period, key a.Customer, key a.Incoterms,
      coalesce( m.map_value, 'UNMAPPED' )                    as ProdGroup,
  @AnalyticsDetails.query.axis: #COLUMNS
      a.Sales, a.OnSales, a.ShPre, a.ShTerm, a.ShBill, a.ShDoc, a.ShBatch, a.Qty,
      // 계산항목 : 정시 인식률(%) · 이동 비율(%)
      division( a.OnSales * 100, a.Sales, 2 )                                          as OnRate,
      division( ( a.ShPre + a.ShTerm + a.ShBill + a.ShDoc + a.ShBatch ) * 100, a.Sales, 2 ) as ShiftRate
}

⑧ 접근 제어 — 집계에 거는 권한

권한은 집계를 읽는 자리에 걸어야 합계에서 빼는 방식으로 새지 않습니다. 회사코드 단위가 기본이고, 영업조직 단위가 필요하면 조건을 추가합니다.

// ─────────────────────────────────────────────────────────────
// ZC_CutofQuery 접근 제어 (DCL)
// 하는 일 : 회사코드 권한이 있는 사용자만 해당 회사의 행을 읽게 한다
// 확인 필요 : 영업조직 · 판매그룹 단위가 필요한지, 권한 객체 이름
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '매출 기간귀속 접근 제어'
@MappingRole: true
define role ZC_CUTOFQUERY {
  grant select on ZC_CutofQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_VBRK_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의 — 화면이 부르는 계약

화면은 서비스 계약만 알고 뷰 이름은 모릅니다. 장부 큐브와 기준 큐브를 엔티티셋으로 노출하고, 요인분해 · 해설 · 에이전트 실행은 펑션으로 둡니다. 운영에서는 이 서비스 주소만 화면에서 바꿉니다.

// ─────────────────────────────────────────────────────────────
// ZUI_CutofSrv : 서비스 정의 (OData V2 로 게시)
// 하는 일 : 쿼리 · 기준 큐브 · 원천 라인을 엔티티셋으로 노출한다
// 확인 필요 : 서비스 바인딩 유형, 쓰기 가능 집합(사유 · 레이아웃 · 감시 규칙)의 저장 위치
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '매출 기간귀속 서비스'
define service ZUI_CutofSrv {
  expose ZC_CutofQuery  as CubeSet;
  expose ZI_CutofPlan   as PlanSet;
  expose ZI_CutofItemCtrl as ItemSet;
  // 요인분해 · 해설 · 에이전트 실행은 펑션(unmanaged 구현)으로 추가 : 확인 필요
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않고 뷰부터 만들면 첫 대사 회의에서 막힙니다.

숫자를 믿을 수 있는가 — 검증 결과

사례에서 본 숫자(기준 28,403 → 장부 28,221, 총차이 −183)는 아래 대사식 전수 검사를 통과한 값입니다.

검사 78건 모두 차이 0건. 기준에 없는 장부 조합 27건과 장부에 없는 기준 조합 20건은 조회 범위 앞뒤 경계에서 장부 인식월과 통제 이전월이 달라 한쪽에만 걸리는 조합이라 일부러 대사 차이와 분리해 두었고, 요인 합계에는 포함되어 합이 맞습니다. 화면 쪽은 실제 브라우저에서 기능 15개 점검을 따로 돌려 모두 통과했습니다.

운영 데이터로 갈 때

수출 청구가 연 수십만 줄, 문서 흐름까지 수천만 건이 되면 지금의 “큐브 전체를 읽어 브라우저에서 묶는” 방식은 막힙니다. 먼저 집계 위치를 DB(큐브 뷰)로 내리고, 기간과 회사코드를 필수 파라미터로 둬 전 기간 조회를 막습니다. 드릴스루는 칸의 차원 값과 기간을 모두 조건으로 걸어 문서 라인을 쪽 단위로 읽고(기본 500행), 청구일과 고객 기준 인덱스 또는 사전 집계 테이블을 둡니다. 응답 시간 기준(예: 조회 몇 초 이내)은 도입 전에 정하고, 화면의 행 500개·열 36개 상한은 운영에서도 그대로 둡니다.

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 사용

분석 기능

도입과 운영