수출 네고 매입 정산 점검 — 환가료와 수수료를 다시 계산해 은행 통지서·장부와 맞춰 보는 수출 화면

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

수출 대금을 은행에 네고하면 은행은 매입 금액에서 환가료와 수수료를 떼고 나머지를 입금합니다. 재무 담당이 월마감마다 받는 질문은 같습니다. 은행이 뗀 환가료와 수수료가 약정대로인가, 개설은행에서 대금은 예정일에 제대로 들어왔는가, 하자가 풀리지 않은 채 남은 건은 없는가. 지금 이 세 답은 은행 통지서 · 입금 전표 · 네고 서류를 엑셀 한 장에 붙여 놓고 눈으로 맞추는 일에 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여, 건마다 계산기를 두드리는 일과 “어느 건이 아직 안 들어왔나” 하는 확인을 줄입니다.

핵심 포인트 여섯 가지

이런 회사에 맞습니다

외화로 수출하고 은행에 네고(매입)로 대금을 앞당겨 받는 제조 · 무역 기업의 재무 · 외환 담당 조직입니다. 네고 건과 입금 전표가 SAP 에 쌓여 있고, 은행 통지서의 환가료 · 수수료를 어떤 형태로든 데이터로 얻을 수 있는 환경이면 같은 구조로 붙습니다. 반대로 네고 없이 송금으로만 대금을 받는 회사에는 맞지 않습니다.

이 앱이 하지 않는 일

은행에 이의를 제기하거나 상환청구를 하지 않습니다. 약정 조건은 회사와 은행이 원문으로 확인해야 하고, 화면의 환가료율 4.8 ~ 5.4% · 수수료율 0.10% · 유예 5일 · 하자 14일 · 허용 차이 1,000원 · 월 점검 비율 30%는 모두 샘플 가정값입니다. 이 앱은 “어디부터 들여다봐야 하는가”를 가려 주는 점검 도구입니다.

실행 화면

실제 브라우저에서 검증용 샘플 데이터로 띄운 화면 8종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 거래처 · 은행 · 네고 번호는 모두 가상입니다.

화면의 구성

맨 위에 조회조건, 그 아래에 요약 숫자 일곱 개, 그 아래에 탭 여섯 개가 세로로 쌓입니다. 탭의 숫자는 그 조건으로 조회된 행 수입니다. 오른쪽 위 버튼은 지금 보고 있는 탭을 CSV 로 내려받습니다.

필수 조건은 회계연도 하나뿐입니다. 요약 숫자는 네고 36건, 판정 대상 34건, 점검 필요 17건, 매입 금액 8,744.1백만원, 미결제 매입 잔액 1,552.4백만원, 환가료·수수료 재계산 35.4백만원, 대사 차이 0건입니다. 판정에서 빠진 2건은 환매 처리가 끝난 건이라 처음부터 세지 않습니다. 금액은 모두 백만원 단위입니다.

조회조건은 전부 OData $filter 로 서비스에 전달됩니다. 전체를 고르면 조건을 빼는 것이지 특정 코드를 넘기는 것이 아닙니다. 판정 유형이나 은행 · 통화 · 네고일 기간을 함께 걸면 어느 은행의 어느 달 건이 몰렸는지 바로 좁혀집니다.

하자와 입금 — 점검의 본체

하자가 있는 채로 매입한 건은 조건부 매입이라, 개설은행이 승인하지 않으면 상환청구로 돌아올 수 있습니다. 샘플에서는 하자 9건 중 미해소 3건이고, 네고일부터 14일(가정)을 넘긴 2건을 점검 필요로 올립니다.

정산 통지가 도착한 29건이 여기 오고, 입금이 예정일보다 5일(가정)을 넘게 늦었거나 부족한 건은 점검 필요입니다. 통화가 다르면 외화 금액을 그대로 더하지 않고 건 단위로만 보여 줍니다.

은행·통화별 · 월별 · 대사

외화 금액은 통화별로만 더하고 원화 합계는 가정 환율로 환산한 매입 금액 기준입니다. 점검 필요 비율이 30% 이상인 쌍은 따로 표시해 어느 은행의 어느 통화부터 볼지 정하게 합니다.

월마감 때 가장 먼저 보는 탭입니다. 월별 합계와 은행·통화별 합계가 어긋나면 대사 결과 탭에 차이로 올라오고, 점검 필요 비율이 높은 달은 그 달의 네고 건부터 확인합니다.

매입 − 환가료 − 수수료 − 하자 수수료 = 순입금, 건별 합계 = 은행·통화별 합계 = 월별 합계, 네고 = 입금 + 공제 + 부족 같은 등식입니다. 샘플에서는 6가지 모두 차이 0이고, 환매 처리 2건은 차이와 섞이지 않게 의도적 예외로 따로 셉니다.

행 상세

숫자를 의심할 때 화면을 옮기지 않고 같은 자리에서 근거를 봅니다. 은행·통화별이나 월 행을 누르면 그 묶음에 속한 네고 건이 아래 표로 열립니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 조회를 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다 — 증빙 확인과 감사 대응은 표준 거래가 맡는 편이 안전합니다.

데이터가 어디서 오는가

수출 쪽은 청구 문서(VBRK · VBRP)와 판매오더(VBAK · VBAP), 회계 쪽은 전표(BKPF · BSEG)와 고객 미결 · 청산 항목(BSID · BSAD), 거래처는 KNA1 에서 옵니다. 다만 은행 통지서의 환가료 · 수수료 · 공제 금액은 표준 테이블에 정해진 자리가 없어서, 이 사례에서는 샘플 가정값을 쓰고 운영에서는 회사의 통지 데이터로 바꿔 끼웁니다. 어느 테이블에서 가져올지는 도입에서 가장 먼저 정해야 하는 항목입니다.

산출 순서

CDS 구성

이 사례의 화면은 서비스가 내려 준 엔티티셋 여섯 개를 그대로 바인딩합니다. 운영에서는 그 서비스 뒤를 CDS 뷰와 재계산 로직으로 채웁니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 은행 통지 데이터는 원천이 확인되지 않아 뷰에 넣지 않고 입력 계약으로만 두었습니다.

뷰 레이어 구성

① 네고 기본 뷰

네고 한 건의 기준이 되는 외화 금액과 통화를 한 곳에서 정합니다. 네고 대상 청구를 어떻게 식별할지(결제 조건 · 지급 방법 · 사용자 정의 표시)는 회사가 정할 일이라 도입에서 합의해야 합니다.

@EndUserText.label: '네고 기본'
@AbapCatalog.viewEnhancementCategory: [#NONE]
define view entity ZI_NegoBase
  as select from vbrk
    inner join vbrp on vbrp.vbeln = vbrk.vbeln
{
  key vbrk.vbeln      as InvNo,            "상업송장(청구) 번호
      vbrk.kunag      as CustId,
      vbrk.fkdat      as BlDate,           "선적일 기준일 — 회사 기준 확인 필요
      vbrk.zterm      as PayTerm,
      vbrk.waerk      as Curr,
      @Semantics.amount.currencyCode: 'Curr'
      vbrp.netwr      as FcAmt
}

② 약정 조건 뷰

환가료율과 수수료율은 은행과 약정으로 정해지므로 코드에 넣지 않고 조건 테이블에서 읽습니다. 샘플의 4.8 ~ 5.4% · 0.10% · 최소 10,000원은 가정값입니다.

@EndUserText.label: '네고 약정 조건'
define view entity ZI_NegoTerms
  as select from znegoterms     "사용자 정의 약정 테이블 — 이름은 확인 필요
{
  key bank_code     as BankCode,
  key valid_from    as ValidFrom,
      int_rate      as IntRate,          "환가료율(연 %)
      fee_rate      as FeeRate,          "수수료율(%)
      fee_min       as FeeMin,           "최소 수수료
      grace_days    as GraceDays         "만기 후 유예 일수
}

③ 은행 통지 입력 뷰

은행 통지서의 값은 표준 테이블에 자리가 없습니다. 스캔 · 전자 수신 결과를 담는 테이블이나 외부 시스템 연계 결과를 이 뷰가 한 줄로 받게 하면, 위 뷰들은 원천이 바뀌어도 그대로 둘 수 있습니다.

@EndUserText.label: '은행 통지 입력'
define view entity ZI_NegoBankNotice
  as select from znegonotice    "사용자 정의 통지 테이블 — 원천 확인 필요
{
  key inv_no        as InvNo,
      int_bank      as IntBank,          "환가료(은행 통지)
      fee_bank      as FeeBank,          "수수료(은행 통지)
      recv_fc       as RecvFc,           "개설은행 입금(외화)
      deduct_fc     as DeductFc,         "개설은행 공제(외화)
      settle_date   as SettleDate
}

④ 재계산과 판정 뷰

환가료와 수수료를 다시 계산하고 은행 통지 · 장부와 비교해 판정 코드를 붙입니다. 우선순위(제외 → 만기 경과 → 미해소 하자 → 입금 부족 → 장부 차이 → 환가료 차이 → 수수료 차이)를 이 뷰의 CASE 순서로 못 박아, 화면은 판정 결과만 읽습니다.

@EndUserText.label: '네고 재계산·판정(스케치)'
define view entity ZC_NegoCheck
  as select from ZI_NegoBase       as n
    inner join   ZI_NegoTerms      as t on t.BankCode = n.BankCode
    left outer join ZI_NegoBankNotice as b on b.InvNo = n.InvNo
{
  key n.InvNo,
      n.Curr,
      /* 환가료 재계산 = 매입 금액 × 환가료율 ÷ 100 × 일수 ÷ 365 */
      cast( n.NegoKrw * t.IntRate / 100 * n.IntDays / 365 as abap.dec(17,0) ) as IntCalc,
      /* 수수료 재계산 = max(최소 수수료, 매입 금액 × 수수료율) */
      cast( case when n.NegoKrw * t.FeeRate / 100 > t.FeeMin
                 then n.NegoKrw * t.FeeRate / 100 else t.FeeMin end
            as abap.dec(17,0) )                                                as FeeCalc,
      b.IntBank,
      b.FeeBank,
      case
        when n.ExcFlag = 'X'                                  then 'EXC'
        when n.Overdue > t.GraceDays and b.SettleDate is null then 'OVERDUE'
        when n.DiscOpen > 0 and n.OpenDays > 14               then 'OPENDISC'
        else 'OK'
      end                                                                      as CheckCode
}

⑤ 하자 뷰

하자는 네고 한 건에 여러 줄이 달릴 수 있어 별도 뷰로 둡니다. 해소 여부와 해소일을 어디서 가져올지(서류 관리 시스템인지 사용자 정의 테이블인지)는 도입에서 정해야 합니다.

@EndUserText.label: '네고 하자 내역(스케치)'
define view entity ZC_NegoDisc
  as select from znegodisc      "사용자 정의 하자 테이블 — 원천 확인 필요
{
  key inv_no       as InvNo,
  key disc_no      as DiscNo,
      disc_code    as DiscCode,
      resolved     as Resolved,
      resolve_date as ResolveDate,
      /* 해소되지 않았으면 기준일까지, 해소됐으면 해소일까지의 경과 일수 */
      case when resolved = 'Y'
           then dats_days_between( nego_date, resolve_date )
           else dats_days_between( nego_date, $session.system_date ) end as OpenDays
}

⑥ 은행·통화별 집계 뷰

외화 금액은 통화가 다르면 더하지 않으므로 은행과 통화를 묶음의 키로 둡니다. 월별 집계도 같은 방식으로 만들고, 두 집계의 매입 금액 합이 같은지를 대사식으로 검사합니다.

@EndUserText.label: '은행·통화별 합계(스케치)'
define view entity ZC_NegoBankCurr
  as select from ZC_NegoCheck
{
  key BankCode,
  key Curr,
      count( * )                         as NegoCnt,
      @Semantics.amount.currencyCode: 'Curr'
      sum( FcAmt )                       as FcAmt,
      sum( NegoKrw )                     as NegoKrw,
      sum( IntCalc )                     as IntCalc,
      sum( IntBank )                     as IntBank,
      sum( IntBank ) - sum( IntCalc )    as DiffInt
}
group by BankCode, Curr

⑦ 접근 제어

집계 단계에서 권한을 걸어야 합계와 전체의 차이로 남의 숫자가 드러나지 않습니다. 권한 객체와 필드 이름은 회사의 권한 설계에 따라 달라지므로 아래는 모양만 보인 스케치입니다.

@EndUserText.label: '네고 점검 접근 제어(스케치)'
@MappingRole: true
define role ZC_NEGOCHECK_DCL {
  grant select on ZC_NegoCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 전환에서 정해야 할 항목

OData 서비스 계약

화면은 서비스 이름 nego_srv 하나만 부르고, 경로는 모두 상대 경로입니다. 엔티티셋은 여섯 개입니다 — NegoSet(네고 명세) · DiscSet(하자 내역) · SettleSet(입금 정산) · BankSet(은행·통화별) · MonSet(네고월별) · ReconSet(대사). 펑션 두 개 GetTotalNetCalc(재계산 순입금 합계)와 GetMaxOverdueDays(최대 만기 경과 일수)는 선택 파라미터 NegoYm 을 받습니다. 조회조건은 전부 $filter 로 가고 “전체”는 조건을 빼는 방식이며, 총건수는 $inlinecount=allpages 로 받습니다. 같은 계약을 지키는 운영 서비스로 경로만 바꾸면 화면을 고치지 않고 연결됩니다.

자주 묻는 질문

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

계산과 규칙

데이터와 검증

화면 사용

도입과 운영