S/4HANA 전환 일정을 짤 때, 자산 회계 때문에 연말을 기다려야 할까요? 자산 회계만 놓고 보면 연말일 필요는 없습니다. 대신 이전하는 때에 열린 회계연도가 하나뿐이어야 하고, 설치 직전에 직전 기간 마감을 완전히 끝내야 합니다. 이 글을 읽고 나면 후보 날짜마다 열린 회계연도가 몇 개일지 따져 보고, SUM(Software Update Manager)을 시작하기 전에 자산 회계에서 끝낼 일과 감가상각 전기 화면(AFAB)에서 볼 칸을 짚을 수 있습니다.
예시는 가상 회사 코드 BX01입니다. 회계연도는 역년과 같고, SAP ERP 6.0 EHP8(ECC)에서 classic Asset Accounting을 쓰다가 SAP S/4HANA 2025로 전환한다고 가정합니다. 후보는 2026년 11월 말, 2027년 1월 초, 2027년 3월의 주말 셋입니다. 근거는 S/4HANA 2025 FPS02(2026년 10월판) 자산 회계 이전 안내(영어), ECC 6.0 EHP8 자산 회계 문서, S/4HANA 2025 전환 가이드 3.0판, SUM 2.0 SP27 문서이며 2026년 10월 27일에 확인했습니다. SAP 시스템에서 실행한 것은 없습니다.
연말이 아니어도 되지만, 조건이 둘 있다
classic Asset Accounting에서 옮길 때 자산 회계 관점에서는 S/4HANA를 연말에 설치할 필요가 없고, 그 준비 단계 안내는 달 중간에 전환하는 경우를 예로 듭니다. EHP7 SPS02 이상에서 new Asset Accounting을 이미 쓰는 시스템이라면 연말이나 기간 말에 설치하지 않아도 됩니다. 어느 쪽이든 날짜를 막는 것은 달력이 아니라 두 조건입니다.
첫째, 이전하는 때에 자산 회계에 열린 회계연도가 하나뿐이어야 합니다. 어느 해까지 닫혔는지는 자산 회계 Customizing의 Preparations for Going Live > Tools > Execute/Undo Year-End Closing에서 봅니다. 이 경로는 S/4HANA 2025 문서의 표기이고, ECC 6.0 EHP8 문서에는 Periodic processing > Year-end closing > Reverse로 나옵니다. 둘째, S/4HANA 설치 직전에 직전 기간의 자산 회계 마감을 완전히 끝내야 합니다. 설치가 끝나면 이전이 모두 성공할 때까지 자산 회계에 전기할 수 없습니다. 그러니 자산 회계가 멈추는 기간은 기술 설치가 아니라 Customizing과 전표 이전이 끝날 때까지이고, 그동안 사용자를 잠가 두기를 권합니다.
설치 전에 끝내야 하는 일도 있어 날짜를 잡을 때 함께 봅니다. 새 감가상각 계산을 위한 Financials Extension(EA-FIN) 활성화, 그리고 원장의 병행 통화에 맞는 통화 영역이 자산 회계에 없을 때 그 영역을 만드는 별도 프로젝트입니다.
열린 회계연도가 둘이 되는 구간
ECC의 자산 회계에서 새 회계연도는 회계연도 변경을 실행해야 열립니다. 변경은 빨라도 옛 해의 마지막 달에 할 수 있고, 새 해 안이면 언제든 할 수 있습니다. 변경 전에는 새 해 날짜로 전기할 수 없고, 변경한 뒤에도 옛 해에는 계속 전기할 수 있습니다. 동시에 열어 둘 수 있는 해는 둘까지입니다.
옛 해는 연말 마감 프로그램으로 닫습니다. 닫을 수 있는 해는 마지막으로 닫은 해의 다음 해이고, 현재 회계연도는 닫을 수 없습니다. 감가상각 계산 오류가 있거나, 계획 감가상각·정기 전기 잔액이 원장에 덜 전기됐거나, 자본화하지 않은 취득 자산이 남아 있으면 닫히지 않습니다. 두 문서를 합치면 회계연도 변경부터 옛 해 연말 마감까지는 열린 해가 둘이라 이 상태로는 이전 조건을 채우지 못합니다. SAP 문장이 아니라 이 글의 추론입니다.
BX01의 후보에 대 보면 이렇습니다. 2025년을 이미 닫았다면 11월 말에는 2026년 하나만 열려 있습니다. 1월 초는 회계연도 변경을 했는지에 달렸습니다. 아직 2027년으로 바꾸지 않았다면 열린 해는 여전히 2026년 하나이고(이 글의 추론), 그 대신 그때까지 자산 회계에 2027년 날짜로 전기할 수 없습니다. 다만 전환 전 점검 SI-Check(Simplification Item Check)가 이 상태를 어떻게 판정하는지는 공개 문서에서 찾지 못했으니, 이 후보는 테스트 시스템에서 SI-Check로 먼저 확인합니다. 12월에 이미 바꿨다면 두 해가 열려 있으므로, 1월 초에 전환하려면 2026년 연말 마감부터 끝내야 합니다. 3월도 2026년을 닫았는지에 따라 갈립니다.
옛 해를 서둘러 닫을 때는 한 가지를 더 봅니다. ECC에서는 너무 일찍 닫은 해를 Customizing에서 다시 열 수 있지만, 이전을 마친 뒤에는 이전 전 회계연도를 자산 회계에서 다시 열지 말아야 합니다. 그러니 2026년을 닫고 전환한다면, 그해 자산 숫자를 고칠 일은 전환 전에 끝내 두는 편이 안전합니다.
SAP 노트
BX01에 열린 회계연도는 몇 개인가
가상 회사 코드, 회계연도 = 역년. ECC 6.0 EHP8 자산 회계 규칙으로 따짐
2026년 하나만 열림
2026- 열린 해 1 · 이전 조건 충족
- 2025년을 이미 닫은 상태
- 2026년 11월 말 후보는 여기에 든다
2027년으로 회계연도 변경
- 빨라도 2026년 12월, 2027년 안이면 언제든
- 실행 전에는 2027년 날짜로 전기할 수 없다
- 추론: 아직 실행하지 않았다면 2027년 1월 초도 첫 상태 그대로
2026·2027 두 해가 열림
2026 + 2027- 열린 해 2 · 이 상태로는 이전하지 않음
- 옛 해 2026에도 계속 전기할 수 있다
- 추론: 열린 해가 하나여야 하므로 이 구간은 피한다
2026년 연말 마감
- 빨라도 2027년 1월. 현재 회계연도는 닫을 수 없다
- 감가상각 오류 없음, 원장 전기 완료, 취득 자산 자본화, 미완성 자산 없음
2027년 하나만 열림
2027- 열린 해 1 · 이전 조건 충족
- 2026년을 닫고 전환한다면 그해 자산 숫자는 전환 전에 고친다
- 이전 뒤에는 이전 전 회계연도를 다시 열지 않는다
회계연도 변경부터 옛 해 연말 마감까지가 두 해가 열린 구간이다. 이 구간에서 이전하지 않는다는 결론은 SAP 문장이 아니라 두 문서를 합친 추론이다. 날짜와 상태는 가상 예시다.
직전 기간 마감: AFAB를 끝까지 돌린다
설치 직전의 완전한 기간 마감에는 네 가지가 들어갑니다. 감가상각 전기 실행(RAPOST2000, 트랜잭션 AFAB), 주 평가와 병행 평가 모두에 대한 원장과 자산 보조원장의 대사, 정기 APC 전기(RAPERB2000), 감가상각 재계산(AFAR)입니다. APC는 취득·제작 원가(acquisition and production costs)입니다. RAPERB2000은 오류 없이 끝나고 타임스탬프가 현재여야 하며, 설치 직전에 마지막으로 한 번 더 돌립니다. 설치 뒤에는 이 전기를 따라잡을 수 없고, 이전 뒤에는 프로그램도 필요 없어져 쓸 수 없습니다.
달 중간에 전환한다면, BX01의 11월 말 후보처럼 지난달 10월의 마감부터 끝내고, 그사이 11월에 생겼을 수 있는 APC 관련 전기 때문에 정기 APC 전기를 설치 직전에 다시 돌립니다. 11월분 감가상각을 이전 전에 미리 돌렸다면 설치 뒤에는 10월분 감가상각을 다시 전기할 수 없고, 설치 뒤 10월에 영향을 주는 조정을 10월로 전기하면 그 감가상각은 11월에 해당하는 전기 기간으로 들어갑니다.
AFAB 선택 화면에서는 실행 이유를 고릅니다(ECC 6.0 EHP8 문서 기준). Planned posting run은 전기 주기에 따른 다음 기간을 전기하고(①), Repeat는 마지막으로 전기한 기간을 다시 돌려 차이만 전기합니다. Restart는 기술적 이유나 사용자 오류로 끊긴 실행을 이어 가는 모드로, 앞 실행에서 성공하지 못한 자산만 처리합니다(②). 갱신 실행은 백그라운드로만 시작할 수 있습니다. 처음 돌리거나 데이터나 설정을 크게 바꿨다면, 갱신 실행과 같은 점검을 하고 만들어질 전표를 시뮬레이션하는 시험 실행부터 합니다(③).
오류 처리도 같은 ECC 문서 기준이며 단계마다 다릅니다. 시작 단계에서 선택 조건이 맞지 않으면(예: 정기 실행의 기간이 마지막 전기 기간 바로 다음이 아님) 실행이 끝납니다. 문서는 이 단계에서 오류를 분석하고 실행을 다시 시작하라고 적습니다. 감가상각 계산 오류는 해당 자산만 빼고 실행을 이어 가며, 다른 오류가 없으면 Restart 없이 자산 값을 고친 뒤 Repeat나 다음 정기 실행으로 전기합니다. 다만 전환 직전에는 다음 정기 실행이 설치 뒤가 되므로, 고친 자산은 설치 전에 Repeat로 전기해 둡니다(이 글의 판단). 개별 항목 생성이나 전표 갱신에서 난 오류(계정·원가 센터 누락 등)는 고친 뒤 Restart로 마저 처리합니다. 그러니 Restart나 Repeat로 마저 전기할 자산을 남긴 채 SUM을 시작하지 않습니다.
직접 전기에서 생긴 업데이트 중단도 남아 있으면 안 됩니다. SI-Check 프로그램 /SDF/RC_START_CHECK에서 ID SI2: FIN_AA로도 확인할 수 있습니다. 업데이트 관리 화면 SM13에서 상태가 Error인 업데이트는 원인을 고치는 것만으로는 부족하고, 다시 실행해야 데이터베이스에 기록됩니다.
SUM을 켜기 전 차례, 그리고 다운타임 최적화 전환
준비 단계 안내와 이전 흐름 안내를 합치면 차례는 전제 조건 확인, 사용자 잠금(기간 마감에 필요한 전기만 남김), 직전 기간 완전 마감, 백업, SUM으로 설치입니다. 두 안내는 SI-Check를 둔 자리가 다르지만, SUM이 처음과 다운타임 직전에 자산 회계 사전 점검이 든 SI-Check를 다시 돌립니다. 처음에는 반환 코드 12, 다운타임 직전에는 8 이상의 메시지가 있으면 SUM이 멈춥니다. 이 준비는 Customizing 시스템과 그 뒤의 테스트·운영 시스템에서 각각 합니다.
다운타임 최적화 전환은 데이터 변환의 일부를 업타임에 하므로 자산 회계가 멈추는 방식이 다릅니다(SUM 2.0 SP27 문서 기준). MAIN_SHDRUN/REQ_SMIG_APPL_LOCK 단계에서 데이터베이스 동결 트리거가 자산 회계의 주요 테이블을 잠그고, 그동안 RAPERB2000이나 ASKB로 정기 자산 전기를 마감하고 운영 시스템에서 AFAR로 계획 감가상각을 계산합니다. 잠금이 풀린 뒤(MAIN_SHDRUN/REQ_SMIG_APPL_UNLOCK) 다운타임까지의 제약 가운데 일부를 들면, AJRW·AJAB로 자산 회계 연말 작업을 하지 않고, 닫은 회계연도를 다시 열지 않고, 모든 자산에 대한 정기 감가상각 전기는 피합니다. 원본 시스템의 T093D가 논리 풀 테이블이면 트리거가 켜진 동안 AFAB로 감가상각을 계산하지 않습니다. 그러니 잠금부터 다운타임까지 자산 회계 연말 작업이 끼지 않게 날짜를 잡습니다(이 글의 판단).
SAP 노트
SUM을 시작하기 전, 자산 회계에서 끝낼 일
준비 단계 안내와 이전 흐름 안내를 합친 차례. 가상 BX01의 11월 말 전환 후보
전제 조건 확인
- 자산 회계에 열린 회계연도가 하나인지
- EA-FIN, 병행 통화 영역처럼 설치 전에 끝낼 일
사용자 잠금
- 기간 마감에 필요한 전기만 남긴다
10월 마감
AFAB (RAPOST2000)- Restart·Repeat로 마저 전기할 자산을 남기지 않는다
- 원장과 자산 보조원장 대사, 주 평가와 병행 평가 모두
정기 APC 전기와 감가상각 재계산
RAPERB2000 · AFAR- RAPERB2000은 오류 없이, 현재 타임스탬프로
- 11월에도 APC 전기가 있었을 수 있으니 설치 직전에 다시
업데이트 중단 없음
SM13 · SI2: FIN_AA- 직접 전기에서 생긴 업데이트 중단이 없어야 한다
- Error 상태 업데이트는 다시 실행해야 DB에 기록된다
백업 뒤 SUM
- SI-Check가 처음과 다운타임 직전에 다시 확인
- 설치부터 이전 완료까지 자산 회계 전기 불가
Customizing 시스템과 테스트·운영 시스템마다 같은 준비를 한다. 회사 코드와 달은 설명용 가상 예시다.
후보 날짜를 고를 때 먼저 적을 것은 연말이 아니라 두 날짜, 다음 회계연도 변경일과 옛 해 연말 마감일입니다. 전환일이 그 사이에 들어오면 옛 해를 먼저 닫을 수 있는지부터 정합니다. 어느 경우든 설치 직전 주에는 AFAB를 빠진 자산 없이 끝내고 RAPERB2000을 마지막으로 돌릴 시간을 일정표에 넣습니다.
이 기록에 대화를 더해 주세요.
궁금한 점, 다른 접근, 직접 해 본 결과를 나눠 주세요.
로그인 상태 확인 중…
댓글을 불러오는 중…