쇼핑몰 주문이 ERP에 중복 등록되지 않도록 프로그램 개발하기

핵심 요약

1. 판매채널과 주문번호를 묶어 보관하고, 같은 주문이 ERP에 두 번 생성되지 않도록 처리합니다. 2. PostgreSQL 트랜잭션과 BullMQ를 연결해 주문 기록 누락과 겹치는 전송 작업을 줄입니다. 3. 응답이 끊긴 주문의 재확인, 변경·취소 구분, 담당자 재처리 화면은 업무에 맞게 직접 개발합니다.

쇼핑몰에서 주문을 보냈는데 ERP의 응답이 오지 않으면 담당자는 다시 전송할지 판단하기 어렵습니다. 실제로는 ERP에 주문이 만들어졌을 수도 있기 때문입니다. 이런 프로그램 개발은 전송 성공 여부보다 ‘같은 주문을 다시 보내도 새 주문이 생기지 않는가’를 중심으로 범위를 정해야 합니다.

아래는 쇼핑몰 API 개발과 ERP 연동에 필요한 구현 방식입니다. 특정 ERP의 기본 제공 기능을 전제하지 않으며, 연결할 ERP의 조회·등록 기능을 확인한 뒤 적용합니다.

판매채널과 주문번호로 같은 주문 가려내기

입력 자료에는 판매채널, 주문번호, 상품 코드, 수량, 주문의 변경·취소 구분이 필요합니다. 판매채널과 주문번호를 합친 고유키는 같은 주문을 식별하는 기준입니다. 주문번호가 같아도 판매채널이 다르면 별도 주문으로 처리합니다.

접수 시에는 이 조합이 중복 저장되지 않도록 제한하고, 동시에 요청이 들어와도 주문 기록은 하나만 남게 만듭니다. 같은 키의 요청은 내용을 비교해 신규 생성, 변경, 취소 중 어느 처리로 이어갈지 정합니다. 검수에서는 같은 채널의 동일 주문은 하나로 연결되고, 다른 채널의 동일 번호는 각각 등록되는지 확인합니다.

PostgreSQL로 접수와 전달할 내용 함께 저장하기

PostgreSQL 트랜잭션은 여러 데이터 변경을 함께 반영하거나 취소하지만 외부 API까지 되돌리지는 않습니다. 이를 활용해 쇼핑몰 주문 내용과 ERP에 전달할 항목을 한 묶음으로 저장합니다. 주문만 저장되고 전달할 내용은 빠지는 상황을 막기 위한 자체 처리입니다.

저장이 끝난 주문부터 전송 대상으로 가져오고, ERP가 돌려준 주문번호는 원래 고유키에 연결해 보관합니다. 관리 화면에서는 쇼핑몰 주문과 연결된 ERP 주문번호를 함께 보여줍니다. 저장 중 오류를 발생시켜도 접수 내용과 전달할 항목 중 한쪽만 남지 않는지 검수합니다.

BullMQ로 진행 중인 중복 전송 줄이기

BullMQ의 Simple Mode는 같은 중복방지 ID의 미완료 작업이 있으면 추가 작업을 무시하지만 외부 업무의 중복 처리까지 보장하지는 않습니다. 이 기능은 같은 주문의 생성 요청이 짧은 시간에 몰릴 때 겹치는 전송 작업을 줄이는 데 사용합니다.

직접 개발할 부분은 주문 고유키와 작업을 연결하고, 전송 직전에 이미 ERP 주문번호가 있는지 다시 확인하는 로직입니다. 작업이 끝난 뒤 같은 요청이 들어와도 보관된 주문 기록으로 재생성을 막습니다. 변경·취소는 생성 요청과 구분해 보관하며, 생성 작업이 진행 중이라는 이유로 필요한 수정 요청이 사라지지 않는지도 확인합니다.

응답이 끊긴 주문은 ERP에서 재확인하기

ERP에 등록 요청을 보낸 뒤 응답이 끊기면 곧바로 재전송하지 않습니다. ERP가 외부 주문 식별자로 조회하는 기능을 제공한다면, 앞서 보낸 판매채널과 주문번호로 기존 주문을 찾습니다. 조회 결과가 있으면 해당 ERP 주문번호를 연결하고 신규 등록을 종료합니다.

조회에서 주문이 보이지 않는다는 이유만으로 즉시 재등록하는 것도 피해야 합니다. 앞선 요청이 아직 처리 중일 수 있으므로, 재조회 간격과 재전송 조건을 별도로 정합니다. ERP가 동일 식별자의 중복 등록을 막는 기능을 제공하면 이를 함께 사용하고, 처리 여부를 확인할 수 없다면 자동 재전송을 멈춰 담당자가 확인할 목록에 표시합니다.

변경·취소 연결과 재처리 버튼 검수하기

수량 변경과 주문 취소는 기존 ERP 주문번호를 대상으로 처리합니다. 변경 순서를 판단할 기준은 쇼핑몰이 제공하는 변경 시각이나 이력 번호에서 정하고, 이를 지원하지 않으면 최신 주문 내용을 다시 확인하는 절차가 필요합니다. 생성 결과가 확인되지 않은 주문의 취소 요청은 먼저 보관하고, ERP 등록 여부를 확인한 뒤 이어서 처리합니다.

핵심 실패 사례는 ‘ERP에는 주문이 생성됐지만 응답만 끊긴 상황’입니다. 이 상황을 재현한 뒤 담당자가 재처리 버튼을 여러 번 눌러도 ERP 주문은 하나이고 변경·취소가 그 주문에 연결되는지 확인합니다. 재처리 버튼도 자동 전송과 같은 중복 확인 절차를 거치게 만들고, 화면에는 연결된 ERP 주문번호와 마지막 처리 결과를 보여줍니다.

판매채널·주문번호·상품 코드·수량이 담긴 신규·변경·취소 주문 샘플과 ERP의 주문 등록·조회·수정·취소 API 문서 및 응답 예시를 준비해 주세요. 연결할 판매채널과 재처리 업무를 함께 정리해 트램스에 주문 중복 방지 프로그램 개발과 쇼핑몰 API 개발을 문의해 주세요. 트램스 AI 제작 문의 (https://trams.co.kr/ai-si/contact/#inquiry)