배경/목적

해운업에서 선박명, 항구명, 업체명 등은 관례상 대문자(UPPER CASE)로 작성. 현재는 수동 입력이라 소문자가 섞여 들어가는 경우 많음.

상세 요구사항

1. 바이어/셀러 관리에서 저장(PUT/POST) 시 문자열 필드를 자동 대문자 변환
2. 예외 필드: 담당자명 (이름 원형 유지), 이메일 주소
3. 대문자 변환 대상: 선박명, 항구명, 업체명, 터미널명, 유종명, 메모/비고
4. 백엔드 API에서 변환 (저장 시점)

영향 범위

• 바이어 관리 — OrderController PUT/POST
• 셀러 관리 — SalesOrderController PUT/POST
• 정산 관리
• 이메일 시스템
• 업체 관리
• 회원 관리
• DB 스키마 변경
• 기존 API 수정

API 설계

참고

한글은 ToUpper() 해도 변화 없으므로 별도 처리 불필요. 이메일 판별: @ 포함 여부. 기존 데이터는 건드리지 않음.

배경/목적

아랍권(UAE 등) 거래 시 인보이스를 디르함(AED)으로 발행해야 함. 현재 USD만 지원. 체크박스로 AED 변환 발행 가능해야 함.

상세 요구사항

1. 인보이스/BDR 생성 화면에 "AED(디르함) 발행" 체크박스 추가
2. 기본값: 해제 (USD 기본)
3. 체크 시: USD → AED 환율 적용 변환 후 발행
4. 인보이스 PDF에 통화 단위 표시: USD → AED
5. AED 환율: 고정(3.6725) 또는 실시간 선택

영향 범위

• 바이어 관리
• 셀러 관리
• 문서/파일 — 인보이스 PDF 생성 로직
• DB 스키마 변경 — 환율 테이블 AED 추가
• 신규 API — AED 환율 조회
• 기존 API 수정 — 인보이스 생성 API에 currency 파라미터

API 설계

참고

USD/AED 고정환율: 1 USD = 3.6725 AED (UAE 페그제). 큰 변동 없음.

배경/목적

인보이스 은행 정보가 하나은행 고정. 홍콩이마린 거래 시 수동으로 IBK로 변경 중. 체크박스로 선택해야 함.

상세 요구사항

1. "IBK 계좌로 발행" 체크박스 추가 (기본: 하나은행)
2. IBK 정보: Account 054-160034-56-00011, Bank Industrial Bank of Korea, SWIFT IBKOKRSEXXX
3. 향후 은행 추가 가능하도록 BankAccount 테이블 신설

영향 범위

• 문서/파일 — 인보이스 PDF 은행 정보 동적 변경
• DB 스키마 변경 — BankAccount 테이블 신설
• 기존 API 수정 — bankAccountId 파라미터 추가

DB 변경

초기 데이터

배경/목적

메일 발송 시 수신자/참조 이메일을 수동 입력 중. 주문업체명+선박명으로 검색하여 이메일을 자동으로 가져오고 업체/회원 정보에 반영해야 함.

현재 이메일 DB 구조

상세 요구사항

1. 메일 발송 화면에서 주문업체명+선박명 기준으로 이메일 이력 자동 조회
2. 조회된 이메일을 To, CC에 자동 채움
3. 새 이메일 발견 시 업체/회원 정보에 업데이트
4. 벙커 아카이브 연동: 방식 확인 필요 (API? DB? 크롤링?)

영향 범위

• 바이어 관리
• 셀러 관리
• 이메일 시스템
• 업체 관리
• 회원 관리
• DB 스키마 변경
• 신규 API
• 기존 API 수정

참고

1차: 내부 이메일 이력(EmailRelatedToOrder)에서 추출. 2차: 벙커 아카이브 외부 연동.

배경/목적

지급기한(PayDueDate)이 언제인지 한눈에 파악하기 어려움. 태그 형태로 날짜를 표시하고 기한 임박 시 색상 경고 필요.

색상 규칙

영향 범위

• 바이어 관리 — OrderList.razor 태그 추가
• 셀러 관리 — SalesOrderList.razor 태그 추가

참고

결제 완료된 건(PayCompleteDate 있으면)은 태그 표시 안 함. SngPayDueTag.razor 컴포넌트 신규 생성.

코드 분석 결과

현재 검색 로직 (OrdersController.cs:428):

Ship.ShipName.Contains(bargeShipName)  // = SQL %LIKE%

배경/목적

인쿼리 텍스트를 보고 수동으로 바이어/셀러 주문을 등록 중. 자동 파싱하여 주문을 자동 생성해야 함.

처리 순서

1. 텍스트 입력 (붙여넣기)
2. 파싱 → 구조화된 데이터로 변환
3. DB 매칭 (업체관리/회원관리에 있는 것만)
4. 미리보기 표시 (매칭 결과 + 미매칭 하이라이트)
5. 사용자 확인/수정
6. 바이어 주문 생성 (POST /api/order/OrderForAdmin)
7. 셀러 주문 생성 (POST /api/Sales/Order/AddExclusiveReg) — 바이어 OrderInfoId 연결

기본 스펙 매핑 (스펙 미명시 시 2010 기준 자동 적용)

업체명 매핑 (한국어 약칭 → 영문)

매핑에 없으면 아래 매칭 로직으로 처리

업체명 매칭 우선순위

1순위: 한국어 매핑 테이블 (홍콩이마린 → 정확 매칭)
2순위: 영문 입력 시 앞 5~10글자 + 뒤 5~10글자로 DB 2중 확인
       예: "HONGKONG E-MARINE SUPPLY SERVICE CORP., LTD."
       → 앞: "HONGKONG E-" → DB StartsWith 매칭
       → 뒤: "CORP., LTD." → DB EndsWith 매칭
       → 둘 다 일치하면 확정
3순위: 못 찾으면 → 미리보기에서 드롭다운 수동 선택

배경/목적

바이어/셀러 관리 화면에서 요청사항(RequestMemo) 입력 시 고정 높이에 스크롤이 생김. 입력한 만큼 영역이 자동으로 늘어나야 내용 전체가 한눈에 보임.

상세 요구사항

1. 요청사항 텍스트 입력 영역을 내용에 따라 자동 확장으로 변경
2. 스크롤 없이 입력한 텍스트 전체가 보여야 함
3. 최소 높이는 현재와 동일 유지
4. OrderList.razor, SalesOrderList.razor 양쪽 모두 적용

영향 범위

• 바이어 관리 — OrderList.razor
• 셀러 관리 — SalesOrderList.razor

참고

프론트만 수정, 백엔드 변경 없음. MudBlazor AutoGrow 또는 CSS/JS auto-resize 활용.

배경/목적

일부 검색 필드가 정확 일치(==)로 되어있어 부분 검색이 안 됨. 텍스트 검색은 모두 Contains()(%LIKE%)로 동작해야 함.

코드 분석 결과

수정 대상

영향 범위

• 바이어 관리 — OrdersController 검색 쿼리
• 셀러 관리 — SalesOrdersController 검색 쿼리
• 기존 API 수정

참고

NEW-006(바지선명 검색)과 같이 진행하면 효율적. 규칙: 텍스트 입력 → Contains, 드롭다운 선택 → 정확 일치.

배경/목적

인보이스 발행 시 선박명을 포함하지 않아야 하는 경우가 있음. 기존 AED/IBK 체크박스와 동일한 패턴으로 "선박명 제거" 옵션 추가.

상세 요구사항

1. 인보이스(INVOICE) 서류 발행 영역에 "선박명 제거" 체크박스 추가
2. 체크 시 인보이스 PDF에서 선박명(ShipName)이 빈 값으로 생성
3. AED, IBK 체크박스와 조합 가능 (3개 독립 동작)
4. 발행 완료 후 체크박스 자동 초기화

수정 파일

배경/목적

BDR, 인보이스 등 서류 PDF/이미지에서 특정 내용(업체명, 선박명 등)을 지워서 수정본을 만들어야 하는 경우가 있음. 외부 편집 도구 없이 인트라넷 내에서 바로 편집 가능해야 함.

상세 요구사항

1. 서류관리 → 서류보기에서 각 파일 옆에 편집 아이콘 표시
2. 클릭 시 이미지 편집 모달 열림
3. 파일 로드: 📂 파일 선택 버튼으로 로컬 PDF/이미지 직접 로드
4. 멀티페이지 PDF 지원: 전체 페이지를 세로로 이어붙여 표시, 페이지 구분선 + 번호
5. 두 가지 편집 모드:
     • 브러시 모드: 원형 브러시로 자유롭게 칠하기 (크기 조절 슬라이더)
     • 사각형 모드: 드래그로 사각형 영역 선택
6. 편집 중에는 빨간 하이라이트로 표시만 — 실제 지우기는 저장 시 적용
7. 지우기 알고리즘: 각 마스크 픽셀마다 주변 배경 픽셀 30개 평균으로 채움 (글자 건너뜀, 워터마크 상쇄)
8. 색상지정 모드: 이미지에서 클릭하여 3×3 평균색 추출 → 해당 색으로 고정 채움
9. 되돌리기/초기화: 스트로크 단위 Undo (최대 30회), 전체 초기화
10. 저장: 원본 유지 + 편집본을 새 파일로 추가 (PDF→PDF, 이미지→이미지)
11. 파일명 규칙: 원본명 + E (예: _BDR_20260326A9PPE.pdf), 중복 시 E2, E3...
12. 바이어 관리(OrderList), 셀러 관리(SalesOrderList) 양쪽 모두 적용

영향 범위

• 바이어 관리 — OrderList.razor 편집 모달/로직 추가
• 셀러 관리 — SalesOrderList.razor 동일 적용
• 정산 관리
• 이메일 시스템
• 업체 관리
• 회원 관리
• 견적(RFQ)
• 문서/파일 — 편집된 파일 저장, ImageLink 신규 생성
• DB 스키마 변경
• 신규 API 필요 — ImageEditController (Save)
• 기존 API 수정

API 설계

신규 파일

수정 파일

사용 라이브러리

참고사항

PDF 렌더링은 클라이언트(pdf.js)에서 처리, 서버 의존 없음. 편집은 Canvas 위 마스크 방식 (원본 변경 없이 표시만). 저장 시에만 마스크 영역을 배경색으로 채워서 최종 이미지 생성. 고정색 모드는 워터마크가 심한 문서에서 유용.

배경/목적

현재 입금 확인을 수동으로 하고 있음. 은행 API로 입금 여부를 자동 확인하고, 지급기한일 기준으로 바이어에게 페이먼트 리마인더 메일을 자동 발송하여 업무 효율화.

Part A — 입금 자동 확인

1. 은행 API 연동하여 입금 내역 자동 조회 (은행사 추후 결정)
2. 입금 확인되면 해당 주문의 PayCompleteDate (지급완료일) 자동 업데이트
3. 주문 상태를 "정산완료"로 자동 변경
4. 변경 이력에 "입금 확인 (자동)" 로그 기록
5. 백그라운드 서비스로 주기적 조회 (예: 30분마다)

Part B — 페이먼트 리마인더 (바이어 대상)

1. 지급기한일 2일 전 — 첫 번째 리마인더 메일 발송
2. 지급기한일 1일 전 — 두 번째 리마인더 메일 발송
3. 지급기한일 당일 — 세 번째 리마인더 메일 발송
4. 지급기한일 지남 (미입금) — 연체 알림 메일 발송
5. 이미 입금 완료된 주문은 리마인더 발송 안 함
6. 리마인더 발송 이력을 OrderLog에 기록
7. 기존 OutboundMailer 사용
8. 백그라운드 서비스로 매일 오전 9시 자동 체크

영향 범위

• 바이어 관리 — 입금 상태 자동 업데이트
• 셀러 관리
• 정산 관리 — 지급완료일 자동 세팅
• 이메일 시스템 — 리마인더 메일 템플릿 신규
• 업체 관리
• 회원 관리
• DB 스키마 변경
• 신규 API 필요 — 은행 연동 + 리마인더 상태 조회
• 기존 API 수정 — OrderSettlement 자동 업데이트

API 설계

메일 템플릿

참고사항

은행사 결정 후 API 연동 방식 확정. Part B(리마인더)는 은행 API 없이도 독립 구현 가능 — 지급기한일과 PayCompleteDate만 비교하면 됨.

배경/목적

바이어 관리 화면에서 라디오버튼 정렬 미흡, IMO 미표시, 필수 입력 필드 구분 부재 등으로 휴먼에러 발생 가능성 높음. UI/UX 차원에서 체계적으로 개선.

상세 요구사항

필수필드 빨간 테두리 대상 (바이어 관리만)

영향 범위

• 바이어 관리 — OrderList.razor (라디오 정렬 + IMO + 빨간 테두리)
• 셀러 관리 — 적용 안 함
• 백엔드 변경 없음

주요 수정 파일

배경/목적

톤당 수수료(브로커리지) 거래를 일반 거래와 구분해서 관리해야 함. 태그로 시각 구분 + 필터로 브로커리지 건만 조회 가능해야 함.

상세 요구사항

1. 브로커리지 체크박스 추가: BUNKER ONLY 체크박스 바로 아래에 "BROKERAGE" 체크박스 추가
2. 태그 표시: 기존 태그 영역(M/B, B/O, N/I)에 B/K : Brokerage 추가
   • 태그 디자인: 다른 태그와 차별화된 독특한 스타일 (그라데이션 or 골드 계열)
3. 브로커리지 필터 버튼: 태그 헤더 위에 "브로커리지" 필터 버튼 추가
   • 클릭 시 브로커리지 태그가 있는 주문만 필터링
   • 다시 클릭 시 필터 해제 (토글)
4. 태그 정보 팝오버 업데이트: 기존 M/B, B/O, N/I에 B/K 설명 추가

태그 디자인

영향 범위

• 바이어 관리 — OrderList.razor (체크박스 + 태그 + 필터 버튼)
• 셀러 관리 — SalesOrderList.razor (태그 표시 + 필터)
• 기존 API 수정 — 브로커리지 플래그 저장/조회
• DB — OrderInfo에 IsBrokerage 필드 추가 (bit)

DB 변경

주요 수정 파일

참고

브로커리지 태그는 골드 그라데이션으로 다른 태그와 시각적 차별화. 필터 버튼은 활성화 시 골드 배경으로 토글 표시.

배경/목적

구매관리 주문 상세의 추가비용(AddPay) 항목에 현재 BARGE CHARGE만 있음. 실무에서 자주 사용하는 DEMURRAGE(정박료)와 AGENT FEE(에이전트 수수료)를 추가비용 드롭다운에 추가해야 함.

상세 요구사항

1. 추가비용 항목(Item) 드롭다운에 DEMURRAGE 옵션 추가
2. 추가비용 항목(Item) 드롭다운에 AGENT FEE 옵션 추가
3. 기존 BARGE CHARGE, ETC 와 동일한 구조로 매출/매입 구분 가능
4. 인쿼리 파싱 및 외부 API에서도 해당 항목 지원

영향 범위

• 바이어 관리 — 추가비용 등록 UI
• 셀러 관리
• 정산 관리
• 이메일 시스템
• DB 스키마 변경
• 신규 API 필요
• 기존 API 수정 — AddPay 항목 유효성

현재 추가비용 항목

배경/목적

현재 메일 발송 시 "송신 요청 성공"만 표시되고, 실제로 메일이 도착했는지/실패했는지 확인할 수 없음. 본서버에서 메일이 안 보내지는 경우가 종종 발생. 메일 발송 상태를 콜백으로 받아서 UI에 반영해야 함.

현재 문제점

1. 메일 발송 API 호출 → "송신 요청 성공" 표시 → 실제 발송 여부 불명
2. 발송 실패 시 사용자에게 알림 없음
3. 발송 중/성공/실패 상태를 구분할 수 없음
4. 본서버에서 간헐적으로 메일 발송 실패 발생

상세 요구사항

1. 발송 상태 콜백: 메일 서비스(NAVER Outbound Mail)에서 발송 결과 콜백 수신
2. 상태 구분:
   • PENDING — 발송 요청됨 (대기 중)
   • SENDING — 발송 중
   • SUCCESS — 발송 완료 (수신자 도달)
   • FAILED — 발송 실패
   • BOUNCED — 반송됨 (주소 오류 등)
3. UI 반영: 발송 이력 목록에 상태 컬럼 추가 (색상 뱃지로 표시)
4. 실패 알림: 발송 실패 시 관리자에게 알림 (웹 알림 또는 재발송 버튼)
5. 재발송: 실패한 메일을 1클릭으로 재발송할 수 있는 기능
6. 자동 재시도: 발송 실패 시 자동 재시도 (최대 3회, 5분 간격)

영향 범위

• 바이어 관리 — 발송 이력 UI
• 셀러 관리 — 발송 이력 UI
• 정산 관리
• 이메일 시스템 — 콜백 수신 + 상태 저장 + 재시도
• 업체 관리
• DB 스키마 변경 — OutboundMail 상태 필드 확장
• 신규 API 필요 — 콜백 수신 엔드포인트
• 기존 API 수정 — 발송 이력 조회에 상태 포함

발송 상태 UI 예시

참고사항

NAVER Outbound Mail API에서 콜백 지원 여부 확인 필요. 콜백 미지원 시 폴링(주기적 상태 조회) 방식으로 대체 가능.

배경/목적

동림 인보이스 등에서 환율을 수동으로 확인하고 있음. 기존 환율 API가 이미 연동되어 있으므로, 날짜를 선택하면 해당 날짜의 환율을 바로 조회할 수 있는 UI를 추가. 로그아웃 버튼 왼쪽에 배치.

상세 요구사항

1. 상단 네비게이션 바의 로그아웃 버튼 왼쪽에 환율 조회 영역 배치
2. 날짜 선택 (DatePicker) + 환율 표시 영역
3. 날짜 선택 시 해당 날짜의 USD/KRW 환율을 API에서 자동 조회
4. 기본값: 오늘 날짜의 환율
5. 기존 ExchangeRateService / ExchangeRateController 활용
6. 환율 데이터가 없는 날짜 (주말/공휴일)는 가장 가까운 영업일 환율 표시

UI 배치

[바이어 관리] [셀러 관리] [정산관리] [업체관리] [회원관리]    📅 2026-04-10  💰 1,382.50원/USD   [로그아웃]

영향 범위

• 바이어 관리 — 상단 네비게이션
• 셀러 관리 — 상단 네비게이션 (공통 레이아웃)
• 정산 관리
• 이메일 시스템
• 업체 관리
• DB 스키마 변경
• 신규 API 필요
• 기존 API 수정

기존 환율 인프라

참고사항

환율 표시 UI는 공통 레이아웃(SngNavMenu.razor)에 추가하면 모든 페이지에서 보임. 동림 인보이스 발행 시 해당 환율을 자동으로 적용하는 기능은 추후 확장 가능.

배경/목적

외부 시스템에서 인쿼리 텍스트를 API로 전송하면, 웹에서 인쿼리 파싱 → 주문 등록하는 것과 동일하게 바이어 주문 + 셀러 주문이 자동 생성됩니다. 수작업 없이 시스템 간 자동 연동이 가능합니다.

상세 요구사항

1. API Key 인증: 헤더 X-Api-Key로 인증. DB ExternalApi 테이블에서 키 관리
2. 인쿼리 텍스트 파싱: 기존 InquiryTextParser와 동일한 파싱 엔진 사용
3. 자동 주문 생성: 웹 인쿼리 파싱과 동일한 4단계 흐름 (POST 생성 → GET 조회 → PUT 셀러 정보 수정 → 셀러 지급기한 업데이트)
4. 동시 호출 제어: SemaphoreSlim(1,1)로 동시 1개만 처리 → 주문번호 정합성 보장
5. 자동 생성 항목: 바이어 주문, 셀러 주문, 유종/가격, 추가비용(BARGE CHARGE), 지급기한(DDD+공휴일), 에이전트, 선박(미등록 시 자동 생성)

API 설계

인증 방식

신규 파일

수정 파일

DB 변경

요청/응답 예시

// 요청
POST /api/ExternalInquiry/Create
X-Api-Key: sk-sngy-8f2a4c6e9b1d3f5a7c0e2b4d
{"text":"VESSEL NAME: DIAMOND SEA\nIMO : 9112233\n..."}

// 응답 (성공)
{
  "code": 200,
  "message": "주문 생성 완료",
  "data": {
    "orderId": "20260331WMQG",
    "vesselName": "DIAMOND SEA",
    "buyerCompany": "홍콩이마린",
    "sellerCompany": "동림",
    "buyerPayDueDate": "2026-04-13",
    "sellerPayDueDate": "2026-03-23"
  }
}