SAP 발생수익 인식·해소 점검 — 청구 전에 인식한 수익, 다음 달엔 정말 해소됐는가
결산 때 인식한 발생수익(미청구수익) 전표를, 다음 기간 해소 이행과 총계정원장 잔액까지 한 화면에서 대사해 둡니다
결산월에는 용역을 이미 제공했거나 공사가 진행됐는데도 아직 세금계산서를 발행하지 못해, 수익은 발생했지만 청구되지 않은 금액이 남습니다. 이런 발생수익(미청구수익)은 결산 시점에 조정 분개로 인식해 두지만, 문제는 다음 기간에 실제로 청구·해소가 이뤄졌는지를 전표를 일일이 뒤져 확인하기 번거롭다는 점입니다. 확인이 늦어지면 이미 해소됐어야 할 전표가 몇 달째 미해소 상태로 방치되는 경우도 생깁니다.
표준 전표 데이터 구조를 그대로 이어받아 발생수익 전표별로 해소 예정액과 실제 해소액을 대사하고, 해소기한이 지났는데도 미해소인 건을 자동으로 가려내며, 계정·기간별 총계정원장 잔액까지 함께 맞춰보는 화면으로 OpenUI5 화면으로 확장했습니다. 실제 구동 화면 3종을 함께 공개합니다.
SAP 표준 기능을 그대로 이어받은 부분
- 전표 원천 — 총계정원장 라인(계정·회사코드·전기일·금액) 구조를 그대로 사용
- 표준 화면 — 일반 전표 입력(FB50) · G/L 개별 항목 조회(FBL3N) · 반제 처리(FB08)
| 항목 | 내용 |
|---|---|
| 업무 영역 | 재무회계(FI) · 결산 조정 분개 |
| 관련 기준서·대상 영역 | - (대상 영역 : 결산 조정 분개 — 발생수익(미청구수익) 인식·해소 점검) |
| Namespace | zui5.accrualrev |
| 셸 구조 | 조회조건 영역(우측 조회) + 발생수익 전표 목록·총계정원장 대사 2개 패널, 발생·해소 대사 상세 Dialog |
| 화면 수 | 조회 화면 1개 + 발생·해소 대사 상세 다이얼로그 |
| SAP 표준 T-code | FB50 · FBL3N · FB08(§7 참고) |
| 성격 | 조회·대사·점검형 — 해소 전표 기표 자체는 화면 밖 프로세스 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 3종 둘러보기
회사코드·회계연도·기간을 넣고 조회하면 발생수익 전표 목록이 뜹니다 → 계정으로 좁혀 다시 조회하면 해당 계정 건만 남고 → 행을 클릭하면 그 전표의 해소 예정액·실제 해소액·차이·판정을 다이얼로그로 확인합니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- 회사코드(고정) · 회계연도 · 기간 · 계정 · 코스트센터 · 해소상태를 지정한 뒤 조회조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력 필드에서 Enter 키를 누릅니다.
- 발생수익 전표 목록에서 발생전표번호·계정·거래처·발생액·해소기한·해소상태를 확인합니다.
- 행을 클릭하면 그 전표의 해소 예정액·실제 해소액·차이·판정이 다이얼로그로 뜹니다.
- 총계정원장 대사 패널을 펼치면 계정·기간별 원장 잔액과 전표 합계 대사 결과를 확인합니다.
- CSV 다운로드로 현재 조회된 목록 전체를 내려받습니다.
- "전체"를 선택한 조건은 조회 시 필터에서 제외됩니다.
해소 판정 로직
이 화면의 핵심 판정은 두 가지입니다 : "해소전표가 있고 실제 해소액이 해소 예정액과 맞는가", "해소전표가 없는 채로 해소기한이 지났는가".
| 판정 조건 | 결과 상태 | 사용자 조치 |
|---|---|---|
| 해소전표가 존재하고 실제 해소액 = 해소 예정액 | 해소완료 | 별도 조치 불요 |
| 해소전표가 없고 해소기한이 아직 남음 | 미해소 | 기한 내 정산 여부를 계속 관찰 |
| 해소전표가 없고 해소기한이 지남 | 기한경과·확인 필요 | 미청구 사유를 확인하고 해소 여부를 점검 |
| 해소전표는 있으나 실제 해소액 ≠ 해소 예정액 | 차이 "확인 필요" | 부분 해소·금액 오류 여부를 확인 |
이 화면이 대신 정하지 않는 것
발생수익 인식 자체의 회계처리 적정성과 미청구 사유의 타당성은 회사의 결산·내부통제 프로세스에서 판단하며, 이 화면은 그 결과가 해소 데이터와 정합적으로 대사되는지만 점검합니다.
발생·해소 대사 처리 단계
| 단계 | 내용 |
|---|---|
| 1단계 | 결산월에 청구되지 않은 수익을 발생수익 전표로 인식합니다(발생액 = 해소 예정액) |
| 2단계 | 각 전표에 해소 예정일(청구 기준일)을 부여합니다 |
| 3단계 | 익월 실제 청구·해소가 이뤄지면 해소전표·해소일·실제 해소액을 반영해 상태를 해소완료로 바꿉니다 |
| 4단계 | 전표별로 해소 예정액과 실제 해소액을 대사하고, 계정·기간별로 전표 합계와 총계정원장 잔액을 대사합니다 |
| 5단계 | 해소기한이 지났는데도 미해소인 건을 기한경과·확인 필요로 재분류합니다 |
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
| 회사코드 | 필수 | 대상 회사코드(고정값) |
| 회계연도 | 필수 | 4자리 연도 |
| 기간 | 선택 | 전체 선택 시 필터 제외 |
| 계정 | 선택 | 발생수익 계정 3종, 전체 선택 시 필터 제외 |
| 코스트센터 | 선택 | 전체 선택 시 필터 제외 |
| 해소상태 | 선택 | 미해소·해소완료·기한경과·확인 필요, 전체 선택 시 필터 제외 |
결과 컬럼
| 패널 | 컬럼 · 표시 |
|---|---|
| 발생수익 전표 목록 | 발생전표번호 · 기간 · 전기일 · 계정 · 계정명 · 코스트센터 · 거래처 · 발생액 · 통화 · 해소기한 · 해소상태 · 해소전표번호 · 인식사유 · 프로젝트 |
| 총계정원장 대사 | 기간 · 계정 · 계정명 · 원장잔액 · 전표합계 · 차이 |
| 발생·해소 대사 상세(다이얼로그) | 발생전표번호 · 계정 · 거래처 · 해소 예정액 · 실제 해소액 · 차이 · 해소기한 · 판정 · 의도적 예외 건 |
SAP 표준 기능 매핑
발생수익 인식·해소 점검은 결산 통제 절차라, 전체에 정확히 대응하는 단일 SAP 표준 T-code는 확인되지 않습니다. 아래는 전표의 기표·조회에 관련된 표준 화면입니다.
| SAP 표준 T-code | 연관 기능 |
|---|---|
FB50 | 일반 전표 입력 — 발생수익 조정 분개가 실제로 기표되는 표준 거래 |
FBL3N | G/L 계정 개별 항목 조회 — 발생·해소 전표를 포함한 원장 원천 조회 |
FB08 | 전표 반제·역분개 — 익월 해소(청구) 전표 처리에 관련된 표준 화면 |
대상 영역 대응 매핑표
| 대상 영역 | 요구사항(명칭) | 이 화면의 대응 기능 | 원천 데이터 | 비고 |
|---|---|---|---|---|
| 결산 조정 분개 | 발생수익 인식·해소 이행 점검 | 발생·해소 대사 상세(예정액 vs 실제액) | 총계정원장(전표 헤더·명세) | 해소기한 산정 기준은 회사가 정하는 내부 관리 기준입니다 |
| 결산 조정 분개 | 총계정원장 대사 | 계정·기간별 원장 잔액 vs 전표 합계 대사 | 총계정원장 잔액 + 전표 명세 합계 | - |
도입 시 확인이 필요한 부분
해소기한 산정 기준(청구 주기), 발생수익 계정 범위, 총계정원장 대사 축(계정·기간 외 추가 축 필요 여부)은 회사의 결산 통제 정책에 따라 확정해야 합니다.
참고 CDS 뷰
운영 서비스로 연결할 때를 가정해 새로 스케치한 조회 뷰 예시입니다(운영 반영 시 권한 체크를 추가해야 합니다).
@AbapCatalog.sqlViewName: 'ZIACCRUALREV'
define view entity ZI_AccrualRevenue
as select from bseg
association [0..1] to bkpf as _Header on _Header.bukrs = bseg.bukrs
and _Header.belnr = bseg.belnr
and _Header.gjahr = bseg.gjahr
{
key bseg.bukrs as CompanyCode,
key bseg.gjahr as FiscalYear,
key bseg.belnr as AccrualDocNo,
key bseg.buzei as AccrualDocItem,
bseg.hkont as GLAccount,
bseg.dmbtr as AccrualAmount,
_Header.budat as PostingDate
}
where bseg.hkont in ('0161000100','0161000200','0161000300') // 발생수익 계정(예시)
// 해소전표·해소일·해소상태는 후속 청구 전표와의 대사 로직에서 별도로 산출
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 조회조건 영역 · 발생수익 전표 목록·총계정원장 대사 2개 패널 |
| 조회조건 | sap.m.Input·sap.m.ComboBox — 우측 끝에 조회 버튼, 입력 필드 Enter 시 즉시 조회 |
| 발생수익 전표 목록 | sap.ui.table.Table(컬럼 14개) — 행 클릭 시 발생·해소 대사 상세 다이얼로그 |
| 총계정원장 대사 | sap.m.Table — sap.m.ObjectStatus로 차이 상태 표시 |
| 상세 | sap.m.Dialog — 클릭 시점에 해당 전표의 대사 결과를 키 지정 조회(read)해 표시 |
| 공통 처리 | CSV 다운로드 공통 컨트롤러, 전역 오류 처리기(ErrorHandler) |
파일 구성
| 경로 | 역할 |
|---|---|
index.html | OpenUI5 부트스트랩 — sap_horizon · lodash · moment |
Component.js | OData 모델 초기화, 전역 오류 처리기 연결 |
manifest.json | 앱 디스크립터 — zui5.accrualrev · ko 로케일, OData 서비스 연결 |
view/Main.view.xml | 조회화면 + 목록·대사 패널 |
view/DetailDialog.fragment.xml | 발생·해소 대사 상세 다이얼로그 |
controller/Main.controller.js | 조회 · 필터 · 다이얼로그 · CSV 다운로드 로직 |
controller/BaseController.js | CSV 다운로드 공통 처리 |
model/ErrorHandler.js | 전역 오류 처리 |
model/formatter.js | 금액 · 날짜 · 상태 표시 서식 |
i18n/i18n_ko.properties | ko 로케일 리소스 |
운영 데이터는 OData 서비스 폴더에서 서비스하며, 화면과 판정 로직은 그대로 씁니다.
검증 결과
화면 구성에 쓴 데이터는 발생액·해소액·원장잔액이 원(KRW) 단위로 정확히 맞물리도록 구성했습니다 (의도적으로 넣은 예외 건은 별도로 표시했습니다).
| 검증 항목 | 결과 |
|---|---|
| 해소 대사(해소완료 전표의 예정액=실제액, 74건 중 해소완료 56건 검사) | 통과 — 차이 3건은 의도적 예외 |
| 총계정원장 대사(계정×기간 12건) | 통과 — 차이 1건은 의도적 예외 |
| 해소기한 경과 판정(기한경과·확인 필요 11건 산출) | 판정 로직 일치 확인 |
| 표시 금지 검사 — 커스텀 프로그램ID·앱 식별자·출처 표현 검출 | 0건 |
| 화면 렌더링 — 실브라우저에서 조회 → 필터 조회 → 행 클릭 상세 실동작 후 캡처 | 3/3 |
| 조회 버튼 위치 · sap_horizon 테마 적용 · Enter 조회 · CSV 다운로드 동작 | 확인 |
계정·금액은 모두 검증용으로 구성한 가상 데이터입니다.
자주 묻는 질문
이 점검은 특정 기준서 시행일에 맞춰 하는 건가요?
아닙니다. 발생수익 인식·해소 점검은 특정 기준서의 시행일이 있는 요구사항이 아니라 회사의 상시 결산 절차입니다. 매 결산월 마감 시점에 그 회계연도·기간에 인식된 발생수익 전표를 조회하는 방식으로 활용합니다.
화면의 "기한경과·확인 필요" 표시는 회계기준 위반을 뜻하나요?
아닙니다. 이 화면은 발생수익 전표의 해소 이행 여부를 조회·점검하는 도구이며, 미청구 사유의 타당성과 회계처리의 최종 판단은 회사와 감사인이 결산 절차·내부통제 기준에 따라 내립니다.
해소기한(익월 10일) 기준은 모든 회사에 똑같이 적용되나요?
아니요. 이 화면 예시의 해소기한 산정 기준은 예시 구성이며, 실제 회사에서 적용하는 해소 점검 기준일은 결산 정책과 청구 주기에 따라 다릅니다.
해소되지 않은 발생수익은 항상 문제가 있는 건가요?
아닙니다. 청구 절차가 늦어지는 경우도 있을 수 있습니다. 이 화면은 그런 건을 놓치지 않고 확인 대상으로 표시해 담당자가 후속 조치를 판단할 수 있게 돕는 점검 도구입니다.