coreerp project

1. 프로젝트 개요 서비스 명: CoreERP 핵심 가치: 기업 운영의 핵심(Core)이 되는 구매, 자재, 재고 관리의 무결성 확보 배경: KIMPVIEW 프로젝트를 진행하며 느꼈던 ‘기초 설계의 중요성’을 바탕으로, 데이터의 생성부터 흐름까지 엄격하

1. 작성 목적 본 글은 CoreERP 프로젝트의 로그인·회원가입 화면을 포함한 전체 프론트엔드 구조를 기존 HTML 기반 정적 화면에서 React + TypeScript 기반 SPA 구조로 전환한 과정을 기록하기 위한 문서이다. 단순 기술 스택 변경이 아니라, 유지보수성·확장성·구조적 안정성을 확보하기 위한 설계 전환이라는 점을 중심으로 정리한다...

1. 작성 목적 본 기록은 CoreERP 프로젝트의 백엔드 개발을 시작하며 진행한 Spring Boot 기반 환경 구성 및 데이터베이스 연결 과정을 정리하기 위한 문서이다. 이 단계의 목표는 기능 구현이 아니라, 향후 도메인 설계를 안정적으로 진행하기 위한 백

1. 작성 목적 본 기록은 CoreERP 백엔드 환경 구성 이후, 실제 도메인 설계에 진입하기 전 수행한 계층 구조 정비 과정을 정리하기 위한 문서이다. 이 단계의 핵심은 기능 구현이 아니라, ERP 시스템으로 확장 가능한 구조를 먼저 고정하는 것이었다. 2. 불필요 코드 정리 Spring Boot 프로젝트 생성 직후에는 기본 테스트용 Con...

1. 작성 목적 본 기록은 CoreERP 백엔드 구조 정비 이후, 실제 ERP 시스템의 핵심이 되는 데이터 구조(ERD)를 확정한 과정을 정리하기 위한 문서이다. 이 단계의 목표는 기능 구현이 아니라, 데이터 무결성을 보장할 수 있는 도메인 구조를 먼저 고정하는

1. 작성 목적 본 기록은 CoreERP 프로젝트에서 재고 시스템의 핵심인 “조정(Adjustment)” 경로를 구현하며, 재고 스냅샷(Inventory)과 원장(StockTx)을 함께 운영하는 구조를 완성한 과정을 정리하기 위한 문서이다. 단순 CRUD가 아닌 ERP 관점의 데이터 무결성과 트랜잭션 흐름을 우선 기준으로 두었으며, 재고 변동이 발생하...

1. 이번 단계의 관점 이번 단계는 CoreERP가 단순 CRUD 프로젝트에서 벗어나 “재고가 변하는 구조”를 실제 ERP 형태로 고정한 구간이다. 특히 다음 두 가지를 명확히 확정했다. 재고 스냅샷(Inventory) + 원장(StockTx) 이중 구조 마스터 데이터(Warehouse) API 안정화 이 시점부터 재고는 단순 수치가 아니라, ...

이번 단계는 CoreERP에서 “업체(거래처, Vendor)”를 마스터 데이터로 확정하고, 프론트엔드(React)의 Vendor List 화면(모달 등록 방식)과 연결 가능한 백엔드 API 기준을 고정한 작업이다. ERP에서 입고(Inbound), 발주(Purchase Order), 정산/거래 이력 등 대부분의 업무 데이터는 거래처(Vendor)를 참...

이번 단계는 CoreERP에서 “입고 확정(Inbound Confirm)” 트랜잭션을 구현하며, 재고 증가가 발생하는 공식 경로를 완성한 작업이다. 이전 단계에서 Inventory(스냅샷)와 StockTx(원장)를 분리 설계하고, 재고 조정(ADJUST) API를 통해 재고 엔진의 기반을 만들었다. 이번 단계는 실제 업무 흐름에 해당하는 “입고 확정”...

이번 단계에서는 CoreERP 재고 시스템의 또 다른 핵심 축인 출고(Outbound Confirm) 로직을 구현하였다. 입고 확정을 통해 재고가 증가하는 경로를 완성했다면, 이번 단계에서는 재고가 감소하는 유일한 공식 경로를 완성하는 것이 목표였다. 1. 이번 단계의 목적 ERP 시스템에서 재고는 단순 숫자가 아니라, 트랜잭션 기반으로 움직이는 자산...

이번 단계는 재고 원장(StockTx)을 단순 기록 테이블이 아닌, 실제 운영 및 감사(Audit)에 활용 가능한 수준으로 고도화하였다. 1. 이번 단계의 핵심 목표 원장에 작업 직후 재고량(balance_after) 기록 작업자(created_by) 정보 추가 원장 이력 조회 API 구현 쓰기(StockService)와 읽기(StockTxQueryS...

오늘은 ERP에서 “재고가 움직이는 또 하나의 핵심 경로”인 창고 이동(Warehouse Transfer)을 확정(Confirm) 흐름으로 구현했다. 단순히 from 재고를 빼고 to 재고를 더하는 수준이 아니라, 재고 스냅샷(Inventory)과 원장(StockTx

이번 작업의 목표는 “업무 흐름이 연결된다”를 백엔드에서 증명하는 것이다. 단순히 발주를 저장하는 수준이 아니라, 입고 확정 시 발주 라인의 입고 누계(qty_received)가 갱신되고, 그 결과로 발주 상태(OPEN / PARTIAL_RECEIVED / RECEIVED)가 자동으로 바뀌는 흐름을 완성했다. 2. 완료 범위 Inbound 확정 A...

이번 단계는 “발주 기능만 놓고 봤을 때” 완성도를 끝까지 끌어올리는 데 집중했다. 단순 CRUD가 아니라, ERP에서 중요한 “상태 전이(OPEN → CANCELLED 등)”를 도메인 규칙으로 고정하고, 프론트(다른 페이지)에서 발주 데이터를 안전하게 사용할 수 있도록 API 형태와 응답 일관성을 정리했다. 1) 이전 단계 요약 CoreERP는 프...

이번 단계는 CoreERP가 단순한 프론트 목업 상태를 벗어나, 실제 Spring Boot 백엔드 API와 연결된 “동작하는 발주(Purchase Order) 모듈”로 전환되는 구간이었다. 이전까지는 더미 데이터로 UI 시나리오(필터/정렬/상태 변경)를 검증하는 수준이었다면, 이번 작업은 발주 생성(Create)부터 이력 조회, 상세 조회, 취소까지 ...

이번 단계는 CoreERP에서 “실제 재고가 변하는 순간”을 구현한 구간이다. Purchase Order(발주)는 계획 데이터이고, Inbound Confirm(입고 확정)은 실재고 반영 트리거다. 따라서 이 단계에서 중요한 건 단순 CRUD가 아니라, 입고

이번 단계는 CoreERP의 “입고” 기능을 실제 운영 흐름에 맞게 연결한 작업이었다. 입고등록 화면에서 입고 확정 API를 호출하고, 그 결과가 입고이력 화면에 즉시 반영되도록 데이터 흐름을 고정했다. 1. 이번 단계의 핵심 목적 프론트 “입고등록(입고확정)” → 백엔드 /api/inbounds/confirm 호출로 실제 입고 데이터 생성 입고 ...

1. 이전 단계 요약 구매(PurchaseOrder) → 입고(Inbound) 확정 흐름을 통해 재고 증가 로직과 원장(StockTx) 기록 구조를 먼저 완성했다. 이번 단계는 그 반대 축인 출고(Outbound)를 붙여 재고 사이클을 닫는 과정이다. 2. 이번 단계의 핵심 목적 출고는 단순히 outbound row를 저장하는 게 아니라, 재...

1. 이번 단계 목표 출고(Outbound) 이력 화면을 더미 데이터 기반에서 벗어나, Spring Boot API(/api/outbounds)와 직접 연결해 실데이터 기반으로 목록을 렌더링한다. 동시에 화면에서 요구하는 컬럼 순서를 고정하고, 발주 이력(Purch

1. 작업 목적 창고 관리 기능을 단순 마스터 CRUD 수준에서 끝내지 않고, 실제 재고 흐름과 연결된 창고 현황(Status)과 창고별 재고 상세(Inventory Detail) 조회 기능까지 확장했다. 핵심은 단순 조회가 아니라, Inventory가 존재하지 않는 창고도 정상적으로 표시되는 구조를 만드는 것이었다. 2. 창고 현황(Status)...

이번 단계에서는 Warehouse 영역의 프론트를 단일 화면이 아니라 이동 생성(TransferCreate) → 이동 이력(TransferHistory) → 창고 현황(Status) 까지 하나의 흐름으로 완성했다. 단순 UI 작업이 아니라, API 연동, 데이터

이번 단계에서는 Vendor(업체) 관리 기능을 프론트엔드(React + TypeScript)와 백엔드(Spring Boot) 전체 흐름으로 정리했다. 단순 CRUD가 아니라, 페이지네이션 · 정렬 · 옵션 필터 · 상태 배지 · 모달 상세보기까지 포함하여 실제 ERP에서 사용할 수 있는 수준의 구조로 다듬는 것을 목표로 했다. 1. 이번 단계의 핵심...

1. 이번 단계의 관점 이번 작업은 단순한 품목 조회 화면 구현이 아니라, CoreERP의 “데이터 조회 구조를 실무형으로 전환하는 단계”였다. 기존 List 기반 조회를 Page 기반 API로 변경하고, 프론트는 서버 정렬 및 필터와 완전히 연동되도록 구조를 고정했다. 이 단계의 핵심은 다음 두 가지다. 조회 API를 확장 가능한 구조로 ...

1. 이번 단계의 관점 CoreERP에서 Master Data는 모든 트랜잭션(발주/입고/출고/재고)의 출발점이다. 이번 단계는 단순히 “품목 등록 화면을 만든다”가 아니라, 실무형 기준으로 식별자 정책과 무결성 기준을 확정하고 프론트/백엔드를 동일한 규칙으로 묶는 작업이었다. 결론적으로 정책은 다음처럼 확정했다. 품번(Item Code): 수동 입력...

이번 단계는 “현재재고 페이지”를 프론트(React/TypeScript)에서 실제 API로 붙이고, 백엔드(Spring Boot/JPA)에서 페이징/정렬/필터/집계(가용재고/소요량/안전재고)를 한 화면에 내려주는 구조를 고정한 작업이다. 특히 재고는 ERP에서 가장 핵심 데이터라서, 단순 조회 화면이라도 “Inventory(스냅샷) + StockTx(원...

1. 이번 단계의 핵심 목적 이번 단계의 목표는 재고 화면에서 수량 해석이 혼동되지 않도록 기준을 고정하고, API/화면 구조를 안정화하는 것이었다. 특히 창고별 데이터가 섞여 보이면서 “현재고/안전재고” 의미가 헷갈리는 문제가 있었고, 이를 다음 기준으로 정리했다. 현재고 페이지: 품목 기준 합산(창고명 제외) - /api/stocks/curre...

이번 단계는 “장기 재고(오래 출고/입고가 없거나, 기준 기간 이상 경과한 재고)”를 관리하기 위한 조회 화면을 만들고, 필터/정렬/페이지네이션까지 Frontend(React) ↔ Backend(Spring Boot) ↔ DB(MariaDB) 흐름을 끝까지 연결하는 작업이다. 1) 전체 흐름 (Frontend ↔ Backend ↔ DB) Fron...

이번 단계에서는 CoreERP 프로젝트에 Dashboard 기능을 추가했다. 기존에는 품목, 창고, 재고, 발주, 입고, 출고 기능이 각각 독립적으로 동작하는 구조였다면, 이번 작업부터는 이 여러 데이터를 한 화면에 모아 현재 시스템 상태를 한 눈에 확인할 수 있도록 만드는 것이 핵심 목적이었다. 특히 ERP에서 Dashboard는 단순한 메인 화...

이번에 겪은 문제들은 단순 화면 버그가 아니라, ERP에서 가장 중요한 데이터 정합성과 집계 기준 문제들이 한 번에 섞여 있었던 케이스였다. 특히 출고 처리일시, 재고 원장(stocktx), inventory의 마지막 출고일, 안전재고 부족 집계, 대시보드 요약 기

이번 작업에서는 React Frontend 구조를 기존 pages 중심 구조에서 feature 기반 구조로 재정리했다. CoreERP 프로젝트가 커지면서 inventory, inbound, outbound, purchaseOrder 같은 기능 단위로 화면을 나누는 것이 유지보수 측면에서 훨씬 유리하다고 판단했기 때문이다. Spring Boot ...

이번 단계에서는 CoreERP 프로젝트에 인증 시스템을 붙였다. 기존에는 품목, 거래처, 창고, 발주, 입고, 출고 같은 ERP 내부 기능이 먼저 완성된 상태였고, 이제 그 기능들을 실제 사용자 기준으로 보호할 수 있도록 로그인, 회원가입, 권한 관리, 토큰 재발급 구조를 추가했다. 1. 이번 단계의 핵심 목표 Spring Security + J...

이번 단계에서는 CoreERP 프론트엔드에 인증 기능을 실제로 연결하고, 기존 ERP 화면 구조와 자연스럽게 통합하는 작업을 진행했다. 기존에는 Dashboard, Inventory, Purchase Order, Inbound, Outbound, Warehouse 같은 주요 업무 페이지가 먼저 구성되어 있었고, 이번 작업의 핵심은 여기에 로그인, 회원...

이번 작업에서는 CoreERP 프로젝트에 감사 로그(Audit Log) 기능을 추가했다. 이 기능의 목적은 ERP 내부에서 발생하는 주요 작업 이력을 남기고, 이후 관리자 화면에서 검색·조회할 수 있도록 만드는 것이다. 단순히 로그를 남기는 수준이 아니라, 누가 어떤 작업을 했는지, 어떤 대상에 대해 작업했는지, 언제 실행되었는지, 어떤 상세 데이터가...

이번 문제는 창고 수정 기능 자체의 오류가 아니라, 수정 과정에서 함께 저장되던 Audit Log 때문에 전체 요청이 실패한 케이스였다. 처음에는 Warehouse 수정 API 자체가 잘못된 줄 알았지만, 실제 원인은 감사 로그의 detailjson 저장 과정에 있었다. 1. 문제 상황 창고 수정 요청을 보내면 프론트에서는 아래와 같이 500 Inte...

Audit Log 조회 페이지에서 검색어 필터가 정상적으로 동작하지 않는 문제가 발생했다. 프론트엔드에서는 정상적으로 keyword 파라미터가 전달되고 있었고, DB에서도 동일한 SQL을 실행하면 결과가 정상적으로 조회되었다. 하지만 Spring Boot 서버에서는 검색 요청 시 예외가 발생하면서 조회가 실패하고 있었다. 서버 로그를 확인한 결과 ...

CoreERP를 개발하면서 가장 크게 느낀 점은, ERP는 단순히 CRUD를 많이 만드는 프로젝트가 아니라는 점이었다. 실제로는 발주, 입고, 출고, 재고 스냅샷, 재고 원장, 인증, 권한, 검색, 집계처럼 서로 다른 흐름이 하나의 데이터 체인으로 연결되어 있었다. 그래서 화면이 보인다고 끝나는 것이 아니라, 각 단계의 데이터가 서로 모순 없이 이어지...

오늘 작업은 CoreERP에서 단순 화면 수정이 아니라, 실제 ERP 운영에서 자주 발생하는 “출고 수량 오입력 정정” 상황을 시스템적으로 처리하는 흐름을 완성하는 단계였다. 기존에는 출고 등록은 가능했지만, 이미 등록된 출고 라인의 수량을 수정했을 때

이번 작업에서는 CoreERP 백엔드에 여러 관리 페이지의 CSV export 기능을 순차적으로 추가했다. 단순히 파일 다운로드 기능만 붙인 것이 아니라, 실제 프론트 테이블에서 사용자가 보고 있는 컬럼 순서와 다운로드되는 CSV 컬럼 순서를 일치시키는 방향으로

이번 작업은 CoreERP 프론트엔드에서 여러 조회 페이지에 CSV Export 기능을 공통 구조로 연결하는 작업이었다. 단순히 버튼 하나를 추가하는 수준이 아니라, 현재 페이지에서 사용 중인 검색 조건과 정렬 조건을 그대로 유지한 채 백엔드 export API와 연결되도록 프론트 구조를 정리한 것이 핵심이다. 이번 작업은 Frontend / Re...

이번 단계에서는 기존 DB 기반 Refresh Token 구조를 제거하고, Redis를 활용한 인증 구조로 전환하였다. 단순한 저장소 변경이 아니라, 인증 보안 수준을 한 단계 끌어올리는 작업이었다. 1. 기존 구조의 문제점 기존에는 Refresh Token을 DB에 저장하는 방식이었다. Refresh Token을 테이블에 저장 로그인 시 새...

이번 작업은 단순히 Spring Boot 프로젝트를 실행해보는 수준이 아니라, 실제 배포를 염두에 두고 백엔드 실행 환경을 컨테이너 기반으로 정리하는 과정이었다. 기존에는 로컬 IDE 환경에서만 애플리케이션이 동작하는 구조였다면, 이번에는 Docker를 이용해 Spring Boot 애플리케이션과 Redis를 함께 실행할 수 있도록 구성했고, 민감한 설정...

이번 작업은 단순히 Spring Boot 애플리케이션을 실행하는 수준이 아니라, 실제 운영 구조를 염두에 두고 CoreERP 백엔드를 AWS 환경으로 옮기는 과정이었다. 기존에는 로컬 환경에서 Docker 기반으로 Spring Boot, Redis, MariaDB를 함께 테스트하고 있었다면, 이번 단계에서는 Database를 RDS로 분리하고, Back...

이번 작업에서는 CoreERP 프로젝트를 로컬 개발 환경에서 벗어나 실제 외부에서 접속 가능한 서비스 구조로 올리는 작업을 진행했다. 기존에는 Spring Boot 백엔드와 React 프론트엔드를 각각 로컬에서 실행하며 기능을 검증했다면, 이번에는 백엔드는 AWS