단기 자금 운영 통합 관리 — 지급 예정 편성부터 선지급 소진 · 청구 확정 · 자금 포지션 반영까지 승인과 대사를 한 화면에서

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

자금 담당자는 하루에도 여러 번 같은 질문을 받습니다. 이번 달 지급 예정은 얼마인지, 선지급은 어디까지 소진됐는지, 청구서 금액과 확정 금액이 맞는지, 그 문서는 누가 승인했는지입니다. 지금은 표준 화면 여러 개와 엑셀, 메일 승인을 오가며 답을 맞춥니다. 숫자가 어긋나면 어느 문서에서 났는지 찾는 데 시간이 더 걸립니다.

이 앱은 그 자리를 한 흐름으로 채웁니다. 지급 예정 편성, 선지급 소진, 청구 확정을 문서로 처리하고 승인 · 전기 · 역처리를 거치게 하며, 일괄 실행과 대사 예외 조치, 분석과 감사 이력까지 같은 화면 안에서 이어 갑니다. 관련 기준서는 IAS 7 현금흐름표(K-IFRS 제1007호)와 IFRS 7 금융상품: 공시(K-IFRS 제1107호)이고, 앱은 정보를 모아 점검하는 도구이며 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(가상 값)로 2026-09 처리 금액을 계획과 비교하면 41,139,738.56원 차이가 났고, 요인 다섯 개로 나눈 합계가 같은 금액으로 맞았습니다. 대사 쪽에서는 일부러 남겨 둔 예외 24건(R1 3건 · R2 17건 · R3 2건 · R4 2건)을 미해결 18건 · 조치 중 2건 · 보류 1건 · 해소 2건 · 허용 종결 1건으로 추적했고, 조정 전표를 만들어 다시 대사하면 해소로 바뀌는 것까지 확인했습니다. 위 숫자는 모두 샘플 값이며 효과를 약속하는 수치가 아닙니다.

도입하면 달라지는 것

• 마감 준비 — 편성 · 승인 · 대사 상태가 한 화면에 모여 상태를 따로 적는 일이 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 보다 "어느 예외를 먼저 조치할까" 를 이야기합니다.
• 승인 이력 — 누가 · 언제 · 어떤 값에서 어떤 값으로 바꿨는지 감사 로그로 남습니다.
• 분석의 출발점 — 숫자를 의심하면 전표 라인까지 내려가 직접 확인합니다.

이런 회사에 맞습니다

매월 지급 예정과 선지급 · 청구서를 여러 법인에서 다루고, 승인 단계와 담당 부서가 나뉘어 있어 문서 상태와 대사 결과를 한눈에 보고 싶은 조직에 맞습니다. 월 처리 건수가 수백에서 수천 건이고 승인자가 둘 이상인 자금 · 경영지원 부서를 염두에 두었습니다.

실행 화면 — 화면 36종으로 보는 처리 흐름

사용 방법

1. 조회조건 — 화면 위의 회사와 기간을 고릅니다(둘 다 선택 사항, 기본은 전체 · 열린 기간). 모듈을 옮겨도 조건이 이어집니다.
2. 역할 고르기 — 오른쪽 위 사용자에서 조회자 · 처리자 · 승인자 · 관리자를 바꿉니다. 역할에 따라 버튼이 달라집니다.
3. 요약 확인 — 개요의 타일(마감 진행률 · 기한 경과 · 승인 대기 · 반려 · 전기 대기 · 미해결 예외)을 보고 눌러서 목록으로 이동합니다.
4. 탭 이동 — 왼쪽 메뉴 순서(개요 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 → 분석 → 영역 간 연계 → 이력)가 업무 순서입니다.
5. 행 클릭 상세 — 문서 행을 누르면 분개 항목 · 상태 이력 · 연계 문서가 열리고, 상태에 맞는 버튼만 보입니다.
6. 조회와 내려받기 — 분석은 조회 버튼(또는 Enter)으로 조회하고, 목록은 엑셀 내보내기, 분석은 표 CSV · PPT 보고서로 내려받습니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 처리할 일부터 보입니다

마감 진행률 · 기한 경과 · 승인 대기 · 반려 · 전기 대기 · 미해결 예외 · 보류 · 안 읽은 보고를 타일로 보여 줍니다. 타일 숫자는 위에서 고른 회사 · 기간 기준이고, 예외는 기간과 무관하게 회사 기준입니다.

역할에 맞는 할 일이 종류별로 쌓이고, 행을 누르면 해당 화면으로 이동합니다. 행을 누르면 해당 화면으로 바로 이동하며, 역할이 바뀌면 보이는 할 일도 달라집니다.

기준정보 관리 — 계정과 대상을 서버가 검증합니다

보조원장 잔액과 총계정 잔액을 나란히 두고 신규 · 수정 · 사용 중지를 합니다. 보조원장과 총계정 잔액을 나란히 두어 대사의 출발점을 보여 줍니다.

약정 · 선지급 · 청구서 대상을 구분해 관리합니다. 편성 · 소진 · 청구 대상을 구분해 관리하고, 사용 중인 대상은 삭제 대신 사용 중지로 처리합니다.

필수 항목을 채우면 서버가 검증하고 번호를 채번합니다. 필수값과 형식(예: 계정은 숫자 6자리)을 서버가 확인하고 거절 사유를 알려 줍니다.

엑셀 파일을 고르면 행마다 검증 결과를 먼저 보여 줍니다. 오류 행은 반영에서 빠집니다. 정상 3건과 오류 1건을 올리면 오류 행이 표시되고 정상 건만 반영 대상이 됩니다.

정상 건만 반영하고 성공 · 실패 건수를 알려 줍니다. 반영 뒤에는 성공과 실패 건수를 알려 주고, 실패 사유는 표에서 확인합니다.

문서 처리와 승인 — 승인 버튼은 승인자에게만 보입니다

상태 · 유형 · 기간으로 걸러 보고 엑셀로 내보냅니다. 상태 · 유형 · 기간으로 걸러 보고 엑셀로 내보냅니다.

분개 항목 · 상태 이력 · 연계 문서를 탭으로 보고 상태에 맞는 버튼만 보입니다. 차변과 대변 합계가 맞는지 상세 머리에 표시됩니다.

차변 · 대변 일치와 필수값을 서버가 확인한 뒤 승인 대기로 넘깁니다. 검토 요청 시 필수값과 차대 일치를 서버가 확인합니다.

작성자와 다른 승인자만 승인할 수 있고, 금액 구간에 따라 2단계 승인이 필요합니다. 같은 사용자가 승인하려 하면 직무 분리 메시지로 거절됩니다.

열린 기간에만 전기되고, 권한이 없는 동작은 이유를 안내합니다. 전기는 열린 기간에서만 되며, 권한이 없는 동작은 이유를 안내합니다.

승인자 · 관리자가 사유와 함께 역처리하면 반대 금액의 역분개 문서가 생깁니다. 역처리는 사유가 필수이고 원문서와 연결된 반대 문서가 만들어집니다.

조회자에게는 쓰기 · 처리 버튼이 보이지 않습니다. 조회자로 전환하면 쓰기 · 처리 버튼이 보이지 않고, 직접 요청해도 서버가 거절합니다.

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

실행 조건과 실행 이력을 한 화면에 둡니다. 실행 조건과 실행 이력을 한 화면에 둡니다.

대상과 금액을 저장 없이 먼저 확인합니다. 모의 실행은 저장하지 않으며 대상 건수와 합계를 먼저 보여 줍니다.

실행하면 작성중 문서가 만들어지고 실행 이력에 남습니다. 실행하면 작성중 문서가 만들어지고, 같은 조건 재실행은 중복 없이 0건으로 끝납니다.

대사와 예외 조치 — 차이를 남기고 조치까지 따라갑니다

예외를 상태 · 규칙별로 걸러 조치합니다. 예외를 상태 · 규칙별로 걸러 보고 대상을 눌러 조치합니다.

규칙마다 점검 건수 · 차이 건수 · 최대 차이를 보여 주고, 예외 목록으로 이어집니다. 규칙마다 점검 건수와 차이 건수 · 최대 차이를 비교합니다.

예외에서 조정 전표를 만들면 문서 번호가 예외에 연결됩니다. 조정 전표를 만들면 예외가 조치 중이 되고, 전기 뒤 다시 대사하면 해소로 바뀝니다.

분석 — 축을 바꿔도 합계가 같습니다

행 · 열 축을 바꿔 가며 처리 금액을 보고 계획 대비 차이를 함께 봅니다. 처리 금액 · 유동성 영향 같은 측정값을 행 · 열 축으로 펼치고 계획 대비 차이를 함께 봅니다.

축을 끌어 놓아 행과 열을 바꿉니다. 축을 바꿔도 서버를 다시 부르지 않고 같은 큐브를 다시 묶어, 총합이 변하지 않습니다.

금액 칸을 누르면 그 금액을 이룬 전표 라인이 열립니다. 질의 조건과 합계 일치 여부가 머리에 표시됩니다.

전표 번호를 누르면 문서 상세로 이동합니다. 전표 번호에서 문서 상세로 이어져 처리 상태까지 확인합니다.

총차이가 어느 요인에서 났는지 막대로 보여 줍니다. 요인 합이 총차이와 같은지 검산 줄이 매번 표시됩니다.

열 조합이 한도를 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내를 띄웁니다. 열 조합이 한도를 넘으면 반쯤 그린 표 대신 범위를 좁히라고 안내합니다.

영역 간 연계 — 전기하면 다음 영역 문서가 따라옵니다

재무 문서에서 원가 · 구매 · 자금 문서로 이어지는 흐름을 그리고, 상자를 누르면 문서 상세로 이동합니다. 재무 문서에서 원가 · 구매 · 자금 영역 문서로 이어지는 흐름을 보고 상자를 눌러 상세로 이동합니다.

AI 해설과 에이전트 — 숫자는 서버가 계산합니다

현재 범위의 핵심 발견을 규칙으로 요약합니다. 기본은 규칙 기반 해설이며 모델 연결은 설정으로만 켭니다(기본 꺼짐).

해설에 쓴 근거 표를 펼쳐 숫자를 직접 확인합니다. 해설에 쓴 근거 표를 펼쳐 숫자를 직접 확인합니다.

차이가 큰 행에 사유를 남기면 해설에서 그 단계를 건너뜁니다. 이미 사유가 적힌 차이는 해설에서 건너뜁니다.

감시 규칙에 걸린 항목이 받을 역할 관점의 보고로 올라옵니다. 감시 규칙에 걸리면 받을 역할 관점의 보고가 대기함에 올라옵니다.

하루 한 번 점검을 실행하고 결과 문구를 보여 줍니다. 점검은 하루 한 번만 돌고, 두 번째 호출은 서버가 제한합니다.

이력 · 감사 · 역할

모든 쓰기 · 전이 · 실행 요청이 이전 값과 이후 값과 함께 남고, 거절된 시도도 기록됩니다. 정상 처리와 거절된 시도가 이전 값 · 이후 값과 함께 남습니다.

좁은 화면에서 달라지는 것

390px 폭에서 메뉴가 접히고 타일이 쌓입니다. 폭 390px 에서 메뉴가 접히고 타일이 쌓입니다.

표 아래에 차트가 쌓입니다. 표가 먼저 나오고 차트는 표 아래로 내려갑니다.

차트는 표 아래에서 이어집니다. 아래로 스크롤하면 차트가 이어집니다.

화면 뒤에서 일어나는 일

화면은 서버가 돌려준 값을 보여 줄 뿐이고, 상태 전이 · 채번 · 검증 · 금액 계산은 서비스가 판정합니다. 판정 조건에서 결과 상태, 사용자 조치로 이어지는 규칙은 아래와 같습니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭 600px 이하에서는 메뉴가 접히고 차트가 표 아래로 내려갑니다. 열 조합이 한도(36)를 넘으면 표를 반쯤 그리는 대신 범위를 좁히라는 안내가 나옵니다.

파일 구성

liqhub/
├─ 화면 : view · controller · fragment · css · i18n
├─ model/ : OData 호출 · 큐브 집계 · 보고서 생성
├─ odata/ : 서비스 로직 · 서비스 선언 · 엔티티셋별 데이터
├─ media/ : 소개 영상
└─ readme.html

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

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

T-code 별 연계 지점

기존 리포트를 없애야 하는지 묻는다면 답은 "없애지 않는다" 입니다. 표준 리포트는 그대로 두고, 이 앱의 숫자와 같은 기간으로 맞춰 보는 대사 지점으로 쓰십시오.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 SAP 표준 기능으로 그대로 쓰시면 됩니다. 이 앱은 그 옆에서 승인 · 일괄 실행 · 대사 예외 조치처럼 쓰기가 있는 업무와, 같은 큐브를 축만 바꿔 보는 분석을 더합니다. 특정 Fiori 앱 이름은 확인하지 못해 적지 않았습니다(확인 필요).

기준서 요구사항 매핑

문단 번호는 원문 확인 전이라 적지 않았고, 시행일과 경과규정은 다루지 않습니다.

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

CDS 구성 — 운영 데이터로 갈 때의 구조

뷰 레이어 구성

① 기준 — 계정 · 대상 매핑 테이블

가장 먼저 정할 것은 어떤 계정이 자금 관리 대상이고 어느 구분(편성 · 소진 · 청구)에 속하는지입니다. 이 표가 흔들리면 이후 모든 집계가 어긋나므로 코드가 아니라 데이터로 두어 현업이 직접 관리하게 합니다.

" ───────────────────────────────────────────────
" ZLIQ_ACCT_MAP  자금 관리 대상 계정 매핑
" 역할 : 계정 → 대상 구분(편성 · 소진 · 청구)과 그룹
" 이유 : 계정 추가 때 코드를 고치지 않고 이 표만 갱신하기 위해
" ───────────────────────────────────────────────
@EndUserText.label : '자금 관리 계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zliq_acct_map {
  key client  : abap.clnt not null;
  key bukrs   : bukrs not null;
  key saknr   : saknr not null;
  kind        : abap.char(2);     " PL 편성 · DR 소진 · CF 청구
  acct_group  : abap.char(6);     " ASSET · LIAB · EXP · REV · CLR
  active      : abap_boolean;
}

② 차원 — 계정 차원 뷰

차원 뷰는 화면에 보일 이름과 그룹을 큐브와 떼어 둡니다. 이름이 바뀌어도 큐브를 건드리지 않습니다.

" ───────────────────────────────────────────────
" ZI_LiqAccount  계정 차원
" 역할 : 계정 번호 → 이름 · 그룹 · 대상 구분
" 이유 : 축 값 이름을 큐브와 분리해 재사용
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@ObjectModel.representativeKey: 'Saknr'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_LiqAccount
  as select from zliq_acct_map as m
  association [0..1] to I_GLAccountText as _Text
    on  _Text.ChartOfAccounts = 'YCOA' and _Text.GLAccount = m.saknr
{
  key m.bukrs      as CompanyCode,
  key m.saknr      as Saknr,
      m.kind       as Kind,
      m.acct_group as AcctGroup,
      _Text
}
where m.active = 'X'

③ 큐브 — 전표 라인 집계

큐브는 모든 분석 숫자의 단일 출처입니다. 처리 금액은 절대값 합, 유동성 영향은 방향을 반영한 합으로 나누어 두었고, 통화 환산을 여기서 끝냅니다.

" ───────────────────────────────────────────────
" ZI_LiquidityCube  자금 분석 큐브
" 역할 : ACDOCA 라인을 기간 · 계정 · 구분 축으로 집계
" 이유 : 화면 · 보고서 · 에이전트가 같은 숫자를 읽도록
" ───────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_LiquidityCube
  as select from acdoca as a
  inner join zliq_acct_map as m
    on m.bukrs = a.rbukrs and m.saknr = a.racct
  association [0..1] to ZI_LiqAccount as _Account
    on _Account.CompanyCode = $projection.CompanyCode
   and _Account.Saknr       = $projection.Saknr
{
  key a.rbukrs                                   as CompanyCode,
  key a.gjahr                                    as FiscalYear,
  key a.poper                                    as Period,
  key a.racct                                    as Saknr,
      m.kind                                     as Kind,
      @Semantics.currencyCode: true
      a.rhcur                                    as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( abs( a.hsl ) )                        as AdjAmt,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case m.acct_group when 'EXP' then a.hsl else -a.hsl end ) as NetImpact,
      count( * )                                 as DocLines,
      _Account
}
group by a.rbukrs, a.gjahr, a.poper, a.racct, m.kind, a.rhcur

④ 쿼리 — 소비 뷰

쿼리는 행 · 열 · 측정값 기본 배치를 정하는 얇은 층입니다. 계획 대비는 같은 큐브의 계획 버전을 같은 축으로 읽습니다.

" ───────────────────────────────────────────────
" ZC_LiquidityQuery  분석 쿼리
" 역할 : 화면이 읽는 소비 뷰(기본 행 · 열 · 측정값)
" 이유 : 화면 변경이 큐브에 번지지 않도록 얇게
" ───────────────────────────────────────────────
@Analytics.query: true
@EndUserText.label: '자금 분석'
define view entity ZC_LiquidityQuery
  as select from ZI_LiquidityCube
{
  @AnalyticsDetails.query.axis: #ROWS
  Kind,
  @AnalyticsDetails.query.axis: #COLUMNS
  Period,
  @DefaultAggregation: #SUM
  AdjAmt,
  @DefaultAggregation: #SUM
  NetImpact,
  @DefaultAggregation: #SUM
  DocLines
}

⑤ 권한 — 접근 제어

권한은 드릴스루에만 걸면 합계 뺄셈으로 새어 나가므로 집계 단계의 회사 단위에서 겁니다.

" ───────────────────────────────────────────────
" ZC_LiquidityQuery  접근 제어(DCL)
" 역할 : 회사 단위 조회 권한
" 이유 : 집계 합계로 남의 숫자가 드러나지 않게
" ───────────────────────────────────────────────
@EndUserText.label: '자금 분석 권한'
@MappingRole: true
define role ZC_LiquidityQuery {
  grant select on ZC_LiquidityQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑥ 서비스 — OData 노출

서비스 정의로 쿼리를 노출하면 화면은 같은 엔티티 이름으로 읽습니다. 쓰기가 있는 처리 기능은 RAP 액션이나 표준 BAPI 로 이어 붙이는 자리입니다(확인 필요).

" ───────────────────────────────────────────────
" ZUI_LiquidityHub  서비스 정의
" 역할 : 쿼리와 처리 기능을 OData 로 노출
" 이유 : 화면과 서버 사이의 계약을 한 곳에 둠
" ───────────────────────────────────────────────
@EndUserText.label: '단기 자금 운영 서비스'
define service ZUI_LiquidityHub {
  expose ZC_LiquidityQuery as LiquidityQuery;
  expose ZI_LiqAccount     as Account;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

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

샘플 데이터를 전수로 돌린 대사식 결과입니다(가상 값). 차이 건수는 모두 0건이며, 의도적으로 넣은 대사 예외 24건은 차이 건수와 분리해 기록했습니다.

운영 데이터로 갈 때

운영 데이터로 갈 때는 전표 라인이 수천만 건이 되므로 집계를 화면이 아니라 큐브 뷰에서 끝내고, 조회조건(회사 · 기간)을 필수 파라미터로 받아야 합니다. 큐브 키 조합에 맞는 인덱스(보조 인덱스)와 분석 쿼리 캐시 정책을 정하고, 샘플에서 브라우저가 하던 축 재집계도 범위가 커지면 서버 쪽 집계로 옮기는 것이 안전합니다. 응답 시간 기준은 회사가 정해야 하는 값이며 이 글은 숫자를 단정하지 않습니다(확인 필요).

자주 묻는 질문

적용 범위와 숫자, 화면 조작, 분석과 AI, 도입과 운영 순서로 묶었습니다.

숫자와 산식

화면과 조작

분석과 AI

도입과 운영