Update JH_ERP/02_요구사항_통합정리.md
This commit is contained in:
@@ -0,0 +1,93 @@
|
|||||||
|
# ERP 고도화 검토 자료 - 통합 요구사항 분석 Report
|
||||||
|
|
||||||
|
본 보고서는 24개 소스 문서에 분산되어 기술된 요구사항들을 종합 분석하여, 공통 및 중복 요구사항을 규명하고 이를 관통하는 핵심 기술 아키텍처 5대 영역을 정의한 분석서입니다.
|
||||||
|
*모든 설계 요소는 영문 모델명과 한글명을 병기하여 기술적 일관성을 확보하였습니다.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. 공통 및 중복 요구사항 분석
|
||||||
|
|
||||||
|
소스 문서 검토 결과, 모든 개별 플랫폼 설계 정의서(STEP01~08)와 개발 가이드라인(STEP20~25)에서 일관되게 지향하고 반복 명시한 핵심 요구사항은 다음과 같습니다.
|
||||||
|
|
||||||
|
### A. 데이터 정합성 통제 및 물리 삭제 금지 (No Physical Delete)
|
||||||
|
* **내용**:
|
||||||
|
* 원자재 입고부터 생산, 야적, 출하, 기성 청구, 세금계산서 발행, 수금에 이르는 전체 라이프사이클 상의 모든 트랜잭션 데이터는 물리 삭제(DELETE)가 절대 불가함.
|
||||||
|
* 모든 데이터의 수정/삭제 행위는 상태 코드 변경(`status` 컬럼) 및 `AuditLog(감사로그)`와 `ChangeHistory(변경이력)` 스냅샷 저장을 통해 트레이스(Trace)를 보존함.
|
||||||
|
* **관련 문서**: STEP01, STEP03, STEP08, STEP25 등 전 문서에서 중복 강조됨.
|
||||||
|
|
||||||
|
### B. 가변 공정 흐름 및 유연한 생산 조직 대응 (Flexible Process & Team Model)
|
||||||
|
* **내용**:
|
||||||
|
* 고정된 라인 생산 방식이 아닌 프로젝트 및 교량별로 수행 팀이 수시 지정되는 가변 생산 구조를 지원해야 함.
|
||||||
|
* `TeamWorkFormRule(팀별 입력규칙)`을 두어 철근팀(Rebar Team), 제작팀(Manufacturing Team), 공무팀(Facility Team), 외주팀(Outsourcing Team)이 각기 맡은 업무(WorkTask)와 형식(FormType)만을 입력하도록 제한하되, 팀 간의 교차 입력 및 유연한 자원 배분이 가능해야 함.
|
||||||
|
* **관련 문서**: STEP05, STEP08, STEP25, 원가구조분석 PPTX 등에서 중복 다뤄짐.
|
||||||
|
|
||||||
|
### C. 마감 통제 및 재오픈(Reopen) 승인 프로세스 (Closing & Reopen Control)
|
||||||
|
* **내용**:
|
||||||
|
* 매월 말 생산, 원가, 기성, 매출, 손익 순으로 정해진 흐름에 따라 마감이 진행되어야 함.
|
||||||
|
* 마감이 완료(`status = CLOSED`)된 데이터는 일반 사용자가 수정할 수 없으며, 수정이 필요한 경우 결재라인(Approval Line)을 통한 공식 `ReopenRequest(재오픈요청)` 승인을 거친 뒤 해당 기간에 한해 상태를 임시 변경(`REOPENED`)해 편집을 허용함.
|
||||||
|
* **관련 문서**: STEP04, STEP08, STEP22, STEP25 등에서 중복 명시됨.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. 통합 아키텍처 핵심 관점
|
||||||
|
|
||||||
|
본 ERP 시스템의 기술 아키텍처는 단순한 CRUD 기반 업무 시스템을 넘어 아래의 5가지 핵심 아키텍처 관점을 기반으로 유기적으로 연결되도록 설계되었습니다.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
Project["Project (프로젝트)"] --> Bridge["Bridge (교량)"]
|
||||||
|
Bridge --> BridgeAlias["BridgeAlias (교량별칭)"]
|
||||||
|
Bridge --> WorkTask["WorkTask (업무)"]
|
||||||
|
WorkTask --> FormType["FormType (형식)"]
|
||||||
|
FormType --> Location["Location (작업위치)"]
|
||||||
|
|
||||||
|
DailyWork["DailyWork (작업일보)"] --> |TeamWorkFormRule 검증| ProductionQty["ProductionQty (생산량)"]
|
||||||
|
ProductionQty --> ProductionResult["ProductionResult (생산실적)"]
|
||||||
|
ProductionResult --> ProductionUnit["ProductionUnit (생산품단위)"]
|
||||||
|
|
||||||
|
ProductionUnit --> |QRMaster 연계| YardStock["YardStock (야적재고)"]
|
||||||
|
ProductionUnit --> Shipment["Shipment (출하)"]
|
||||||
|
|
||||||
|
ProductionResult --> |생산손익기준| ProgressClaim["ProgressClaim (기성청구)"]
|
||||||
|
Shipment --> |임시/긴급| TemporarySettlement["TemporarySettlement (임시정산)"]
|
||||||
|
|
||||||
|
ProgressClaim --> ClaimInvoiceMapping["ClaimInvoiceMapping (매핑)"]
|
||||||
|
TaxInvoice["TaxInvoice (세금계산서)"] --> ClaimInvoiceMapping
|
||||||
|
|
||||||
|
TaxInvoice --> |회계매출기준| Payment["Payment (수금)"]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 1) Business Hierarchy (비즈니스 계층 구조) 관점
|
||||||
|
* **구조**: `Project(프로젝트) -> Bridge(교량) [BridgeAlias(교량별칭)] -> WorkTask(업무) -> FormType(형식) -> Location(작업위치)`
|
||||||
|
* **상세**:
|
||||||
|
* **Project(프로젝트)**: 수주/사업의 최상위 묶음 단위.
|
||||||
|
* **Bridge(교량)**: 실무 데이터 귀속(원가, 생산량, 기성 등)의 **가장 핵심적인 앵커 단위**.
|
||||||
|
* **BridgeAlias(교량별칭)**: 현장별 명칭 차이 및 레거시 데이터 매핑 오류를 해소하는 완충 레이어.
|
||||||
|
* **WorkTask(업무) & FormType(형식)**: 생산량 계산, 원가 배분 및 기성 산출의 기준 정보.
|
||||||
|
* **Location(작업위치)**: 공장 내 물리적 구역(A동 데크 등)으로, 제작팀(Manufacturing Team)의 입력 신뢰도를 높이기 위해 활용.
|
||||||
|
|
||||||
|
### 2) Event-Driven Architecture (이벤트 기반 아키텍처) 관점
|
||||||
|
* **구조**: `EventBus(이벤트버스) -> EventQueue(이벤트큐) -> Subscriber(구독자)`
|
||||||
|
* **상세**:
|
||||||
|
* 작업일보 확정, 출하 완료, 기성 승인 등 핵심 비즈니스 이벤트 발생 시 데이터베이스 트랜잭션과 외부 연동을 직접 결합하지 않고 비동기 `EventQueue(이벤트큐)`에 적재함.
|
||||||
|
* 이후 독립적인 백그라운드 데몬 및 배치 스케줄러(`BatchJob`)가 큐를 Polling하여 실시간 알림 발송(`Notification`), 대시보드 스냅샷 갱신(`DashboardSnapshot`), 그리고 회계 연동(`IntegrationQueue`) 등 후속 처리를 처리함.
|
||||||
|
* 이를 통해 시스템 간 결합도를 낮추고 처리 성능 및 장애 탄력성을 확보함.
|
||||||
|
|
||||||
|
### 3) Domain Separation (도메인 분리) 관점
|
||||||
|
* **구조**: 생산량 기반의 생산 손익(`ProductionRevenue`)과 세금계산서 기반의 회계 매출(`AccountingRevenue`)의 철저한 분리.
|
||||||
|
* **상세**:
|
||||||
|
* **생산 손익 Domain**: 실제 생산량을 기준으로 발주처와 월별 생산량을 협의하여 기성 금액을 확정함. 교량별/형식별 손익 분석 및 경영 대시보드(`ProfitSummary`)의 주원천으로 사용.
|
||||||
|
* **회계 매출 Domain**: 발행일자(당월 말일 등)를 기준으로 국세청 세금계산서(`TaxInvoice`)를 교량별 묶음 발행하고, 수금(`Payment`) 및 회계상 미수금(`invoice_receivable`)을 관리함.
|
||||||
|
* **연결점**: 기성 청구 내역과 세금계산서의 N:M 관계를 처리하기 위해 `ClaimInvoiceMapping(기성계산서매핑)` 테이블을 두고 매핑 금액(`mapped_amount`)을 명시하여 두 도메인을 추적 가능하게 연결함.
|
||||||
|
|
||||||
|
### 4) Data Governance (데이터 거버넌스 및 감사) 관점
|
||||||
|
* **구조**: `AuditLog(감사로그)` 및 `ChangeHistory(변경이력)` 스냅샷 설계.
|
||||||
|
* **상세**:
|
||||||
|
* 데이터 무결성을 보장하기 위해 중요 마스터 정보 및 트랜잭션 데이터의 생성, 수정, 삭제(상태 변경) 시 세션 사용자 정보, IP, 행위 유형(`action_type`), 발생 일시(`action_at`)를 자동 로깅함.
|
||||||
|
* 변경 전 데이터와 변경 후 데이터를 JSON 포맷의 스냅샷(`data_snapshot`) 형태로 보관하여 사후 장애 추적 및 부정 방지 거버넌스를 완벽히 수립함.
|
||||||
|
|
||||||
|
### 5) Approval Process (업무흐름 및 전자결재) 관점
|
||||||
|
* **구조**: `ApprovalRequest(결재요청) -> ApprovalLine(결재선) -> ApprovalHistory(결재이력)` 및 `StateTransition(상태전이)` 통제.
|
||||||
|
* **상세**:
|
||||||
|
* ERP 핵심 데이터(출하, 기성, 마감 해제 등)의 상태는 사용자의 임의 업데이트를 차단함.
|
||||||
|
* ERP 내재형 전자결재 모델을 구축하여, 결재 요청(`appr_request`)이 생성되면 정해진 결재선(`appr_line`)을 따르고, 최종 결재 승인(`action_type = APPROVED`) 이벤트가 발송되는 시점에 대상 트랜잭션의 상태(`status`)를 State Machine(상태 머신) 규칙에 따라 자동으로 전이 처리함.
|
||||||
|
|||||||
Reference in New Issue
Block a user