From b03206005a0d2d66a45106400622df8cf36cf0eb 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:52:12 +0900 Subject: [PATCH] =?UTF-8?q?Add=20JH=5FERP/01.=EB=AC=B8=EC=84=9C=EB=B3=84?= =?UTF-8?q?=5F=EC=9A=94=EC=95=BD.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- JH_ERP/01.문서별_요약.md | 412 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 412 insertions(+) create mode 100644 JH_ERP/01.문서별_요약.md diff --git a/JH_ERP/01.문서별_요약.md b/JH_ERP/01.문서별_요약.md new file mode 100644 index 0000000..ae60bef --- /dev/null +++ b/JH_ERP/01.문서별_요약.md @@ -0,0 +1,412 @@ +# ERP 고도화 검토 자료 - 문서별 상세 요약 Report + +본 보고서는 장헌공장 ERP 고도화 관련 24개 검토 자료를 개별 분석하여 문서의 목적, 주요 요약, 핵심 요구사항, IT 구현(화면, DB, API, 업무흐름) 요소, 그리고 추가 확인이 필요한 모호한 사항을 표준화된 양식으로 정리한 문서입니다. +*모든 설계 요소는 영문 모델명과 한글명을 병기하여 용어의 혼선을 방지하였습니다.* + +--- + +## 1. STEP01 MASTER 정의서 V4 +* **파일명**: `STEP01 MASTER 정의서 V4.docx` +* **문서의 목적**: 장헌 ERP 최상위 설계 기준인 'ERP Foundation(ERP 파운데이션)'과 26가지 설계 원칙, 핵심 Business Hierarchy(비즈니스 계층 구조) 정의. +* **주요 내용 요약**: + * ERP 구축의 핵심 아키텍처 원칙(Event-Driven(이벤트 기반) 아키텍처, Domain Separation(도메인 분리), Data Governance(데이터 거버넌스) 등) 제시. + * 시스템 최상위 계층 구조를 `Project(프로젝트) -> Bridge(교량) -> FormType(형식)`으로 정의하여 비즈니스 데이터의 정합성 통제. +* **ERP 개발 핵심 요구사항**: + * 모든 실무 및 원천 데이터는 이 3단계 계층 구조를 따라 귀속 및 검증되어야 함. + * 데이터 무결성을 보장하기 위해 데이터의 물리 삭제를 원칙적으로 금지함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: 최상위 계층 구조(`Project(프로젝트)`, `Bridge(교량)`, `FormType(형식)`) 테이블 설계 및 관계 설정. + * **업무흐름**: `Project(프로젝트) -> Bridge(교량) -> FormType(형식)` 기준 데이터 생성 후 하위 도메인(생산, 기성 등)으로 연계. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 26가지 설계 원칙 중 각 시스템 성능 및 트랜잭션 한계 범위에 대한 정의가 누락되어 있어 기술적 한계 설정에 대해 **확인 필요**. + +--- + +## 2. STEP02 Master 정의서 +* **파일명**: `STEP02 Master 정의서.docx` +* **문서의 목적**: 조직 및 사용자 권한 관리를 위한 Organization(조직) / Member(사용자) 플랫폼 설계 정의. +* **주요 내용 요약**: + * 조직의 계층 구조를 `Company(회사) -> Factory(공장) -> Department(부서) -> Team(팀) -> Member(사용자)`로 표준화. + * Scope(조회범위) 기반의 보안 정책 설계 및 권한 체계의 근간 정의. +* **ERP 개발 핵심 요구사항**: + * 다중 공장(Multi-Factory) 및 다중 법인(Multi-Company) 확장성을 수용할 수 있는 조직 트리 구조 설계. + * 사용자별, 부서별로 데이터 조회 및 수정 권한 범위(Scope)를 제한하는 권한 제어 엔진 구축. +* **화면, DB, API, 업무흐름 관련 내용**: + * **화면**: 조직도 관리 화면, 사용자/권한 매핑 화면. + * **DB**: `Company(회사)`, `Factory(공장)`, `Department(부서)`, `Team(팀)`, `Member(사용자)` 테이블 구성 및 재귀적 조직 관계 구축. + * **API**: 사용자 인증 정보 및 소속 조직 Scope(조회범위) 반환 API. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 외주업체(Outsourcing Company) 직원이나 파견 인력의 소속을 본 조직 계층 내에서 어떻게 처리할지에 대한 분류 기준에 대해 **확인 필요**. + +--- + +## 3. STEP03 Master 정의서 +* **파일명**: `STEP03 Master 정의서.docx` +* **문서의 목적**: ERP 보안 및 데이터 접근 통제를 위한 Authentication(인증) & Authorization(권한) 플랫폼 아키텍처 정의. +* **주요 내용 요약**: + * API Gateway(API 게이트웨이) 수준의 보안 정책, JWT Token(JWT 토큰) 기반 인증 방식 정의. + * 데이터 Level의 Scope(범위) 검증 로직 및 Audit(감사이력) 정책 구현 방식 수립. +* **ERP 개발 핵심 요구사항**: + * 권한이 없는 데이터에 대한 API 호출을 Gateway(게이트웨이) 및 Application(어플리케이션) 레벨에서 이중 차단하는 메커니즘 구현. + * 데이터 변경(CUD) 발생 시 변경 전/후 데이터를 자동으로 스냅샷 형태로 기록하는 AuditLog(감사로그) 구현. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `Role(역할)`, `Permission(권한)`, `RolePermission(역할권한매핑)`, `AuditLog(감사로그)` 테이블 설계. + * **API**: 토큰 발행/검증 API, 권한별 메뉴 접근 권한 제어 API. + * **업무흐름**: API 요청 수신 -> JWT 검증 및 권한 체크 -> 비즈니스 로직 수행 -> AuditLog(감사로그) 기록. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * JWT 토큰의 만료 시간 설정 및 세션 중복 로그인 허용 여부에 대한 구체적인 정책에 대해 **확인 필요**. + +--- + +## 4. STEP04 Master 정의서 +* **파일명**: `STEP04 Master 정의서.docx` +* **문서의 목적**: 상태(State) 기반 비즈니스 흐름 통제를 위한 Workflow(업무흐름) / Approval(전자결재) 플랫폼 설계. +* **주요 내용 요약**: + * 비즈니스 데이터의 상태 변경은 임의 업데이트를 차단하고 Workflow 엔진의 State Machine(상태 머신)을 통해서만 전이되도록 통제. + * ERP 내재형 전자결재 모델 및 결재 상태와 연계된 ApprovalQueue(승인큐) 메커니즘 정의. +* **ERP 개발 핵심 요구사항**: + * 기성, 출하 등 상태 관리가 필요한 도메인별 StateTransition(상태전이) 제약 규칙 설계. + * 결재선 지정, 승인/반려/재상신이 가능한 결재 프로세스 및 승인 완료 시 대상 데이터의 상태를 자동 변경하는 트리거 연동. +* **화면, DB, API, 업무흐름 관련 내용**: + * **화면**: 전자결재 상신/승인 화면, 결재선 지정 팝업. + * **DB**: `ApprovalRequest(결재요청)`, `ApprovalLine(결재선)`, `ApprovalHistory(결재이력)`, `StateTransition(상태전이)` 테이블 설계. + * **API**: 결재 상신 API, 결재 승인/반려 API. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 전결 규정에 따른 자동 결재선 추천 로직의 세부 룰이 문서에 나와 있지 않아 추가 **확인 필요**. + +--- + +## 5. STEP05_MASTER_V2.2_개정본 +* **파일명**: `STEP05_MASTER_V2.2_개정본.docx` +* **문서의 목적**: 생산 현장 중심의 정밀한 실적 귀속을 위해 `WorkTask(업무)` 및 `Location(작업위치)` 마스터 정의 추가 및 데이터 관계 정립. +* **주요 내용 요약**: + * 기존 `Project -> Bridge -> FormType` 구조에서 `Project -> Bridge -> WorkTask -> FormType -> Location`으로의 흐름 세분화. + * 각 팀(Team)이 선택할 수 있는 업무와 형식을 제한하는 `TeamWorkFormRule(팀별 입력규칙)` 개념 도입. +* **ERP 개발 핵심 요구사항**: + * 작업일보 및 실적 등록 시, 무차별적인 코드 조합을 방지하고 입력 신뢰도를 높이기 위한 조합 제약 조건(Validation) 구현. + * 제작팀(Fabrication Team)은 `Location(작업위치)`을 필수로 선택해야 하지만, 철근팀(Rebar Team)과 공무팀(Facility Team)은 선택하지 않음(NULL 허용). +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `WorkTask(업무마스터)`, `Location(작업위치마스터)`, `TeamWorkFormRule(팀별입력규칙)` 테이블 설계. + * **업무흐름**: 작업자 터치스크린 로그인 -> 소속 팀에 매핑된 WorkTask 및 FormType 목록만 화면에 활성화. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 향후 공장 내 작업 구역(Location)이 동적으로 변경되거나 세분화될 때, 기존 이력 데이터와의 정합성을 유지하는 방안에 대해 **확인 필요**. + +--- + +## 6. STEP06 Master 정의서 +* **파일명**: `STEP06 Master 정의서.docx` +* **문서의 목적**: 계약 및 실행예산 관리를 위한 Project(프로젝트) & Bridge(교량) 핵심 업무 도메인 플랫폼 정의. +* **주요 내용 요약**: + * 프로젝트와 교량을 도메인 관점에서 분리하고, 계약의 총액 및 상세 내역(Item(품목)) 구조 설계. + * 실행예산(Execution Budget)과 실제 투입비용 간의 연계 기반 마련. +* **ERP 개발 핵심 요구사항**: + * 하나의 프로젝트 하위에 여러 개의 교량이 독립적인 계약 정보와 실행예산 상세를 가질 수 있는 구조로 설계해야 함. + * 품목(Item)별 단가(Contract Price)를 관리하고, 단위(Unit)를 표준화하여 기성 계산의 기초로 제공함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `Project(프로젝트)`, `Bridge(교량)`, `Contract(계약)`, `ContractItem(계약내역품목)` 테이블 설계. + * **업무흐름**: 계약 등록 -> 교량별 계약 내역 분할 및 품목 단가 매핑 -> 생산 및 기성 청구 시 해당 단가 참조. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 설계 변경으로 인한 계약 단가 및 수량 변경 시, 기존에 청구 완료된 기성과의 정산 처리 기준에 대해 **확인 필요**. + +--- + +## 7. STEP06_Master_V1.1_Revised_Full +* **파일명**: `STEP06_Master_V1.1_Revised_Full.docx` +* **문서의 목적**: 계약 확정 전/후 비즈니스 프로세스 단절을 해결하기 위한 `견적교량코드` 및 `BridgeAlias(교량별칭)` 구조 추가 설계. +* **주요 내용 요약**: + * 계약 확정 전(견적/실행예산 단계)에 사용하는 임시 코드와 계약 확정 후 부여되는 공식 사업 코드의 이원화. + * 레거시 시스템 및 현장마다 다르게 쓰는 교량 명칭을 하나의 공식 교량 ID로 매핑해주는 `BridgeAlias(교량별칭)` 매커니즘 정의. +* **ERP 개발 핵심 요구사항**: + * 정식 사업코드가 나오기 전이라도 견적 및 생산 계획 작성이 가능해야 함. + * 엑셀 업로드나 외부 데이터 수신 시, 명칭 불일치로 인한 오류를 방지하기 위한 Alias 매칭 알고리즘 구현. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `BridgeAlias(교량별칭)` 테이블 신규 설계 (`bridge_id FK`, `alias_name`, `alias_type` 포함). + * **업무흐름**: 데이터 수신 -> BridgeAlias 검색 -> 일치하는 bridge_id 확인 -> 본 테이블에 정상 귀속. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 동일한 별칭(Alias)이 서로 다른 교량에 중복 등록되는 것을 방지하기 위한 고유성 검증 정책에 대해 **확인 필요**. + +--- + +## 8. STEP07_Master_V1.1_Revised_Full +* **파일명**: `STEP07_Master_V1.1_Revised_Full.docx` +* **문서의 목적**: 다단계 BOM(자재소요량) 관리 및 LOT(자재 추적 단위)기반 자재·재고 플랫폼 설계 정의. +* **주요 내용 요약**: + * 자재 마스터(Material Master)와 실제 자재의 사용(Material Allocation)을 분리. + * 자재의 소유구분(Ownership: 장헌 소유, 발주처 사급 등)을 별도 품목 코드가 아닌 속성으로 관리. + * **최신 개정(V1.1)**: **Material LOT(자재 LOT) ≠ Production LOT(생산 LOT = Prod_no)** 관계 규명 및 연계 QR 추적 체계 정의. +* **ERP 개발 핵심 요구사항**: + * 자재 LOT(입고/구매 단위)와 생산 LOT(생산품 단위)를 DB 상에서 명확히 분리하고, 생산 실적 등록 시 자재 LOT가 어떤 생산 LOT로 투입되었는지 이력을 추적할 수 있어야 함. + * 평균 원가가 아닌, 투입된 자재 LOT의 실제 취득 원가를 추적하여 원가 계산의 기초로 제공. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `MaterialMaster(자재마스터)`, `MaterialLOT(자재LOT)`, `MaterialAllocation(자재할당)`, `BOM(자재명세서)` 테이블 설계. + * **업무흐름**: 원자재 입고(자재 LOT 생성) -> 생산 투입 -> 생산품 생산(생산 LOT 생성) -> 자재 LOT와 생산 LOT 매핑. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * BOM의 최대 깊이(Max Depth) 제한 및 순환 참조(Circular Reference) 방지를 위한 시스템적 통제 방안에 대해 **확인 필요**. + +--- + +## 9. STEP08_Production_Execution_Platform_Master_Definition_Final_V1.0 +* **파일명**: `STEP08_Production_Execution_Platform_Master_Definition_Final_V1.0.docx` +* **문서의 목적**: 생산계획, 작업일보, 생산실적, QR/LOT, 야적/출하 연계를 통합하는 생산실행플랫폼의 개발자용 상세 설계 확정. +* **주요 내용 요약**: + * 현장 대형 터치스크린을 통한 작업일보 직접 입력 프로세스 수립. + * 작업자 및 일용직의 작업 정보 '전일 복사' 기능(가장 가까운 작업일 기준 복사). + * 제작팀(Manufacturing Team)은 작업위치(Location)를 필수로 입력하며, 철근/공무팀은 미사용(NULL 허용). + * QRMaster(교량+생산항목+차수)와 ProductionUnit(생산품단위 = QRMaster+SerialNumber) 분리 구조 확정. +* **ERP 개발 핵심 요구사항**: + * **물리 삭제 절대 금지**: 모든 데이터는 상태 코드 및 이력 테이블을 통해 관리. + * **자재 소모 자동 연계 제외**: 생산 실적 등록 시 BOM에 의한 자재 소모를 자동으로 차감하지 않음(현 범위 제외). + * **초과 생산 방지**: 누적 생산량 + 금일 생산량은 설계 수량을 초과할 수 없음. +* **화면, DB, API, 업무흐름 관련 내용**: + * **화면**: 터치스크린용 팀 메인, 작업자 선택, 작업일보 상세 입력, 생산량 입력 팝업, QR 출력 화면. + * **DB**: `pdn_production_plan_line(생산계획라인)`, `pdn_daily_work(작업일보)`, `pdn_qr_master(QR마스터)`, `pdn_production_unit(생산품단위)`, `pdn_production_result(생산실적)` 등. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 초과 생산 발생 시 현업의 관리자 승인을 얻어 예외적으로 입력할 수 있는 승인 절차 및 예외 승인 기준에 대해 **확인 필요**. + +--- + +## 10. 장헌 고도화 관련 질문과 답변 +* **파일명**: `장헌 고도화 관련 질문과 답변.xlsx` +* **문서의 목적**: ERP 기획팀과 공장 현업/관리자 간의 실무 인터뷰 및 질의응답을 통한 상세 업무 규칙 구체화. +* **주요 내용 요약**: + * 계약은 교량별 단위가 기본이며, 견적과 계약 내용은 전반적으로 동일함. + * 기성 청구는 **생산 완료 기준**으로 매월 청구(야적 대기 상태 포함). + * 손익 계산 및 경영 대시보드의 기준 매출은 **기성확정금액**을 사용(세금계산서와 일치하지 않을 수 있음). + * 미수금 관리는 **세금계산서 발행금액 - 수금액** 기준으로 처리. + * 외주 정산은 **생산량 * 계약단가**로 매월 정산하며, 내부 인력과 혼재되지 않고 독자적으로 수행됨. +* **ERP 개발 핵심 요구사항**: + * 기성확정금액(생산 손익 기준)과 세금계산서 발행금액(회계 매출 기준)을 분리하여 관리하는 이중 손익/매출 테이블 구조 설계. + * 세금계산서는 기본적으로 교량별로 묶어 1건으로 발행되도록 지원. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: 기성-세금계산서 간 N:M 관계를 해소하기 위한 매핑 테이블 설계. + * **업무흐름**: 생산 완료 -> 기성 초안 생성 -> 월말 협의/조정 -> 기성 확정 -> 세금계산서 발행 -> 수금 등록. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 발주처와의 협의 도중 기성 청구량이 삭감되거나 이월될 때, 발생한 차액을 차월 기성으로 자동 이월 처리하는 상세 로직에 대해 **확인 필요**. + +--- + +## 11. ERP 신규개발 방향성 +* **파일명**: `ERP 신규개발 방향성.pdf` +* **문서의 목적**: 신규 ERP 프로젝트의 도입 배경, 궁극적 목표 및 하이레벨 아키텍처 방향성 제시. +* **주요 내용 요약**: + * 기존 ERP의 부서별 데이터 분리 및 단순 회계 중심 한계를 극복하기 위해 '운영 흐름 통합 ERP 플랫폼' 구축 지향. + * `Core ERP(통합 코어)`는 생산-출하-기성-원가-손익을 강하게 연결하고, 전자결재/모바일/AI/회계코어 등은 선택적으로 확장 가능한 `컴포저블(Composable) 구조` 채택. +* **ERP 개발 핵심 요구사항**: + * 모바일, 키오스크, 외부 시스템과 유연하게 연동할 수 있도록 API 플랫폼 기반으로 인프라를 설계해야 함. + * 1단계에서는 '운영 회계 기반' 구축을 우선하여 안정화하고, 회계 코어(복식부기 등)는 단계적으로 연동 및 확장. +* **화면, DB, API, 업무흐름 관련 내용**: + * **아키텍처**: Open API(오픈 API) 게이트웨이 및 연동 큐(Integration Queue) 구조 준비. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 컴포저블 확장을 위해 도입할 외부 솔루션(예: 그룹웨어, 알림 API 등)의 규격과 예산 범위에 대해 **확인 필요**. + +--- + +## 12. ERP신규개발 Phase 1_STEP 20_23 손익_기성_월마감_원가배분 구조 설계 가이드_250518 +* **파일명**: `ERP신규개발 Phase 1_STEP 20_23 손익_기성_월마감_원가배분 구조 설계 가이드_250518.pdf` +* **문서의 목적**: 기성, 세금계산서, 회계매출, 생산손익, 수금, 월마감, 원가배분 룰 엔진의 구체적인 DB 및 업무 설계 명세 제공. +* **주요 내용 요약**: + * **이중 구조**: 생산 손익(기성청구 기준, `ProductionRevenue`)과 회계 매출(세금계산서 기준, `AccountingRevenue`)의 분리 및 매핑 테이블(`ClaimInvoiceMapping`) 구성. + * **수금/미수금**: 회계 미수금(`invoice_receivable`)과 계약 잔여금(`contract_remaining_amount`)의 구분 관리. + * **실비/임시정산**: 계약 체결 전 긴급 요청 및 출하에 대응하는 `TemporarySettlement(임시정산)` 관리. + * **월마감**: `생산마감 -> 원가마감 -> 기성마감 -> 매출마감 -> 손익마감` 순으로 마감 이벤트를 체인 형태로 발생시키는 마감 통제 구조. + * **원가배분 Rule Engine(룰 엔진)**: 노무비, 자재비, 외주비 등의 원가를 배분 규칙에 따라 교량/형식별로 배분하는 규칙 엔진 설계. +* **ERP 개발 핵심 요구사항**: + * 도메인(생산, 원가, 기성, 회계)별로 독립된 State Machine(상태 머신)을 설계하고 상호 상태 전이 제약 조건을 적용해야 함. + * 마감 처리 완료 시 해당 기간의 데이터 수정을 원천 차단하고, 수정 필요 시 '재오픈 승인 프로세스'를 거치게 설계. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `ProgressClaim(기성청구)`, `TaxInvoice(세금계산서)`, `ClaimInvoiceMapping(매핑)`, `TemporarySettlement(임시정산)`, `ClosingPeriod(마감기간)` 등 상세 테이블 후보 명세. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 원가 배분 규칙 중 간접비 및 공통비 배분 시 사용할 구체적인 배분율 산출 공식이 명시되지 않아 배분 정밀도 수준에 대해 **확인 필요**. + +--- + +## 13. ERP신규개발 진행현황 검토문서_공장검토용_260515 +* **파일명**: `ERP신규개발 진행현황 검토문서_공장검토용_260515.pdf` +* **문서의 목적**: Phase 1 업무/DB 아키텍처 설계 단계에서 수집된 현업 비즈니스 프로세스 정의가 공장 실무와 일치하는지 1차 검토 및 확인. +* **주요 내용 요약**: + * 실행예산 -> 견적 -> 계약 -> 사업코드 -> 생산계획 -> 작업일보 -> 생산실적 -> 기성 -> 계산서 -> 수금 -> 손익분석에 이르는 전체 라이프사이클 정의 검증. + * 팀별(제작, 철근, 공무) 실적 및 원가 산정 기준 비교 정리. +* **ERP 개발 핵심 요구사항**: + * 기성과 계산서의 이원화 구조, 긴급 요청 시 실비 정산 및 추후 계약 합산 구조의 실무 정합성 확인. + * 외주 공정을 단순 비용이 아닌 하나의 생산 공정으로 취급하여 실적과 원가를 통합 관리함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **업무흐름**: 작업일보는 근태 및 노무비의 기준이 되고, 생산실적은 생산량의 기준이 됨을 명시하고 상호 연결. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 외주 공정을 생산실행 도메인 내부로 끌어올 때 외주사 작업자 계정 및 단말기 입력 권한 부여 범위에 대해 **확인 필요**. + +--- + +## 14. ERP신규개발 진행현황 검토문서_공장검토용_260518 +* **파일명**: `ERP신규개발 진행현황 검토문서_공장검토용_260518.pdf` +* **문서의 목적**: 260515 검토 문서에 대한 임원 및 현업 피드백을 수렴하여 최종 확정한 공장 검토용 보고서. +* **주요 내용 요약**: + * 15일자 보고서와 대부분 동일하나, 생산 손익(기성청구 기준)과 회계 매출(세금계산서 기준)의 명확한 이중 구조 분리 필요성을 재차 강조. + * 월마감 단계 및 순서(`생산 -> 원가 -> 기성 -> 매출 -> 손익`)의 적정성 최종 컨펌. +* **ERP 개발 핵심 요구사항**: + * 현업 및 임원진이 검토 완료한 비즈니스 룰을 그대로 물리 DB 및 기능 명세에 반영해야 함. +* **화면, DB, API, 업무흐름 관련 내용**: + * 15일자 대비 일부 용어가 Standard화되어 상세 설계 기준으로 넘어갈 수 있도록 확정됨. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 월말 마감 중 발주처와의 협의가 지연되어 기성 마감이 다음 달로 밀릴 경우, 당월 생산마감 데이터와의 원가-기성 미매칭 처리 방안에 대해 **확인 필요**. + +--- + +## 15. ERP신규개발_STEP25_개발자용_상세아키텍처_DB설계기준 +* **파일명**: `ERP신규개발_STEP25_개발자용_상세아키텍처_DB설계기준.pdf` +* **문서의 목적**: 아키텍처 설계 단계(STEP25)의 결과물을 물리 DB 설계 단계(STEP26)로 연계하기 위한 구체적인 Technical Architecture(기술 아키텍처) 명세서. +* **주요 내용 요약**: + * **4대 축 아키텍처**: Core Domain(핵심 업무), Operation Engine(워크플로우/결재/마감), Integration Platform(API/연동), Governance(권한/감사/백업). + * 상세 테이블 후보 카탈로그, 테이블 간 관계도, 공통 코드 리스트, API 명세 후보, 배치 작업 목록 제시. +* **ERP 개발 핵심 요구사항**: + * 상태 변경 시 State Transition 규칙 검증 의무화. + * AuditLog(감사로그) 및 ChangeHistory(변경이력) 테이블을 설계하여 CUD 발생 시 변경 전/후 스냅샷 강제 저장. + * 대시보드 조회 성능 최적화를 위한 배치 스냅샷 기법 권장. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `sec_member(사용자)`, `sec_role(역할)`, `prod_plan(생산계획)`, `acct_claim_invoice_map(기성계산서매핑)` 등 30여 개 테이블 명세 수록. + * **API**: 기성청구 생성(`POST /api/v1/claims`), 회계연동 요청(`POST /api/v1/integration/accounting/send`) 등 명세화. + * **배치**: 일일 KPI 집계(`BATCH_DAILY_KPI`), 마감 검증(`BATCH_CLOSING_CHECK`) 등 목록 정의. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * AuditLog(감사로그) 저장 시 스냅샷 데이터의 보관 주기 및 대용량 로그 데이터 파티셔닝 정책에 대해 **확인 필요**. + +--- + +## 16. ERP신규개발_개발방향 +* **파일명**: `ERP신규개발_개발방향.pdf` +* **문서의 목적**: 신규 ERP의 단계별 구축 로드맵 및 핵심 연동 모듈(회계 및 전자결재) 도입 전략 수립. +* **주요 내용 요약**: + * **추진 전략**: 1단계(공장 운영 ERP 구축 - 생산/출하/기성/원가), 2단계(ERP 확장 고도화 - 회계 연동 및 전자결재 통합), 3단계(자체 회계 시스템화 검토). + * **회계 전략**: 회계 전체의 자체 개발은 현실적으로 어려우므로, 1단계에서는 전표번호/증빙/정산 상태 등 '운영 회계' 기반만 설계하고 상용 ERP(더존 등)와의 연동 위주로 진행. + * **전자결재**: 그룹웨어 연동 대신 ERP 내부의 비즈니스 제어와 직결되므로 '자체 개발'을 채택. +* **ERP 개발 핵심 요구사항**: + * 전자결재 기능을 ERP 내부 핵심 모듈로 포함하여 승인 프로세스를 구축해야 함. + * 회계 전표 전송 실패를 방지하기 위해 비동기 Queue 기반의 Interface 연동 레이어를 선제적으로 설계해야 함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **업무흐름**: 기성 확정 -> 전자결재(자체) 승인 -> Integration Queue(연동큐) 적재 -> 외부 회계 ERP 전송. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 상용 회계 ERP의 도입 버전 및 제공되는 API 규격서 확보 여부에 대해 **확인 필요**. + +--- + +## 17. ERP신규개발_개발방향 (PPTX) +* **파일명**: `ERP신규개발_개발방향.pptx` +* **문서의 목적**: 의사결정 보고 및 프레젠테이션용으로 요약한 구축 추진전략 슬라이드. +* **주요 내용 요약**: + * PDF 보고서 버전의 추진전략(1단계: 운영 ERP 구축, 2단계: 연동 강화, 3단계: 장기 검토)을 도식화하여 시각적으로 설명. + * "냉정하게 판단하면 회계 전체 개발은 불가하다"는 현실적 한계를 짚고, 운영 데이터 정합성 확보를 우선 과제로 설정. +* **ERP 개발 핵심 요구사항**: + * PDF 버전과 동일함. +* **화면, DB, API, 업무흐름 관련 내용**: + * PDF 버전과 동일함. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * PDF 버전과 동일함. + +--- + +## 18. ERP신규개발_회계영역_상용회계ERP 연동방안 +* **파일명**: `ERP신규개발_회계영역_상용회계ERP 연동방안.pdf` +* **문서의 목적**: 자체 ERP와 외부 상용 회계 솔루션(더존 등) 간의 최적 연동 모델 검토 및 비교 분석. +* **주요 내용 요약**: + * **방안 1 (전표 수준 연동)**: 실시간 자동 분개 및 개별 전송. 실시간 결산 가능하나 API 개발 난이도 높음(추천). + * **방안 2 (일계/마감 연동)**: 일일 합산 또는 월간 마감 위주 전송. 개발 난이도 보통이나 실시간성 부족. + * **방안 3 (수동 엑셀 업로드)**: ERP에서 엑셀 추출 후 수동 업로드. 개발 비용 없으나 휴먼 에러 가능성 높음. +* **ERP 개발 핵심 요구사항**: + * 경영 대시보드에 실시간 재무 지표를 반영하기 위해 '방안 1 (전표 수준 연동)'을 지향하되, 이를 뒷받침할 Interface Queue(인터페이스 큐) 및 로깅 체계 설계 필요. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `IntegrationQueue(연동큐)`에 외부 전송 대상 전표 및 상태 기록. + * **업무흐름**: ERP 이벤트 발생 -> 자동 전표 분개 -> IntegrationQueue 적재 -> 배치 스케줄러가 외부 API 호출하여 전송. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 연동할 상용 ERP 측에서 실시간 API 전송 방식을 허용 및 지원하는지 기술적 제약조건에 대해 **확인 필요**. + +--- + +## 19. Phase1_STEP 20_23 (PPTX) +* **파일명**: `Phase1_STEP 20_23.pptx` +* **문서의 목적**: 기성, 원가배분, 마감, 손익 아키텍처 설계를 위한 도해식 상세 설계 자료. +* **주요 내용 요약**: + * **기성 확정 흐름**: 생산량 집계 -> 초안 생성 -> 기성 협의 -> 기성 확정 -> 계산서 발행. + * **원가배분 흐름**: 원가 귀속(프로젝트/교량/업무/형식/팀)과 배분 규칙(작업시간, 생산량, TON, 직접입력 등) 도식화. + * **마감 연동**: 도메인별 마감 상태값 전이 및 순차 마감 흐름 설명. +* **ERP 개발 핵심 요구사항**: + * 각 마감 단계별 선행 조건 체크 로직 구현 필요 (예: 생산마감 없이 원가마감 불가). +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: 상태 및 마감 정보를 담은 이력 관리 테이블 구성안 포함. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 마감 완료 후 데이터를 부득이하게 수정해야 할 경우, 마감 해제(Reopen) 권한을 가진 최종 승인권자 지정에 대해 **확인 필요**. + +--- + +## 20. Phase1_STEP 24___ (PPTX) +* **파일명**: `Phase1_STEP 24___.pptx` +* **문서의 목적**: ERP 신규개발을 위한 Logical DB Draft(논리 DB 초안) 및 기준정보 설계안 보고 자료. +* **주요 내용 요약**: + * ERP Foundation 계층 구조의 논리 데이터 모델링 제시. + * `Project(프로젝트) -> Bridge(교량)`를 잇는 마스터 테이블 간의 1:N 관계 및 속성 정리. +* **ERP 개발 핵심 요구사항**: + * 비즈니스 계층 구조의 최하단에 위치하는 형식(FormType)과 실무 품목(Item)의 분리 설계 원칙 적용. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `org_project(프로젝트)`, `org_bridge(교량)`, `org_bridge_alias(교량별칭)` 등의 논리 관계 매핑. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 프로젝트와 교량이 분리된 상태에서 계약 주체가 프로젝트가 아닌 개별 교량 단위로 체결될 때의 다중 계약 매핑 규칙에 대해 **확인 필요**. + +--- + +## 21. Phase1_STEP 24_1___24_6 (PPTX) +* **파일명**: `Phase1_STEP 24_1___24_6.pptx` +* **문서의 목적**: Logical DB Draft(논리 DB 초안)의 세부 도메인(기준정보, 조직, 역할, 승인, 마감) 모델링 상세 명세. +* **주요 내용 요약**: + * 조직(Company-Factory-Team) 모델과 사용자 권한(Role-Permission) 매핑 모델의 구체적인 컬럼 및 관계 정의. + * 결재 요청(`appr_request`)과 결재선(`appr_line`) 등의 릴레이션 상세 설계안 제시. +* **ERP 개발 핵심 요구사항**: + * 다차원 데이터 조회 범위 통제를 위한 `sec_permission` 테이블 설계 필수. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `org_company`, `org_factory`, `org_team`, `sec_member`, `sec_role`, `sec_permission`, `appr_request`, `appr_history` 등 스키마. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 퇴사자 또는 휴직자 발생 시 사용자 계정의 비활성화(status 변경)에 따른 결재선 대행 처리 정책에 대해 **확인 필요**. + +--- + +## 22. Phase1_STEP 25_1__25_14 (PPTX) +* **파일명**: `Phase1_STEP 25_1__25_14.pptx` +* **문서의 목적**: Technical Architecture(기술 아키텍처)의 전반부 설계 명세로, 인프라 및 핵심 엔진 구성 정의. +* **주요 내용 요약**: + * API Gateway 및 라우팅 설계, JWT 인증 발급 및 토큰 주기 관리 전략. + * Workflow State Machine(업무흐름 상태 머신)의 설계 구조 및 API 표준 응답 포맷(Standard Response) 수립. +* **ERP 개발 핵심 요구사항**: + * 모든 백엔드 API 서비스는 일관된 예외 처리 및 에러 코드 체계를 준수해야 함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **API**: API Gateway를 통한 요청 필터링 및 공통 권한 검증 모듈 설계. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * API 트래픽 폭주 시 레이트 리밋(Rate Limiting) 등 서버 보호 정책 수립 여부에 대해 **확인 필요**. + +--- + +## 23. Phase1_STEP 25_15__25_30_ (PPTX) +* **파일명**: `Phase1_STEP 25_15__25_30_.pptx` +* **문서의 목적**: Technical Architecture(기술 아키텍처)의 후반부 설계 명세로, 이벤트, 배치, 모니터링, 데이터 이관 전략 정의. +* **주요 내용 요약**: + * EventBus(이벤트버스) 기반 비동기 후속 처리 아키텍처 설계 (`evt_queue`, `subscriber`). + * 배치 아키텍처 및 대량 데이터 스냅샷 집계 방식 정의. + * 레거시 ERP 데이터 선별 이관(Migration) 및 데이터 정합성 검증 시나리오 수립. +* **ERP 개발 핵심 요구사항**: + * 배치 수행 실패 시 알림 및 자동 재시도(Retry) 메커니즘을 `batch_job_history` 기반으로 구현해야 함. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `evt_queue`, `int_queue`, `batch_job`, `monitoring_event` 등 시스템 통제 테이블 명세. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 레거시 데이터 이관 시, 과거 미결제 상태이거나 데이터 유실이 있는 건에 대한 보정 로직과 책임 한계에 대해 **확인 필요**. + +--- + +## 24. Phase1_Step5_원가구조분석_노무비 (PPTX) +* **파일명**: `Phase1_Step5_원가구조분석_노무비.pptx` +* **문서의 목적**: 작업일보와 노무비, 그리고 원가 배분 엔진 간의 밀접한 데이터 귀속 관계 분석 및 상세 설계. +* **주요 내용 요약**: + * **작업일보**: 근태가 아닌 노무비 귀속 및 원가 배분의 핵심 원천 데이터임. + * **노무비 귀속**: 작업일보에 기록된 시간(분)을 기준으로 교량/형식/업무에 시수를 집계하여 최종 노무비 분할 계산. + * **팀별 배분 규칙**: 철근팀(절단/가공/점접 등 TON 기준), 제작팀(생산량 및 작업시간 기준), 공무팀(지원작업 시수 기준)으로 차별화된 룰 적용. +* **ERP 개발 핵심 요구사항**: + * 작업일보에 입력되는 작업 시간(분)의 정밀성 검증 및 입력 누락 방지를 위한 검증 로직 구현. + * 각 팀의 작업 형태에 따라 적용할 배분 공식(Allocation Formula)을 가변적으로 설정할 수 있는 Rule Engine(룰 엔진) 테이블 설계. +* **화면, DB, API, 업무흐름 관련 내용**: + * **DB**: `DailyWorkDetail(작업일보상세)`, `Team(팀)`, `WorkType(업무)`, `FormType(형식)` 간의 복합 키 매핑 및 시수 집계. +* **모호하거나 추가 확인이 필요한 내용 (확인 필요)**: + * 작업자별 개별 단가(급여 정보)가 기밀 정보인 만큼, ERP 내 노무비 계산 시 이를 암호화하고 조회 권한을 제한하는 보안 규칙에 대해 **확인 필요**.