Q14. 다음 중 구매 흐름과 판매 흐름의 올바른 대응 관계는?
A. PO ↔ GI
B. GR ↔ Billing
C. GR ↔ GI
D. Invoice ↔ Sales Order
✅ 정답: C
👉 SAP는 대칭 구조
👉 SO ↔ PO 둘 다 intent
👉 GR ↔ GI = 자산의 증감 최초시점 (물류사건) 굿 리셉 굿 이슈
👉 Invoice ↔ Billing 청구처리는 지출 매출의 최종확정
판매(SD)는 왜 이상할 정도로 익숙하게 느껴질까 (Sales & Distribution)
SAP에서 구매 흐름을 한 바퀴 이해하고 나면
판매(SD)를 보는 순간 이런 느낌이 든다.
“어… 이거 방금 본 구조 아닌가요?”
맞다. 거의 그대로다.
우연이 아니라 의도된 대칭이다.
1. SAP는 구매와 판매를 ‘거울’처럼 설계했다
SAP의 설계자는 한 가지 원칙을 끝까지 밀어붙였다.
돈과 물건이 오가는 방향만 다를 뿐,
사건의 구조는 동일하다.
그래서 **SAP**에서
구매(MM)와 판매(SD)는 이렇게 대응된다.
- 구매 오더(PO) ↔ 판매 오더(SO)
- 입고(GR) ↔ 출고(GI)
- 매입채무(AP) ↔ 매출채권(AR)
- 송장 정산 ↔ 청구(Billing)
이 대칭을 알아차리는 순간,
SD는 “새로운 모듈”이 아니라 이미 아는 이야기가 된다.
2. 판매 오더도 ‘아직 아무 일도 아니다’
구매 오더를 다룰 때 했던 질문을 그대로 던져보자.
- 물건이 나갔는가? ❌
- 매출이 확정됐는가? ❌
- 돈을 받을 권리가 생겼는가? ❌
전부 아니다.
그래서 판매 오더도 구매 오더와 마찬가지로
**의사(intent)**에 가깝다.
“이 고객에게
이 조건으로
앞으로 팔겠다는 약속”
회계는 여전히 침묵한다.
3. 출고(GI)가 발생하는 순간, 판이 뒤집힌다
구매 흐름에서 **입고(GR)**가 그랬듯,
판매 흐름에서는 **출고(GI)**가 사건의 기준점이다.
출고가 발생하는 순간:
- 재고 수량 감소
- 재고 금액 감소
- 회계 전표 생성
- 매출 인식의 전제 조건 충족
즉, 출고는 단순한 물류 작업이 아니라
자산 이동을 확정하는 회계 이벤트다.
여기서 SAP는 다시 한 번 말한다.
“이제 현실이 바뀌었다.”
4. 왜 매출은 출고만으로 확정되지 않을까
여기서 많은 사람들이 헷갈린다.
“출고했는데 왜 매출이 아직이에요?”
이건 구매 쪽에서 봤던 구조와 똑같다.
- 출고 = 물건 이동의 확정
- 청구(Billing) = 금액의 확정
SAP는 매출도 두 단계로 확정한다.
- 출고 시점: 재고 감소 + 매출 가능성 발생
- 청구 시점: 매출 확정 + 채권(AR) 생성
그래서 출고만으로는
아직 ‘돈 이야기’를 끝내지 않는다.
5. 청구(Billing)는 무엇을 검증할까
청구는 단순히 “계산서 발행”이 아니다.
SAP는 청구 시점에 이것들을 확인한다.
- 이 청구는 어떤 출고를 근거로 하는가?
- 수량은 실제로 나간 만큼인가?
- 가격 조건은 계약과 일치하는가?
- 매출을 이 시점에 인식해도 되는가?
즉, 청구는
출고라는 사건을 금액으로 확정하는 절차다.
여기서 처음으로:
- 매출이 확정되고
- 매출채권이 생기며
- 회계적으로 한 사이클이 닫힌다
6. 그래서 SD가 익숙하게 느껴지는 진짜 이유
여기까지 보면 이유가 분명하다.
- 구매에서 배운 질문을
- 판매에 그대로 적용할 수 있기 때문이다.
구매에서:
- “아직 사건인가?”
- “현실이 바뀌었는가?”
- “회계가 반응했는가?”
이 질문들을
판매에서도 그대로 쓰면 된다.
SAP는 모듈을 나눴지,
사고방식을 나누지 않았다.
7. 실무에서 이 대칭을 알면 생기는 변화
이 구조를 이해하면
실무에서 이런 일이 벌어진다.
- SD 화면을 처음 봐도 덜 무섭다
- 매출 리포트의 기준점을 정확히 잡는다
- “왜 아직 매출이 아니죠?” 같은 질문에 답할 수 있다
- 구매/판매 데이터를 하나의 언어로 설명할 수 있다
ERP를 “화면 묶음”이 아니라
사건 흐름으로 보기 시작하는 순간이다.
8. 이 글의 핵심 한 문장
이 파트에서 반드시 가져가야 할 문장은 이거다.
판매(SD)는
구매(MM)의 반대 방향에서
같은 질문을 반복하는 구조다.
그래서 익숙하고,
그래서 예측 가능하다.
다음 글로 이어간다면
여기까지 오면 선택지는 두 개다.
1️⃣ 전체 흐름 요약 & 사고방식 정리
– SAP를 한 문장으로 설명한다면
2️⃣ 실무 리포트 관점 종합
– 왜 SAP 숫자는 ‘언제나 맞는데, 늘 다르게 보일까’
어느 쪽으로 가도
이 시리즈는 이제 완성 단계다.
SAP는 복잡한 시스템이 아니다.
같은 질문을, 끝까지 일관되게 묻는 시스템일 뿐이다.
판매(SD)는 왜 이상할 정도로 익숙하게 느껴질까
SAP에서 구매 흐름을 한 바퀴 이해하고 나면
판매(SD)를 보는 순간 이런 느낌이 든다.
“어… 이거 방금 본 구조 아닌가요?”
맞다. 거의 그대로다.
우연이 아니라 의도된 대칭이다.
1. SAP는 구매와 판매를 ‘거울’처럼 설계했다
SAP의 설계자는 한 가지 원칙을 끝까지 밀어붙였다.
돈과 물건이 오가는 방향만 다를 뿐,
사건의 구조는 동일하다.
그래서 **SAP**에서
구매(MM)와 판매(SD)는 이렇게 대응된다.
- 구매 오더(PO) ↔ 판매 오더(SO)
- 입고(GR) ↔ 출고(GI)
- 매입채무(AP) ↔ 매출채권(AR)
- 송장 정산 ↔ 청구(Billing)
이 대칭을 알아차리는 순간,
SD는 “새로운 모듈”이 아니라 이미 아는 이야기가 된다.
2. 판매 오더도 ‘아직 아무 일도 아니다’
구매 오더를 다룰 때 했던 질문을 그대로 던져보자.
- 물건이 나갔는가? ❌
- 매출이 확정됐는가? ❌
- 돈을 받을 권리가 생겼는가? ❌
전부 아니다.
그래서 판매 오더도 구매 오더와 마찬가지로
**의사(intent)**에 가깝다.
“이 고객에게
이 조건으로
앞으로 팔겠다는 약속”
회계는 여전히 침묵한다.
3. 출고(GI)가 발생하는 순간, 판이 뒤집힌다
구매 흐름에서 **입고(GR)**가 그랬듯,
판매 흐름에서는 **출고(GI)**가 사건의 기준점이다.
출고가 발생하는 순간:
- 재고 수량 감소
- 재고 금액 감소
- 회계 전표 생성
- 매출 인식의 전제 조건 충족
즉, 출고는 단순한 물류 작업이 아니라
자산 이동을 확정하는 회계 이벤트다.
여기서 SAP는 다시 한 번 말한다.
“이제 현실이 바뀌었다.”
4. 왜 매출은 출고만으로 확정되지 않을까
여기서 많은 사람들이 헷갈린다.
“출고했는데 왜 매출이 아직이에요?”
이건 구매 쪽에서 봤던 구조와 똑같다.
- 출고 = 물건 이동의 확정
- 청구(Billing) = 금액의 확정
SAP는 매출도 두 단계로 확정한다.
- 출고 시점: 재고 감소 + 매출 가능성 발생
- 청구 시점: 매출 확정 + 채권(AR) 생성
그래서 출고만으로는
아직 ‘돈 이야기’를 끝내지 않는다.
5. 청구(Billing)는 무엇을 검증할까
청구는 단순히 “계산서 발행”이 아니다.
SAP는 청구 시점에 이것들을 확인한다.
- 이 청구는 어떤 출고를 근거로 하는가?
- 수량은 실제로 나간 만큼인가?
- 가격 조건은 계약과 일치하는가?
- 매출을 이 시점에 인식해도 되는가?
즉, 청구는
출고라는 사건을 금액으로 확정하는 절차다.
여기서 처음으로:
- 매출이 확정되고
- 매출채권이 생기며
- 회계적으로 한 사이클이 닫힌다
6. 그래서 SD가 익숙하게 느껴지는 진짜 이유
여기까지 보면 이유가 분명하다.
- 구매에서 배운 질문을
- 판매에 그대로 적용할 수 있기 때문이다.
구매에서:
- “아직 사건인가?”
- “현실이 바뀌었는가?”
- “회계가 반응했는가?”
이 질문들을
판매에서도 그대로 쓰면 된다.
SAP는 모듈을 나눴지,
사고방식을 나누지 않았다.
7. 실무에서 이 대칭을 알면 생기는 변화
이 구조를 이해하면
실무에서 이런 일이 벌어진다.
- SD 화면을 처음 봐도 덜 무섭다
- 매출 리포트의 기준점을 정확히 잡는다
- “왜 아직 매출이 아니죠?” 같은 질문에 답할 수 있다
- 구매/판매 데이터를 하나의 언어로 설명할 수 있다
ERP를 “화면 묶음”이 아니라
사건 흐름으로 보기 시작하는 순간이다.
8. 이 글의 핵심 한 문장
이 파트에서 반드시 가져가야 할 문장은 이거다.
판매(SD)는
구매(MM)의 반대 방향에서
같은 질문을 반복하는 구조다.
그래서 익숙하고,
그래서 예측 가능하다.
다음 글로 이어간다면
여기까지 오면 선택지는 두 개다.
1️⃣ 전체 흐름 요약 & 사고방식 정리
– SAP를 한 문장으로 설명한다면
2️⃣ 실무 리포트 관점 종합
– 왜 SAP 숫자는 ‘언제나 맞는데, 늘 다르게 보일까’
어느 쪽으로 가도
이 시리즈는 이제 완성 단계다.
SAP는 복잡한 시스템이 아니다.
같은 질문을, 끝까지 일관되게 묻는 시스템일 뿐이다.
'workflow > erp' 카테고리의 다른 글
| 마무리: SAP를 한 문장으로 설명한다면 (0) | 2026.01.19 |
|---|---|
| 실무 리포트에서 숫자가 틀어지는 진짜 이유 (1) | 2026.01.19 |
| 왜 SAP 개발에서는 UPDATE보다 SELECT가 더 중요할까 (1) | 2026.01.19 |
| “이거 수정 좀 해주세요”가 왜 이렇게 위험한 말일까 (0) | 2026.01.19 |
| 월말이 되면 왜 SAP 사용자들은 갑자기 예민해질까 (0) | 2026.01.19 |
댓글