대리점별 영업 현황을 한눈에 보는 플랫폼 개발하기

핵심 요약

1. 대리점의 견적·협의·발주 기록을 연결해 본사가 영업 진행 상황을 확인하도록 만듭니다. 2. Next.js로 입력을 처리하고 PostgreSQL의 행 단위 보안과 트랜잭션으로 정보 접근과 저장을 관리합니다. 3. 고객 조회 범위, 중복 거래처 통합 승인, 월별 실적 확정 규칙은 업무에 맞게 직접 개발합니다.

본사·대리점용 플랫폼 개발과 CRM 개발에서는 같은 거래를 이어서 확인하는 기능이 필요합니다. 동시에 대리점마다 볼 수 있는 고객 정보와 본사가 집계할 범위를 구분해야 합니다. 아래는 이 업무를 구현할 때 필요한 화면과 자체 개발 규칙입니다.

Next.js로 견적·협의·발주 입력 연결하기

대리점 담당자는 고객, 품목, 견적 금액, 예상 발주일을 입력하고 ‘견적 저장’을 누릅니다. Next.js는 폼 입력값을 묶은 FormData를 서버 함수에서 받아 처리할 수 있습니다. 로그인 확인과 필수 항목 검사, 금액 입력 기준은 별도로 구현합니다.

준비할 첫 자료는 견적번호·대리점·고객·금액·진행 단계가 들어 있는 기존 견적 관리표입니다. 이를 바탕으로 ‘협의로 변경’과 ‘발주 등록’ 버튼의 필수 입력값을 정하고, 같은 영업 건에 변경 이력을 연결합니다. 검수에서는 발주 등록에 필요한 항목이 비어 있으면 저장을 막는지, 목록과 상세 화면의 단계가 일치하는지 확인합니다.

PostgreSQL RLS로 대리점별 고객 조회 제한하기

준비할 두 번째 자료는 사용자·소속 회사·대리점·고객 조회 범위·본사 집계 권한을 정리한 권한표입니다. PostgreSQL RLS는 행 단위 보안 정책으로 사용자별 조회·추가·수정·삭제 대상 행을 제한할 수 있습니다. 로그인한 계정의 소속과 권한을 데이터 접근 조건에 연결하는 정책은 직접 작성하고 적용 계정도 검증합니다.

대리점에는 허용된 고객만 표시하고, 본사에는 자기 회사에 속한 대리점의 집계만 보여줍니다. 회사 구분과 대리점 구분을 함께 확인하도록 상세 조회와 내려받기에도 같은 접근 규칙을 적용합니다. 실패 사례 검수는 A 대리점 계정으로 B 대리점의 견적 주소를 직접 열어 보는 방식이며, 접근이 거절되고 고객명과 금액도 노출되지 않아야 합니다.

중복 거래처 후보와 통합 승인 화면 만들기

같은 고객이 여러 대리점에 등록돼도 이름만 같다는 이유로 합치면 서로 다른 거래가 섞일 수 있습니다. 입력된 사업자등록번호와 고객명을 비교해 중복 후보를 찾고, 본사의 권한 있는 담당자에게 확인 목록을 보여주는 로직이 필요합니다. 후보를 찾는 규칙과 승인 절차는 직접 개발할 업무 기능입니다.

‘통합 검토’ 화면에는 거래처별 담당 대리점과 연결된 견적을 표시하고, 대표 거래처를 선택한 뒤 승인하도록 만듭니다. 통합 대상은 같은 회사의 관리 범위 안으로 제한하며, 고객을 통합해도 기존 견적의 담당 대리점과 조회 권한은 유지하도록 처리합니다. 검수 기준은 고객명이 같아도 식별 정보가 다르면 자동 통합되지 않고, 승인 후에도 다른 대리점의 거래 내역이 새로 노출되지 않는 것입니다.

본사 화면에서 진행 현황과 확정 실적 나누기

본사 대시보드는 견적·협의·발주 단계별 건수와 금액을 보여주고, 월별 확정 실적은 별도 영역에 표시합니다. 발주 등록을 곧바로 실적 확정으로 처리하면 아직 검토가 끝나지 않은 거래가 보고서에 포함될 수 있습니다. 집계 기능에는 진행 단계와 실적 확정 여부를 각각 판단하는 자체 계산 규칙이 필요합니다.

담당자가 대상 월과 거래를 선택하고 ‘실적 확정 요청’을 누르면 본사 승인 대상에 올라가도록 만듭니다. 실적에 사용할 금액과 귀속 월의 기준을 먼저 정하고, 승인된 거래만 월별 보고서에 반영합니다. 검수에서는 대리점별 확정 내역의 합계가 본사 합계와 맞는지, 발주 단계에 머문 미확정 거래가 확정 실적에서 빠지는지 확인합니다.

트랜잭션으로 실적 확정과 마감 기록 함께 저장하기

본사가 ‘확정 승인’을 누르면 거래의 확정 표시와 월별 실적 기록을 함께 저장해야 합니다. PostgreSQL 트랜잭션은 여러 데이터 변경을 모두 반영하거나 모두 취소하지만 외부 API 작업까지 함께 취소하지는 않습니다. 어떤 변경을 한 번의 저장으로 묶을지와 같은 거래의 중복 확정을 막는 조건은 직접 구현합니다.

마감한 달의 거래는 일반 수정 대신 정정 요청을 거치게 하고, 수정 이유와 승인 기록을 남기도록 만듭니다. 검수에서는 저장 도중 오류가 나면 확정 표시와 실적 기록이 함께 취소되는지, 승인 버튼을 두 번 눌러도 실적이 중복 집계되지 않는지 확인합니다. 외부 회계 시스템 연동이 필요하다면 전송 실패 내역과 재전송 기능도 별도 개발 범위로 정합니다.

현재 사용하는 견적 관리표와 대리점 권한표를 준비하고, 월별 실적 확정 기준과 연결할 회계 시스템을 함께 알려주시면 필요한 플랫폼 개발·CRM 개발 범위를 구체적으로 논의할 수 있습니다. 트램스 AI 제작 문의 (https://trams.co.kr/ai-si/contact/#inquiry)