수입 솔루션 · SAP 수입 미착품 다차원 분석 — 수입 미착 잔액 점검

Q: 이 앱을 쓰면 무엇이 달라집니까? 누가 쓰나요?

미착 잔액이 늘었다는 사실에서 멈추지 않고 어느 항로 · 공급사에서, 왜, 누가 확인해야 하는지 까지 한 화면에서 이어 봅니다. 임원 요약은 역할별로 앞세우는 지표가 다릅니다. CFO 는 자재그룹별 기말 잔액과 장기 체류율, 구매 책임자는 공급사별 선적 · 입고와 입고율, 물류 책임자는 항로별 장기 체류, 자금 책임자는 통화별 노출과 순증감을 먼저 봅니다. 같은 큐브에서 나오므로 역할을 바꿔도 합계는 같습니다.

Q: 장기 체류는 어떻게 판정합니까?

기말 기준일에서 선적일을 뺀 체류일이 45일을 넘으면 장기 체류 잔액에 넣습니다. 45일은 샘플의 가정값 이며 운영에서는 회사 기준으로 바꿉니다. 샘플에서는 잔액 34,837.9 중 5,496.2 백만원(15.8%)이고 라인으로는 1,611줄 중 262줄입니다.

소개 영상블로그 목차 순서대로 · 자막 포함

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

수입 담당이 월말에 가장 자주 받는 질문은 “지금 바다 위에 얼마가 떠 있나” 입니다. 선적은 끝났지만 아직 입고하지 못한 물량은 구매오더 조회, 입고 처리, 자재 문서, 송장 검증 화면에 나뉘어 있어서, 같은 숫자를 맞추려면 화면 여러 개와 엑셀을 오가야 합니다. 여기에 포워더가 알려 준 선적일과 도착 예정일까지 더해지면, 기초 잔액에 이번 달 선적을 더하고 입고를 뺀 값이 기말 잔액과 맞는지 확인하는 일만으로 하루가 갑니다.

이 앱은 선하증권 품목 라인을 한 번만 큐브로 묶고, 그 위에서 축만 바꿔 같은 숫자를 다시 보여 줍니다. 기초 · 당월 선적 · 당월 입고 · 기말이 라인마다 맞아떨어지도록 계산해 두었기 때문에 공급사 · 항로 · 운송수단 · 체류 구간 어느 축으로 나눠도 합계가 어긋나지 않습니다. 화면은 SAP 표준 구매 · 입고 · 송장 흐름 위에서 쓰는 분석 확장입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 관련 기준서 대신 대상 영역은 수입 미착 잔액 점검으로 잡았습니다.

한 줄 요약 — 선적했지만 입고하지 못한 미착 잔액을 축으로 나눠 보고, 칸에서 선하증권 품목 라인까지 내려가고, 예정과 다른 이유를 여섯 요인으로 가르며, 그 합이 총차이와 같은지 매번 검산하는 수입 점검 화면입니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 롤포워드가 칸마다 맞는 미착 잔액	기초 + 당월 선적 − 당월 입고 = 기말이 라인마다 성립해, 어느 축으로 나눠도 합이 어긋나지 않습니다.	잔액 리포트와 입출고 리포트를 따로 만들고, 합계가 다르면 어느 쪽이 맞는지부터 맞춥니다.
② 장기 체류가 숫자로 드러남	체류일이 기준을 넘긴 잔액과 비율, 금액 가중 평균 체류일이 공급사 · 항로 · 선적월별로 바로 나옵니다.	입고 지연 건을 포워더 메일과 엑셀로 따로 모아 보고 회의 때마다 새로 셉니다.
③ 칸에서 선하증권 품목 라인까지	숫자를 누르면 그 금액을 만든 선하증권 품목 라인이 열리고, 칸 값과 라인 합이 같은지 머리 줄에 보입니다.	리포트를 닫고 구매오더 · 입고 문서를 따로 열어 조건을 손으로 다시 맞춥니다.
④ 예정과 다른 이유를 여섯 요인으로	선적 시점 · 선적 수량 · 외화 단가 · 환율 · 입고 시점 · 부대비용으로 가르고, 합이 총차이와 정확히 같은지 화면이 검산합니다.	잔액이 예정보다 늘었다는 사실만 보이고, 입고가 늦어서인지 환율 때문인지는 엑셀로 따로 풉니다.
⑤ 사유가 행에 남는다	변동 사유가 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도, 다음 달에도 따라옵니다.	같은 질문을 매달 다시 하고, 지난달 답은 메일함에서 찾습니다.
⑥ 사람이 열지 않아도 도는 점검	규칙마다 임계값과 받을 사람이 붙어, 걸리면 그 사람의 눈으로 다시 적은 보고가 대기함에 올라옵니다.	잔액이 나빠진 날 아무도 화면을 열지 않으면 그대로 지나갑니다.
⑦ 숫자는 모델에 맡기지 않는 AI 분석과 보고서	금액과 비율은 서비스가 큐브에서 계산하고 문장만 해설합니다. 내용은 PowerPoint 보고서로 바로 내려받습니다.	AI 가 만든 숫자를 보고에 써도 되는지부터 따져야 하고, 보고서는 화면을 옮겨 적어 다시 만듭니다.

사례로 보는 효과

검증용 샘플 자료(2026년 4월~9월 선적, 선하증권 품목 3,678줄, 선하증권 · 구매오더 1,757건)에서 기말(9월 30일) 미착 잔액은 예정 21,732.9 백만원에서 실적 34,837.9 백만원으로 +13,105.0 백만원(+60.3%) 늘었습니다. 합계로는 여기까지입니다. 여섯 요인으로 가르면 몫이 분명히 갈립니다.

요인	차이(백만원)	읽는 법
입고 시점	+15,132.4	가장 큰 몫입니다. 예정 도착 시점과 실제 입고 시점이 달라 기말까지 입고되지 않고 남은 금액이라 물류 책임자가 가장 먼저 볼 대상입니다.
선적 수량	+1,716.3	예정보다 많이 선적한 몫입니다.
환율	+389.0	예정 환율보다 실제 적용 환율이 높았던 몫으로 자금 책임자가 환율 전제를 점검할 대상입니다.
부대비용	+134.1	운임 · 보험 등 부대비용율이 예정보다 높았던 몫입니다(샘플의 가정 비율).
외화 단가	+104.7	공급사 단가가 예정보다 오른 몫입니다.
선적 시점	−4,371.5	예정과 실제 선적 시점이 달라 기말 기준일의 선적 여부가 바뀐 효과이며, 이번 샘플에서는 잔액을 줄이는 방향입니다.
합계	+13,105.0	여섯 요인의 합이 총차이와 정확히 같습니다.

잔액 중 선적 후 45일을 넘긴 장기 체류 금액은 5,496.2 백만원(15.8%), 금액 가중 평균 체류일은 28.2일입니다(45일은 샘플의 가정값입니다). 기말까지 입고되지 않은 라인은 1,611줄이고 그 가운데 장기 체류가 262줄입니다. 항로로 나누면 휴스턴→부산이 실적 7,414.4 로 예정 5,067.7 보다 2,346.7 많아 가장 크게 벌어졌고, 함부르크→부산(실적 4,231.4, 예정 2,833.2)이 뒤를 잇습니다. 이 숫자는 점검할 건을 좁혀 주는 것이고, 지연의 실제 원인은 회사와 포워더가 확인해야 합니다.

도입하면 달라지는 것

월말 점검 준비 — 기초 · 선적 · 입고 · 기말 롤포워드와 차이 요인이 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
회의의 주제 — “어느 숫자가 맞나” 가 아니라 “어느 항로의 어느 건을 먼저 확인할까” 를 이야기합니다.
다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
놓치지 않는 점검 — 아무도 화면을 열지 않아도 규칙에 걸린 항로 · 공급사 · 통화가 대기함에 올라옵니다.

이런 회사에 맞습니다

구매오더 · 입고 · 송장 검증을 SAP 로 돌리면서 선적 후 미입고 잔액은 포워더 자료와 엑셀로 따로 관리하는 회사.
해상 · 항공, 여러 항로와 4개 안팎의 통화로 원재료를 들여와 월말 미착 잔액과 입고 지연을 설명해야 하는 구매 · 물류 · 자금 담당 조직.
AI 를 쓰고 싶지만 숫자의 출처를 통제해야 하는 경영지원 조직.

실행 화면

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

사용 방법

조회 조건 — 회사코드(필수)와 선적월 시작·종료를 고릅니다. 공급사 · 항로 · 운송수단 같은 차원 값 선택은 선택 사항이며 비우면 전체입니다.
조회 — 조회 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다.
임원 요약 — 역할(CFO · 구매 · 물류 · 자금 책임자)을 바꾸면 앞세우는 지표와 행 축이 함께 바뀝니다. 다시 조회하지 않습니다.
분석 축 — 사용 가능 칸의 칩을 행 축 · 열 축으로 끌어다 놓거나 화살표 버튼으로 옮깁니다. 서버를 다시 부르지 않고 표와 차트가 바로 바뀝니다.
칸 눌러 품목 라인 — 값 칸을 누르면 그 금액을 만든 선하증권 품목 라인이 열리고 칸 값과 라인 합이 같은지 보입니다.
계산항목 — 롤포워드 기말 · 순증감 · 장기 체류율 · 평균 체류일 · 입고율을 표시 항목으로 고릅니다.
예정 대비 차이 — 비교를 ‘예정 대비 차이’ 로 바꾸면 칸마다 차이가 붙고 차트는 요인 워터폴이 됩니다. 행 이름을 누르면 그 행 범위의 요인으로 바뀝니다.
사유 쓰기 — 차이 모드의 사유 버튼에서 요인 구분과 내용을 저장 · 수정 · 삭제합니다.
AI 분석 · AI 에이전트 · 레이아웃 — 화면 위쪽 버튼으로 엽니다. AI 분석은 PowerPoint 보고서를 내려받고, 에이전트는 규칙 임계를 고쳐 지금 실행하며, 레이아웃은 현재 화면을 이름 붙여 저장합니다.
CSV — 피벗 표와 품목 라인 창에서 UTF-8 CSV 로 내려받습니다.

화면을 열면 조회 조건 · 분석 축 · 피벗 틀이 먼저 보입니다. 기본 레이아웃에 ‘열 때 자동 조회’ 를 지정해 두면 조회된 채로 시작합니다.

무엇으로 만들었나

화면은 OpenUI5(sap_horizon 테마)로 만들었고, 데이터는 OData V2 서비스 하나로만 주고받습니다. 서비스가 선하증권 품목 라인을 큐브로 묶고 계산항목과 요인분해를 계산해 주면 화면은 합산과 배치만 하고, 축을 바꿀 때는 이미 읽어 둔 큐브를 브라우저에서 다시 묶습니다. 그래서 축을 바꿔도 서버를 다시 부르지 않고, 모든 합계가 같은 큐브에서 나옵니다.

자리	무엇	왜 그렇게 두었나
화면 프레임	OpenUI5 · `sap_horizon`	표준 컨트롤만 사용합니다. 외부 UI 라이브러리를 들이지 않아 반입 심사 부담이 없습니다.
데이터 연결	OData V2 서비스 1개	큐브 · 예정 · 품목 라인 읽기, 사유 · 레이아웃 · 감시 규칙 쓰기, 요인분해 · 해설 · 에이전트 실행 호출이 한 서비스에 들어 있습니다. 운영 전환 때는 서비스 주소만 바꾸면 됩니다.
집계 · 판정	서비스의 계산 로직 + 브라우저 재묶음	기초 · 선적 · 입고 · 기말 롤포워드와 요인 산식은 서비스가 정수 원화로 계산하고, 피벗은 브라우저가 행 · 열 축 순서대로 다시 묶습니다. 비율은 합산한 뒤에 계산합니다.
차트	직접 그린 SVG	막대 차트와 요인 워터폴을 외부 차트 라이브러리 없이 그립니다.
AI 해설	규칙 기반 기본 · 모델 연결은 선택	금액과 비율은 서비스가 계산해 근거로 넘기고 문장만 해설합니다. 모델 연결은 서비스 설정에서만 켭니다.
보고서	브라우저에서 PowerPoint 생성	표와 차트를 담은 .pptx 를 서버를 거치지 않고 바로 만들어 내려받습니다.
에이전트	판단과 기록은 서비스	규칙 평가 · 하루 한 번 제한 · 실행 기록은 서버가 정하므로, 화면이 닫혀 있어도 같은 호출로 돌릴 수 있습니다.
테마	`sap_horizon`	SAP 의 최신 시각 체계를 따라 Fiori 앱과 나란히 놓아도 이질감이 적습니다.

SAP 표준 기능을 그대로 이어받은 부분 — 구매오더 · 입고 · 송장 검증 데이터 구조(구매오더 품목, 납품 일정, 구매오더 이력, 자재 문서)를 그대로 이어받고, 표준 T-code 가 담당하는 실행과 전기는 건드리지 않습니다. 이 화면은 같은 데이터를 조회 · 검증 관점에서 묶어 보여 줍니다.

쓰기가 있는 화면입니다. 사유 · 레이아웃 · 규칙은 저장되고, 요인분해 · 에이전트 실행은 서비스 함수를 부릅니다. 그래서 운영 연결 시 쓰기 권한과 감사 기록 범위를 함께 정해야 합니다(아래 CDS 구성의 ‘운영 시점에 해야 할 일’ 참고).

처음 열었을 때

조회 조건 · 분석 축 · 임원 요약 · 피벗이 한 화면에 차례로 놓입니다. 회사코드와 선적월 범위만 확인하고 조회를 누르면 되고, 값 선택은 비워 두면 전체입니다. 조회 조건 영역은 접어 한 줄 요약만 남길 수 있어 표를 넓게 볼 수 있습니다.

**조회 전 — 조회 조건과 레이아웃 보드** — 조회 전에는 조회 조건과 분석 축, 비어 있는 임원 요약과 피벗 틀이 놓여 있습니다.

회사코드는 필수이고 기본은 1000(샘플)입니다. 선적월은 2026.04부터 2026.09까지 고르며, 시작이 종료보다 늦으면 안내 문구가 뜹니다. 조회 버튼은 조회 조건 영역 오른쪽 끝에 있고 입력칸에서 Enter 키로도 조회합니다. 기본 분석 축은 행 운송수단 › 항로, 열 선적월이고 아직 칸 수는 0입니다.

**조회 직후 — 피벗과 막대 차트** — 조회하면 표 왼쪽에 막대 차트가, 오른쪽에 같은 값을 행 · 열로 푼 피벗이 붙습니다.

기본 기준은 기말 미착 잔액이고 칸 수는 1,236입니다. 차트는 운송수단별로 해상 FCL 21,337.4, 해상 LCL 11,553.2, 항공 1,947.3 백만원이며 합치면 총 34,837.9 백만원으로, 아래 요약 · 요인 · 검산 화면의 숫자와 같은 큐브에서 나옵니다. 차트는 외부 라이브러리 없이 SVG 로 직접 그리고, 창이 좁으면 표 아래로 내려갑니다.

**머리 영역 접힘 — 요약 한 줄만 남김** — 조회 조건 영역을 접으면 조건을 한 줄로 요약하고 아래 영역이 올라옵니다.

접힌 줄에는 회사코드 1000 · 2026.04 ~ 2026.09 가 남습니다. 접기는 보기만 바꾸며 조회 조건은 그대로이고, 펼치면 같은 자리에서 고칠 수 있습니다. 분석 축과 임원 요약, 피벗도 각각 접을 수 있습니다.

임원 요약 — 자리마다 다른 화면

같은 데이터를 CFO · 구매 · 물류 · 자금 책임자가 서로 다른 눈으로 봅니다. 역할 선택만 바꾸고 다시 조회하지 않습니다. 앞세우는 지표와 행 축만 달라지므로 어느 역할로 보아도 합계는 같습니다. 요약 값 아래의 작은 숫자는 예정과 예정 대비 차이입니다.

**임원 요약 — CFO** — CFO — 자재그룹 기준으로 기말 미착 잔액과 장기 체류율을 앞세웁니다.

기말 미착 잔액 34,837.9 백만원(예정 21,732.9, +13,105.0), 장기 체류 잔액 5,496.2(예정 0, +5,496.2), 장기 체류율 15.78%, 평균 체류일 28.2일이 보입니다. 아래에는 자재그룹별 예정 초과 상위가 이어지며 플라스틱 수지 13,763.3(+4,653.2), 철강 소재 7,628.5(+3,537.8) 순입니다.

**임원 요약 — 구매 책임자** — 구매 책임자 — 공급사 기준으로 선적 · 입고 흐름과 입고율을 앞세웁니다.

기말 미착 잔액에 더해 당월 선적액 39,610.4(+815.4), 당월 입고액 38,836.6(+1,447.8), 입고율 52.71%가 앞에 옵니다. 공급사별 예정 초과 상위는 휴스턴 수지 7,414.4(+2,346.7)입니다. 이 값은 감시 규칙 R04(미착 잔액 예정 대비 초과)가 보는 숫자와 같습니다.

**임원 요약 — 물류 책임자** — 물류 책임자 — 항로 기준으로 장기 체류 잔액과 평균 체류일을 앞세웁니다.

장기 체류 잔액 5,496.2, 장기 체류율 15.78%, 평균 체류일 28.2일, 미착 수량 5,955,819 가 보입니다. 항로별 상위는 휴스턴→부산 1,227.0 입니다. 기준이 장기 체류 잔액이라 행 축도 항로로 바뀌어 있습니다.

**임원 요약 — 자금 책임자** — 자금 책임자 — 통화 기준으로 순증감과 장기 체류를 함께 봅니다.

기말 미착 잔액과 함께 당월 순증감 773.8(예정 1,406.2, −632.4)을 보여 주고, 통화별 상위는 미국 달러 19,414.1(+7,225.7), 유로 순입니다. 환율 요인 +389.0 과 같이 보면 어느 통화를 먼저 점검할지 정할 수 있습니다.

축 전환과 범위 — 끌어다 놓기

칩을 끌어다 놓거나 화살표로 옮기면 서버를 다시 부르지 않고 표와 차트가 바뀝니다. 열 조합이 너무 많아지면 앞쪽만 보여 주고 범위를 좁히라고 안내합니다.

**축 전환 — 행·열 바꾸기** — 행 · 열 바꾸기 — 선적월이 행으로, 자재그룹이 열로 내려옵니다.

같은 큐브를 다른 모양으로 묶은 것입니다. 선적월별 기말 잔액은 2026.04 355.5, 05 874.1, 06 2,104.9, 07 719.7, 08 6,866.6, 09 23,917.0 으로 합치면 34,837.8(반올림) 이고, 9월 선적분이 가장 큽니다. 축 8가지 배치를 바꿔 가며 총합을 비교했을 때 서버 요청은 0회였고 합계는 모두 같았습니다.

**열 축 2단계 — 선적월 × 통화** — 열 축을 두 단계로 두면 선적월 아래에 통화가 붙습니다.

열 축은 최대 2단계, 행 축은 최대 3단계입니다. 열이 두 단계가 되면 열 수가 곱으로 늘어나므로, 아래 ‘범위 상한’ 화면처럼 앞쪽만 보여 주고 안내를 띄웁니다.

**차원 값 선택 — 비우면 전체** — 차원 값 선택 — 비우면 전체, 값을 고르면 그 값만 남습니다.

같은 차원 안에서는 or, 차원 사이에서는 and 로 묶입니다. 이 화면은 공급사 2곳과 항로 3곳을 고른 상태이고, 값에는 이름과 코드가 함께 보입니다. 선택은 읽어 오는 범위를 바로 줄이므로 대용량에서는 먼저 좁히는 것이 좋습니다.

**값을 좁힌 결과** — 값을 좁힌 결과 — 선택한 공급사와 항로만 남은 표와 차트입니다.

선택 값들의 큐브 합과 화면 합계가 같은지를 자동으로 비교했을 때 차이는 0이었습니다. 좁힌 결과도 같은 큐브에서 나오므로 축을 다시 바꿔도 합이 유지됩니다.

칸에서 선하증권 품목 라인까지

큐브 칸의 숫자가 믿을 만한지는 그 칸을 만든 라인을 열어 보면 압니다. 값 칸을 누르면 같은 조건의 선하증권 품목 라인이 열리고, 칸 값과 라인 합이 같은지가 머리 줄에 표시됩니다.

**드릴스루 — 선하증권 품목 라인** — 칸을 누르면 그 금액을 만든 선하증권 품목 라인이 목록으로 열립니다.

이 화면은 운송수단 해상 FCL · 항로 닝보→부산 · 선적월 2026.05 칸으로, 칸 값 39.4 와 읽은 라인 합 39.4 가 같고 9건 중 9건을 읽었다고 표시합니다. 선하증권 · 품목 · 공급사 · 자재 · 체류 구간 · 선적일 · 예정 입고일 · 입고일 · 수량 · 환율이 한 줄에 보입니다. 표본으로 확인한 다른 칸(호치민→부산 2026.05 43.8 · 3줄, 함부르크→부산 2026.07 21.3 · 27줄, 시애틀→부산 2026.09 1,730.1 · 129줄)도 모두 라인 합과 같았습니다. 더 읽기 · 모두 읽기 · CSV 를 쓸 수 있습니다.

**기간별 요약과 큐브 검산** — 검산 표와 선적월별 요약이 같은 영역에 놓입니다.

큐브 합계와 원천 라인 합계를 측정값 7종마다 비교해 차이 0을 보여 줍니다(기말 미착 34,837,863,612 = 34,837,863,612). 선적월별 요약은 라인 수와 선하증권 건수를 함께 보여 주며 2026.09 선적분이 2,066줄(991건)으로 가장 많습니다. 어긋나면 붉은색으로 표시합니다.

계산항목 — 합산한 뒤에 나누는 비율

장기 체류 비율처럼 비율은 칸마다 비율을 평균하면 틀립니다. 화면은 분자와 분모를 먼저 합산한 뒤 나눕니다. 계산항목은 롤포워드 기말 · 순증감 · 장기 체류율 · 평균 체류일 · 입고율 5종이며 토큰 식으로 정의되어 있습니다.

**계산항목 — 장기 체류 비율** — 장기 체류율을 표시 항목으로 고르면 칸마다 비율이 계산됩니다.

전체 장기 체류율은 5,496.2 ÷ 34,837.9 = 15.78% 이고 칸마다 같은 식으로 다시 계산합니다. 자재그룹 행에서는 4~7월에 선적한 잔액이 모두 장기 체류(100%)이고 9월 선적분은 0%로 보입니다. 계산항목 값이 토큰 식 결과와 같은지는 전체 합 5종과 칸 20개에서 자동으로 대조했고 차이는 0이었습니다.

예정 대비 차이 — 같은 표가 회의 자료가 된다

비교를 ‘예정 대비 차이’ 로 바꾸면 같은 표의 칸마다 실적 − 예정이 붙습니다. 금액 임계와 비율 임계를 둘 다 넘은 칸만 증가는 붉은색, 감소는 초록색으로 칠합니다. 하나만 넘은 칸은 칠하지 않습니다.

**예정 대비 차이 — 표** — 차이 표와 워터폴 — 항로 × 선적월의 차이, 왼쪽에는 전체 범위의 요인 워터폴이 붙습니다.

행은 항로이고 칸마다 실적 − 예정이 붙습니다. 임계 점검에서 59개 칸 가운데 49개가 칠해졌고 판정과 어긋난 칸은 없었습니다(금액 임계 1,000,000원, 비율 임계 10%). 워터폴은 예정 21,732.9 에서 시작해 선적 시점 −4,371.5, 선적 수량 +1,716.3, 외화 단가 +104.7, 환율 +389.0, 입고 시점 +15,132.4, 부대비용 +134.1 을 거쳐 실적 34,837.9 로 끝납니다.

**요인 워터폴과 검산 줄** — 행을 자재그룹으로 바꿔도 같은 워터폴과 검산 줄이 따라옵니다.

‘검산: 요인 합 − 총차이 = 0원’ 줄이 차트 위에 항상 보입니다. 요인 합이 총차이 +13,105.0 과 같은지는 라인별 3,678건과 차원 값 범위별 65건 모두 차이가 0이었습니다.

**항로 하나의 요인 워터폴** — 행 이름을 누르면 그 항로 범위의 요인 워터폴로 바뀝니다.

함부르크→부산 한 행만 보면 예정 2,833.2 에서 실적 4,231.4 로 늘었고, 가장 큰 몫은 입고 시점입니다. 이 행의 요인 합과 총차이의 검산 줄은 0입니다. 어느 항로가 전체 차이의 몫을 만들었는지 행마다 눌러 확인할 수 있습니다.

**변동 사유 작성** — 변동 사유 — 대상 행의 차이를 보며 주된 요인과 사유를 적습니다.

대상 행(자재그룹 플라스틱 수지)과 예정 대비 차이 +4,653.2(+51.1%)가 위에 보이고, 주된 요인을 고른 뒤 사유를 500자 안에서 적어 저장합니다. 수정 · 삭제도 같은 창에서 합니다.

**변동 사유 저장 직후** — 저장하면 ‘사유를 저장했습니다’ 안내가 뜨고 행에 사유가 붙습니다.

사유는 조회 범위와 행 경로에 묶여 저장되므로 축을 바꿔도 같은 행이면 따라옵니다. 화면을 새로 고쳐 다시 열어도 사유가 남아 있고 사유 건수가 1로 표시되는 것을 확인했습니다. 이 화면은 철강 소재 행을 눌러 범위를 바꾼 워터폴이기도 합니다.

AI 분석과 보고서

AI 분석은 기본적으로 규칙에 따른 해설입니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고, 문장은 그 숫자만 풀어 씁니다. 모델 연결은 서비스 설정에서만 켜는 선택 사항이며 꺼 두어도 같은 화면이 동작합니다.

**AI 분석 — 해설과 점검 대상** — 해설과 점검 대상 — 요약 문장과 점검 대상 표가 함께 열립니다.

요약은 ‘선택 범위 선하증권 1,757건 · 원천 라인 3,678건의 기말 미착 잔액은 348.38억원으로 예정 217.33억원 대비 +131.05억원(+60.3%)’ 로 시작해 장기 체류 잔액 54.96억원(15.8%)과 가장 큰 요인인 입고 시점(+151.32억원)을 말합니다. 점검 대상은 자재그룹 3곳과 공급사 4곳이 주된 요인과 함께 올라오고 사유 없음이 붉게 표시됩니다. 해설의 숫자는 서비스가 계산한 값과 같고, 모델이 새로 만들지 않습니다.

**AI 분석 — PPTX 보고서** — PPTX 보고서 — 같은 내용을 .pptx 로 브라우저에서 바로 만들어 내려받습니다.

보고서 만들기를 누르면 ‘보고서 AI_Report_….pptx 을(를) 만들었습니다’ 안내가 뜹니다. 샘플에서 만든 보고서는 6장(163,612바이트)이고 파이썬 라이브러리로 열었을 때 오류가 없었습니다. 서버를 거치지 않고 브라우저에서 만듭니다.

AI 에이전트 — 사람이 열지 않아도 도는 점검

에이전트는 감시 규칙 5개를 평가해 걸린 항목을 받을 사람의 눈으로 다시 적은 보고로 대기함에 올립니다. 규칙 평가 · 하루 한 번 제한 · 실행 기록은 서비스가 정합니다.

**AI 에이전트 — 감시 규칙** — 감시 규칙 — 규칙마다 설명 · 대상 역할 · 임계 · 사용 여부가 보입니다.

R01 장기 체류 잔액 비율 25%(물류 책임자), R02 환율 영향 20,000,000원(자금 책임자), R03 입고 지연 영향 50,000,000원(CFO), R04 미착 잔액 예정 대비 25%(구매 책임자), R05 통화별 노출 한도 600,000,000원(자금 책임자)이 기본값입니다. 임계는 입력칸에서 고치고 저장합니다. 위쪽 스위치로 화면을 열어 둔 동안 한 시간마다 실행하게 할 수도 있습니다.

**AI 에이전트 — 지금 실행** — 지금 실행 — 규칙을 평가하고 결과를 한 줄로 알려 줍니다.

첫 실행 뒤 ‘점검을 실행했습니다. 걸린 규칙 4건을 대기함에 올렸습니다’ 안내가 뜨고 대기함 탭에 4가 표시됩니다. 규칙 5개 가운데 4개가 걸린 결과입니다.

**AI 에이전트 — 하루 두 번째 실행(한도)** — 같은 날 두 번째 실행은 한도(LIMITED)로 기록됩니다.

‘오늘은 이미 실행해서 한도에 걸렸습니다. 하루 한 번 제한 — 새 보고를 올리지 않았습니다’ 라고 알려 줍니다. 판정은 서버가 하므로 화면을 여러 번 눌러도 대기함이 중복으로 쌓이지 않습니다.

**AI 에이전트 — 대기함** — 대기함 — 걸린 규칙이 받을 사람별로 올라와 있습니다.

예를 들어 ‘환율 영향 임계 — 4건 점검 필요’(자금 책임자)에는 통화별 환율 요인과 임계가, ‘입고 지연 영향 임계 — 10건’(CFO)에는 항로별 입고 시점 요인이, ‘미착 잔액 예정 대비 초과 — 10건’(구매 책임자)에는 공급사별 증가가 적힙니다. 보고는 점검 후보를 알리는 것이고 확정은 사람이 합니다.

**AI 에이전트 — 실행 기록** — 실행 기록 — 실행 시각 · 호출 · 상태 · 걸린 규칙 수가 남습니다.

실행 시각, 호출(USER), 상태(DONE), 걸린 규칙/전체(4/5), 비고가 한 줄로 남습니다. 두 번째 실행은 LIMITED 로 기록됩니다. 감사 추적이 필요할 때 이 기록을 근거로 씁니다.

레이아웃 저장과 복원

현재 축과 조회 조건 · 표시 항목을 이름 붙여 저장하고, 기본으로 지정하거나 ‘열 때 자동 조회’ 를 켤 수 있습니다.

**레이아웃 — 저장 전 목록** — 저장 전 — 레이아웃 이름과 기본 · 열 때 자동 조회 선택이 있고 목록은 비어 있습니다.

‘저장된 레이아웃이 없습니다’ 로 보이고, 이름을 적어 현재 화면 저장을 누르면 현재 축 · 조회 조건 · 표시 항목이 담깁니다.

**레이아웃 — 저장** — 저장 후 — 목록에 올라오고 기본 · 열 때 자동 조회 표시가 붙습니다.

‘장기 체류 점검 — 공급사 × 분기’ 로 저장한 예입니다. 목록 줄에서 적용 · 지금 조회 · 삭제를 누르고, 별 모양으로 기본 지정을 바꿉니다.

**레이아웃 — 새로 고침 뒤 조회된 채 복원** — 새로 고침 뒤에도 같은 모양으로 조회된 채 복원됩니다.

기본 레이아웃에 자동 조회를 켜 두면 행 공급사 · 열 분기 배치와 표시 항목(장기 체류 잔액), 차원 값 1개 선택이 복원되고 열자마자 조회합니다. 요약 값이 32,890.6 으로 바뀐 것은 저장해 둔 값 선택이 함께 적용되었기 때문입니다.

좁은 화면과 한계

휴대폰 폭에서도 같은 기능을 씁니다. 조회 버튼은 항상 보이고, 차트는 표 아래로 내려갑니다. 한계는 숨기지 않고 안내로 보여 줍니다.

**안내 — 기간 순서** — 선적월 시작이 종료보다 늦으면 ‘시작 기간이 종료 기간보다 늦습니다’ 안내가 뜹니다.

잘못된 범위로는 조회하지 않고 안내만 띄웁니다.

**안내 — 열 조합 범위 상한** — 열 조합이 너무 많으면 앞의 36개만 보여 줍니다.

‘열이 59개라 앞의 36개만 보여 줍니다. 열 축을 줄이거나 차원 값을 골라 주세요’ 라는 안내가 나옵니다. 범위를 좁히거나 축을 바꾸면 전체를 볼 수 있습니다.

**390px — 처음 열었을 때** — 390px 폭 — 처음 열었을 때도 조회 버튼이 한 줄에 보입니다.

가로 넘침은 0입니다. 영역마다 접이식이라 필요한 영역만 펼쳐 쓸 수 있습니다.

**390px — 임원 요약** — 임원 요약도 같은 폭에서 지표가 두 열로 쌓이고 역할 선택이 위에 붙습니다.

기말 미착 잔액 34,837.9, 장기 체류 잔액 5,496.2, 장기 체류율 15.78%, 평균 체류일 28.2일이 두 열로 보이고 아래에 자재그룹별 예정 초과 상위가 이어집니다. 값은 넓은 화면과 같습니다.

**390px — 피벗 표와 그 아래 차트** — 피벗 표는 가로로 밀어 보고, 차트는 표 아래로 내려갑니다.

표만 옆으로 밀리고 페이지 전체는 넘치지 않습니다. 좁은 화면에서는 표를 먼저 보고 차트를 아래에서 확인하는 순서가 더 읽기 쉽습니다.

화면 뒤에서 일어나는 일

서비스는 선하증권 품목 라인마다 기초 기준일(2026-08-31)과 기말 기준일(2026-09-30) 시점의 상태를 판정해 금액을 만듭니다. 기초 미착은 기초 기준일에 선적됐고 입고되지 않은 금액, 기말 미착은 기말 기준일의 같은 금액이며, 선적월에 선적한 금액과 입고월에 입고한 금액이 그 사이를 잇습니다. 그래서 라인마다 기초 + 당월 선적 − 당월 입고 = 기말 이 성립합니다(3,678줄 전부, 실적과 예정 모두 차이 0). 체류일은 기말 기준일에서 선적일을 뺀 값이고, 45일을 넘으면 장기 체류 잔액으로 셉니다(45일은 샘플의 가정값).

판정 규칙

판정 조건	결과 상태	사용자 조치
금액 차이 ≥ 금액 임계 그리고 차이율 ≥ 비율 임계, 잔액 증가	붉은색	요인 워터폴로 주된 요인을 확인하고 사유를 남깁니다.
위와 같고 잔액 감소	초록색	감소가 일회성 입고인지 확인합니다.
둘 중 하나만 넘음	표시 없음	-
영향 방향이 감소형인 측정값(당월 입고액)	부호 반전 판정	입고가 줄면 붉은색으로 보여 줍니다.
체류일이 45일을 넘은 미입고 라인	장기 체류 잔액에 포함	45일은 샘플 가정값이며 운영에서는 회사 기준으로 바꿉니다.
큐브 합계와 원천 라인 합계가 다름	검산 차이 표시	적재 범위를 점검합니다.
요인 합 − 총차이 ≠ 0	검산 줄 붉은색	요인 산식을 점검합니다.
에이전트 실행이 같은 날 두 번째	LIMITED	내일 다시 실행합니다. 새 보고는 올라가지 않습니다.

요인 산식

선하증권 품목 라인 단위로 예정 값을 아래 순서대로 하나씩 실적 값으로 바꿔 가며 기말 미착 잔액이 얼마나 달라지는지 계산합니다(순차 대입). 정수 원화로 계산하므로 여섯 요인의 합이 총차이와 정확히 같습니다.

순서	요인	실적으로 바꾸는 값	읽는 법
1	선적 시점	선적일(기말 기준일의 선적 여부)	예정과 실제 선적 시점이 달라 잔액에 들어가고 빠지는 효과
2	선적 수량	수량	예정보다 많거나 적게 선적한 효과
3	외화 단가	외화 단가	공급사 단가 변경 효과
4	환율	적용 환율	환율 변동 효과
5	입고 시점	입고일(기말 기준일의 입고 여부)	입고가 앞서거나 늦어 기말에 남은 효과
6	부대비용	부대비용율	운임 · 보험 등 비율 변경 효과

조회조건

필드	필수	기본값	OData 조건 · 비고
회사코드	필수	1000(샘플)	`Bukrs eq '1000'`
선적월 시작 · 종료	필수	202604 · 202609	`Period ge '202604' and Period le '202609'` — 같은 속성의 두 조건은 하나의 AND 묶음으로 보냅니다
차원 값 선택	선택	전체	같은 차원은 or, 차원 사이는 and
비교	선택	실적만	예정 대비 차이를 고르면 금액 · 비율 임계 입력
표시 항목	선택	기말 미착 잔액	측정값 7종 + 계산항목 5종

결과 컬럼

컬럼	의미	산출식
기초 미착 잔액	기초 기준일에 선적됐고 입고되지 않은 금액	라인 금액의 조건부 합
당월 선적액	선적월에 선적한 금액	라인 금액의 조건부 합
당월 입고액	입고월에 입고한 금액(감소형)	라인 금액의 조건부 합
기말 미착 잔액	기말 기준일에 선적됐고 입고되지 않은 금액	라인 금액의 조건부 합
장기 체류 잔액	기말 미착 중 체류일이 45일을 넘은 금액	기말 미착의 조건부 합
체류일 가중 금액	금액 × 체류일	기말 미착 × (기말 기준일 − 선적일)
미착 수량	기말 미착의 수량	수량의 조건부 합
롤포워드 기말	기초 + 당월 선적 − 당월 입고	계산항목
장기 체류율	장기 체류 잔액 ÷ 기말 미착 잔액 × 100	합산 후 계산
평균 체류일	체류일 가중 금액 ÷ 기말 미착 잔액	합산 후 계산

좁은 화면에서 달라지는 것

조회 버튼은 접히지 않고 항상 보입니다(머리 영역 도구줄에서 접히지 않도록 고정).
차트는 표 아래로 내려가 표를 먼저 읽습니다.
열 조합이 36개를 넘으면 앞쪽만 보여 주고 안내를 띄웁니다.
표는 가로로 밀리고 페이지 전체는 넘치지 않습니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/ (Main · Base)   view/ (Main + 대화상자 5)
├─ model/ (cube · chart · layout · pptx · formatter · ErrorHandler)
├─ css/ · i18n/ · media/ (소개 영상 · 포스터 · 재생 지점)
└─ odata/ 서비스 (메타데이터 · 서비스 로직 · 계산 로직 · 샘플 자료 16묶음)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 구매오더를 만들고 입고를 처리하고 송장을 검증하는 일은 표준 화면에 그대로 두고, 그 사이에 있는 “선적은 됐는데 아직 입고되지 않은 금액” 을 한 번에 묶어 보는 자리만 채웁니다.

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

하고 싶은 일	SAP 표준	이 앱이 더하는 관점
구매오더 한 건의 수량 · 단가 · 환율 · 납품 일정 확인	구매오더 조회(ME23N)로 충분합니다.	예정 값의 원천으로 읽어 실제 값과 나란히 놓고 요인으로 가릅니다.
입고 처리와 입고 문서 확인	입고 처리(MIGO) · 자재 문서 목록(MB51)이 담당합니다.	입고일과 수량을 선하증권 품목 라인에 붙여 기말 기준일의 입고 여부를 판정합니다.
송장 검증과 청구 금액 대조	송장 검증(MIRO)이 담당합니다.	청구 금액을 입고 · 선적 라인과 같은 키로 맞춰 봅니다.
입고와 송장 시점 차이 정리	GR/IR 계정 정리(MR11)가 담당합니다.	정리 대상 후보를 좁히는 조회 관점만 더하며 정리 자체는 하지 않습니다.
기말 시점에 선적 후 미입고 잔액을 공급사 · 항로 · 체류 구간별로 합계	이 관점을 한 번에 묶는 표준 리포트가 있는지는 확인 필요입니다.	롤포워드와 장기 체류, 평균 체류일을 같은 큐브에서 계산해 보여 줍니다.
예정 대비 차이의 요인 분해와 사유 기록	표준 화면은 개별 문서 단위 확인입니다.	여섯 요인으로 가르고 합이 총차이와 같은지 검산하며 사유를 행에 남깁니다.

T-code 별 연계 지점

T-code	이름	연계
ME23N	구매오더 조회	이어받는 데이터 구매오더 헤더 · 품목(공급사 · 자재 · 통화 · 인코텀즈 · 수량 · 단가 · 예정 환율)과 납품 일정(예정 도착). 대사 지점 예정 큐브의 수량 · 금액이 오더와 같은지. 오가는 법 화면에서 라인을 열어 구매오더 번호를 확인한 뒤 ME23N 에서 원천 조건을 봅니다. 표준에 남기는 일 오더 생성 · 변경.
MIGO	입고 처리	이어받는 데이터 입고 일자와 수량. 대사 지점 라인의 입고일 · 입고액이 입고 처리 결과와 같은지. 오가는 법 입고 완료로 표시된 라인의 문서를 MIGO 에서 확인합니다. 표준에 남기는 일 입고 전기.
MB51	자재 문서 목록	이어받는 데이터 자재 문서 품목(수량 · 전기일). 대사 지점 당월 입고액 합계가 기간별 자재 문서 합과 같은지. 오가는 법 이 앱의 당월 입고 칸 → MB51 에서 같은 기간 · 같은 자재로 조회. 표준에 남기는 일 문서 조회 · 취소.
MIRO	송장 검증	이어받는 데이터 청구 수량 · 금액. 대사 지점 입고되었지만 송장이 없는 라인과 송장은 있는데 입고가 없는 라인. 오가는 법 점검 후보 라인 → MIRO 에서 송장 상태 확인. 표준에 남기는 일 송장 전기 · 지급 처리.
MR11	GR/IR 계정 정리	이어받는 데이터 입고와 송장의 시점 차이 후보. 대사 지점 정리 전 후보 금액이 이 앱의 입고 시점 요인과 같은 방향인지. 오가는 법 이 앱에서 후보를 좁히고 정리는 MR11 에서 합니다. 표준에 남기는 일 정리 전표 생성 · 결산 대응.

기존 리포트를 없애야 하나요? 아닙니다. 운영 전환 뒤에도 표준 화면과 기존 리포트는 법정 · 감사 · 세무 대응의 근거로 그대로 둡니다. 이 앱은 월말 점검과 회의에서 “어디를 먼저 볼지” 를 정하는 자리를 맡고, 확인은 위 T-code 로 내려가서 합니다.

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

S/4HANA 의 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 같은 큐브 · 쿼리 계층 위에서 동작합니다. 이 앱이 읽는 큐브와 쿼리는 그 계층과 같은 형태(차원 · 측정값 · 집계)로 설계되어 있어, 운영에서는 같은 쿼리를 Analysis for Office 에서도 열 수 있습니다. 이 앱이 더하는 것은 롤포워드 판정, 요인분해 · 사유 기록, 에이전트 점검처럼 표준 분석 쿼리에 없는 관점입니다. 확인하지 못한 Fiori 앱 이름은 적지 않았으며, 도입 시 사용 중인 앱 목록과 겹치는 부분은 확인 필요합니다.

분석 지표 정의표

지표	산식 · 판정 기준	대응 기능	원천 데이터	비고
기말 미착 잔액	기말 기준일에 선적됐고 입고되지 않은 금액의 합	표 · 차트 · 임원 요약	구매오더 이력 · 입고 문서 · 납품 일정	측정값
롤포워드 기말	기초 + 당월 선적 − 당월 입고	표 · 검산	같음	계산항목, 기말과 같아야 함
장기 체류 잔액 · 비율	체류일 45일 초과 금액, 그 ÷ 기말 미착 × 100	표 · 규칙 R01	선적일 · 기준일	45일은 가정값, 비율은 합산 후 계산
평균 체류일	체류일 가중 금액 ÷ 기말 미착	표 · 임원 요약	같음	금액 가중
입고율	당월 입고 ÷ (기초 + 당월 선적) × 100	표 · 구매 책임자 요약	같음	계산항목
예정 대비 차이	실적 − 예정	차이 모드	예정은 구매오더 조건 기준	가정값 샘플
요인 6종	순차 대입(선적 시점 · 수량 · 단가 · 환율 · 입고 시점 · 부대비용)	워터폴 · AI 해설	라인 단위 계산	합 = 총차이

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

자리	무엇을 손대나	왜 고객사마다 다른가
선적일 · 선하증권 번호의 원천	인바운드 납품 · 공급사 확인(EKES)을 쓰는지, 별도 포워더 자료를 적재하는지 정합니다.	선적 정보를 SAP 에 입력하는 방식이 회사마다 달라 확인 필요입니다.
항로 · 운송사 그룹 매핑	공급사 또는 자재에 항로 · 운송수단 · 운송사 그룹을 붙이는 매핑 테이블 또는 확장 필드.	표준 마스터에 없을 수 있어 고객사가 관리하는 값입니다.
부대비용율	운임 · 보험 등 조건 유형을 라인 금액에 어떻게 반영할지.	인코텀즈에 따라 부담 주체와 반영 시점이 다릅니다.
장기 체류 기준일수	샘플은 45일이며 회사 기준으로 바꿉니다.	품목 · 공급사별 기준이 다를 수 있습니다.
권한	플랜트(또는 구매 조직) 단위로 큐브를 제한하는 권한 정의.	같은 화면이라도 담당 범위의 금액만 보여야 합니다.
감시 규칙 임계와 받을 사람	규칙별 임계값 · 대상 역할 · 실행 주기.	조직 구조와 보고 라인에 따라 다릅니다.

CDS 구성

샘플 자료에서는 선하증권 품목 라인 3,678줄을 서비스가 큐브 8,652행(차원 조합 1,236칸 × 측정값 7종)으로 묶어 주고, 브라우저가 그 큐브를 다시 묶어 보여 줍니다. 운영에서는 이 계층을 CDS 뷰로 둡니다. 아래는 그 구성입니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	라인 기준 뷰 · 이력 뷰	선적 후 미입고 라인을 한 줄로 만들고, 입고 일자 · 수량을 별도로 모읍니다.	입고가 여러 번 나뉘는 품목을 라인 뷰와 섞으면 금액이 중복됩니다.
차원	차원 뷰	공급사 · 자재 · 항로 · 운송사 그룹 이름을 붙입니다.	행 머리글에 코드와 이름이 함께 나오게 합니다.
큐브	실적 큐브 · 예정 큐브	기초 · 기말 기준일을 파라미터로 받아 라인마다 잔액을 판정하고 합산합니다.	같은 키 · 같은 측정값 이름을 쓰면 두 큐브를 같은 칸에서 빼기만 하면 됩니다.
쿼리	분석 쿼리	행 · 열 차원과 필수 파라미터, 필터 방식을 정합니다.	화면이 큐브를 직접 읽지 않게 해 전체 기간을 무심코 읽는 일을 막습니다.
권한	DCL	플랜트 단위 접근을 제한합니다.	합계만 보여도 금액이 노출되기 때문입니다.
서비스	서비스 정의 · 바인딩	쿼리를 OData V2 서비스로 노출합니다.	서비스 이름과 엔티티셋 이름을 화면과 같게 맞춰 두면 서비스 주소만 바꿔 운영으로 옮길 수 있습니다.

① 라인 기준 뷰 — 선적 후 미입고 라인을 한 줄로

미착 잔액의 최소 단위는 구매오더 품목의 납품 일정 한 줄입니다. 선적일·예정 도착일·입고일과 수량·단가·환율·부대비용율을 한 뷰에 모아 두면, 이후 모든 합산이 이 뷰 하나만 바라봅니다. 선적일과 선하증권 번호의 원천은 인바운드 납품·공급사 확인 사용 방식에 따라 달라 확인이 필요합니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitLine
" 역할   : 구매오더 품목 단위의 선적·입고 이력을 한 줄로 만든다
" 이렇게 : 일자 판정(기초·기말 시점에 선적/입고됐는가)은 큐브에서 한다.
"          이 뷰는 사실(일자·수량·단가)만 담아 두어 기준일이 바뀌어도 그대로 쓴다
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '미착 라인 기준'
define view entity ZI_TransitLine
  as select from ekpo
    inner join ekko on ekko.ebeln = ekpo.ebeln
    left outer join eket on eket.ebeln = ekpo.ebeln
                        and eket.ebelp = ekpo.ebelp
{
  key ekpo.ebeln                         as PurchaseOrder,
  key ekpo.ebelp                         as PurchaseOrderItem,
      ekko.bukrs                         as CompanyCode,
      ekko.lifnr                         as Supplier,
      ekko.waers                         as TransactionCurrency,
      ekko.wkurs                         as ExchangeRate,
      ekko.inco1                         as IncotermsClassification,
      ekpo.matnr                         as Material,
      ekpo.matkl                         as MaterialGroup,
      ekpo.werks                         as Plant,
      ekpo.netpr                         as NetPriceAmount,
      eket.eindt                         as PlannedArrivalDate,
      @Semantics.quantity.unitOfMeasure: 'OrderUnit'
      ekpo.menge                         as OrderQuantity,
      ekpo.meins                         as OrderUnit
      " 선적일·선하증권 번호·운송수단·항로·운송사 → 인바운드 납품 또는 공급사 확인 사용 방식에 따라 원천이 다름(확인 필요)
}

② 이력 뷰 — 입고 일자와 입고 수량

입고는 구매오더 이력과 자재 문서에서 읽습니다. 같은 품목에 입고가 여러 번 있으면 일자별로 합쳐야 하므로, 라인 뷰와 섞지 않고 별도 뷰로 둡니다. 이 뷰의 합계가 입고 처리 화면의 수량과 맞는지가 첫 번째 대사 지점입니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitReceipt
" 역할   : 품목별 입고 일자·수량 (이동유형 101 계열 입고, 취소 제외)
" 이렇게 : 입고가 분할되면 일자별 한 줄이 되도록 group by 한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '미착 입고 이력'
define view entity ZI_TransitReceipt
  as select from ekbe
{
  key ebeln                              as PurchaseOrder,
  key ebelp                              as PurchaseOrderItem,
  key budat                              as PostingDate,
      @Semantics.quantity.unitOfMeasure: 'BaseUnit'
      sum( menge )                       as ReceivedQuantity,
      meins                              as BaseUnit
}
where vgabe = '1'                          " 입고
  and bewtp = 'E'
group by ebeln, ebelp, budat, meins

" ───────────────────────────────────────────────────────────────
" ZI_TransitLineDated — 라인 + 입고 완료일 + 선적일(큐브가 읽는 뷰)
" ───────────────────────────────────────────────────────────────
define view entity ZI_TransitLineDated
  as select from ZI_TransitLine as l
    left outer join ZI_TransitReceipt as r
      on r.PurchaseOrder = l.PurchaseOrder and r.PurchaseOrderItem = l.PurchaseOrderItem
{
  key l.PurchaseOrder,
  key l.PurchaseOrderItem,
      l.Supplier, l.Material, l.MaterialGroup, l.TransactionCurrency, l.Plant,
      l.PlannedArrivalDate                                   as ShipDate,   " 선적일 원천은 확인 필요
      max( r.PostingDate )                                   as ReceiptDate,
      cast( l.OrderQuantity * l.NetPriceAmount * l.ExchangeRate as abap.curr(17,0) ) as LineAmount
}
group by l.PurchaseOrder, l.PurchaseOrderItem, l.Supplier, l.Material, l.MaterialGroup,
         l.TransactionCurrency, l.Plant, l.PlannedArrivalDate, l.OrderQuantity, l.NetPriceAmount, l.ExchangeRate

③ 차원 뷰 — 공급사·자재·항로 이름

화면의 행 머리글에 코드와 이름이 같이 나오려면 차원 이름 뷰가 필요합니다. 항로와 운송사 그룹은 표준 마스터에 없을 수 있어, 운영에서는 고객사가 관리하는 매핑을 두거나 확장 필드를 씁니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitSupplier / ZI_TransitMaterial
" 역할   : 코드 → 이름 (value help · 행 머리글)
" 이렇게 : 이름은 큐브에 넣지 않고 association 으로 읽는다 → 큐브가 가벼워진다
" ───────────────────────────────────────────────────────────────
@ObjectModel.dataCategory: #TEXT
define view entity ZI_TransitSupplier
  as select from lfa1
{
  key lifnr                              as Supplier,
      @Semantics.text: true
      name1                              as SupplierName
}

@ObjectModel.dataCategory: #TEXT
define view entity ZI_TransitMaterial
  as select from makt
{
  key matnr                              as Material,
  key spras                              as Language,
      @Semantics.text: true
      maktx                              as MaterialName
}

④ 큐브 뷰 — 두 기준일 시점의 잔액을 한 번에

이 앱의 핵심 설계입니다. 기초·기말 두 기준일을 파라미터로 받아, 라인마다 그 시점에 선적됐고 입고되지 않았는지를 case 로 판정해 금액을 만듭니다. 같은 라인에서 기초 + 당월 선적 − 당월 입고 = 기말이 항상 성립하므로, 선적월 축으로 나눠도 합이 어긋나지 않습니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitCube
" 역할   : 미착 잔액 큐브 — 기초·기말 두 기준일을 파라미터로 받는다
" 이렇게 : 잔액을 기간마다 쌓지 않고 '기준일 두 개'로 고정한다
"          → 어떤 축으로 나눠도 합이 같고, 롤포워드가 라인 단위로 성립한다
" ───────────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '미착 잔액 큐브'
define view entity ZI_TransitCube
  with parameters
    p_cut0 : abap.dats,                  " 기초 기준일
    p_cut1 : abap.dats                   " 기말 기준일
  as select from ZI_TransitLineDated as l
  association [0..1] to ZI_TransitSupplier as _Supplier on $projection.Supplier = _Supplier.Supplier
{
  key l.PurchaseOrder,
  key l.PurchaseOrderItem,
      l.Supplier,
      l.Material,
      l.MaterialGroup,
      l.TransactionCurrency,
      l.Plant,
      substring( l.ShipDate, 1, 6 )       as ShipMonth,

      @DefaultAggregation: #SUM
      cast( case when l.ShipDate <= $parameters.p_cut0
                  and ( l.ReceiptDate is null or l.ReceiptDate > $parameters.p_cut0 )
                 then l.LineAmount else 0 end as abap.curr(17,0) )   as OpeningAmount,
      @DefaultAggregation: #SUM
      cast( case when l.ShipDate >  $parameters.p_cut0
                  and l.ShipDate <= $parameters.p_cut1
                 then l.LineAmount else 0 end as abap.curr(17,0) )   as ShippedAmount,
      @DefaultAggregation: #SUM
      cast( case when l.ShipDate <= $parameters.p_cut1
                  and l.ReceiptDate >  $parameters.p_cut0
                  and l.ReceiptDate <= $parameters.p_cut1
                  and l.ShipDate <= $parameters.p_cut0
                 then l.LineAmount else 0 end as abap.curr(17,0) )   as ReceivedAmount,
      @DefaultAggregation: #SUM
      cast( case when l.ShipDate <= $parameters.p_cut1
                  and ( l.ReceiptDate is null or l.ReceiptDate > $parameters.p_cut1 )
                 then l.LineAmount else 0 end as abap.curr(17,0) )   as ClosingAmount,
      _Supplier
}
" 설계 메모: 기초에 이미 선적되어 기간 안에 입고된 라인과, 기간 안에 선적되어 기간 안에 입고된 라인은
"           입고액에 넣는 규칙을 회사 기준으로 정해야 한다(운영 시점에 해야 할 일 참고)

⑤ 예정 큐브 — 구매오더 조건 기준의 예정 값

비교 기준은 구매오더가 처음 약속한 선적·도착 일정과 수량·단가·예정 환율입니다. 예정 큐브는 실적 큐브와 같은 키·같은 측정값 이름을 쓰므로, 화면은 두 큐브를 같은 칸에서 빼기만 하면 됩니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitPlanCube
" 역할   : 같은 라인의 '예정' 값 — 예정 선적일·예정 수량·예정 단가·예정 환율
 이렇게 : 실적 큐브와 키·측정값 이름을 같게 해 칸 단위 차이를 바로 뺄 수 있게 한다
"          ZI_TransitPlanLine 은 ① 과 같은 구조에 예정 일자·예정 수량·예정 단가·예정 환율을 담은 뷰다
" ───────────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@EndUserText.label: '미착 잔액 큐브(예정)'
define view entity ZI_TransitPlanCube
  with parameters
    p_cut0 : abap.dats,
    p_cut1 : abap.dats
  as select from ZI_TransitPlanLine as p
{
  key p.PurchaseOrder,
  key p.PurchaseOrderItem,
      p.Supplier,
      p.Material,
      p.MaterialGroup,
      substring( p.PlannedShipDate, 1, 6 )   as ShipMonth,
      @DefaultAggregation: #SUM
      cast( case when p.PlannedShipDate <= $parameters.p_cut1
                  and p.PlannedArrivalDate > $parameters.p_cut1
                 then p.PlanQuantity * p.PlanPrice * p.PlanRate
                 else 0 end as abap.curr(17,0) )                     as PlanClosingAmount
}

⑥ 쿼리 뷰 — 화면이 읽는 분석 쿼리

화면은 큐브를 직접 읽지 않고 분석 쿼리를 읽습니다. 행·열에 올릴 차원과 필수 파라미터, 필터 방식을 여기서 정합니다. 기준일 파라미터를 필수로 두면 전체 기간을 무심코 읽는 일이 막힙니다.

" ───────────────────────────────────────────────────────────────
" ZC_TransitQuery
" 역할   : 분석 쿼리 — 행/열 기본 배치와 필수 파라미터
" 이렇게 : 기준일 두 개를 필수 파라미터로 두어 대용량 전체 읽기를 막는다
" ───────────────────────────────────────────────────────────────
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '미착 잔액 분석'
define view entity ZC_TransitQuery
  with parameters
    @Consumption.defaultValue: '20260831' p_cut0 : abap.dats,
    @Consumption.defaultValue: '20260930' p_cut1 : abap.dats
  as select from ZI_TransitCube( p_cut0: $parameters.p_cut0, p_cut1: $parameters.p_cut1 )
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
  Supplier,
  @AnalyticsDetails.query.axis: #COLUMNS
  ShipMonth,
  @AnalyticsDetails.query.axis: #FREE
  Material,
  MaterialGroup,
  @AnalyticsDetails.query.axis: #FREE
  TransactionCurrency,
  @DefaultAggregation: #SUM OpeningAmount,
  @DefaultAggregation: #SUM ShippedAmount,
  @DefaultAggregation: #SUM ReceivedAmount,
  @DefaultAggregation: #SUM ClosingAmount
}

⑦ 권한 정의 — 플랜트 단위 접근 제한

분석 앱은 합계만 보여도 금액이 노출됩니다. 구매오더 조회 권한 오브젝트의 플랜트 값으로 큐브를 제한해, 같은 화면이라도 담당 플랜트의 미착 잔액만 보이게 합니다.

" ───────────────────────────────────────────────────────────────
" ZI_TransitCube 용 DCL
" 역할   : 플랜트 권한이 있는 사용자만 해당 플랜트의 잔액을 본다
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '미착 큐브 권한'
@MappingRole: true
define role ZI_TransitCube {
  grant select on ZI_TransitCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 붙는 OData 서비스

마지막으로 쿼리를 서비스로 노출합니다. 서비스 이름과 엔티티셋 이름을 화면과 같게 맞추면 manifest 의 서비스 주소만 바꿔 운영 서비스로 옮길 수 있습니다. 예정 대비 차이 분해·해설·에이전트는 펑션 또는 액션으로 같은 서비스에 둡니다.

" ───────────────────────────────────────────────────────────────
" 서비스 정의 · 바인딩
" 역할   : 분석 쿼리와 마스터 이름을 OData V2 서비스로 노출
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '미착 분석 서비스'
define service ZUI_TransitCube {
  expose ZC_TransitQuery      as CubeSet;
  expose ZI_TransitSupplier   as SupplierText;
  expose ZI_TransitMaterial   as MaterialText;
}
" 서비스 바인딩: OData V2 - UI  →  게시 후 서비스 주소를 manifest 의 dataSources 에 넣는다
" 차이 분해(DecomposeVariance)·해설(ExplainScope)·에이전트(RunAgent)는 액션/펑션 구현 클래스에서 큐브 값을 읽어 계산한다(확인 필요)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
선적일 · 선하증권 번호의 원천	공급사 확인(인바운드 정보)을 쓸지, 포워더 자료를 적재할지	기초 · 기말 시점의 선적 여부를 판정할 수 없습니다.	구매 · 물류 · IT
항로 · 운송사 그룹 매핑	공급사 또는 자재에 항로와 운송수단을 붙이는 방식	항로별 분석이 비거나 기존 리포트와 다르게 묶입니다.	물류 · IT
예정 값의 원천	구매오더 납품 일정 · 예정 환율을 예정으로 볼지	예정이 왜 이 숫자냐는 질문이 반복됩니다.	구매 · 재무
부대비용 반영 기준	운임 · 보험 조건 유형과 인코텀즈별 반영 시점	부대비용 요인이 의미 없는 숫자가 됩니다.	구매 · 재무
환율 유형 · 환산 시점	기말 환율을 어떤 유형으로 쓸지	환율 요인이 결산 환율과 어긋납니다.	자금 · 재무
장기 체류 기준일수	품목 · 공급사별 기준	장기 체류 잔액을 회의에서 받아들이지 않습니다.	물류 · 구매
권한 설계	플랜트 또는 구매 조직 단위 접근	다른 조직의 잔액이 보입니다.	IT · 내부 통제
대사 체계	표준 T-code 와 맞출 항목과 주기	숫자가 다를 때 어느 쪽이 맞는지 정할 수 없습니다.	재무 · IT
성능 기준	기간 · 파라미터 필수화, 집계 위치	대용량에서 응답이 늘어집니다.	IT
전송(TR) 순서	기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스	활성화 순서가 어긋나 오류가 납니다.	IT
서비스 활성화 · 주소 교체	서비스 게시와 화면의 서비스 주소 교체	샘플 서비스를 계속 보게 됩니다.	IT
에이전트 실행 방식	배치 등록 주기와 받을 사람	점검이 화면을 열 때만 돕니다.	IT · 현업

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 만드는 쪽에서 먼저 대사식을 세워 전수로 돌린 결과이며, 도입 포인트의 사례와 같은 숫자입니다.

대사식	검사 건수	차이 건수	의도적 예외
선적 라인 실적 값 재계산	3,678	0	0
선적 라인 예정 값 재계산	3,678	0	0
라인별 롤포워드 기초 + 선적 − 입고 = 기말 (실적 · 예정)	7,356	0	0
큐브 칸별 롤포워드	1,236	0	0
요인 합 = 총차이 (라인별)	3,678	0	0
요인 합 = 총차이 (차원 값 범위별)	65	0	0
큐브 합계 = 원천 라인 합계 (측정값 7종 · 실적 · 예정)	14	0	0
통화별 합계 = 전체 합계	4	0	0
칸 금액 = 드릴스루 라인 합 (표본 4칸)	4	0	0

화면 쪽은 따로 자동화로 돌려 축 8가지 배치에서 총합이 같은지, 차이 색 판정이 59칸에서 어긋나지 않는지, 사유가 새로 열어도 남는지를 확인했습니다.

운영 데이터로 갈 때

전표 · 문서 흐름이 수천만 건이면 집계는 서버(큐브 뷰)에서 끝내고 화면에는 칸 단위만 내려보내야 합니다. 기초 · 기말 기준일과 기간을 필수 파라미터로 두고, 차원 값 선택은 가능한 한 서버 필터로 적용합니다. 선하증권 품목 라인은 칸을 눌렀을 때만 페이지 단위로 읽고, 응답 시간 기준은 도입 전에 합의합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문입니다. 네 묶음으로 나눠 적었습니다.

도입과 활용

이 앱을 쓰면 무엇이 달라집니까? 누가 쓰나요?

미착 잔액이 늘었다는 사실에서 멈추지 않고 어느 항로 · 공급사에서, 왜, 누가 확인해야 하는지까지 한 화면에서 이어 봅니다. 임원 요약은 역할별로 앞세우는 지표가 다릅니다. CFO 는 자재그룹별 기말 잔액과 장기 체류율, 구매 책임자는 공급사별 선적 · 입고와 입고율, 물류 책임자는 항로별 장기 체류, 자금 책임자는 통화별 노출과 순증감을 먼저 봅니다. 같은 큐브에서 나오므로 역할을 바꿔도 합계는 같습니다.

언제부터 쓸 수 있습니까?

검증용 샘플 자료로 먼저 둘러볼 수 있습니다. 운영 데이터 적용 시기는 선적 정보의 원천(공급사 확인 또는 포워더 자료)과 항로 매핑이 합의된 뒤에 정해지므로 현재 확인 필요입니다. 합의 항목은 CDS 구성의 ‘운영 시점에 해야 할 일’ 표에 정리했습니다.

어떤 회사에 맞습니까?

구매오더 · 입고 · 송장 검증을 SAP 로 돌리면서 선적 후 미입고 잔액은 포워더 자료와 엑셀로 따로 관리하는 회사에 맞습니다. 해상과 항공이 섞이고 항로와 통화가 여러 개일수록 효과가 큽니다. 반대로 수입 물량이 적고 항로가 한두 개이면 표준 화면과 엑셀로 충분할 수 있습니다.

SAP 표준 T-code 와는 어떤 관계입니까?

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 구매오더 조회(ME23N), 입고 처리(MIGO), 자재 문서(MB51), 송장 검증(MIRO), GR/IR 정리(MR11)에서 하던 일은 그대로 두고, 이 화면에서 후보를 좁힌 뒤 해당 T-code 로 내려가 확인합니다. 기존 리포트를 없앨 필요는 없습니다.

분석 결과를 그대로 결산에 써도 됩니까?

이 화면은 집계와 차이 확인을 돕는 점검 도구입니다. 최종 판단은 회사와 감사인이 하며, 세무 관련 판단은 회사와 세무 대리인 · 관세사가 확인해야 합니다. 화면이 보여 주는 숫자는 점검할 후보를 좁혀 주는 용도입니다.

도입 효과를 숫자로 말할 수 있습니까?

시간 절감률 같은 숫자는 말씀드리지 않습니다. 대신 검증용 샘플에서 확인한 사실만 적습니다. 예정 대비 +13,105.0 백만원을 여섯 요인으로 가르자 입고 시점이 +15,132.4 로 가장 큰 몫이었고, 합이 총차이와 같은지 3,678줄 전부에서 차이 0으로 확인했습니다.

숫자와 산식

기초 · 선적 · 입고 · 기말이 왜 항상 맞습니까?

라인마다 기초 기준일(2026-08-31)과 기말 기준일(2026-09-30) 시점의 상태를 같은 규칙으로 판정해 금액을 만들기 때문입니다. 기초 미착 + 당월 선적 − 당월 입고 = 기말이 성립하도록 계산하고, 3,678줄 전부(실적 · 예정)와 큐브 칸 1,236개에서 차이 0임을 확인했습니다. 선적월 축으로 나눠도 합이 어긋나지 않습니다.

미착 잔액은 어떻게 정의합니까?

기말 기준일에 선적됐고 아직 입고되지 않은 금액입니다. 샘플에서는 선적일과 입고일로 판정하며, 운영에서는 선적일의 원천(공급사 확인 또는 포워더 자료)을 먼저 정해야 합니다. 선적 정보가 없는 라인은 ‘미선적’ 체류 구간으로 따로 보입니다.

장기 체류는 어떻게 판정합니까?

기말 기준일에서 선적일을 뺀 체류일이 45일을 넘으면 장기 체류 잔액에 넣습니다. 45일은 샘플의 가정값이며 운영에서는 회사 기준으로 바꿉니다. 샘플에서는 잔액 34,837.9 중 5,496.2 백만원(15.8%)이고 라인으로는 1,611줄 중 262줄입니다.

요인분해는 어떤 방식입니까?

라인 단위로 예정 값을 선적 시점 · 선적 수량 · 외화 단가 · 환율 · 입고 시점 · 부대비용 순서로 하나씩 실적 값으로 바꿔 가며 기말 잔액이 얼마나 달라지는지 계산합니다(순차 대입). 정수 원화로 계산하므로 요인 합이 총차이와 정확히 같습니다.

순서가 바뀌면 요인별 몫은 달라질 수 있지만 합은 변하지 않으며, 이 순서는 화면과 설명서에 고정되어 있습니다.

외화와 환율은 어떻게 처리합니까?

라인 금액은 수량 × 외화 단가 × 환율 × 부대비용율로 원화 환산해 만들고, 합계는 원화 환산 값만 더합니다. 통화별 외화 금액은 합산하지 않습니다. 샘플의 환율은 월별로 움직이도록 만든 가정값이며, 운영에서는 환율 유형과 환산 시점을 회사 기준으로 정해야 합니다.

예정은 무엇을 기준으로 합니까?

구매오더가 처음 약속한 선적 · 도착 일정과 수량 · 단가 · 예정 환율입니다. 예정 큐브는 실적 큐브와 같은 키 · 같은 측정값 이름을 써서 화면이 같은 칸에서 빼기만 합니다. 운영에서 예정 환율과 일정을 어느 필드로 볼지는 합의가 필요합니다.

화면 숫자와 원천 라인이 어긋나지 않는다는 걸 어떻게 압니까?

칸을 누르면 그 금액을 만든 라인이 열리고 칸 값과 라인 합이 같은지 머리 줄에 표시됩니다. 별도로 큐브 합계와 원천 라인 합계를 측정값 7종마다 비교한 검산 표가 있고, 표본 4칸(39.4 · 43.8 · 21.3 · 1,730.1 백만원)에서 라인 합과 같았습니다.

화면과 분석 기능

축을 바꾸면 서버를 다시 부릅니까?

아닙니다. 조회 때 읽어 둔 큐브를 브라우저가 행 · 열 축 순서대로 다시 묶습니다. 축 8가지 배치에서 서버 요청은 0회였고 총합은 모두 같았습니다. 열 조합이 36개를 넘으면 앞쪽만 보여 주고 범위를 좁히라는 안내를 띄웁니다.

예정 대비 차이의 색은 어떤 기준입니까?

금액 임계와 비율 임계를 둘 다 넘은 칸만 증가는 붉은색, 감소는 초록색으로 칠합니다. 하나만 넘으면 칠하지 않습니다. 임계는 화면에서 바꿀 수 있고(샘플 기본은 1,000,000원, 10%), 59개 칸을 비교한 점검에서 49개가 칠해졌으며 판정과 어긋난 칸은 없었습니다.

변동 사유는 어디에 저장되며 축을 바꾸면 사라집니까?

사유는 조회 범위와 행 경로에 묶여 저장되고 서비스에 남습니다. 축을 바꿔도 같은 행이면 따라오고, 화면을 새로 고쳐 다시 열어도 사유 건수가 유지되는 것을 확인했습니다.

AI 분석은 외부 AI 서비스를 씁니까? 숫자를 모델이 만듭니까?

기본은 규칙 기반 해설이며 외부 서비스를 부르지 않습니다. 금액과 비율은 서비스가 큐브에서 계산하고 문장은 그 숫자만 풀어 씁니다. 모델 연결은 서비스 설정에서만 켜는 선택 사항이며, 연결하더라도 숫자는 서비스가 준 값만 근거로 쓰도록 되어 있습니다.

PowerPoint 보고서는 어떻게 만들어집니까?

AI 분석 창의 PPTX 보고서 버튼을 누르면 브라우저가 표와 차트를 담은 .pptx 를 직접 만들어 내려받습니다. 서버를 거치지 않으며 샘플에서 만든 보고서는 6장이었고 파이썬 라이브러리로 열었을 때 오류가 없었습니다.

에이전트는 무엇을 하고, 하루 두 번 실행하면 어떻게 됩니까?

감시 규칙 5개를 평가해 걸린 항목을 받을 사람의 눈으로 다시 적은 보고로 대기함에 올립니다. 서버가 하루 한 번만 인정하므로 두 번째 실행은 한도(LIMITED)로 판정되어 실행 기록에만 남고 새 보고는 올라가지 않습니다. 샘플에서 첫 실행은 규칙 5개 중 4개가 걸렸습니다.

레이아웃은 무엇이 저장됩니까?

행 · 열 축, 조회 조건, 표시 항목, 영역 접힘이 저장됩니다. 기본으로 지정하고 ‘열 때 자동 조회’ 를 켜면 열자마자 같은 모양으로 조회됩니다. 새로 고침 뒤 복원되는 것을 확인했습니다.

휴대폰에서도 쓸 수 있습니까?

390px 폭에서 가로 넘침 없이 동작합니다. 조회 버튼은 항상 보이고 차트는 표 아래로 내려가며 표는 가로로 밀어 봅니다. 열이 너무 많으면 앞의 36개만 보여 주는 한계는 같습니다.

도입과 운영

운영 데이터에 연결하려면 무엇이 필요합니까?

CDS 구성에 적은 뷰(기준 · 차원 · 큐브 · 쿼리 · 권한 · 서비스)를 만들고 서비스를 활성화한 뒤 화면의 서비스 주소만 바꿉니다. 코딩보다 선적일 원천, 항로 매핑, 부대비용 반영 기준, 환율 유형 같은 합의가 먼저입니다. 소요 기간은 합의 범위에 따라 달라 현재 확인 필요입니다.

권한과 보안은 어떻게 합니까?

큐브를 읽는 자리에 플랜트(또는 구매 조직) 단위 권한 정의를 겁니다. 합계만 보여도 금액이 노출되므로 같은 화면이라도 담당 범위의 금액만 보이게 합니다. 사유 · 레이아웃 · 규칙 쓰기와 에이전트 실행에는 별도의 쓰기 권한과 감사 기록 범위를 정해야 합니다.

대용량에서는 어떻게 됩니까?

집계는 서버(큐브 뷰)에서 끝내고 화면에는 칸 단위만 내려보냅니다. 기준일과 기간을 필수 파라미터로 두고, 선하증권 품목 라인은 칸을 눌렀을 때만 페이지 단위로 읽습니다. 응답 시간 기준은 도입 전에 합의해야 합니다.

항로나 운송수단 같은 매핑이 바뀌면 어떻게 합니까?

항로 · 운송사 그룹은 고객사가 관리하는 매핑이라 바뀌면 차원 뷰의 매핑 테이블만 고칩니다. 화면은 차원 목록을 서비스에서 읽어 오므로 화면 수정은 필요 없습니다. 이전 기간 숫자를 다시 묶을지는 합의가 필요합니다.

화면은 점검 도구라고 하는데, 책임은 누구에게 있습니까?

이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다. 세무 신고 관련은 회사와 세무 대리인 · 관세사가 확인합니다. 화면은 후보를 좁혀 주고, 확인과 전기는 표준 화면에서 합니다.

샘플 숫자는 실제 업무 데이터입니까?

아닙니다. 공급사 · 자재 · 선하증권 번호는 모두 가상이고, 환율과 체류 기준 등은 가정값입니다. 사례의 숫자는 같은 검증용 샘플에서 나온 것이며 실제 거래 결과가 아닙니다.

SAP 수입 미착품 다차원 분석 — 선적 후 미입고 잔액을 축으로 나눠 보고 예정과 다른 이유를 여섯 요인으로 가르는 수입 점검 화면

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

핵심 포인트 일곱 가지

사례로 보는 효과

도입하면 달라지는 것

이런 회사에 맞습니다

실행 화면

사용 방법

무엇으로 만들었나

처음 열었을 때

임원 요약 — 자리마다 다른 화면

축 전환과 범위 — 끌어다 놓기

칸에서 선하증권 품목 라인까지

계산항목 — 합산한 뒤에 나누는 비율

예정 대비 차이 — 같은 표가 회의 자료가 된다

AI 분석과 보고서

AI 에이전트 — 사람이 열지 않아도 도는 점검

레이아웃 저장과 복원

좁은 화면과 한계

화면 뒤에서 일어나는 일

판정 규칙

요인 산식

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

파일 구성

SAP 표준 기능 확장 포인트

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

T-code 별 연계 지점

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

분석 지표 정의표

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

CDS 구성

뷰 레이어 구성

① 라인 기준 뷰 — 선적 후 미입고 라인을 한 줄로

② 이력 뷰 — 입고 일자와 입고 수량

③ 차원 뷰 — 공급사·자재·항로 이름

④ 큐브 뷰 — 두 기준일 시점의 잔액을 한 번에

⑤ 예정 큐브 — 구매오더 조건 기준의 예정 값

⑥ 쿼리 뷰 — 화면이 읽는 분석 쿼리

⑦ 권한 정의 — 플랜트 단위 접근 제한

⑧ 서비스 정의 — 화면이 붙는 OData 서비스

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

자주 묻는 질문

도입과 활용

숫자와 산식

화면과 분석 기능

도입과 운영