ERP(Ecount 계열) API 연동 개발 정리

ERP(Ecount 계열) API 연동 개발 정리

— 거래처 등록 / 입하 등록 자동화 구현 경험

1. 정리 배경

사내 MES 또는 관리 시스템에서
외부 ERP 시스템과 데이터를 연동해야 하는 요구는 매우 흔하다.

그중에서도 자주 등장하는 시나리오는 다음과 같다.

• 거래처 정보를 ERP에 자동 등록
• 입하(자재 수불) 데이터를 ERP로 전송
• 엑셀/수기 입력 제거
• “이미 전송된 데이터”의 중복 처리 방지

이 글은
ERP(Ecount 계열) Open API를 활용해
거래처 등록과 입하 등록을 연동 구현하면서 정리한 실무 개발 흐름과 주의점을
기술 블로그 형태로 정리한 기록이다.

---

2. 전체 구조 개요

연동 구조는 다음과 같은 흐름을 가진다.

1. 사내 화면(스프레드시트/그리드)에서 데이터 관리
2. 사용자가 “ERP 저장” 버튼 클릭
3. 체크된 행만 대상으로 API 요청
4. JSON 형태로 데이터 변환
5. ERP API 호출
6. 결과에 따라 DB 상태 업데이트
7. 이미 전송된 데이터는 재전송 방지

핵심은
UI → API → DB 상태 관리가 하나의 트랜잭션 흐름처럼 동작해야 한다는 점이다.

---

3. ERP API 연동을 위한 기본 준비

3.1 개발 환경 사전 조건

• HTTP 통신 라이브러리
• JSON 직렬화/역직렬화 유틸
• Dictionary / Collection 기반 데이터 구조

(언어/플랫폼은 중요하지 않고, 개념이 핵심)

---

3.2 API 인증 구조 이해

ERP API 연동은 다음 순서를 따른다.

1. API 인증키 발급 (운영/테스트 구분)
2. Zone 정보 조회
3. Zone 기반 로그인
4. Session ID 획득
5. 이후 모든 API 요청에 Session ID 사용

⚠️ 주의
테스트 키를 사용하더라도
실제 운영 데이터가 등록되는 구조인 경우가 있으므로
사전 검증이 필수다.

---

4. 거래처 등록 API 연동 흐름

4.1 UI 버튼 클릭 시 동작

• 스프레드시트 전체 행 중
  • “ERP 저장” 체크된 행만 대상
  • 사업자번호 등 필수 값 존재 여부 확인
• 조건 만족 시 거래처 등록 API 호출

---

4.2 데이터 매핑 전략

가장 중요한 부분이다.

1. ERP 개발 문서 기준으로
   • 필수 컬럼
   • 선택 컬럼 구분
2. 화면 컬럼과 ERP API 필드 1:1 매핑
3. Dictionary 구조로 데이터 구성
4. Dictionary → JSON 변환

예시 개념:

 

화면 컬럼: 사업자번호 → API 필드: BUSINESS_NO 화면 컬럼: 거래처명 → API 필드: CUST_NAME

👉 컬럼명 하드코딩이 아니라,
ColID 기반 매핑 구조를 유지하는 것이 유지보수에 매우 중요

---

4.3 API 호출 및 결과 처리

• 성공
  • DB의 erp_yn (또는 유사 플래그) 업데이트
  • UI 상 성공 표시
• 실패 (요청 오류)
  • 사용자 알림
• 에러 (응답 없음)
  • 즉시 종료 및 로그 확인

---

4.4 중복 전송 방지

• 이미 ERP 전송 완료된 행은
  • 조회/새로고침 시 Lock 처리
• 사용자가 실수로 다시 전송하지 못하도록 UI 제어

---

5. 입하 등록 API 연동 흐름

거래처 등록과 구조는 유사하지만,
입하 등록은 “헤더 + 디테일” 구조라는 차이가 있다.

---

5.1 실행 조건

• “ERP 저장” 체크 여부
• 전표번호 존재 여부
• 사업자번호 존재 여부

조건 미충족 시:

• 즉시 사용자 알림
• API 호출 중단

---

5.2 JSON 구조 차이

입하 등록은 보통 다음 구조를 가진다.

 

{ "Header": { ... }, "Items": [ { ... }, { ... } ] }

따라서:

• Dictionary + Collection 구조 사용
• Collection을 포함한 JSON 변환 로직 필요

---

5.3 입하 등록 API 처리 결과

• 성공
  • DB 상태 업데이트
  • 전표번호 기준으로 Lock 처리
• 실패
  • 알림 및 해당 행 Focus 이동
• 에러
  • 즉시 종료

---

6. 공통 모듈 설계 포인트

6.1 API 요청 공통 함수

공통 로직:

1. 파라미터 → JSON 변환
2. API URL 조합
3. HTTP 요청
4. 응답 수신
5. JSON 파싱
6. 성공/실패 판단

👉 거래처/입하 API가 달라도
요청·응답 구조는 최대한 공통화하는 것이 유지보수에 유리하다.

---

6.2 환경 설정 분리

• API Base URL
• 회사 코드
• 인증 키

→ 설정 파일 또는 환경 변수로 관리

⚠️ 테스트/운영 키 혼용 주의

---

7. 실무에서 중요했던 포인트

• API 연동은 “한 번 성공”보다
  “실수해도 다시 안전하게 처리할 수 있느냐”가 중요
• UI Lock 처리 없으면
  운영 중 중복 전송 사고 발생 가능성 매우 높음
• ERP API는 대부분
  • 에러 메시지가 불친절
  • 원인 파악이 어려움
    → 로그와 단계별 검증 필수

---

8. 마무리

ERP API 연동은 단순히
“API 한 번 호출하는 작업”이 아니다.

• UI 상태 관리
• DB 상태 플래그
• 중복 방지
• 사용자 실수 방어
• 장애 시 복구 시나리오

까지 함께 설계해야
실제로 운영 가능한 연동 기능이 된다.

이 글은
그 과정에서 정리한 실무 중심의 사고 흐름 기록이다.

---

 

※ 본 글은 실제 ERP API 연동 경험을 일반화하여 재구성한 기술 기록이며, 특정 회사·고객사·상용 시스템의 내부 구현 세부사항을 포함하지 않습니다.