사용자 명시 요청 — 운영 DB 는 이미 모든 스키마/데이터 변경 반영됐고,
더 이상 자동 reload 가 필요 없음. 매 deploy 시 마이그레이션이 실행되며
사용자 변경(비밀번호, 부서, 추가 거래처 등) 을 원복하는 사고를 막기 위해
폴더 통째로 삭제.
- db/migrations/*.sql 35개 모두 삭제
- .gitea/workflows/deploy.yml 의 migrate-momo.mjs 호출 단계 제거
- scripts/migrate-momo.mjs 파일 자체는 유지
운영 DB 의 모든 user_info 비밀번호는 '1' 로 직접 reset 완료(142명).
운영 DB 직접 점검 후 발견:
- supply_mng.objid 는 numeric NOT NULL (TEXT 아님) → 'MOMOSUP000000001'
같은 문자열 INSERT 가 cast fail 로 80개 다 fail 하고 supply_mng = 0개
잔존 상태였음. 운영 DB 에는 직접 80개 박아둠 (objid 1..80).
- 035 마이그레이션도 동일 패턴(numeric objid)으로 재작성. 매 deploy 안전.
직전 deploy #137 (485aea4) 빌드 실패 원인:
- procurements/page.tsx 의 deleteProc 에서 setActiveId(null) → state 가
string 이라 타입 에러. setActiveId("") 로 수정.
직전 batch 가 운영 반영 후에도 supply_mng 가 10개로 유지된다는 사용자 신고.
원인 추정: 031/032/033 의 DO block 안에서 어딘가 fail → migrate-momo.mjs 가
process.exit(1) → 그 뒤 마이그레이션 (034, 035) 실행 자체 못 함.
→ 031/032/033 본문을 SELECT 1; 로 NO-OP 화. fail 지점 우회.
→ 035 가 단독으로 회원 135 + 공급업체 80 + 제조사 메뉴 삭제 모두 처리.
· DO block 없이 plain SQL 만 (각 statement 가 별도 transaction)
· supply_mng: 통째 DELETE 후 80개 plain INSERT
· user_info: user_type='U' DELETE 후 ON CONFLICT (user_id) UPSERT
· 매 deploy 안전 — UPSERT 라 중복 INSERT 도 OK
- 매입 발주서: OPEN 일 때 삭제 버튼 노출, 라인 포함 hard delete
· 신규 API /api/m/procurements/delete (status='OPEN' 만 허용)
- 매입 발주 editable: STATUS === 'OPEN' → STATUS not in (PAID, CANCELLED)
· lines/save API 가드도 동일 (PAID/CANCELLED 만 차단)
- 035_supply_mng_plain_reload.sql: 직전 DO block 마이그레이션이 어디서
fail 하는지 추적 불가 → 가장 단순한 plain SQL 로 supply_mng 다 비우고
엑셀 기준 80개 INSERT ON CONFLICT(supply_code) UPSERT
· momo_items/momo_procurements 의 vendor_objid 모두 NULL 처리
· UNIQUE INDEX 보장 후 INSERT — 매 deploy 안전
진짜 root cause — 019_proc_terms.sql 이 매 deploy 시
DELETE FROM supply_mng;
INSERT INTO supply_mng ... 10개 시드 (VND-001 ~ VND-010)
를 실행해서 supply_mng 가 항상 10개로 reset 되고 있었음.
→ 019 의 supply_mng 시드 부분 제거 (납품조건 ALTER 만 유지).
034 신설 — idempotent 매 deploy 안전 실행:
- product_lines 컬럼 보장
- supply_code UNIQUE 인덱스 보장 (ON CONFLICT 동작)
- 옛 'VND-*' 시드는 items/procurements 의 vendor_objid 끊은 후 DELETE
- 엑셀 80개 INSERT ON CONFLICT (supply_code) DO UPDATE
- sentinel 가드 없이 매번 안전 — 사용자 추가 supply (다른 supply_code) 는 보존
근본 원인:
- 008_makers_menu.sql: 매 deploy 시 제조사 관리 메뉴를 status='active' 로
되돌려놓아 사용자가 메뉴 삭제해도 다음 배포 때 부활.
- 023_seed_momo_vendors_from_xlsx.sql: 매 deploy 시 옛 100개 공급업체를
비-idempotent 한 INSERT 로 박아 supply_mng 가 영원히 옛 데이터로 원복.
→ 두 파일을 빈 NO-OP 으로 교체.
033_force_reload_v2.sql 신설 (sentinel 가드 momo_migration_marks 기반):
- 제조사 메뉴 menu_info objid=9000204 삭제
- momo_einvoice_items/einvoices/stock_moves(ORDER)/order_items/orders 통째
- user_info user_type='U' 다 삭제 후 momo001..momo135 ON CONFLICT UPSERT
· 본사팀 85 (HQ), 김포팀 50 (KIMPO), 카테고리별 default_wh 매핑, 비번 '1'
- supply_mng 다 삭제 후 80개 INSERT (엑셀 모모유통 제조사 리스트 26.05.12)
· product_lines 컬럼 ALTER (DO block 밖)
사용자 요청 — docs 의 엑셀 두 파일을 기준으로:
- 회원(user_info user_type='U') 전부 삭제 후 momo001..momo135 신규 등록
· 본사팀(85): 창고픽업 WH001 / 시장픽업 WH002 / 용차배송 WH003
· 김포팀(50): 김포지사 WH004 / 창고픽업 WH005 / 시장픽업 WH007 / 용차배송 WH006
· statement_branch: 본사='HQ' / 김포='KIMPO'
· 비번 '1' (AES 암호화)
- 공급업체(supply_mng) 전부 삭제 후 80개 신규 등록 (제조사 리스트 엑셀 기준)
· supply_mng 에 product_lines TEXT 컬럼 추가하여 제품명 보관
· items.vendor_objid 는 NULL 처리 (참조 무결성)
1회성 sentinel — momo_migration_marks 테이블로 가드. 신규 데이터가
다음 deploy 때 또 지워지는 사고 방지.
사용자 명시 요청 — supplier snapshot 이전의 옛 발주 데이터를 통째로
비우고 신규 발주만 운용. 사용자가 새로 등록하기로 함.
⚠️ migrate-momo.mjs 가 매 deploy 시 모든 .sql 을 재실행하므로 raw DELETE
를 그대로 박으면 신규 발주가 다음 deploy 때 또 지워지는 사고가 남.
→ sentinel 테이블 momo_migration_marks 도입, 1회만 실행되도록 가드.
삭제 범위:
- momo_einvoice_items (발주연결분)
- momo_einvoices WHERE order_objid IS NOT NULL
- momo_stock_moves WHERE ref_type='ORDER'
- momo_order_items 전체
- momo_orders 전체
보존: momo_stocks.qty — 사용자가 inventory 메뉴에서 직접 보정.
기존: 거래명세표 발급 때마다 user_info.statement_branch + branches table
을 실시간 조회 → 사용자의 기준 명세표를 바꾸거나, branches 의 계좌/
전화/이메일을 수정하면 과거 이미 찍힌 명세표까지 함께 바뀌어버림.
수정: 출고요청(REQUESTED) 시점에 supplier 8개 컬럼을 momo_orders 행에
박아두고, 이후 detail/statement/approve 는 이 snapshot 을 사용.
- 마이그레이션 030: momo_orders 에 supplier_branch / supplier_name /
supplier_ceo / supplier_bank_account / supplier_phone / supplier_email
/ supplier_biz_no / supplier_address 컬럼 추가 (idempotent IF NOT EXISTS)
- save: 발주 INSERT 시 getSupplierByBranch(user.statement_branch) 호출 결과
를 그대로 박음
- detail/statement/approve: snapshot 컬럼이 있으면 그것을 사용, 없으면
옛 발주용 폴백으로 user_info.statement_branch → branches table 조회
기존 5개 (objid/wh_code 그대로 유지 — 재고 이동·입출고 데이터 보존):
- WH001 본사창고 → 본사 창고 (HQ_STOCK)
- WH002 시장픽업 → 본사 시장 (HQ_MARKET)
- WH003 용차배송 → 본사 용차 (HQ_CHARTER)
- WH004 창고픽업팀 → 김포지사 (KIMPO_BRANCH)
- WH005 김포창고 → 김포 창고 (KIMPO_STOCK)
신규 2개 (idempotent INSERT):
- WH006 김포 용차 (KIMPO_CHARTER)
- WH007 김포 시장 (KIMPO_MARKET)
총 7개. 사용자 요청한 본사 3 + 김포 4 구성 정확히 맞춤.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
마이그레이션 028:
- momo_statement_branches 테이블 신설 (code PK / name / bank_account / phone / email 등)
- HQ, KIMPO 기본 시드 INSERT (사용자가 관리자 페이지에서 편집 가능)
- 메뉴: 시스템 그룹에 '기준 명세표 관리' (M_ASBR / menu_info 9000310)
라이브러리 (src/lib/momo-branches.ts):
- 하드코딩 → DB 조회로 변경 (60초 in-memory 캐시)
- getSupplierByBranch 가 async — detail/statement/approve API 도 await 추가
- 저장 시 invalidateBranchCache() 호출
페이지/API (관리자 전용):
- /m/admin/statement-branches : list + 등록/수정/삭제 모달
- POST /api/m/admin/statement-branches/list
- POST /api/m/admin/statement-branches/save (regist / update / delete)
사용자 수정 폼:
- "기준 거래명세서" select 옵션이 하드코딩 본사/김포 → DB 의 branches list 동적 fetch
창고 관리:
- WH_TYPE 카테고리 5개 → 7개 (옛 enum 도 라벨 매핑은 유지)
· HQ_STOCK 본사 창고
· HQ_CHARTER 본사 용차
· HQ_MARKET 본사 시장
· KIMPO_BRANCH 김포지사
· KIMPO_STOCK 김포 창고
· KIMPO_CHARTER 김포 용차
· KIMPO_MARKET 김포 시장
- 신규 추가 시 select 는 위 7개만 노출, 기존 데이터 (STOCK 등) 는 라벨로 자연 표시
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
마이그레이션 027:
- user_info 에 statement_branch VARCHAR(10) DEFAULT 'HQ' 컬럼 추가
- 기존 사용자 일괄 'HQ' 로 채움
라이브러리:
- src/lib/momo-branches.ts 신설 — HQ / KIMPO 두 branch 의 공급자 정보 정의
· HQ: 기업은행 434-115361-01-016 (이상용) / 010-6369-8443 / momo8443@daum.net
· KIMPO: 농협 351-1383-7634-13 (모모유통) / 010-5789-9431 / momokimpo@nate.com
- getSupplierByBranch(branch) helper
거래명세표 supplier 분기 (3개 API):
- /api/m/orders/detail: order.STATEMENT_BRANCH 따라 supplier 객체 결정
- /api/m/orders/statement/[id]: xlsx 다운로드도 동일
- /api/m/orders/approve: 메일 발송 stmt 도 동일
사용자 수정 폼:
- /api/admin/users/detail: statement_branch 반환 (default 'HQ')
- /api/admin/users/save: statement_branch 받아 UPDATE
- /admin-panel/user-form: "기준 거래명세서" select 추가 (본사/김포)
흐름: 거래처 사용자의 기준을 김포로 설정 → 그 사용자의 발주에 대한 거래명세표 supplier 가 김포 정보로 표시
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
지난 commit 의 026 이 ON CONFLICT(objid) 로 INSERT 시도 → menu_info 에 PK/unique 없어 PG 에러.
패턴: INSERT WHERE NOT EXISTS + 그 다음 별도 UPDATE WHERE objid=... 로 idempotent 처리.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1) 사이드바 메뉴 누락 fix (마이그레이션 026):
- FITO menu_info 테이블에 9000304 '매입 입금관리', 9000305 '재고이력' INSERT
- 기존 입고/재고 seq 재정렬 (11→12, 12→13)
- momo_menus 만으로는 사이드바에 안 나옴 — menu_info 가 사이드바의 진짜 소스
2) 재고이력 표시 개선:
- inventory/history API: REF_TYPE_LABEL (한글) + COUNTER_WH_NAME (이동 시 상대 창고) 추가
- inventory/transfer 라우트: stock_moves 의 ref_objid 에 상대 창고 objid 박음
- StockHistoryModal + history page: "INBOUND" → "입고", TRANSFER 시 "→ XX창고/← XX창고" 표시
3) 자동조회 (조회 버튼 없이 즉시):
- m/orders (내발주이력): 날짜 from~to + 상태 input 추가 + state dep useEffect
- m/orders/new (출고요청): "재고있는 품목만 / 전체 품목" 필터 추가 + 250ms 디바운스 자동 fetch
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1) 입고 처리 (m/admin/inbounds):
- 노출 대상: REQUESTED+PARTIAL → PAID+PARTIAL 로 변경 (입금 안 된 발주는 입고 불가)
- editable 조건 / STATUS 라벨/색상 PAID 추가
- 안내 문구 갱신
2) 재고이력 메뉴 (마이그레이션 025):
- M_AINVH '재고이력' 메뉴 매입 그룹 sort 34 에 INSERT (페이지는 기존 /m/admin/inventory/history 활용)
3) 재고관리 페이지 (m/admin/inventory):
- 데스크탑 표/모바일 카드 모두 행마다 "이력" 버튼 추가
- 클릭 시 StockHistoryModal 팝업 — 해당 품목 + 해당 창고 한정 이력 조회 (POST /api/m/inventory/history)
매입 흐름 완성: 매입발주(REQUESTED) → 입금관리(PAID) → 입고처리(RECEIVED)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
매입 흐름: 매입발주(REQUESTED) → 매입 입금관리(PAID) → 입고 처리(RECEIVED)
DB (마이그레이션 024):
- momo_procurements 에 paid_date, paid_amount, paid_method, paid_memo 컬럼 추가
- 매입 그룹 메뉴 sort 재정렬: 매입발주 30, 입금관리(신설) 31, 입고처리 32, 재고관리 33
- M_APROCPAY '매입 입금관리' /m/admin/proc-payments 메뉴 INSERT (ON CONFLICT idempotent)
UI/API:
- /m/admin/proc-payments 페이지 — 발주요청/입금완료 분리 카드 + 입금 처리 모달 (금액/방법/메모)
- 조회조건: 날짜 from~to + 공급업체 + 상태 (즉시 반영)
- POST /api/m/admin/proc-payments/list — REQUESTED|PAID 만 노출
- POST /api/m/admin/proc-payments/confirm — REQUESTED → PAID 전환 + paid_* 채움
다음 단계 (별도 batch): 입고 처리 페이지에서 PAID 만 노출 + 입고 시 RECEIVED 전환
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1) 삭제:
- src/app/(main)/m/admin/makers/page.tsx
- src/app/api/m/makers/{list,save,delete}/route.ts
(메뉴 DB 의 제조사 항목은 이전 commit 9705a04 에서 이미 제거됨)
2) 마이그레이션 023:
- docs/모모유통 제조사 리스트(26.05.12).xlsx 의 80개 업체를 supply_mng 에 일괄 등록
- idempotent: supply_name 중복 시 SKIP (NOT EXISTS)
- supply_code: MM-NNNN 자동 채번 (기존 max(objid) + ROW_NUMBER)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
[원인]
- db/migrations/009_items_user_permissions.sql 가 user_type<>'C' AND
NOT IN (admin 7인) 사용자를 삭제하는 정리 쿼리를 포함
- user_type 'C' → 'U' 통합 이후 'U' 거래처 134명이 위 조건에 걸려
매 배포마다 통째로 삭제됨 (어제·오늘 두 번 사용자 관리에 거래처 0명)
[수정]
- 해당 DELETE 블록 통째로 주석 처리 — 마이그레이션은 idempotent 해야 하고
destructive 작업은 두지 않는다는 원칙
- 거래처 134명은 별도 복구 스크립트로 다시 INSERT (이 commit 직후)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
운영 momo_warehouses.objid 가 text 타입(예: MOMOWH000000001)이라
default_wh_objid 도 text 로 일치시켜야 매핑 가능.
- db/migrations/022_user_default_wh_text.sql
- /api/admin/users/save: ::numeric 캐스트 제거
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
[DB 019]
- momo_procurements 에 delivery_place / delivery_period / payment_terms / freight_terms 컬럼 추가
- 기존 supply_mng (공급업체) 데이터 모두 삭제 + 샘플 10개 신규 등록
· (주)아바텍, 대성식품, (주)고기파는농부, 광이진천 농장, 단과일,
봉담수산, 명일동유기농, 울산단과일, 농부의아침, 초록마을 도매
- 시퀀스 가정 없이 MAX(objid)+1 로 안전하게 부여
[발주서 양식 — 표준 거래명세표 양식 반영]
- ProcurementForm: "2. 납품조건" 섹션 추가
· 1)~3) 표준 조항 (납기 지연 공제 / 검수 부적합 반출 / 수량 규격 변경)
· 4) 납품장소 5) 납품기간 6) 대금지불 7) 운임부담 — 표 형식 입력칸
· 8)~9) 표준 조항 (3일 이의 제기 효력 / 명시되지 않은 사항)
· 하단 "상기와 같이 발주함." + 발주일 + 발주자
- update-header API: 4개 필드 동적 업데이트
- /api/m/procurements/excel/[id]: 엑셀 출력에도 납품조건 9개 항목 + 4필드 표
- /api/m/procurements/send: 메일 본문 HTML 에도 납품조건 표 + 표준 조항
[관리자/사용자 모드 토글]
- 헤더 매뉴얼 옆에 [👥 사용자 / 🛡 관리자] 토글 버튼 (admin 권한자만 노출)
- menu-store: viewMode("user"|"admin") + setViewMode 추가
- 사이드바: viewMode 에 따라 대메뉴 필터링
· 사용자 모드: '거래처 주문' 그룹만
· 관리자 모드: 출고/정산 + 매입/입고 + 마스터 관리 + 통계
- admin 권한자 자동으로 로그인 시 관리자 모드 진입
[ItemPicker 모달 모바일 친화]
- 모바일에서 화면 하단 도킹(items-end) → 풀스크린 시트 처럼
- 헤더는 sticky top-0 으로 고정 → 긴 목록에서도 검색바 항상 보임
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
[새 통계 — 거래처×일자 매출 피벗]
- API: POST /api/m/statistics/monthly-pivot
· 입력: { year, month }
· 응답: dates[] / rows[ {거래처, BY_DAY:{날짜:{면세,과세}}, TOTAL_TAXFREE/TAXABLE} ] / totalsByDay / grandTotal
· 출고완료/입금완료/계산서발행 상태 발주만 집계
- 화면: /m/admin/statistics/pivot
· 가로 스크롤 피벗 표 (왼쪽 sticky 업체명)
· TOT 행: 월간 일자별 총합 (부가세 신고용)
· 거래처별 정렬: 매출 큰 순
· 합계 카드 3종: 면세/과세/총
· 엑셀 다운로드 (거래처 행 × 일자 컬럼 평면화)
- 메뉴 등록: 018 마이그레이션 (objid 9000504, 통계 그룹)
[세금계산서 중복 발행 차단]
- /api/m/einvoices/issue: orderObjid 가 이미 발행됨(FAIL/CANCELED 제외) 이면 400
· "이미 발행된 발주입니다 (상태/승인번호)" 메시지 + alreadyIssued=true 플래그
- /m/admin/einvoices: 발행 가능 발주 리스트에서 이미 발행된 건 자동 제외
· orders/list 와 einvoices/list 동시 조회 후 클라이언트 측 필터
· DRAFT/QUEUED/SENT/ACK 모두 발행 완료로 간주 — 재발행 불가
· FAIL/CANCELED 만 다시 발행 가능
[매뉴얼]
- 통계 표에 "거래처×일자 매출 (피벗)" 항목 추가, 부가세 신고 자료 활용 안내
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
[거래명세표 행 순서]
- 택배(DELIVERY)/용차(CHARTER) 라인이 품목(ITEM) 위로 표시되도록 정렬
- /api/m/orders/detail, /api/m/orders/statement/[id]: ORDER BY CASE kind 추가
- /m/admin/orders 화면 + xlsx 출력: 표시 순서 기준으로 SEQ 재부여 (DB seq 와 무관)
[메뉴 014]
- 마스터 관리 (9000200) → 마지막 (seq 900)
- 대시보드 (9000001) → 통계 그룹(9000500) 자식으로 이동, parent 변경
- 빈 [DASHBOARD] 대메뉴(1837127121) 비활성화
- 최종 순서: 거래처 주문 → 매입/입고 → 출고/정산 → 통계(대시보드 포함) → 마스터 관리
[로그인 랜딩]
- 기존: 모든 사용자 /m/dashboard
- 변경: 역할별 분기
· ADMIN/관리자 → /m/admin/orders (발주서 관리·출고처리)
· USER/거래처 → /m/orders/new (출고 요청)
- 회원가입 직후도 /m/orders/new 로
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
[정책]
- 발주/출고/입금 흐름과 분리된 별도 메뉴 (월말 일괄 또는 신고 시점 발행 가능)
- 출고 시 자동 발행은 향후 토글 옵션으로 추가
[DB 012]
- momo_einvoices: 발행 이력 (공급자/받는자/금액/승인번호/상태/원본XML)
- momo_einvoice_items: 라인별 상세
- 상태: DRAFT → QUEUED → SENT → ACK | FAIL | CANCELED
[발행 어댑터 추상화 (lib/einvoice)]
- InvoiceProvider 인터페이스 — issue/status/cancel
- adapters/manual.ts: 자체 거래명세서 (국세청 전송 X, 기본)
- adapters/nts-esero.ts: 국세청 e-세로 직접 연동 골격
· NTS_ESERO_MODE: stub | test | prod
· stub 모드는 DB 기록만 (개발/CI 안전)
· 실 통신은 사업자 공동인증서 + ERP 연계 승인 후 활성화
· SOAP/XMLDSig 페이로드 빌더 골격 작성, 인증서 받으면 서명+전송 추가
- index.ts: EINVOICE_PROVIDER 환경변수로 어댑터 선택
[API]
- POST /api/m/einvoices/list: 발행 이력 조회 + 필터 (관리자)
- POST /api/m/einvoices/issue: 발주(orderObjid)로부터 또는 수동 입력으로 발행
· 어댑터 결과를 momo_einvoices/_items 에 트랜잭션 기록 (성공/실패 모두)
[UI]
- /m/admin/einvoices 페이지 신설
· 발행 가능 발주 리스트 (출고/입금 완료된 건)
· 한 번 클릭으로 세금계산서 발행 → 결과 모달
· 발행 이력 (날짜/상태/승인번호 필터, 엑셀 다운로드)
· STUB 모드 안내 배너 — 운영 활성화 절차 명시
[문서]
- docs/MOMO_DISTRIBUTION_SPEC.md 부록 B (v0.6) 추가
다음 단계 (인증서 + ERP 연계 승인 후):
- nts-esero.ts 의 SOAP + XMLDSig 실제 구현
- NTS_ESERO_MODE=test 로 100건 검증
- NTS_ESERO_MODE=prod 전환
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
증상: 거래명세표에서 [+ 택배/용차 추가] 클릭 시
null value in column "item_objid" of relation "momo_order_items" violates not-null constraint
원인: 001_momo_init.sql 에서 item_objid 가 TEXT NOT NULL 로 정의됨.
택배/용차 라인(kind=DELIVERY/CHARTER)은 품목이 아니라 가상 부가 라인이라 NULL 이 정상.
해결: ALTER ... DROP NOT NULL. ITEM 라인은 어차피 코드 레벨에서 항상 값을 넣고 있어 무영향.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
사용자 명시적 운영 배포 승인 ('운영배포까지 진행 ... 될때까지 하라고').
- 로그인 후 redirectTo /dashboard → /m/dashboard 로 통일 (plm_admin 도 모모로)
- 세션 있으면 / · /login · /signup → /m/dashboard 리다이렉트 (middleware)
- /m/items 페이지를 /m/orders/new 로 redirect — 메뉴 통합
- 출고요청 카트를 상단 sticky bar 로 이동, 클릭 시 펼침 + 발주 버튼 항상 노출
- user_info 에 biz_no/ceo_name 컬럼 추가 (migration 006)
- signupMomoUser 가 biz_no/ceo_name 저장하도록 수정
- 메뉴: 9000101 품목 검색 비활성화 (출고요청과 통합으로 중복)
- admin-panel: 메뉴관리 섹션 idempotent 복구 (migration 006)
DB:
- [사용자] 그룹 아래에 5개 대메뉴 신규 (거래처 주문/마스터 관리/매입·입고/출고·정산/통계)
- 각 대메뉴 아래에 모모 페이지 소메뉴로 배치 (URL 직접 연결)
- 기존 [DASHBOARD] 대메뉴 활용 — 자식 [대시보드 → /m/dashboard] 추가, 기존 dashboard.do 비활성화
코드:
- /m/admin/users, /m/admin/roles, /m/admin/menus 페이지 삭제
- /api/m/users, /api/m/roles, /api/m/menus 삭제
- 모모 사이드바 [시스템] 그룹 제거 (기존 admin-panel 사용자/권한/메뉴 관리 활용)
→ plm_admin 로그인 후 [사용자] 그룹 펼치면 깔끔한 2단 트리 표시,
각 소메뉴 클릭 시 /m/* 페이지로 정상 이동
- src/app/(main), admin, admin-panel, common, api/{admin,common,menu} 복원
- /api/auth/login: FITO 인증 다시 활성화 (plm_admin 등 FITO 사용자 로그인 가능)
- 미들웨어: 옛 경로 강제 리다이렉트 제거
- /m/layout.tsx: FITO 슈퍼관리자(isAdmin)도 ADMIN 으로 받아 모모 페이지 진입 허용
- DB 005: menu_info 에 모모유통 루트(9000000) + 자식 19개(/m/* URL 직접 연결)
→ plm_admin 로그인 후 사이드바 [모모유통] 그룹에서 클릭 시 동작
→ 메뉴 관리 UI 에서 추가/수정/삭제 가능
기능:
- 매입처(vendor) 마스터 + API
- 매입 발주(procurement) 작성/목록/상세 + API
- 입고 처리(inbound): 매입발주 라인 자동 로드 또는 단독 입고
- 정상/불량 수량 분리 입력, 정상만 재고 +, 불량 사유 기록
- 출고 관리: 상태 라벨 변경 (REQUESTED→출고요청, APPROVED→출고완료, PAID→입금완료, INVOICED→계산서발행)
- 입금 관리 페이지 (부분/전액 입금 등록 → 완납 시 자동 PAID 전환)
- 계산서 일괄 발행 페이지 (체크박스 멀티 선택)
- 일자별 매출 통계 + 막대 그래프
- 원가/마진 통계 (월간 품목별, 마진율 표시)
- 사이드바 그룹 재구성 (마스터/매입/출고-정산/통계)
- 랜딩 페이지에 5단계 업무 흐름 다이어그램 추가
- DB v2 마이그레이션: 입고 헤더/라인 + 매입발주에 정상/불량 컬럼
CI/CD:
- secret-free webhook 자동 배포로 전환 (시크릿 등록 불필요)
- /api/deploy/webhook 엔드포인트가 X-Deploy-Token 검증 후 deploy.sh 실행
- docker-compose.prod.yml에 docker.sock + 소스 마운트 (자가 배포 가능)
- workflow는 단순히 webhook curl + 헬스체크 폴링
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- DB 연결: 211.115.91.141:11140/fito, postgres/intops0909!!
- 도메인: fito.wace.me
- 소스 교체 (woosung 기반)
- Dockerfile.dev 컴파일 단계 추가
- 로그인 페이지 DH Autoware 스타일 리디자인
- Constants: 회사명 (주)피토/fito, SYSTEM_TITLE FITO PLM
- 헤더 로고 FITO 로고로 변경
- 파비콘 추가
- 관리자 팝업 window.open 공백 이슈 수정
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
chpark