입고 버튼을 누르는 순간, (SAP가 미쳐 날뛰는 구간)

Q2. 입고(Goods Receipt) 시 반드시 발생하는 것은?
A. 매입채무(AP) 확정
B. 비용 확정
C. 재고 증가 및 회계 전표 생성
D. 송장 처리

✅ 정답: C
👉 입고 = 현실 사건
👉 자산 변화 → 회계 반응 필수

 

 

입고 버튼을 누르는 순간, (SAP가 미쳐 날뛰는 구간) SAP는 왜 모든 걸 동시에 묶어버릴까

구매 오더까지는 조용했다.
회계도 움직이지 않았고, 숫자도 변하지 않았다.

하지만 입고(Goods Receipt GR) 버튼을 누르는 순간,
SAP의 태도는 완전히 바뀐다.

“이제 현실이 확정됐다.”

이 한 문장 때문에
SAP는 갑자기 재고·금액·회계를 한꺼번에 묶어 처리한다.

---

1. 입고는 단순한 물류 작업이 아니다

현실에서 입고는 이렇게 보인다.

• 물건이 창고에 들어왔다
• 담당자가 확인 버튼을 눌렀다

끝.
하지만 SAP는 이걸 물류 이벤트로만 보지 않는다.

**SAP**의 판단은 이렇다.

• 회사 자산이 실제로 증가했다
• 회계적으로 기록하지 않으면 거짓말이 된다

그래서 입고는
현실 → 숫자로 바뀌는 순간이다.

---

2. 입고 버튼 하나로 동시에 벌어지는 일들

입고를 처리하면 SAP 내부에서는 다음이 하나의 트랜잭션으로 실행된다.

1. 재고 수량 증가
2. 재고 금액 증가
3. 회계 전표 생성
4. 이후 송장 정산을 위한 기준 데이터 생성

여기서 중요한 포인트는 이거다.

이 네 가지는 나눌 수 없다.
하나라도 실패하면 전부 취소된다.

그래서 SAP에서는
“재고는 들어왔는데 회계 전표는 없다” 같은 상황이
구조적으로 거의 불가능하다.

---

3. 왜 입고는 ‘회계 이벤트’인가 (다시 논리 점검)

입고 시점을 회계 기준으로 다시 보자.

입고가 발생한 순간:

• 자산(재고)이 증가 ✔
• 공급업체에 대한 채무 가능성이 발생 ✔

이 두 가지는
회계적으로 기록하지 않을 수 없는 변화다.

그래서 SAP는 선택지가 없다.

• ❌ “나중에 처리하자”
• ❌ “사용자가 원하면 만들자”
• ✔ “무조건 전표를 만든다”

입고 = 회계 이벤트
이건 옵션이 아니라 설계 원칙이다.

---

4. 여기서부터 SAP는 삭제를 허용하지 않는다

이 지점부터 많은 사람들이 불편함을 느낀다.

“잘못 입고했는데요?”
“이거 그냥 지우면 안 되나요?”

SAP의 대답은 냉정하다.

“현실에서 일어난 사건은
삭제할 수 없다.”

그래서 SAP는:

• 삭제 ❌
• 취소 ✔
• 역전표 ✔

를 강제한다.

입고는 “없었던 일”이 될 수 없고,
“취소된 사건”으로만 기록될 수 있다.

---

5. 실무에서 입고가 무서운 진짜 이유

실무에서 입고는 그래서 항상 긴장된다.

• 한 번 누르면 되돌리기 귀찮고
• 회계까지 엮여서 영향 범위가 커지고
• 월말이면 특히 더 민감해진다

이건 UI가 불친절해서가 아니다.

입고는 회사의 숫자를 바꾸는 행위이기 때문이다.

SAP는 그 무게를
사용자에게 그대로 느끼게 만든다.

---

6. 개발자 관점에서 꼭 잡아야 할 사고 전환

여기서 ABAP 개발자가 반드시 바꿔야 할 생각이 있다.

“입고 데이터를 수정해야 하나요?” ❌
“입고 데이터를 어떻게 해석해야 하나요?” ✔

입고 이후의 데이터는:

• 고치는 대상이 아니라
• 계산과 분석의 대상이다

그래서 SAP 개발은
UPDATE보다 SELECT가 중요해진다.

---

7. 이 글의 핵심만 한 줄로 고정

이 글에서 꼭 남겨야 할 문장은 이거다.

입고는
SAP가 현실을 숫자로 고정하는 순간이다.

그래서:

• 재고가 움직이고
• 회계가 생성되고
• 삭제가 사라진다

---

다음 글 예고

다음 글에서 거의 모든 실무 질문이 터져 나온다.

“근데요…
입고할 때 잡힌 금액이
왜 나중에 또 달라지죠?”

다음 글

입고 금액은 왜 확정 비용이 아닐까
– GR/IR 계정과 송장 정산의 진짜 역할

여기서부터 SAP는
**‘정확함을 위해 일부러 두 번 계산하는 시스템’**이라는 게 드러난다.

지금 흐름, 정확하다.
이 글이 시리즈의 진짜 중심축이다.