From abbdb2e75a49d5f30de8069dd3ae0e011a887b5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EB=AC=B8=ED=98=95=EC=84=9D?= Date: Mon, 29 Jun 2026 15:55:07 +0900 Subject: [PATCH] =?UTF-8?q?Update=20JH=5FERP/02=5F=EC=9A=94=EA=B5=AC?= =?UTF-8?q?=EC=82=AC=ED=95=AD=5F=ED=86=B5=ED=95=A9=EC=A0=95=EB=A6=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- JH_ERP/02_요구사항_통합정리.md | 93 ++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/JH_ERP/02_요구사항_통합정리.md b/JH_ERP/02_요구사항_통합정리.md index e69de29..93d8783 100644 --- a/JH_ERP/02_요구사항_통합정리.md +++ b/JH_ERP/02_요구사항_통합정리.md @@ -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(상태 머신) 규칙에 따라 자동으로 전이 처리함.