수출 추심 만기·회수 점검 — 만기일을 다시 계산하고 미회수 잔액을 한 화면에서 대사하는 수출 대금 점검

개발 배경 — 이 앱을 사용해야 하는 이유

수출 대금 담당자가 월말마다 받는 질문은 비슷합니다. 이번 달 만기인 추심 건이 몇 건인가, 만기를 넘겼는데 아직 들어오지 않은 돈은 얼마인가, 그 잔액은 외화로 얼마이고 원화로는 얼마인가. 지금은 이 답이 판매·청구 화면, 고객 계정 명세, 은행과 주고받은 추심 서류 사본, 그리고 담당자가 손으로 관리하는 엑셀에 흩어져 있습니다. 추심 조건이 인수인도(D/A)인지 지급인도(D/P)인지에 따라 만기일을 세는 기준일도 다르기 때문에, 엑셀 한 장에서 조건마다 다른 계산식을 유지하는 일이 쉽지 않습니다.

이 앱은 그 자리를 메웁니다. 추심 조건과 기한으로 만기일을 다시 계산하고, 기준일 현재 만기 전·만기 임박·경과 구간으로 나누어 회수 내역과 견줍니다. 결과는 점검 필요 건, 지연 회수 건, 서류를 넘겼는데 회수 내역이 없는 건으로 가려 보여 주고, 통화별 외화 금액과 외환차손익은 명세와 요약이 서로 맞는지 대사해 줍니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다.

핵심 포인트 여섯 가지

만기일을 서류가 아니라 조건에서 다시 구해야 하는 이유

추심 건의 만기일은 서류에 한 번 적히면 끝나는 값처럼 보이지만 실제로는 조건에서 파생되는 값입니다. 지급인도 건은 서류를 은행에 넘긴 날이 기준이고, 인수인도 건은 구매자가 인수한 날 또는 선적일이 기준입니다. 인수일이 들어오지 않은 인수인도 건은 만기일을 계산할 수 없습니다. 이 앱은 그런 건을 억지로 계산하지 않고 보류로 두어 판정에서 빼며, 의도적으로 넣은 보류 건은 대사 결과 탭에서 따로 집계합니다. 숫자를 채우기 위해 날짜를 추정하지 않는다는 원칙입니다.

허용 일수도 같은 이유로 정책표에 둡니다. 샘플에서는 5일로 가정했지만 실제 값은 회사의 회수 관리 기준과 은행 영업일 관행에 따라 달라지므로, 화면은 값을 바꿔 다시 조회하는 쪽을 전제로 만들었습니다. 점검 필요는 “회수가 안 된다”는 결론이 아니라 “일정을 확인할 대상”이라는 표시입니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리 숫자)를 확인합니다. 거래처·통화·추심 조건·회수 상태·만기일 범위·판정은 선택이며 비워 두면 전체입니다.
2. 조회 — 조회조건 줄 맨 오른쪽의 조회 버튼을 누르거나 회계연도·날짜 칸에서 Enter 를 누릅니다. 화면을 열면 한 번 자동으로 조회합니다.
3. 요약 확인 — 추심 건수, 판정 대상, 점검 필요, 미회수 잔액, 만기 경과 잔액, 대사 차이 건수를 위쪽 숫자 카드로 봅니다.
4. 탭 이동 — 추심 명세 → 만기 구간별 → 통화별 → 추심 조건별 → 거래처별 → 대사 결과 순서로 범위를 좁혀 갑니다.
5. 행 클릭 — 행을 누르면 상세 창이 열려 만기일 계산에 쓴 기준일과 회수 환율, 판정 내용을 보여 줍니다. 요약 행은 해당 조건의 추심 건 목록까지 함께 보여 줍니다.
6. 내려받기 — 오른쪽 위 CSV 내려받기로 현재 탭의 결과를 UTF-8 파일로 받습니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌렸습니다. 샘플 추심 60건 전부를 대상으로 했고, 차이는 모든 항목에서 0건입니다.

의도적 예외는 대사 차이와 분리해 두었습니다. 인수일이 없어 만기일을 계산할 수 없는 보류 3건과, 서류 인도일은 있으나 회수 내역이 없는 지급인도 2건입니다. 두 경우 모두 화면에서 점검 사례로 보이도록 일부러 넣은 건이며, 대사 결과 탭에 따로 표시됩니다.

무엇으로 만들었나

실행 화면

아래 화면은 모두 검증용 샘플 데이터(가상 해외 거래처 8곳, 추심 60건, 통화 4종, 기준일 2026-09-30)로 실제 브라우저에서 띄워 찍은 것입니다. 환율과 기한은 가정값이며 실제 고시값이 아닙니다.

처음 열었을 때

숫자 카드는 추심 60건, 판정 대상 57건, 점검 필요 14건, 미회수 잔액 8,045.4백만원, 만기 경과 잔액 2,825.9백만원, 대사 차이 0건을 보여 줍니다. 판정 대상이 57건인 것은 만기일을 계산할 수 없는 보류 3건이 빠졌기 때문입니다. 조회 버튼은 조회조건 줄 맨 오른쪽에 있습니다.

조건으로 좁히기와 구간별 보기

네 건이 남고 미회수 잔액은 1,206.9백만원입니다. 숫자 카드도 같은 조건으로 다시 계산되므로 표와 카드가 어긋나지 않습니다. 만기일 시작·종료를 넣으면 만기가 몰린 달만 따로 볼 수 있고, 초기화 버튼은 조회 버튼 옆에 있습니다.

경과 구간에 점검 필요 건이 몰려 있는지 봅니다. 인수일이 없어 만기를 계산할 수 없는 건은 마지막 보류 구간으로 따로 모입니다. 행을 누르면 그 구간의 추심 건 목록이 상세 창에 열립니다.

거래처와 통화로 보기

점검 필요 비율이 40.00% 이상인 거래처는 판정 열에 점검 필요가 표시됩니다. 회수 일정을 먼저 확인할 거래처를 고를 때 씁니다. 평균 회수 지연 일수는 회수 내역이 있는 건만으로 계산합니다.

서로 다른 통화의 외화 금액은 더하지 않고 통화 행마다 따로 둡니다. 합계가 필요한 곳은 원화 환산 금액으로만 냅니다. 외환차손익은 회수 원화에서 회수분 인식 원화를 뺀 값이며 환율은 샘플 가정값입니다.

상세와 대사

판정 문구는 “확인 필요”처럼 점검 방향만 적고 원인을 단정하지 않습니다. 같은 창에서 요약 행은 해당 조건의 추심 건 목록을 함께 보여 줍니다. 닫기 버튼 또는 배경을 눌러 닫습니다.

통화별 외화, 인식 원화, 외환차손익, 구간·조건·거래처·통화별 합계가 모두 차이 0건입니다. 마지막 두 줄은 보류 3건과 서류 인도 후 미회수 2건이며, 대사 차이와 분리해 표시됩니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 조회조건을 표준 필터 객체로 바꾸어 서비스에 보냅니다. 서비스는 추심 건마다 만기일을 정책표로 다시 계산하고, 기준일과 견주어 만기 경과 일수와 회수 지연 일수, 구간, 판정을 붙인 뒤 여섯 묶음의 결과를 각각 돌려줍니다. “전체”를 고르면 해당 조건은 필터에서 빠집니다.

산출·대사식은 순서대로 이렇습니다. 만기일 = 기준일(의뢰일·선적일·인수일) + 기한, 미회수 외화 = 추심 외화 − 회수 외화, 인식 원화 = 추심 외화 × 가정 환율 = 회수분 인식 원화 + 미회수 원화, 외환차손익 = 회수 원화 − 회수분 인식 원화, 만기 경과(일) = 기준일 − 만기일, 회수 지연(일) = 최종 회수일 − 만기일입니다.

조회조건

결과 컬럼 — 추심 명세

파일 구성

index.html · Component.js · manifest.json
controller/  view/  model/  css/  i18n/
odata/ (서비스 정의 · 서비스 로직 · 결과집합 데이터)
media/ (소개 영상 · 첫 화면 이미지)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 아래는 표준 화면으로 충분한 일과 이 앱이 더하는 관점을 나란히 둔 것입니다.

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

T-code 별 연계 지점

표준에 남겨 둘 일도 분명합니다. 회계 전표의 전기와 취소, 채권 반제, 법정·감사·세무 신고 대응은 모두 표준 거래에서 합니다. 이 앱은 조회와 점검만 하므로 기존 리포트를 없앨 필요가 없고, 오히려 기존 리포트와 숫자를 맞춰 보는 용도로 함께 두는 것이 안전합니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱으로 미결 채권의 연령 분석을 이미 쓰고 있다면, 이 앱은 그것과 경쟁하지 않고 추심 조건이라는 한 가지 관점을 더합니다. 연령 분석은 청구일이나 전기일을 기준으로 구간을 나누는 경우가 많은데, 추심 건은 조건에 따라 기준일이 달라지기 때문입니다. 어떤 표준 앱이 같은 기능을 제공하는지는 고객사 릴리스에 따라 다르므로, 이 글에서는 앱 이름을 단정하지 않고 확인 필요로 둡니다.

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

분석 지표 정의표

CDS 구성

화면이 읽는 여섯 묶음의 결과는 운영 환경에서 CDS 뷰 계층으로 만듭니다. 아래 코드는 이 화면의 구조를 설명하기 위해 새로 스케치한 것이며, 청구·전표·고객 마스터의 표준 테이블 필드를 기준으로 합니다. 추심 건번호·인수일·서류 인도일처럼 표준 필드를 확인하지 못한 값은 확인 필요로 주석에 남겼습니다.

뷰 레이어 구성

① 정책 매핑 테이블 — 조건별 기한

만기일 계산의 모든 입력은 이 테이블에서 옵니다. 추심 조건 코드마다 기준일 종류와 기한, 지급인도 대기일을 한 행에 둡니다. 운영에서는 이 테이블 값이 곧 회사의 만기 정책이므로, 정책 변경 이력을 남기려면 유효 시작일 키를 추가합니다.

@EndUserText.label : '추심 조건별 만기 정책'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zcoll_policy {
  key client    : abap.clnt not null;
  key cond      : abap.char(2) not null;   " DA 인수인도 / DP 지급인도
  key tenor_key : abap.char(3) not null;   " 기한 구분
  tenor_days    : abap.int4;               " 30 · 60 · 90 · 120
  base_kind     : abap.char(5);            " BL 선적일 / ACC 인수일 / SUB 의뢰일
  wait_days     : abap.int4;               " 지급인도 대기일 (샘플 15)
  grace_days    : abap.int4;               " 허용 일수 (샘플 5)
  soon_days     : abap.int4;               " 만기 임박 기준 (샘플 7)
}

② 청구·수금 기준 뷰

청구문서에서 통화·환율·금액을 읽고, 고객 계정의 미결·반제 항목에서 회수일과 회수 금액을 읽습니다. 추심 건번호와 인수일, 서류 인도일은 표준 필드를 확인하지 못해 자리만 표시했습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '추심 건 기준 — 청구'
define view entity ZI_CollectionBase
  as select from vbrk as bh
    inner join   vbrp as bp on bp.vbeln = bh.vbeln
    left outer join kna1 as kn on kn.kunnr = bh.kunag
{
  key bh.vbeln             as CollId,
      bh.kunag             as CustId,
      kn.name1             as CustName,
      kn.land1             as Country,
      bh.fkdat             as BillDate,        -- 청구일
      bh.waerk             as Curr,
      bh.kurrf             as Rate,
      @Semantics.amount.currencyCode: 'Curr'
      bp.netwr             as FcAmt
      -- 추심 의뢰일·인수일·서류 인도일: 표준 필드 확인 필요
}

③ 만기일 재계산 뷰 — 판정 규칙을 한 곳에

이 뷰가 이 앱의 핵심입니다. 정책 테이블을 조인해 만기일을 구하고, 기준일과 견주어 경과·지연 일수, 구간, 판정 코드를 만듭니다. 인수일이 없는 인수인도 건은 만기일을 null 로 두어 보류로 분류합니다. 날짜를 추정해 채우지 않습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '추심 만기일 재계산'
define view entity ZI_CollectionDue
  with parameters p_asof : abap.dats
  as select from ZI_CollectionBase as c
    inner join   zcoll_policy      as p on p.cond = c.Cond
{
  key c.CollId,
      c.CustId, c.Curr, c.FcAmt, c.Rate,
      case p.base_kind
        when 'SUB' then dats_add_days( c.SubmitDate, p.wait_days, 'NULL' )
        when 'ACC' then dats_add_days( c.AccDate,    p.tenor_days, 'NULL' )
        else            dats_add_days( c.BlDate,     p.tenor_days, 'NULL' )
      end                                              as DueDate,
      dats_days_between( dueDate, $parameters.p_asof ) as OverDays,
      case
        when dueDate is null                          then 'HLD'
        when c.OpenFc > 0 and OverDays > p.grace_days then 'OVD'
        when c.OpenFc > 0 and OverDays > 0            then 'GRC'
        else 'OK'
      end                                              as CheckCode
}

④ 구간·통화 집계 큐브 — 통화를 섞지 않는다

큐브는 통화를 그룹 키에 넣어 외화를 더하지 않습니다. 원화 합계가 필요한 자리는 건별 원 단위 반올림 값을 더해 명세 합계와 같아지게 합니다. 구간 코드는 만기 경과 일수에서 정합니다.

@Analytics.dataCategory: #CUBE
@EndUserText.label: '추심 구간·통화 집계'
define view entity ZI_CollectionAgingCube
  with parameters p_asof : abap.dats
  as select from ZI_CollectionDue( p_asof: $parameters.p_asof )
{
  key Curr,
  key case
        when DueDate is null   then 'H'
        when OverDays <= -8    then 'B1'
        when OverDays <=  0    then 'B2'
        when OverDays <= 30    then 'B3'
        when OverDays <= 60    then 'B4'
        when OverDays <= 90    then 'B5'
        else 'B6'
      end                       as Bucket,
      @Aggregation.default: #SUM
      OpenFc                    as OpenFc,
      @Aggregation.default: #SUM
      cast( round( OpenFc * Rate, 0 ) as abap.dec(17,0) ) as OpenKrw,
      @Aggregation.default: #SUM
      case when CheckCode = 'OVD' then 1 else 0 end       as NeedCnt
}

⑤ 점검 쿼리 — 화면과 같은 입력

쿼리는 조회조건과 같은 이름의 파라미터와 필터를 받습니다. 화면의 조회조건이 그대로 이 쿼리의 입력이 되므로, 외부 소비자가 같은 쿼리를 불러도 화면과 같은 숫자를 받습니다.

@Analytics.query: true
@EndUserText.label: '추심 점검 쿼리'
define view entity ZC_CollectionCheckQuery
  with parameters
    @Consumption.defaultValue: '20260930'
    p_asof : abap.dats
  as select from ZI_CollectionAgingCube( p_asof: $parameters.p_asof )
{
  @AnalyticsDetails.query.axis: #ROWS
  Bucket,
  @AnalyticsDetails.query.axis: #COLUMNS
  Curr,
  OpenFc,
  OpenKrw,
  NeedCnt
}

⑥ 접근 제어 — 집계 단계에 건다

권한은 상세 행에만 걸면 합계로 새어 나갑니다. 큐브 단계의 회사코드와 영업조직에 걸어 합계도 조회 권한 범위 안에서만 계산되게 합니다.

@EndUserText.label: '추심 점검 접근 제어'
@MappingRole: true
define role ZI_CollectionAgingCube {
  grant select on ZI_CollectionAgingCube
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 — 결과집합을 묶음별로

여섯 묶음은 각자 엔티티셋으로 노출합니다. 소계처럼 성격이 다른 행이 한 응답에 섞이지 않게, 묶음마다 별도 결과집합과 키를 둡니다.

@EndUserText.label: '추심 점검 서비스'
define service ZUI_CollectionCheck {
  expose ZC_CollectionCheckQuery as CollSet;
  expose ZC_CollectionCheckQuery as AgingSet;
  expose ZC_CollectionCheckQuery as CurrSet;
  expose ZC_CollectionCheckQuery as CondSet;
  expose ZC_CollectionCheckQuery as CustSet;
  expose ZC_CollectionCheckQuery as ReconSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여섯 가지는 코딩이 아니라 합의이고, 합의가 끝나면 기술 작업은 위 뷰를 만들고 화면을 올리는 일입니다.

운영 데이터로 갈 때

추심 건이 수만 건이 되어도 집계는 큐브 단계에서 하므로 화면이 받는 행 수는 구간·통화·거래처 수준으로 작게 유지됩니다. 명세 탭만 건수가 커지므로 기준일과 만기일 범위를 필수에 가깝게 쓰고, 한 번에 가져오는 행 수에 상한을 두는 것을 권합니다. 청구와 미결 항목이 수천만 건인 환경이라면 기준 뷰의 조인 키와 인덱스를 먼저 점검하고, 응답 시간 기준은 도입 전에 합의해 두는 편이 안전합니다. 구체적인 수치는 고객사 환경에서 측정해야 하므로 이 글에서는 확인 필요로 둡니다.

자주 묻는 질문

도입 전에 가장 많이 확인하는 질문을 숫자와 산식, 화면과 조작, 도입과 운영 세 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

도입과 운영