SAP 영업 여신 통합 관리 — 한도 변경부터 수주 여신 점검 · 청구 전환 · 보류 · 연체 독촉 · 수금까지 한 앱에서 처리하고 승인 · 대사 · 분석으로 닫는 여신 운영

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

여신 업무의 질문은 늘 같습니다. 이 고객에게 이 수주를 받아도 되는가, 한도를 올려 줄 것인가, 연체 고객에게 누가 어떤 단계로 독촉할 것인가, 그리고 지금 보이는 숫자가 맞는가. 현업은 이 답을 한도 변경(FD32), 차단된 SD 문서(VKM1), 판매 오더(VA03), 고객 라인 아이템(FBL5N), 독촉(F150), 수금 반영(F-28)처럼 표준 화면 여럿을 오가며 얻고, 승인은 메일로 받고, 대사는 월말 엑셀로 맞춥니다. 표준 화면이 부족해서가 아니라 업무가 한 줄로 이어져 남지 않기 때문에 느려지는 자리입니다.

이 앱은 그 자리를 메웁니다. 한도 변경에서 수금 반영까지 일곱 가지 문서를 같은 상태 흐름(임시저장 → 검토요청 → 승인 → 확정, 필요하면 반려와 취소)으로 처리하고, 일괄 실행과 대사, 다차원 분석, 영역 간 문서 흐름, 감사 이력까지 한 앱 안에 둡니다. 업무 흐름 범위는 한도 변경 → 수주 여신 점검 → 청구 전환 → 여신 보류 · 해제 → 연체 독촉 → 수금 반영이며, 특정 기준서의 적용 판단을 대신하는 앱이 아니라 처리와 점검을 돕는 도구입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(고객 48곳 · 문서 570건 · 문서 항목 3,678건 · 채권 808건)에서 2026-01 ~ 2026-10 수주 여신 점검액은 실적 64,236,219,000원, 계획 60,010,088,000원이었습니다. 표준 리포트는 여기서 총차이 4,226,131,000원이 났다는 데까지 말해 줍니다. 이 앱은 차이를 다섯 요인으로 가릅니다.

총차이만 보면 “약 42억 원 더 받았다”로 끝나지만, 요인으로 가르면 초과 +52.6억 원과 미달 −46.1억 원이 서로 상쇄하고 있고 신규 발생이 +41.1억 원이라는 점이 드러납니다. 원인은 화면이 단정하지 않습니다 — 점검 필요 항목으로만 올리고, 판단은 담당자가 합니다. 같은 샘플에서 연체 독촉 일괄 실행은 시뮬레이션이 미리 보여 준 문서 9건 · 3,877,300,000원과 실행 뒤 생성된 문서 합계가 같았고, 대사는 247건을 점검해 의도적으로 심어 둔 예외 12건 외에는 차이가 0이었습니다.

도입하면 달라지는 것

• 승인 대기와 반려가 할 일로 모인다 — 문서 승인 대기 22건 · 반려 18건이 개요 화면의 할 일로 보입니다.
• 독촉 준비 시간이 줄어든다 — 독촉 대상 9건을 시뮬레이션으로 미리 보고 한 번에 만듭니다.
• 월말 대사가 규칙이 된다 — 6개 규칙 · 247건 점검에서 의도적 예외 12건만 남습니다.
• 차이 설명이 한 화면에서 나온다 — 총차이 4,226,131,000원을 다섯 요인으로 가르고 검산합니다.

사람 · 회의 · 마감 관점에서 보면, 승인자는 메일 대신 할 일 목록에서 점검 결과가 붙은 문서를 열고, 회의의 주제는 “어느 숫자가 맞나”에서 “이 고객에게 무엇을 할 것인가”로 옮겨 갑니다.

이런 회사에 맞습니다

고객별 여신 한도를 운영하고 수주 · 청구 · 수금이 매달 수백 건 이상 오가는 영업 조직. 여신 담당 · 영업 책임자 · 물류 담당이 같은 고객을 서로 다른 화면으로 보고 있는 회사. 표준 화면은 쓰지만 승인 근거와 대사 증적을 엑셀과 메일로 남기고 있는 경영지원 조직. 법인 · 사업장 수가 늘수록, 승인 단계가 둘 이상일수록, 독촉과 보류 해제를 여러 부서가 나눠 처리할수록 이 앱이 하나로 묶어 주는 몫이 커집니다.

실행 화면

아래 화면은 모두 검증용 샘플 데이터로 실제 브라우저에서 찍은 것입니다(고객 이름 · 한도 · 환율은 가상 값과 가정값입니다). 왼쪽 메뉴 순서와 같게 개요 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 → 분석 → 영역 간 연계 → 이력 · 감사 순서로 따라갑니다.

사용 방법

1. 조회조건을 넣습니다. 위쪽 조회조건 줄에 영업조직(기본 전체) · 기간 시작 / 종료(필수, 2026-01 형식, 기본 2026-01 ~ 2026-10) · 고객(선택, 고객 코드)이 있습니다. 기간이 거꾸로면 안내 메시지가 뜹니다.
2. 조회 버튼은 조회조건 줄의 오른쪽 끝에 있고, 입력 칸에서 Enter 키를 눌러도 조회됩니다. 개요 화면은 열 때 바로 읽고, 분석 화면은 [조회]를 눌러야 큐브를 한 번 읽어 옵니다.
3. 개요에서 요약을 봅니다. 총 여신 한도 · 총 노출액 · 한도 사용률 · 보류 고객 수 · 연체 잔액 · 승인 대기 · 반려 · 미해결 대사 예외 · 확정 문서 · 열린 할 일, 열 개 카드와 역할별 요약이 나옵니다.
4. 왼쪽 메뉴 순서대로 이동합니다. 개요 · 할 일 → 기준정보 관리 → 문서 처리 → 일괄 실행 → 대사 · 점검 → 분석 → 영역 간 연계 → 이력 · 감사 · 권한. 메뉴는 ☰ 로 접고 펼 수 있습니다.
5. 행을 누르면 상세가 열립니다. 문서 처리는 오른쪽에 상세가 열리고 항목 · 상태 이력 · 연계 문서 · 감사 로그 탭이 있습니다. 기준정보는 행 앞 선택 칸을 누른 뒤 수정 · 사용 중지 · 변경 이력 · 고객 문서 버튼을 씁니다.
6. 처리는 상태 순서대로 합니다. 생성 → 저장(임시저장) → 검토 요청 → 승인 → 확정(전기) 순이고, 확정한 문서는 역처리(취소)로 되돌립니다. 지금 누를 수 없는 버튼은 보이지 않거나 사유가 안내됩니다.
7. 내려받기는 목록 머리의 CSV · xlsx, 분석 화면의 PowerPoint · CSV 입니다. 문서는 xlsx 로 한꺼번에 올릴 수도 있고, 형식 검사 결과를 미리 본 뒤 반영합니다.
8. 사용자 전환은 오른쪽 위 목록에서 합니다(조회자 · 처리자 · 승인자 · 관리자). 이 전환은 시연용이며, 역할에 따라 보이는 버튼과 서버가 허용하는 처리가 달라집니다.

무엇으로 만들었나

처음 열었을 때 — 할 일부터 보인다

맨 위 열 개 카드는 조회 범위 기준 값입니다. 총 여신 한도 49,980백만 원, 총 노출액 36,908백만 원(수주 잔액 + 미결 채권), 한도 사용률 73.8%(노출액 ÷ 한도), 연체 잔액 6,133백만 원, 승인 대기 22건, 반려 18건, 미해결 대사 예외 11건, 확정 문서 457건, 열린 할 일 80건입니다. 사용률 80% 이상은 점검 필요로 칠합니다. 카드 아래 역할별 요약(경영진 · 영업 책임자 · 여신 담당 · 물류 담당)을 누르면 분석 화면이 그 역할의 관점(측정값과 쪼개는 차원)으로 열립니다. 아래에는 내 역할의 할 일과 에이전트가 올린 알림이 나옵니다.

기준정보 관리 — 한도와 등급을 한곳에서

탭은 고객 여신 마스터와 등급 정책 두 개입니다. 사용률이 100%를 넘으면 빨갛게 보이고(예: 누리솔루션 168.1%), 한도가 0인 신규 고객은 사용률 0%입니다. 위 검색어(코드 · 이름) · 여신 상태 · 등급 · 상태로 거르고, 관리자 역할만 생성 · 수정 · 사용 중지 · 다시 사용을 할 수 있습니다. 모든 변경은 변경 이력에 남습니다.

한도를 3억 원에서 3.5억 원으로 바꾸고 저장하면 새로 고친 뒤에도 350,000,000원으로 남습니다(서비스가 실제로 기록합니다). 한도는 0 이상이어야 하고, 필수 칸이 비면 저장되지 않습니다. 사용 중지는 아직 확정되지 않은 문서가 그 고객을 쓰고 있으면 서버가 안내하며 막습니다.

문서 처리와 승인 — 같은 상태 흐름으로

목록은 문서번호 · 구분 · 고객 · 영업조직 · 문서일 · 금액 · 통화 · 점검 결과 · 상태 순입니다. 위 [생성] · [한도 점검] · [업로드(xlsx)] · [CSV] · [xlsx] 버튼이 있고, 점검 결과가 한도 초과인 문서는 빨간 글씨로 표시됩니다. 역처리 문서(RV 로 시작)는 금액이 음수로 보입니다.

고객 다온시스템에 600,000,000원 수주를 점검하면 점검 결과가 한도 초과(점검 필요), 사용 후 노출액 600,000,000원, 사용률 133.3%로 나옵니다. 승인 단계는 0 / 2단계 — 금액이 1억 원 이상이고 점검 결과가 이내가 아니므로 두 단계 승인 대상입니다. 아래 상태 이력에 만든 사람과 일시가 남습니다.

화면 아래 토스트 메시지 “검토 요청했습니다.”가 잠깐 뜨고 같은 문서는 승인자의 할 일에 올라갑니다. 이 시점부터 작성자는 내용을 고칠 수 없습니다. 반려된 문서(90)는 보완한 뒤 같은 버튼으로 다시 요청합니다.

메시지는 “2단계 승인은 1단계 승인자와 다른 관리자만 할 수 있습니다.”입니다. 작성자 본인이 자기 문서를 승인하려는 경우도 같은 방식으로 거절됩니다. 거절된 요청은 감사 로그에 “권한 없음”으로 남아, 막힌 시도도 증적이 됩니다.

대화상자에는 “금액 600,000,000 KRW — 2단계 승인 대상입니다. (현재 0단계 완료)”와 함께 한도 점검 결과가 한 줄로 적혀 있습니다. 승인 메모에 예외 사유(여기서는 담보 확인 후 예외 승인)를 적어야 [확인]이 동작하며, 사유 없이 서버로 보내도 거절됩니다.

승인 단계는 2 / 2로 바뀌고 승인자 항목에 마지막 승인자가 남습니다. 확정은 승인자 역할 이상만 누를 수 있으며, 점검 결과가 보류인 수주 · 청구 문서는 승인돼 있어도 확정이 거절됩니다(보류 해제 후 진행).

이 화면에서는 상태가 확정이고 역처리(취소)와 후속 문서 만들기가 나타납니다. 수주 점검은 청구 전환으로, 보류는 보류 해제로, 연체 독촉은 수금 반영으로 이어지며, 후속 문서는 원문서의 남은 금액 안에서만 만들 수 있습니다.

연계 문서 탭에 앞 문서 OC26000135 → 뒤 문서 RV26000027(확정 취소)이 한 줄로 이어져 보이고, 출하 일정을 참조한 물류 문서도 같은 흐름에 나옵니다. 아래 감사 로그에는 승인 → 확정 → 역처리 순서와 처리자가 남습니다. 역처리는 한도 변경 · 수주 점검 · 보류 · 해제 · 수금만 가능하고, 닫힌 기간의 문서는 거절됩니다.

남는 것은 목록을 내려받는 CSV · xlsx 뿐입니다. 버튼을 숨기는 것으로 끝나지 않고, 조회자가 처리 요청을 직접 보내도 서버가 권한 없음으로 거절합니다.

일괄 실행 — 시뮬레이션 합계와 실행 결과가 같다

국내 영업(S100) 2026-10 기준일 2026-10-16로 돌리면 생성 9건 · 제외 2건 · 문서 금액 3,877,300,000 KRW가 나옵니다. 고객마다 최대 연체일과 비고(1차 독촉 · 2차 독촉 · 보류 검토 필요)가 붙고, 이미 진행 중인 독촉 문서에 담긴 청구서만 있는 고객은 제외 사유와 함께 따로 보입니다. 시뮬레이션은 아무것도 저장하지 않습니다.

실행 이력의 RN00006은 문서 수 9건, 문서 금액 3,877,300,000 KRW로 시뮬레이션 합계와 같습니다. 같은 조건으로 다시 돌리면 중복 문서를 만들지 않고 거절되며, 만들어진 문서는 모두 임시저장이라 검토 요청부터 진행합니다. 아래 실행 로그에서 문서별 생성 내용을 확인합니다.

대사와 예외 조치 — 차이를 규칙으로 잡고 조치로 닫는다

규칙은 고객 연체 잔액 · 미결 채권 · 노출액 · 보류 잔액 · 수주 잔액(고객 기준 5개)과 원장 합계(1개)입니다. 결과 표에서 규칙마다 점검 건수 48건(원장 합계는 측정값 7건), 차이 건수, 좌 · 우 합계, 최대 차이를 봅니다. 의도적으로 심어 둔 차이가 R1 2건 · R2 3건 · R3 2건 · R4 2건 · R5 3건, 합계 12건이며 최대 차이는 R5의 15,000,000원입니다.

마루정밀(R1)의 차이 −2,800,000원은 정정 문서 생성으로 조치합니다. 사유를 적고 [조치]를 누르면 정정 문서가 만들어져 예외에 연결되고, 상태는 미해결에서 조치 중으로 바뀝니다.

EX000001은 해소, EX000002는 조치 중(정정 문서 연결), 나머지는 미해결입니다. 조치 중인 예외는 [대사 실행(재대사)]을 다시 돌려 차이가 사라지면 해소로 바뀌며, 이 흐름은 서비스 검증에서 확인했습니다. 12건의 합은 언제나 미해결 + 조치 중 + 해소와 같습니다.

분석 — 같은 큐브에서 나오는 피벗 · 차이 · 드릴스루

기본 배치는 행 축 등급, 열 축 기간이며 측정값은 수주 점검액입니다. 전체 합계 64,236,219,000원이 등급별(A 41,519,156,380 + B 15,196,408,240 + C 6,180,005,200 + D 1,340,649,180)로 나뉘어 합이 같습니다. 칸을 누르면 그 금액을 만든 문서 라인(드릴스루)이 열리고, 행 축은 최대 3단계 · 열 축은 최대 2단계(열 36개 상한)까지 둘 수 있습니다.

[행↔열 바꾸기]를 누르면 행 축이 기간, 열 축이 등급으로 바뀌고 전체 합계는 그대로 64,236,219,000원입니다(요청 0건 확인). 차원 칩을 끌어다 놓아도 같습니다. 비교 기준을 계획으로 켜면 같은 표가 칸마다 차이와 증감률을 보여 주는 차이 리포트가 되고, 색은 금액 1백만 원과 증감률 5%를 둘 다 넘을 때만 칠합니다.

AI 분석과 에이전트 — 숫자는 서비스가, 설명만 AI 가

화면 맨 위에 “AI 는 숫자를 만들지 않습니다”가 먼저 나옵니다. 요약은 실적 64,236,219,000원, 계획 60,010,088,000원, 차이 +4,226,131,000원(7%)이고 가장 큰 요인은 초과(+5,262,040,000원)이지만 “원인은 확인 필요”로 끝납니다. 핵심 발견은 수연바이오(+212.1%)처럼 계획 대비 크게 벌어진 고객을 점검 필요로 올립니다. 모델 연결은 서비스 설정에서만 켤 수 있고 기본은 꺼져 있으며, [PowerPoint 보고서]로 같은 내용을 내려받습니다.

[지금 실행]을 누르면 “감시 규칙 4건 점검 — 걸린 항목 28건, 대기함에 보고 올림”이 나옵니다(여신 사용률 90% 초과 12건 · 연체 비중 30% 초과 12건 · 보류 30일 초과 3건 · 승인 대기 적체 1건). 하루 한 번 제한은 서버가 판정하므로 같은 날 두 번째 호출은 “활동 기록만 남겼습니다”로 끝납니다. 운영에서는 이 호출을 배치(SM36)나 cron 으로 매일 한 번 돌립니다.

영역 간 연계 — 영업 문서가 물류 · 재무로 이어지는 흐름

수주 여신 점검 OC26000010은 물류의 출하 일정 참조(DL26000010)와 영업의 청구 전환(BL26000013)으로 이어지고, 청구 전환은 재무의 매출채권 전표(FI26000013)로 이어집니다. 같은 영역 문서는 누르면 문서 처리로 이동하고, 다른 영역 문서는 흐름만 보여 줍니다. 아래 표는 연계 내역과 금액, 비고(어떤 표준 단계에 해당하는지)를 CSV 로 내려받을 수 있습니다.

이력 · 감사 · 역할 — 막힌 시도까지 남는다

조회자는 READ 뿐이고, 처리자는 편집 · 검토 요청 · 생성 · 일괄 실행 · 대사 · 조치 · 업로드, 승인자는 여기에 승인 · 반려 · 확정 · 역처리를, 관리자는 기준정보 관리까지 가집니다. 아래 표의 상태 전이(임시저장 → 검토요청 → 승인 → 확정 → 취소) 밖의 요청은 서버가 안내와 함께 거절하며, 거절된 요청도 감사 로그에 남습니다. 운영에서는 이 역할을 SAP 권한 객체와 역할로 옮깁니다.

레이아웃과 좁은 화면 — 휴대폰에서도 같은 숫자

긴 표는 가로로 넘기고 상한을 넘는 축 조합에는 안내 문구가 뜹니다. 레이아웃은 이름을 붙여 저장해 두었다가 다시 불러올 수 있고, 기본 레이아웃 + 자동 조회로 지정하면 열자마자 조회된 채 시작합니다.

숫자 · 판정은 넓은 화면과 같은 서비스 값을 쓰므로 폭이 달라져도 합계가 달라지지 않습니다.

화면 뒤에서 일어나는 일

화면은 서비스가 판정한 결과를 보여 줄 뿐입니다. 판정은 다음 순서로 이루어집니다.

점검 결과 판정 규칙

수주 점검 · 청구 전환 · 한도 변경 문서에는 점검 결과가 하나만 붙고, 여러 조건이 겹치면 가장 앞선(무거운) 것이 남습니다.

보류 · 보류 해제 · 연체 독촉 · 수금 반영 · 정정 문서는 해당 없음으로 표시합니다. 승인 단계는 기본 1단계이고, 점검 결과가 이내가 아니면서 금액이 1억 원 이상이거나 한도 변경의 증감 합계가 3억 원 이상이면 2단계입니다. 1단계는 승인자(또는 관리자), 2단계는 1단계 승인자와 다른 관리자가 승인합니다.

문서 유형과 확정 효과

상태 전이와 직무 분리

일괄 실행의 처리 단계

1. 시뮬레이션 — 대상을 모아 문서 미리보기와 상태 해시를 돌려줍니다. 아무것도 저장하지 않습니다.
2. 실행 — 해시가 시뮬레이션 때와 같을 때만 문서를 만듭니다. 달라졌으면 다시 시뮬레이션하라는 안내와 함께 거절합니다.
3. 중복 방지 — 같은 유형 · 기간 · 영업조직 · 동일 대상의 재실행, 이미 진행 중인 문서에 담긴 대상은 서버가 제외하거나 거절합니다.
4. 로그 — 실행번호 · 유형 · 기간 · 문서 수 · 금액과 문서별 생성 내용이 남습니다. 합계는 시뮬레이션 합계와 같아야 합니다.

연체 독촉 일괄(기준일 2026-10-16)은 연체일 1일 이상의 미결 채권을 고객별로 묶어 고객당 문서 1건을 만들고, 연체일이 60일을 넘으면 “보류 검토 필요”로 표시합니다. 정기 한도 재산정은 재산정 시기가 도래한 활성 고객의 제안 한도를 노출액 × 1.3을 1천만 원 단위로 올림하되 최소 1천만 원, 등급 최대 한도 이내로 계산하고 증감이 1천만 원 이상일 때만 한도 변경 문서를 만듭니다.

대사식

1. R1 고객 연체 잔액 = 미결 채권 중 연체(연체일 1일 이상) 미결 금액 합
2. R2 고객 미결 채권 = 채권 미결 금액 합
3. R3 고객 노출액 = 수주 잔액 + 미결 채권
4. R4 고객 보류 잔액 = 확정 보류 − 확정 보류 해제(역처리 반영)
5. R5 고객 수주 잔액 = 확정 수주 점검 − 확정 청구 전환(역처리 반영)
6. R6 측정값별 원장 합계 = 확정 문서 항목 합계 (허용 오차는 규칙마다 1원)

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 왼쪽 메뉴는 아이콘만 남기고 접히며 ☰ 로 다시 펼칩니다.
• 조회조건은 한 줄에 하나씩 세로로 쌓이고 [조회] 버튼은 조건 아래에 놓입니다.
• 차트는 표 옆이 아니라 표 아래로 내려갑니다. 열 상한(36개)을 넘는 축 조합은 안내 문구로 줄이도록 알려 줍니다.
• 합계 · 판정은 넓은 화면과 같은 서비스 값입니다. 폭이 달라져도 숫자가 달라지지 않습니다.

파일 구성

(앱 폴더)
├─ index.html            앱 진입점
├─ Component.js · manifest.json    서비스 선언 · 모델 설정 · 라우팅
├─ view/                 개요 · 기준정보 · 문서 · 일괄 실행 · 대사 · 분석 · 연계 · 감사 화면과 대화상자
├─ controller/           화면별 컨트롤러 (판정은 하지 않고 서비스 결과를 보여 줌)
├─ model/                오류 처리 · 권한 표시 · 큐브 피벗 · 차트 · xlsx/pptx 작성 · 포맷터
├─ i18n/ · css/          문구 · 스타일
├─ odata/                서비스 선언(메타데이터) · 서비스 로직 · 샘플 json
└─ readme.html           설명서

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리와 점검 관점을 더해 확장합니다. 표준 화면을 없애는 앱이 아니라, 표준 화면 여럿에 흩어진 여신 업무를 한 줄로 이어 주고 승인 · 대사 · 분석 근거를 남기는 앱입니다. 아래 표와 설명은 어느 일이 표준으로 충분한지, 어느 자리에서 이 앱이 이어받는지, 운영에서 어디를 손대는지를 순서대로 정리한 것입니다.

표준으로 되는 것과 더하는 것

왼쪽 두 열은 표준 화면으로 충분한 일이고, 오른쪽 두 열은 이 앱이 더하는 관점입니다. 법정 · 감사 · 세무 신고에 쓰는 자료는 표준에서 만든 것이 기준이며, 이 앱의 결과는 그것을 점검하고 설명하는 보조 자료입니다.

T-code 별 연계 지점

이 앱의 결과를 표준 T-code 로 원천 확인하고, 표준 화면의 값을 이 앱에서 다시 보는 방법을 T-code 마다 정리했습니다. 두 화면의 숫자를 맞춰 보는 지점은 대사 R1 ~ R6 이 그대로 받아 줍니다.

오가는 방법

1. 이 앱 → 표준: 문서 상세에서 수주 번호 · 청구 번호 · 고객 번호를 확인한 뒤 VA03 · VF03 · FBL5N 에서 같은 번호로 엽니다. 대사 예외의 고객은 FBL5N 과 FD33 으로 확인합니다.
2. 표준 → 이 앱: 표준 화면에서 본 고객 번호로 이 앱의 고객 여신 마스터를 열면 한도 · 노출액 · 사용률이 보입니다. 문서 목록에서 같은 고객으로 거르면 처리 중인 문서와 연체 독촉 단계가 보입니다.
3. 숫자가 다를 때: 대사 화면에서 규칙(R1 ~ R6)을 돌려 어느 규칙에서 차이가 났는지부터 봅니다. 차이가 난 고객은 정정 문서 · 보류 · 사유 기록 중 하나로 조치하고 다시 돌립니다.

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

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 표준 분석 도구가 있습니다. 이 앱의 분석 화면은 그와 경쟁하는 자리가 아니라 여신 문서 흐름을 기준으로 한 분석 화면입니다. 표준 분석 도구는 회계 · 판매 데이터를 폭넓게 보는 데, 이 앱은 여신 문서(한도 변경 · 수주 점검 · 청구 전환 · 보류 · 독촉 · 수금)를 기준으로 계획과 비교하고 차이를 요인으로 가르는 데 쓰입니다. 운영에서는 아래 CDS 구성을 표준 분석 스택의 큐브와 같은 방식으로 만들기 때문에, 분석 쿼리를 Fiori 분석 앱이나 Analysis for Office 에서 열어도 같은 큐브를 봅니다.

• 표준 CDS 뷰와의 관계 — 고객은 I_Customer, 판매 문서 항목은 I_SalesDocumentItem, 미결 채권 원천은 I_OperationalAcctgDocItem 을 기준으로 삼습니다. 확인하지 못한 표준 뷰는 사용하지 않고 원천 테이블 기준으로 쓰며, 아래 CDS 구성에서는 확인 필요로 표시했습니다.
• Fiori 분석 앱과의 관계 — 구체적인 Fiori 앱 이름은 보유 릴리스의 앱 라이브러리에서 확인한 뒤 연결합니다(확인 필요). 이 글에서는 확인하지 못한 앱 이름을 쓰지 않습니다.
• Analysis for Office 와의 관계 — 분석 쿼리를 서비스로 게시하면 엑셀 쪽 분석 도구에서도 같은 쿼리를 열 수 있습니다. 화면의 피벗 · 드릴스루 · 차이 분해는 이 앱 안에서 바로 쓰고, 엑셀 작업이 필요한 사용자는 같은 쿼리를 엽니다.

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

고객사마다 달라지는 자리는 대체로 일곱 곳입니다. 운영에서는 아래 표의 값을 코드가 아니라 설정이나 매핑 테이블에 두는 것을 권합니다.

분석 지표 정의

이 앱의 분석 화면은 일곱 가지 측정값을 같은 큐브에서 보여 줍니다. 계산항목은 측정값 코드로 식을 적어 두고, 차이 요인은 서비스가 계산합니다.

CDS 구성 — 운영 환경에서 이 앱을 어떻게 만드나

데모는 모델 수준의 서비스로 돌지만, 운영에서는 같은 구조를 CDS 뷰와 RAP 로 옮깁니다. 아래는 기준 → 차원 → 기초 → 큐브 → 쿼리 → 권한 → 서비스 순서로 쌓은 구성과 객체별 코드입니다. 이름과 필드는 기능을 뜻하는 영문으로 지었고, 표준 뷰와 표준 필드 중 확인하지 못한 것은 코드 주석에 확인 필요로 적었습니다. 코드는 구조를 보이기 위한 것이라 보유 릴리스에서 활성화를 확인한 뒤 씁니다.

뷰 레이어 구성

① 등급 정책 테이블

점검 결과가 한도 초과인지 연체 초과인지는 모두 이 표의 값에서 갈립니다. 운영 전환에서 가장 먼저 확정해야 하는 표이고, 값을 바꾸는 일이 개발 요청이 되지 않도록 고객 유지(customizing) 테이블로 둡니다.

" ────────────────────────────────────────────────────────────────
"  zcrd_grade_pol — 고객 등급별 여신 정책 (투명 테이블)
"  최대 한도 · 최대 연체일 · 자동 보류율 · 재산정 주기를 등급 하나당 한 행으로 둔다.
"  코드에 박지 않는 이유 : 정책 개정 때마다 개발자를 부르면
"  점검 결과가 곧바로 낡는다. 값만 바꾸면 판정이 바뀐다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '고객 등급별 여신 정책'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " 유지보수 뷰를 함께 만들어 둔다
define table zcrd_grade_pol {
  key mandt        : mandt not null;
  key grade        : abap.char(1) not null;   " A ~ D
  grade_text       : abap.char(40);
  @Semantics.amount.currencyCode : 'zcrd_grade_pol.currency'
  max_limit        : abap.curr(15,2);          " 등급별 최대 한도
  currency         : waers;
  max_overdue_days : abap.int4;                " 이 일수를 넘으면 점검 결과 OVD
  auto_hold_rate   : abap.dec(5,2);            " 사용률(%)이 이 값을 넘으면 자동 보류 검토
  review_months    : abap.int4;                " 정기 한도 재산정 주기
  active           : abap_boolean;
}

② 고객 차원 뷰

고객 한 명이 한 행이고, 영업조직 · 지역 · 채널 · 그룹 · 등급이 모두 여기에서 나옵니다. 값 도움말과 텍스트가 이 뷰 하나를 보게 하면 큐브는 join 을 한 번만 걸면 됩니다. 한도는 표준 여신 관리 쪽에 있다면 그 원천에서 읽고, 그 필드명은 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CreditCustomer — 고객 차원
"  고객 한 명당 한 행. 등급 정책과 한도를 여기서 붙인다.
"  차원 뷰를 따로 두는 이유 : 큐브 · 쿼리 · 대사 뷰가 모두 같은 고객 속성을
"  보게 하고, 값 도움말과 텍스트를 한 곳에 모으기 위해서다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '여신 고객 차원'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'Customer'
define view entity ZI_CreditCustomer
  as select from I_Customer          as Cust
  left outer join zcrd_cust_ext      as Ext                    // 등급 · 채널 · 그룹 확장 (고객사 고유)
    on Ext.customer = Cust.Customer
  left outer join zcrd_grade_pol     as Pol
    on Pol.grade = Ext.grade
  association [0..1] to I_CustomerText as _Text                // 확인 필요 : 보유 릴리스의 텍스트 뷰 이름
    on _Text.Customer = $projection.Customer
{
      @ObjectModel.text.association : '_Text'
  key Cust.Customer                  as Customer,
      Ext.sales_org                  as SalesOrg,
      Ext.region                     as Region,
      Ext.channel                    as Channel,
      Ext.cust_group                 as CustomerGroup,
      Ext.grade                      as Grade,
      Pol.max_overdue_days           as MaxOverdueDays,
      Pol.auto_hold_rate             as AutoHoldRate,
      // 한도 : 여신 세그먼트 테이블(UKMBP_CMS_SGM)의 한도 필드를 읽는다 — 필드명 확인 필요
      _Text
}

③ 노출액 기초 뷰

노출액은 수주 잔액과 미결 채권의 합입니다. 미결 채권은 표준 회계 항목에서, 수주 잔액은 판매 문서 항목에서 오고, 두 값이 한 뷰에서 만나야 대사 R3 이 성립합니다. 연체일은 저장하지 않고 조회 시점의 기준일로 계산합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CreditExposure — 고객별 노출액 기초
"  미결 채권(표준 회계 항목) + 수주 잔액(판매 문서 항목) = 노출액.
"  연체일을 저장하지 않는 이유 : 저장하면 하루가 지날 때마다 낡는다.
"  기준일은 파라미터로 받아 대사 · 화면이 같은 날짜를 보게 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '고객별 노출액 기초'
define view entity ZI_CreditExposure
  with parameters
    P_KeyDate : abap.dats
  as select from I_OperationalAcctgDocItem as Item           // 필드명 확인 필요
{
  key Item.Customer                                           as Customer,
      Item.CompanyCodeCurrency                                as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Item.ClearingDate is initial
               then Item.AmountInCompanyCodeCurrency else 0 end )  as OpenReceivable,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Item.ClearingDate is initial
                and Item.NetDueDate < $parameters.P_KeyDate
               then Item.AmountInCompanyCodeCurrency else 0 end )  as OverdueReceivable,
      max( case when Item.ClearingDate is initial
                 and Item.NetDueDate < $parameters.P_KeyDate
               then dats_days_between( Item.NetDueDate, $parameters.P_KeyDate )
               else 0 end )                                   as MaxOverdueDays
}
where Item.FinancialAccountType = 'D'                         // 고객 계정
  and Item.SpecialGLCode        = ''                          // 특별 총계정 항목은 포함 여부를 정해야 한다
group by Item.Customer, Item.CompanyCodeCurrency

// 수주 잔액은 판매 문서 항목(I_SalesDocumentItem)에서 별도 뷰로 읽어 같은 고객 키로 붙인다.
// 미출하 · 미청구 잔여 계산에 쓰는 필드는 보유 릴리스에서 확인 필요.

④ 원장 큐브

화면의 피벗 · 드릴스루 · 차이 분해가 모두 읽는 뷰입니다. 확정된 문서 항목 한 줄이 측정값 한 칸만 채우도록 case 로 가르고 sum 으로 모읍니다. 금액은 환산 금액(원화)만 더하고 외화 금액은 통화 필드와 함께 두어 서로 다른 통화가 합쳐지지 않게 합니다. 이 큐브의 합계가 원장 합계와 같은지가 검증 표의 첫 줄입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CreditLedgerCube — 여신 원장 큐브
"  확정 문서 항목 → 기간 · 조직 · 고객 · 등급 · 점검 결과 × 측정값 7개.
"  측정값 : ORD 수주 점검 · BIL 청구 전환 · PAY 수금 반영 · HLD 보류 · REL 해제
"           OVD 독촉 연체 · LMT 한도 증감
"  case 로 나누는 이유 : 한 행에 측정값 하나만 채워 같은 키 아래에서
"  피벗 축을 바꿔도 합계가 변하지 않게 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '여신 원장 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_CreditLedgerCube
  as select from zcrd_doc_item          as Item
  inner join      zcrd_doc_head         as Head
    on  Head.doc_no = Item.doc_no
    and Head.fiscal_year = Item.fiscal_year
  association [0..1] to ZI_CreditCustomer as _Customer
    on _Customer.Customer = $projection.Customer
{
      @ObjectModel.foreignKey.association : '_Customer'
  key Head.cust_no                      as Customer,
  key Head.period                       as Period,
  key Head.sales_org                    as SalesOrg,
  key Head.limit_result                 as CheckResult,        // HLD · OVD · GRD · OVR · OK
  key Head.currency                     as Currency,

      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'OC' then Item.amount else 0 end ) as OrdAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'BL' then Item.amount else 0 end ) as BilAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'PY' then Item.amount else 0 end ) as PayAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'HD' then Item.amount else 0 end ) as HldAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'RL' then Item.amount else 0 end ) as RelAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'DN' then Item.amount else 0 end ) as OvdAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Head.doc_type = 'LM' then Item.amount else 0 end ) as LmtAmt,

      count( * )                                                        as Lines,
      _Customer
}
where Head.status = '40'                                          // 확정 문서만
group by Head.cust_no, Head.period, Head.sales_org,
         Head.limit_result, Head.currency

⑤ 계획 테이블과 차이 분류 뷰

계획 대비 차이를 요인으로 가르려면 실적과 계획이 같은 키에 놓여야 합니다. 실적에만 있으면 신규 발생, 계획에만 있으면 계획 소멸, 둘 다 있으면 크기에 따라 초과 또는 미달입니다. 이 분류를 뷰 한 곳에 고정해 두어야 화면의 다섯 요인과 합계 검산이 같은 규칙을 씁니다. 환율 요인은 외화 행에서 환율 차이로 생긴 몫이며, 환율 유형과 시점은 운영에서 정합니다.

" ────────────────────────────────────────────────────────────────
"  zcrd_plan · ZI_CreditVariance — 계획과 차이 분류
"  계획 테이블은 실적 큐브와 같은 키(기간 · 조직 · 고객 · 통화 · 측정값)를 가진다.
"  분류를 뷰에 두는 이유 : 화면 · 에이전트 · 보고서가 같은 규칙을 쓰게 한다.
"  full outer join 을 쓰지 않고 두 쪽 키를 union 한 뒤 양쪽을 left outer join 한다.
" ────────────────────────────────────────────────────────────────
define table zcrd_plan {
  key mandt    : mandt not null;
  key version  : abap.char(8) not null;    " 예: PLAN
  key period   : abap.char(7) not null;    " 2026-01 형식
  key cust_no  : kunnr not null;
  key measure  : abap.char(3) not null;    " ORD · BIL · PAY ...
  sales_org    : vkorg;
  currency     : waers;
  @Semantics.amount.currencyCode : 'zcrd_plan.currency'
  plan_value   : abap.curr(17,2);
}

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '실적과 계획 키 합집합'
define view entity ZI_CreditVarianceKey
  as select distinct from ZI_CreditLedgerCube { key Period, key Customer, SalesOrg, Currency }
  union
  select distinct from zcrd_plan { key period as Period, key cust_no as Customer,
                                   sales_org as SalesOrg, currency as Currency }

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '수주 점검액 계획 대비 차이'
@Analytics.dataCategory              : #CUBE
define view entity ZI_CreditVariance
  as select from ZI_CreditVarianceKey as K
  left outer join ZI_CreditLedgerCube as Act
    on Act.Period = K.Period and Act.Customer = K.Customer
  left outer join zcrd_plan           as Pln
    on Pln.period = K.Period and Pln.cust_no = K.Customer
   and Pln.measure = 'ORD'   and Pln.version = 'PLAN'
{
  key K.Period,
  key K.Customer,
      K.Currency,
      @Semantics.amount.currencyCode : 'Currency'
      coalesce( Act.OrdAmt, 0 )                                   as Actual,
      @Semantics.amount.currencyCode : 'Currency'
      coalesce( Pln.plan_value, 0 )                               as Plan,
      @Semantics.amount.currencyCode : 'Currency'
      coalesce( Act.OrdAmt, 0 ) - coalesce( Pln.plan_value, 0 )   as Diff,
      case
        when coalesce( Pln.plan_value, 0 ) = 0 and coalesce( Act.OrdAmt, 0 ) <> 0 then 'NEW'    // 신규 발생
        when coalesce( Act.OrdAmt, 0 ) = 0 and coalesce( Pln.plan_value, 0 ) <> 0 then 'GONE'   // 계획 소멸
        when coalesce( Act.OrdAmt, 0 ) >= coalesce( Pln.plan_value, 0 )          then 'OVER'    // 초과
        else 'UNDER'                                                                           // 미달
      end                                                         as FactorKind
      // 환율 요인은 외화 행의 (실적 − 실적 × 계획환율 ÷ 실적환율)로 따로 계산한다 — 환율 테이블 확인 필요
}

⑥ 분석 쿼리

화면이 읽는 것은 이 쿼리뿐입니다. 필터와 축의 기본 배치, 표시 형식만 여기서 정하고 계산은 아래 레이어에 둡니다. 그래서 같은 쿼리를 엑셀 쪽 분석 도구에서 열어도 같은 숫자가 나옵니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CreditUsageQuery — 여신 사용 분석 쿼리
"  기간 · 영업조직은 필터로, 등급 × 기간은 기본 축으로 둔다.
"  쿼리에 계산을 두지 않는 이유 : 계산이 쿼리마다 흩어지면 합계가 달라진다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '여신 사용 분석'
@Analytics.query                  : true
@Metadata.allowExtensions         : true
define view entity ZC_CreditUsageQuery
  as select from ZI_CreditLedgerCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @AnalyticsDetails.query.displayHierarchy : #OFF
  @Consumption.filter : { selectionType : #INTERVAL, multipleSelections : false, mandatory : true }
  Period,

  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  SalesOrg,

  @AnalyticsDetails.query.axis : #ROWS
  _Customer.Grade                       as Grade,

  @AnalyticsDetails.query.axis : #COLUMNS
  @UI.lineItem : [{ position : 10 }]
  OrdAmt,
  @AnalyticsDetails.query.axis : #COLUMNS
  @UI.lineItem : [{ position : 20 }]
  BilAmt,
  @AnalyticsDetails.query.axis : #COLUMNS
  @UI.lineItem : [{ position : 30 }]
  PayAmt,
  @AnalyticsDetails.query.axis : #COLUMNS
  @UI.lineItem : [{ position : 40 }]
  OvdAmt
}

⑦ 접근 제어(DCL)

조회자가 어떤 영업조직의 숫자를 볼 수 있는지는 화면이 아니라 데이터 레이어에서 막습니다. 표준 영업조직 권한 객체를 쓰면 PFCG 역할을 새로 만들지 않고 기존 권한 설계에 올라탈 수 있습니다. 객체와 필드 구성은 운영 권한 설계에서 확인합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CreditLedgerCube_DCL — 영업조직 단위 접근 제어
"  표준 영업조직 권한 객체(V_VBAK_VKO)의 영업조직 · 활동 값을 그대로 쓴다.
"  DCL 로 막는 이유 : 직접 서비스를 호출해도 같은 제한이 걸린다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '여신 원장 큐브 접근 제어'
@MappingRole : true
define role ZI_CreditLedgerCube_DCL {
  grant select on ZI_CreditLedgerCube
    where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

⑧ 문서 처리 — RAP 동작 정의와 서비스 게시

상태 전이와 직무 분리는 화면이 아니라 서버가 지킵니다. RAP 의 액션과 검증으로 옮기면 어느 경로로 호출해도 같은 거절이 나옵니다. 아래는 문서 루트의 동작 정의이고, 승인 액션에서 작성자 본인과 1단계 승인자의 재승인을 막는 검증을 붙입니다.

" ────────────────────────────────────────────────────────────────
"  ZR_CreditDoc — 여신 문서 루트의 동작 정의
"  상태 전이(검토 요청 · 승인 · 반려 · 확정 · 역처리)를 액션으로, 직무 분리를 검증으로 둔다.
"  서버에서 막는 이유 : 화면에서 버튼을 숨겨도 직접 호출하면 뚫린다.
" ────────────────────────────────────────────────────────────────
managed implementation in class zbp_r_creditdoc unique;
strict ( 2 );

define behavior for ZR_CreditDoc alias CreditDoc
persistent table zcrd_doc_head
lock master
authorization master ( instance )
etag master ChangedAt
{
  create;
  update ( features : instance );
  association _Item { create; }

  field ( readonly ) DocNo, Status, LimitResult, ExposureAfter, UsageRate;

  action ( features : instance ) Submit;      // 임시저장 · 반려 → 검토요청
  action ( features : instance ) Approve;     // 1단계 · 2단계 승인
  action ( features : instance ) Reject parameter ZA_RejectReason;
  action ( features : instance ) Post;        // 확정 — 원장 · 큐브 · 고객 잔액 반영
  action ( features : instance ) Reverse parameter ZA_ReverseReason;   // 반대 문서 생성

  determination CheckLimit on save { create; update; }   // 점검 결과 판정
  validation ValidateSegregation on save { field Status; }   // 작성자 본인 · 같은 사람의 2단계 승인 거절
  validation ValidateStatusFlow  on save { field Status; }   // 허용되지 않는 상태 전이 거절
}

" ────────────────────────────────────────────────────────────────
"  ZUI_CreditMgmt — 서비스 정의
"  화면이 읽는 쿼리와 처리하는 문서를 한 서비스로 게시한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '영업 여신 통합 관리 서비스'
define service ZUI_CreditMgmt {
  expose ZR_CreditDoc          as CreditDoc;
  expose ZC_CreditUsageQuery   as UsageQuery;
  expose ZI_CreditCustomer     as Customer;
}

운영 시점에 해야 할 일

운영 전환은 개발보다 정하는 일이 많습니다. 아래 표의 항목을 정하지 않은 채 코드부터 옮기면 같은 질문이 나중에 장애처럼 돌아옵니다.

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

검증용 샘플 데이터(고객 48 · 문서 570 · 문서 항목 3,678 · 채권 808 · 원장 3,052)에서 대사식마다 전수로 맞춰 본 결과입니다. 도입 포인트의 “사례로 보는 효과”에 쓴 숫자와 같습니다. 의도적 예외 12건은 대사가 잡아내는지 보려고 일부러 심어 둔 것이며, 그 12건을 제외하면 어떤 식에서도 차이가 없었습니다.

운영 데이터로 갈 때

데모의 원천 라인은 3,052건이지만 운영의 전표와 문서 흐름은 수천만 건이 됩니다. 이때 정해야 하는 것은 네 가지입니다.

• 집계 위치 — 큐브 집계는 데이터베이스에서 돌려야 합니다. 조회 때마다 전체를 합치기 어려우면 월 단위로 확정된 기간은 집계 테이블에 미리 쌓고 열린 기간만 그때그때 합치는 방식을 씁니다.
• 필수 파라미터 — 기간과 영업조직을 필수 필터로 둡니다. 개요 화면처럼 열자마자 읽는 화면도 기본 기간을 좁게 두어 전체 기간 조회가 기본이 되지 않게 합니다.
• 인덱스와 키 — 큐브가 group by 하는 키(기간 · 영업조직 · 고객 · 점검 결과)에 맞춰 문서 헤더와 항목 테이블의 보조 인덱스를 설계합니다. 인덱스는 실제 쿼리 계획으로 확인한 뒤 정합니다.
• 응답 시간 기준 — 화면별로 “처음 보이는 데까지 몇 초”를 사전에 합의합니다. 드릴스루는 칸을 누른 범위의 라인만 읽도록 필터를 그대로 넘기고, 목록은 한 번에 읽는 건수를 제한해 이어서 읽습니다.

자주 묻는 질문

도입을 검토할 때 자주 나오는 질문을 숫자와 산식 · 화면과 조작 · 분석 기능 · 도입과 운영으로 나눠 답합니다.

숫자와 산식

숫자가 어떻게 만들어지는지, 어디까지 믿어도 되는지에 대한 질문입니다.

화면과 조작

화면을 쓰는 방법과 처리 규칙에 대한 질문입니다.

분석 기능

피벗 · 드릴스루 · AI 분석 · 에이전트에 대한 질문입니다.

도입과 운영

도입 효과, 표준 화면과의 관계, 운영 전환에 대한 질문입니다.