[FAQ] ERP/WMS연동

Slack QA 로그(원본 129건) 중 ERP/WMS연동 영역에서 반복 질문되거나 확정된 답변 12건을 정리했다. ⚠ 배지가 붙은 항목은 과거 오답/정정 이력이 있거나 아직 결론이 나지 않은 주제이니 답변을 그대로 신뢰하지 말고 표시된 대로 재검증할 것.

Q40. worksout-SDB(쉐어디비)-두손 3자간 데이터 연동은 어떻게 동작해?

웍스아웃→SDB→두손: 온라인주문/회원정보/SKU정보를 두손이 polling/배치로 읽어감. 두손→SDB→웍스아웃: 재고정보(SEND_YN 플래그)와 출고/송장정보를 웍스아웃이 polling으로 가져감. 실시간연동이 아니라 양방향 폴링 구조.

출처 [[51]][[89]][[120]]

Q41. 미결제 주문은 WMS(ERP)가 알아?

모름. TEB_ORDERS는 결제완료 후 OrderSyncService.intoOrder() 호출 시점에만 INSERT되므로, 결제 전 주문은 메인DB에만 존재하고 ERP는 그 존재 자체를 모름.

출처 [[84]]

Q42. ERP 연동이 왜 polling 방식이야, 실시간 push가 낫지 않아?

레거시 Oracle ERP는 REST API가 없어 polling이 합리적 선택이었을 것으로 추정. push는 ERP 장애 시 온라인 API도 영향받고 트래픽 급증 시 ERP 부하가 직격. polling은 온라인/ERP 처리속도를 디커플링(공용DB=큐, SEND_YN=ACK 역할). 이벤트기반(Kafka)이 업계표준이지만 ERP 전면개편 수준이라 신규시스템에만 적용 검토 대상.

설계의견(사내 코드 사실확인 아닌 참고용 의견)

출처 [[81]][[89]]

Q43. WMS 입고/출고/매장이동/창고이동 4대 플로우는 어떻게 돼?

입고: 계약완료→입고예정(TLG_WAREIN_PLAN)→입고완료→검수→입고확정(PR_WAREIN_BILL)→적치(입고확정과 동시발생, 별도 상태 없음). 출고: 출고요청→지시(TLG_WAREOUT_PLAN)→피킹→검수→패킹→출고확정(PR_WAREOUT_BILL)→배송. 매장/창고이동: 이동지시→출발(재고임시차감)→배송중→도착입고→검수→확정(PR_SHOPMOVE_BILL/PR_WAREMOVE_BILL)→적치.

출처 [[85]] · 확인 필요 시 담당자: 박근태

Q44. 그 외 굵직한 ERP 플로우(판매/마감/온라인주문 등)는 뭐가 있어?

판매(POS, ksa_shopsell)/재고조정(ksa_adjust)/반품(ksa_warerepur)/일마감·월마감(ksa_rebuild)/온라인주문(TEB_ORDERS)/가격관리(FSA_GET_STYLEPRICE)/수수료정산/마일리지(구매7일후 자동적립, 180일미주문 만료)/배분계획/자금흐름(TAM_AMTFLOW)/자동검증(kcm_check) 총 11개, 업무빈도는 매일>주간>월간>수시 순.

출처 [[85]]

Q45. 매장간 이동시 검수과정이 필요할까?

현재 WMS(PR_SHOPMOVE_BILL)는 상태/검수/송장 개념이 전혀 없는 단일전표 집계 방식(입고쪽 프로시저 12개 대비 이동쪽은 1개뿐 - 내부거래라 신뢰기반으로 설계됨). 검수 도입 시 로스율 임계값(예: 5%) 기준 자동처리/수동확인 분기 하이브리드 방식을 권장. 로스 발생 시 WMS는 이동 자체엔 로스개념이 없고 별도 재고조정(PR_ADJUST_APPLY_SHOP, LOSS타입)으로 사후처리함.

설계제안(구현 전)

출처 [[90]]

Q46. SKU 구성요소(CORP_CD/STYLE_CD/COLOR_CD/SIZE_CD)는 각각 뭐야?

CORP_CD=법인코드(여러 브랜드/회사 운영 시 구분용). STYLE_CD=상품 기본모델/디자인. COLOR_CD/SIZE_CD=색상/사이즈. 이 4개 복합키가 곧 SKU(별도 SKU_CD 컬럼 없음). SKU는 스타일/색상/사이즈 조합을 직접 INSERT해야 생성됨(자동발생 안 함). SKU 코드 체계에 업계표준은 없음.

다수 항목이 추정(DDL 직접확인 불가)

출처 [[86]][[97]]

Q47. 발주(Purchase) 설계는 어떻게 돼있어(TLG_PURCHASE)?

KB에 실제 정보 없음. 확인 불가. 일반적 두손ERP 구조 기준의 추정 구조만 존재.

미확인

출처 [[85]]

Q48. 매장출고 순서(FSA_GET_SHOP_STOCK)를 우리쪽에서 제어할 수 있어?

아니. 이 함수는 두손 ERP 내부함수로 매장별 재고를 조회/정렬해 반환하며, 우리쪽은 반환결과를 받아 재정렬/필터링만 가능(함수 내부 ORDER BY 로직은 직접 제어 불가). 출고지시 생성도 두손 ERP가 함. 복수 매장 우선순위 리스트는 두손 표준기능으로 지원 안 됨(TEB_ORDERS는 단일 희망매장 필드만 있어 커스텀개발 필요).

출처 [[125]]

Q49. JP 오프라인(매장) 결제는 PG를 거쳐?

안 거침. 두손ERP(TSA_ShopSellHdr/Det)로 직접 꽂힘. 워크스아웃 Order테이블엔 pgKey=null인 요약정보만 동기화됨. 환불도 1분주기 배치(loadOffline) polling 방식(push/웹훅 없음, 최대 1분 지연).

출처 [[126]]

Q50. 일본 매장 환불 시 새 주문건(ORDER_ID)이 또 생기는 이슈, 원인이 뭐야?

일본 POS는 원본 주문 업데이트 대신 새 ORDER_ID로 환불전표를 별도생성하는 방식을 쓰는데(PROPERTY_02에 원본주문번호 참조), 기존 취소판별 로직(IS_CANCELED==‘T’ 또는 paid<0)이 이 패턴에 대응하지 못해 놓침. 수정안: PROPERTY_02가 있고(자기자신 아님) paid<=0이면 취소로 간주하는 조건 추가. 오프라인 주문은 jp-api 재고(product_size.stock, 온라인전용)와 무관하므로 이 수정이 재고에 영향 없음.

출처 [[126]]

Q51. 반품신청취소 시 ERP(TebOrderManage)에 어떤 값을 보내?

ACTION/STATUS/CUR_STATE 필드를 CANCEL_RETURNED(C3, 반품요청취소)로 변경, CANCEL_DATE 갱신. STATUS 변경 전 값은 E10(READY_RETURN, 반품배송대기). KR/JP 동일 로직.

⚠미해결: 실제 운영에서 E10→C3 전환이 안 되는 이슈가 있었고, store쪽(자체DB)은 정상인데 두손쪽만 안 바뀌는 것으로 추정됨(원인 미확정, 박근태 확인 필요)

출처 [[121]] · 확인 필요 시 담당자: 박근태