반제전기 — 미결 항목을 좌우로 갈라 놓고 짝은 규칙과 AI 가 먼저 찾는다, 퍼블릭의 비동기 전기까지 한 화면에서

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

핵심 포인트

사례로 보는 효과

월말에 고객 입금 40건을 미결 청구 120건에 맞춰 터는 일을 생각해 보겠습니다. 한 표에 섞여 있으면 차대 칸을 눈으로 가려 가며 찾고, 금액이 맞는지는 계산기로 더해 봅니다. 두 쪽으로 갈라 두면 왼쪽 합계와 오른쪽 합계가 머리에 떠 있어 얼마를 더 골라야 맞는지 바로 보입니다. 차액이 남으면 전기 전에 빨갛게 서므로, 전기해 보고 되돌리는 일이 줄어듭니다.

전기 뒤에도 달라집니다. 퍼블릭에서는 전기 요청이 큐로 들어가 전표번호가 바로 나오지 않습니다. 모니터가 없으면 「보내긴 했는데 됐나?」 를 확인하려고 전표 조회를 반복하게 됩니다. 요청번호와 상태를 화면 안에 두면 그 반복이 사라집니다.

도입하면 달라지는 것

• 맞추는 과정이 눈에 보입니다 — 두 쪽 합계와 차액이 선택할 때마다 다시 계산됩니다.
• 전기 전에 막습니다 — 잔액 불일치 · 통화 혼재 · 이미 반제된 항목을 제안 단계에서 걸러 냅니다.
• 전표를 먼저 봅니다 — 전기키와 계정까지 붙은 라인을 확인하고 전기합니다.
• 결과를 기다리지 않아도 됩니다 — 요청번호로 되묻고, 끝나면 목록에서 반제된 항목이 빠집니다.
• 같은 조건을 다시 채우지 않습니다 — 조회조건과 전표헤더를 한 세트로 저장합니다.
• 되돌리는 길이 같은 화면에 있습니다 — 요청 취소와 반제 취소를 나눠 두었습니다.

이런 회사에 맞습니다

• S/4HANA Cloud Public Edition 을 쓰면서 반제 전기를 Fiori 표준 앱 밖에서 다루고 싶은 회사
• 고객 입금이나 공급업체 지급 건수가 많아 한 표에서 맞추기 어려운 회사
• 현금할인 · 단수차이 · 환율차이 때문에 차액 처리가 잦은 회사
• 부분반제를 자주 쓰는 회사 — 잔액 항목이 어떻게 생기는지 화면에서 확인할 수 있습니다
• 회사코드가 여러 개이고 담당자마다 보는 조건이 정해져 있는 회사

실행 화면 — 두 쪽으로 갈라 맞추고 전기까지

아래 화면은 모두 앱을 실제로 띄워 찍은 것입니다. 그림을 누르면 크게 볼 수 있습니다.

한 화면, 두 쪽으로 갈라 보기

한 표에 섞어 두면 무엇과 무엇을 맞춰야 하는지 눈으로 좇기 어렵습니다. 계정유형을 공급업체로 바꾸면 왼쪽이 채무(미결 송장·대변), 오른쪽이 지급(차변)으로 좌우가 뒤집힙니다. 총계정원장이나 전체를 고르면 차변·대변으로 둡니다.

양쪽에서 골라 맞추기

고르는 즉시 두 쪽 합계와 차액이 다시 계산됩니다. 잔액이 맞지 않는 상태로는 전기가 막히고, 차액계정을 지정하거나 부분반제를 켜야 넘어갑니다. 전기 전에 눈으로 확인하는 자리입니다.

자동 매핑 — 규칙이 먼저 짝을 찾습니다

화면이 보고 있는 그 조회 결과로 짝을 찾습니다. 위에서 잡힌 항목은 아래 규칙이 다시 쓰지 않고, 한 항목은 한 묶음에만 들어갑니다. 묶음을 고르면 아래 표에 그 묶음에 든 항목이 좌/우 구분과 함께 펼쳐집니다. 그림의 G003 은 참조 AM1D0003 으로 묶인 청구 세 건(240만 + 310만 + 175만)이 입금 725만과 맞아떨어진 경우입니다.

AI 보강 — 규칙이 남긴 것만 모델이 읽습니다

필드만 보는 규칙으로는 잡히지 않는 항목이 남습니다. AI 보강은 그 나머지만 거래처별로 모아 모델에게 묻습니다. 모델은 어느 것끼리 한 짝인지만 고르고, 금액·합계·차액은 서버가 다시 계산합니다. 모델이 거래처를 넘나드는 짝을 고르면 검증에서 버립니다.

고른 묶음을 양쪽 표 선택으로

차액이 남는 묶음(현금할인·단수차이·부분입금)이면 차액사유나 부분반제를 미리 켜 두어 이어지는 시뮬레이션에서 오류 라인이 서지 않게 합니다. 그다음은 지금까지와 똑같습니다.

시뮬레이션 — 반제 전표 미리보기

전기키는 고객 차변 01 · 대변 15, 공급업체 차변 21 · 대변 25, 총계정원장 차변 40 · 대변 50 으로 세웁니다. 라인 종류를 반제 · 차액 · 잔액 · 오류로 나눠 두어, 오류가 하나라도 있으면 전기 버튼이 막힙니다.

전표헤더 검증

전기일이 열린 기간을 벗어났는지, 증빙일이 전기일보다 뒤인지, 외화인데 환율이 비었는지, 환율이 기준환율과 10% 넘게 벌어졌는지를 봅니다. 오류와 경고를 나눠 돌려주므로 경고는 알고 넘어갈 수 있습니다.

전기 모니터 — 비동기 요청

전기 버튼을 누르면 전표번호가 아니라 요청번호가 돌아옵니다. 접수 → 큐 대기 → 전기 처리중 → 전기 완료까지 상태를 되물어 따라가고, 완료 시점에 반제전표 번호가 채워집니다. 전기가 끝나기 전이라면 요청을 취소할 수 있습니다.

레이아웃 저장

반제 전기는 「무엇을 모을지」 와 「어떤 헤더로 전기할지」 가 늘 짝입니다. 둘을 따로 저장하면 다음에 반쪽만 맞습니다. 기본으로 지정하고 자동 적용을 켜 두면 앱을 열 때 조건과 헤더가 채워진 채 조회까지 끝나 있습니다.

저장된 레이아웃

적용을 누르면 조회조건과 전표헤더가 함께 돌아옵니다. 표의 컬럼 표시 여부도 같이 담깁니다.

반제 취소

그 전표로 반제된 항목이 모두 다시 미결이 되고, 부분반제로 생겼던 잔액 항목은 함께 지워집니다. 전기가 아직 끝나지 않은 요청이라면 모니터에서 요청 취소로 멈추는 편이 깔끔합니다.

자동 매핑과 AI — 짝을 찾는 일을 규칙과 모델에 나눠 맡기는 법

반제 화면에서 사람이 가장 오래 쓰는 시간은 전표를 만드는 시간이 아니라 「이 입금이 어느 청구를 턴 것인가」 를 찾는 시간입니다. 그 찾기는 대개 몇 가지 단서로 끝납니다 — 금액, 할당번호, 참조(송장)번호, 여러 건의 합, 약정 할인, 끝자리 단수. 자동 매핑은 그 단서를 규칙으로 적어 두고, 규칙이 못 고른 나머지만 모델에게 묻습니다.

규칙 일곱 가지

위에서 잡힌 항목은 아래 규칙이 다시 쓰지 않습니다. 큰 금액부터 보고, 한 항목은 한 묶음에만 들어갑니다. 그리고 참조·할당번호라는 단서가 없는 근접 금액은 짝으로 보지 않습니다 — 금액이 비슷하다는 것만으로 묶으면 무작위로 가까운 금액이 잡혀 오탐이 납니다. 단서 없이 인정하는 것은 끝자리 차이뿐이고, 비율로 넓힌 창은 참조가 같을 때만 씁니다.

모델에게 맡기는 것과 맡기지 않는 것

실제로 무엇이 잡혔나

거래처 한 곳(미결 청구 21건 · 입금 13건)에서 규칙이 묶음 8개 19건을 8밀리초 만에 찾았습니다 — 정확일치 2 · 참조합계 1 · 금액일치 1 · 묶음합계 1 · 현금할인 1 · 단수차이 1 · 부분입금 1, 오탐 0건입니다. 남은 15건을 모델에 넘기자 참조 칸은 비어 있고 적요에만 「INV-…-10008 건 1차 분할」 이라고 적힌 입금 한 건을 950만원 청구의 분할 입금으로 집어냈습니다(신뢰도 76%, 18초). 같은 질의에서 모델이 고른 다른 짝 두 개는 거래처가 다르거나 금액이 맞지 않아 서버 검증에서 걸러졌습니다.

자동이라는 말의 경계

자동 매핑은 전기까지 하지 않습니다. 사람이 고른 묶음만 왼쪽·오른쪽 표의 선택으로 옮기고, 차액이 남는 묶음이면 차액사유나 부분반제를 미리 맞춰 둡니다. 그다음은 지금까지와 똑같이 시뮬레이션을 거쳐 전기합니다. 신뢰도와 근거 문장을 묶음마다 붙여 보여 주는 것도 같은 이유입니다 — 기계는 후보를 좁히는 데까지, 고르는 일은 사람이 합니다.

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

CDS 구성 — 운영 데이터로 갈 때의 뷰 레이어와 코드

데모는 JSON 기반 서비스로 동작하지만, 운영에서는 아래 뷰를 만들어 OData 로 노출하면 화면은 그대로 돕니다.

ZI_ClearingOpenItem

미결 항목 조회 뷰 — 화면 왼쪽·오른쪽 두 쪽을 모두 이 뷰 하나로 읽는다

@AbapCatalog.sqlViewName: 'ZICLROPEN'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '반제 대상 미결 항목'
@VDM.viewType: #BASIC
@Analytics.dataCategory: #FACT
define view ZI_ClearingOpenItem
  as select from I_OperationalAcctgDocItem as Item
  inner join   I_AccountingDocumentHeader  as Head
    on  Item.CompanyCode       = Head.CompanyCode
    and Item.AccountingDocument = Head.AccountingDocument
    and Item.FiscalYear        = Head.FiscalYear
{
  key Item.CompanyCode                                    as Bukrs,
  key Item.AccountingDocument                             as Belnr,
  key Item.FiscalYear                                     as Gjahr,
  key Item.AccountingDocumentItem                         as Buzei,

      // 계정유형 — 고객 D · 공급업체 K · 총계정원장 S
      case when Item.Customer <> '' then 'D'
           when Item.Supplier <> '' then 'K'
           else 'S' end                                   as Koart,
      case when Item.Customer <> '' then Item.Customer
           when Item.Supplier <> '' then Item.Supplier
           else Item.GLAccount end                        as Konto,
      Item.GLAccount                                      as Hkont,
      Head.AccountingDocumentType                         as Blart,
      Head.DocumentDate                                   as Bldat,
      Item.PostingDate                                    as Budat,
      Item.NetDueDate                                     as Netdt,
      Item.BaselineDate                                   as Zfbdt,
      Item.TransactionCurrency                            as Waers,
      Item.AmountInTransactionCurrency                    as Wrbtr,
      Item.AmountInCompanyCodeCurrency                    as Dmbtr,
      Item.DebitCreditCode                                as Shkzg,
      Item.DocumentItemText                               as Sgtxt,
      Item.AssignmentReference                            as Zuonr,
      Head.DocumentReferenceID                            as Xblnr,
      Item.PaymentTerms                                   as Zterm,
      Item.SpecialGLCode                                  as Umskz,
      Item.TaxCode                                        as Mwskz,
      Item.CostCenter                                     as Kostl,
      Item.ProfitCenter                                   as Prctr,
      Item.ClearingAccountingDocument                     as Augbl,
      Item.ClearingDate                                   as Augdt,

      // 미결 O · 반제 C — 화면의 "미결만" 조건이 이 칸을 본다
      case when Item.ClearingDate is initial then 'O' else 'C' end as Status,

      // 연체일 — 만기일이 지난 날 수(미결일 때만 센다)
      case when Item.ClearingDate is initial
                 and Item.NetDueDate < $session.system_date
           then dats_days_between( Item.NetDueDate, $session.system_date )
           else 0 end                                     as OverdueDays
}
where Item.FinancialAccountType <> ''

ZC_ClearingOpenItem

화면이 직접 부르는 소비 뷰 — 조회조건을 파라미터로 받는다

@AbapCatalog.sqlViewName: 'ZCCLROPEN'
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '반제전기 — 미결 항목 조회'
@VDM.viewType: #CONSUMPTION
@OData.publish: true
@UI.headerInfo: { typeName: '미결 항목', typeNamePlural: '미결 항목' }
define view ZC_ClearingOpenItem
  with parameters
    @Environment.systemField: #SYSTEM_DATE
    p_KeyDate   : vdm_v_key_date,
    p_OnlyOpen  : abap_boolean,
    p_Overdue   : abap_boolean
  as select from ZI_ClearingOpenItem
{
  @UI.lineItem: [{ position: 10, label: '회사코드' }]
  key Bukrs,
  @UI.lineItem: [{ position: 20, label: '전표번호' }]
  key Belnr,
  key Gjahr,
  key Buzei,
      @UI.selectionField: [{ position: 10 }]
      Koart,
      @UI.selectionField: [{ position: 20 }]
      Konto,
      Hkont, Blart, Bldat, Budat, Netdt, Zfbdt,
      @UI.selectionField: [{ position: 30 }]
      Waers,
      @Semantics.amount.currencyCode: 'Waers'
      Wrbtr,
      @Semantics.amount.currencyCode: 'Waers'
      Dmbtr,
      Shkzg, Sgtxt, Zuonr, Xblnr, Zterm, Umskz, Mwskz, Kostl, Prctr,
      Augbl, Augdt, Status, OverdueDays
}
where ( :p_OnlyOpen = '' or Status  = 'O' )
  and ( :p_Overdue  = '' or OverdueDays > 0 )
  and Budat <= :p_KeyDate

ZI_ClearingRequest

비동기 전기 요청을 담는 테이블과 뷰 — 퍼블릭에서는 이 자리가 반드시 필요하다

// ── 테이블 ZFI_CLR_REQ ─────────────────────────────────────────────
// request_id  CHAR32   요청번호 (키)
// bukrs       BUKRS    회사코드
// status      CHAR12   ACCEPTED · QUEUED · INPROCESS · POSTED · FAILED · CANCELLED
// soap_msgid  CHAR64   SOAP 메시지 ID — 상태를 되물을 때 쓴다
// belnr       BELNR_D  전기된 반제전표 (완료 뒤 채워진다)
// gjahr       GJAHR
// msgty       CHAR1    메시지 유형
// message     CHAR220
// created_at  TIMESTAMPL
// updated_at  TIMESTAMPL
// 이 테이블이 있어야 "요청은 보냈는데 결과를 모르는" 구간이 사라진다.

@AbapCatalog.sqlViewName: 'ZICLRREQ'
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '반제 전기 요청'
define view ZI_ClearingRequest
  as select from zfi_clr_req as Req
  left outer join I_AccountingDocumentHeader as Doc
    on  Req.bukrs = Doc.CompanyCode
    and Req.belnr = Doc.AccountingDocument
    and Req.gjahr = Doc.FiscalYear
{
  key Req.request_id                                      as RequestId,
      Req.bukrs                                           as Bukrs,
      Req.status                                          as Status,
      case Req.status
        when 'ACCEPTED'  then '요청 접수'
        when 'QUEUED'    then '큐 대기'
        when 'INPROCESS' then '전기 처리중'
        when 'POSTED'    then '전기 완료'
        when 'FAILED'    then '전기 실패'
        when 'CANCELLED' then '취소됨'
        else Req.status end                               as StatusText,
      Req.soap_msgid                                      as SoapMessageId,
      Req.belnr                                           as Belnr,
      Req.gjahr                                           as Gjahr,
      Doc.PostingDate                                     as Budat,
      Req.msgty                                           as MsgType,
      Req.message                                         as Message,
      Req.created_at                                      as CreatedAt,
      Req.updated_at                                      as UpdatedAt
}

운영 적용 시 해야 할 작업

자주 묻는 질문 — 화면과 조작, 회계 처리, 도입과 운영