ERP

h1. 개발 로드맵

h2. 전체 구조

* 이론 : ERP/회계/프로세스/재고•세무•원가의 핵심 개념 파악

* 실전 : 웹 ERP(모놀리식) MVP 개발 → 점진적 고도화

* 최소 산출물 : 도메인 용어집, 프로세스 다이어그램, ERD, 자동분개 규칙, API 스펙, 화면 와이어프레임, 테스트 시나리오, 배포 스트립트

* 개발 스택

** 프론트엔드 : React.js + shadcn/ui (공통)

** 백엔드1 : TypeScript/NextJS + Prisma + PostgreSQL + Next.js

** 백엔드2 : Spring Boot + JPA + PostgreSQL + Next.js 

h2. 아키텍처 원칙

* 단일 정보 출처(SSOT)

** DB : 스키마 - sql/migrations의 순수 SQL(표준 Postgres)로 관리 (둘다 동일 스키마 사용)

** API : openapi/openapi.yaml (서버/클라이언트 SDK 자동 생성)

** 이벤트 : events/*.json (도메인 이벤트 페이로드 스펙)

* 동일한 메인 모듈

<pre>

auth, core, master(품목/거래처), finance(GL/분개), purchasing, sales, inventory

</pre>

* 동일한 테스트 시나리오

** 단위(분개 룰), 통합(입고→전표), E2E(발주→입고→청구/지급, 주문→출고→청구/수금)

h2. 로드맵 요약

h3. 1-4주차 : 이론 기초 + 플랫폼 뼈대 구성

* 이론

** ERP 핵심: 주문→출하/인도→청구→수금(O2C), 요청→발주→입고→정산(P2P)

** 이중부기와 계정과목, 보조부→총계정원장(GL) 흐름.

** 한국 로컬 포인트 : 부가가치세(영세/과세/면세), 환율, 회계기간, 월마감

* 실전

** 프로젝트 템플릿 생성, 모놀리식 모듈 구조(ex. core, auth, master, finance, purchasing, sales, inventory)

** 공통 레이어

*** 인증/인가(JWT + RBAC), 사용자/조직, 번호체계, 감사로그(Audit), 첨부/코멘트

*** 표준 응답/에러/검증 파이프, OpenAPI 문서화

** 데이터 모델(핵심)

*** 마스터 : partners, items, warehouses, tax_codes, currencies, exchange_rates, gl_accounts

*** 회계 : gl_journals, gl_journal_lines, fiscal_periods

*** 공통 : attachments, audit_logs, doc_sequences

** UI 골격

*** 레이아웃, 공통 그리드(저장된 필터/컬럼), 상태배지, Export(CSV/XLSX)

* 주간 산출물

** 용어집(파트너/품목/전표/세금코드 등)

** ERD 초안(v0)

** 와이어프레임(전표 미리보기 패널 포함)

*** 배포 : Docker(Contaner Manager) + Nginx(프록시) + Cl(빌드/테스트)

h3. 5-6주차 : 회계 엔진 코어(필수)

* 이론

** 분개 규칙 : 판매확정, 입고확정, 출고확정, 청구/수금, 매입/지급 시 차/대변 매핑.

** 환율/다중통화, 세금 분개(매출•매입•부가세)

* 실전

** 테이블 확정 : gl_accounts, posting_rules, gl_journals, gl_journal_lines

** 자동분개 엔진(룰 기반) 구현 : 도메인 이벤트→룰 조회→분개 생성→저장

** 샘플 룰(JSON)

<pre>

{

  "event": "SALES_CONFIRMED",

  "conditions": { "tax_code": "VAT10", "item_type": "GOODS" },

  "lines": [

    { "side": "DR", "account": "AR", "amount": "net+vat" },

    { "side": "CR", "account": "REV", "amount": "net" },

    { "side": "CR", "account": "VAT_OUT", "amount": "vat" }

  ]

}

</pre>

** 의사코드

<pre>

onEvent(e):

  rule = PostingRules.match(e)

  lines = rule.build(e.payload)  // 금액, 통화, 세금

  Journal.create(headerFrom(e), lines)

</pre>

* 산출물

** 분개 규칙 표(이벤트별)

** 전표장/원장 기본 리포트 API

h3. 7-9주차 : 구매(P2P) + 재고(수불)

* 이론

** 재고평가 방법 : 가중평균 or FIFO(MVP는 한 가지로 고정)

** 입고/반품/이동, 창고/로케이션 개념

* 실전

** 구매요청(PR)→발주(PO)→입고(GR)→매입세금계산서(AP)→지급

** 테이블 : purchase_requests, purchase_orders, receipts, ap_invoices, payments, inventory_moves, inventory_layers(평가용), grn_lines 등

** 분개 포인트 예시

*** 입고확정 : 재고자산(차)/매입채무(대)

*** 매입세금계산서 : 매입부가세(차)/매입채무(대)

** 그리드 UX : 라인 인라인 편집, 단가/세액 자동계산, 상태 전이(초안→승인→확정)

* 산출물

** 입고 전표 자동생성 E2E 테스트

** 재고수불 리포트(기간/창고/품목)

h3. 10-12주차 : 판매(O2C) + 청구/수금

* 이론

** 주문/출고/매출/수금 흐름, 출고 시점의 매출원가(COGS) 인식

* 실전

** 견적→주문→출고→매출세금계산서(AR)→수금

** 분개 포인트 예시

*** 출고확정 : 매출원가(차)/재고자산(대)

*** 매출확정 : 외상매출금(차)/매출(대)+부가세계수금(대)

** 리포트 : 매출현황, 미수잔액(고객/기간), 손익 간이표

* 산출물

** 판매/출고/청구 E2E 시나리오

** 시산표(월/계정) v1

h3. 13-14주차 : 마감/권한/감사 + 안정화

* 이론

** 월마감 : 역분개/조정분개, 기간 잠금, 승인 체계

** 권한 모델 : 문서 단위 보기/작성/승인/역분개

* 실전

** 마감 작업 배치(Job) + 재무기간 잠금

** 역분개(Reverse) : 수정 대신 역분개 + 재기표 정책

** 권한 세분화(엔드포이트/액션 레벨)

** 대량 데이터 성능(인덱스, 파티셔닝 : 월/회사)

* 산출물

** 마감 체크리스트, 감사 로그 대시보드, 성능지표(Grafana 권장)

h3. 15-16주차 : 운영/배포/데이터•테스트

* 운영

** Docker 이미지 최적화, 백업/복구 시나리오, 스냅샷 테이블(BI용) 설계

** 모니터링/알람 : Prometheus(or node_exporter) + Grafana, 구조화 로깅

* 테스트 전략

** 단위 : 분개빌더, 금액/세액 라운딩

** 통합 : 입고→전표, 출고→전표, 청구→수금

** E2E : P2P/O2C 핵심 흐름 10개 시나리오 자동화

* 최종 산추물(캡스톤)

** 데모 스크립트(5분) : PO 생성→입고→AP전표/지급, SO→출고→AR전표/수금, 시산표 확인

** 관리자 계정, 3개 역할(Role) 데모, 10만행 샘플로 리포트/성능 확인

-----------------------

h2. 핵심 설계 체크리스트

* ▢ 이벤트 → 자동분개 룰 → 전표 생성 파이프라인이 단방향으로 깔끔한가?

* ▢ 모든 문서에 상태머신과 감사로그가 붙었는가?

* ▢ 전표 미리보기(가상 분개)가 저장 전 확인 가능하게 되어 있는가?

* ▢ 역분개 정책이 코드/화면/권한에서 일관성 있는가?

* ▢ 재고평가(가중평균/FIFO)가 전 과정에서 동일 규칙으로 계산되는가?

* ▢ 한국 VAT, 환율, 기간 잠금이 반영됐는가?