전자 데이터 교환(Edi)

전자 데이터 교환(EDI)이란?

전자 데이터 교환(EDI)은 합의된 표준을 사용하여 조직 간에 구조화된 비즈니스 문서를 컴퓨터 간에 교환하는 것입니다. 물류, 전자상거래 및 국제 무역에서 EDI를 사용하면 구매자, 공급업체, 창고, 운송업체 및 기타 거래 파트너가 운영하는 시스템이 각 문서를 사람이 다시 입력하지 않고도 구매 주문서, 배송 통지서, 운송 지시서 및 송장과 같은 정보를 교환할 수 있습니다.

EDI의 핵심 특징은 단순히 정보가 전자적으로 전송된다는 데 있지 않습니다. 정보는 수신 소프트웨어가 합의된 사양에 따라 해석할 수 있도록 필드, 세그먼트 및 메시지로 구성됩니다. 따라서 이메일에 PDF로 첨부된 송장은 그 자체로 EDI 송장이 아닙니다. 비즈니스 시스템이 사용할 수 있도록 사람이 직접 내용을 추출하거나 문서 처리 도구를 사용해야 할 수 있기 때문입니다.

EDI는 하나의 소프트웨어 제품, 네트워크 또는 파일 형식이 아니라 비즈니스 정보를 교환하는 방법을 의미합니다. 제대로 작동하려면 호환 가능한 문서 정의, 통신 방법, 식별자 및 비즈니스 규칙이 필요합니다.

물류 및 전자상거래에서의 EDI

EDI는 조직 간의 경계를 넘나드는 활동을 연결합니다. 소매업체의 구매 시스템이 주문을 생성하고, 공급업체의 시스템이 이를 확인하며, 창고가 상품 준비 지시를 받을 수 있습니다. 이후 배송 정보와 송장이 별도의 메시지로 관련 시스템 간에 이동할 수 있습니다.

전자상거래에서 EDI는 소비자 대상 온라인 매장 뒤에서 이루어지는 기업 간 프로세스를 지원할 수 있습니다. 예를 들어 온라인 소매업체는 EDI를 사용하여 공급업체에 재고를 주문하거나 창고와 주문 처리 정보를 교환할 수 있습니다. 소비자의 결제 거래와 소매업체의 후속 EDI 메시지는 서로 관련된 비즈니스 이벤트이지만 반드시 동일한 거래이거나 동일한 기술 인터페이스를 사용하는 것은 아닙니다.

국경 간 무역에서 EDI는 국제 운송 및 상업 문서에 필요한 정보를 전달할 수 있습니다. 세관 당국도 자체 사양에 따라 구조화된 전자 메시지를 사용할 수 있습니다. 그러나 공급업체 또는 운송업체와 EDI 메시지를 교환하는 것만으로는 세관 신고를 구성하거나 규정 준수를 확립하거나 상품 반출을 승인하는 것이 아닙니다.

일반적인 비즈니스 문서

다음 예시는 필수 순서가 아니라 문서의 기능을 보여 줍니다. 사용되는 메시지는 거래 관계와 적용되는 구현 가이드에 따라 달라집니다.

흔히 ASN으로 줄여 부르는 사전 배송 통지는 예상 배송을 설명하지만 상품이 도착했다는 증거는 아닙니다. 마찬가지로 배송 상태 메시지도 자동으로 배송 완료의 증거가 되는 것은 아닙니다. 그 의미는 보고된 이벤트와 이를 뒷받침하는 정보에 따라 달라집니다.

표준, 형식 및 통신 방법

EDI 표준은 비즈니스 메시지가 어떻게 구성되는지와 데이터 요소가 무엇을 의미하는지를 정의합니다. 널리 확립된 두 표준군은 X12와 UN/EDIFACT로 알려진 행정, 상업 및 운송을 위한 유엔 전자 데이터 교환 규칙입니다. GS1도 UN/EDIFACT를 기반으로 하는 EANCOM 및 GS1 XML을 포함한 EDI 표준을 유지 관리합니다.

X12의 예로는 850 구매 주문서, 856 배송 통지/매니페스트 및 810 송장이 있습니다. UN/EDIFACT는 구매 주문서용 ORDERS, 발송 통지용 DESADV 및 송장용 INVOIC와 같은 메시지를 제공합니다. 이러한 예시는 표준 전반에서 관련된 비즈니스 목적을 갖지만 구조와 구현 요구사항은 서로 호환되지 않습니다.

표준만으로는 거래 관계의 모든 세부사항이 정의되지 않습니다. 파트너는 적용 버전과 구현 가이드, 필수 필드, 허용 코드, 식별자 및 검증 규칙에도 합의해야 합니다. 두 조직이 동일한 표준군을 지원하더라도 시스템이 사용 가능한 메시지를 교환하기 전에 매핑 작업이 필요할 수 있습니다.

AS2는 HTTP를 통해 비즈니스 데이터를 교환하기 위한 통신 사양으로, 보안 및 수신 확인 메커니즘을 제공합니다. 이는 구매 주문서나 송장 형식이 아닙니다. 부가가치 네트워크(VAN)는 중개 메시지 교환 서비스를 제공할 수 있으며, 마찬가지로 비즈니스 문서 표준과는 별개입니다.

EDI 교환의 작동 방식

1. 비즈니스 이벤트가 데이터를 생성합니다. 예를 들어 구매자가 전사적 자원 관리 또는 주문 관리 시스템에서 구매 주문을 승인합니다.
2. 데이터가 메시지로 매핑됩니다. 번역 소프트웨어가 내부 필드를 합의된 표준 및 구현 가이드에 필요한 구조로 변환합니다.
3. 발신 메시지가 확인됩니다. 검증 과정에서 구문, 필수 필드, 코드 값 및 파트너별 요구사항을 확인할 수 있습니다.
4. 메시지가 전송됩니다. 메시지는 합의된 통신 채널을 통해 수신자 또는 중개자에게 전달됩니다.
5. 수신자가 메시지를 검증하고 번역합니다. 수신 시스템이 메시지를 확인하고 승인된 정보를 내부 애플리케이션 형식으로 매핑합니다.
6. 비즈니스 처리가 이어집니다. 수신 애플리케이션이 주문을 생성하거나 예상 입고를 기록하거나 검토를 위해 예외를 전달할 수 있습니다.
7. 응답이 조정됩니다. 기술적 수신 확인, 승인 및 비즈니스 응답을 통해 발신자는 교환에 어떤 일이 발생했는지 판단할 수 있습니다.

이러한 단계가 모든 거래가 자동으로 처리된다는 것을 보장하지는 않습니다. 구조적으로 유효한 메시지라도 알 수 없는 상품 식별자, 잘못된 배송지, 중복 문서 번호 또는 지원되지 않는 측정 단위로 인해 개입이 필요할 수 있습니다.

수신, 검증 및 비즈니스 승인

EDI 승인은 서로 다른 수준에서 작동합니다. 전송 수신 확인은 메시지가 통신 엔드포인트에 도달했음을 나타낼 수 있습니다. 기능적 또는 구현 승인은 구조적 검증 결과를 보고할 수 있습니다. 비즈니스 응답은 주문 또는 기타 요청이 승인, 거부 또는 변경되었는지를 전달할 수 있습니다.

이러한 신호를 동일한 것으로 취급해서는 안 됩니다. 전송 성공이 반드시 주문이 승인되었거나 상품이 배송될 것임을 의미하지는 않습니다. 승인의 구체적인 의미는 관련 사양과 거래 파트너 간 합의에 따라 해석해야 합니다.

주문부터 배송까지의 예시

소매업체는 EDI를 통해 해외 공급업체에 구매 주문서를 보낼 수 있습니다. 공급업체의 시스템은 상품 식별자, 수량 및 요청된 배송 정보를 확인합니다. 거래 계약에 주문 응답이 포함되어 있다면 공급업체는 별도의 메시지를 통해 승인 또는 제안된 변경 사항을 전달할 수 있습니다.

상품이 준비되면 공급업체는 배송물과 그 내용물을 식별하는 사전 배송 통지를 발행할 수 있습니다. 수령 창고는 이 정보를 사용하여 입고를 준비하고 예상 수량과 실제 수령 상품을 비교할 수 있습니다. 공급업체는 소매업체의 재무 시스템에서 처리할 송장을 보낼 수도 있습니다.

이 예시는 EDI가 조직 간 기록을 어떻게 연결하는지 보여 줍니다. 모든 당사자가 동일한 소프트웨어를 사용하거나 각 메시지가 실시간으로 전달되거나 상업 문서가 운송 및 세관 요건을 대체한다는 의미는 아닙니다. 구매 주문서, 배송 참조 정보 및 송장을 일치시키려면 일관된 식별자와 합의된 비즈니스 로직이 여전히 필요합니다.

EDI 및 관련 기술

모든 아키텍처에서 EDI와 API가 상호 배타적인 대안인 것은 아닙니다. 조직은 파트너 거래에 EDI 메시지를 사용하고 해당 거래를 내부 애플리케이션에 연결하는 데 API를 사용할 수 있습니다. 적절한 방식은 기술 명칭만이 아니라 문서 요구사항, 파트너 역량, 일정 요구사항 및 운영 통제에 따라 결정됩니다.

구현 시 고려사항 및 제한사항

시스템이 호환 가능한 메시지를 성공적으로 교환하고 처리하면 EDI는 반복적인 수동 데이터 입력을 줄일 수 있습니다. 그러나 부정확한 원천 데이터를 수정하거나 상업적 분쟁을 해결하거나 예외 처리를 없애지는 못합니다. 자동화는 기술적 호환성과 교환되는 비즈니스 정보의 품질 모두에 달려 있습니다.

EDI 연결을 설정하기 전에 거래 파트너는 다음 운영 사항을 명확히 해야 합니다.

• 문서 범위: 어떤 메시지가 필요하며 어떤 비즈니스 이벤트가 이를 트리거합니까?
• 식별자: 상품, 위치, 당사자, 주문 및 배송을 어떻게 식별하고 일치시킵니까?
• 메시지 요구사항: 어떤 버전, 필수 필드, 코드 목록 및 매핑 규칙이 적용됩니까?
• 통신 및 보안: 어떤 연결 방식, 인증 방식 및 접근 제어가 필요합니까?
• 승인: 어떤 응답이 전달, 검증 및 비즈니스 승인을 나타냅니까?
• 예외 처리: 거부된 메시지, 누락된 응답 및 불일치 데이터를 누가 조사합니까?
• 중복 방지: 재전송을 새로운 비즈니스 거래와 어떻게 구분합니까?
• 테스트 및 변경 관리: 변경사항을 운영 환경에 적용하기 전에 매핑과 파트너 요구사항을 어떻게 테스트합니까?

운영 모니터링에서는 통신 실패, 데이터 검증 실패 및 비즈니스 예외를 구분해야 합니다. 메시지를 다시 보내는 것은 전송 실패를 해결할 수 있지만 잘못된 상품 코드를 수정하지는 못합니다. 중복 제어가 없으면 성공적으로 처리된 주문을 재전송하여 의도하지 않은 두 번째 거래가 생성될 수도 있습니다.

자주 묻는 질문

물류에서 EDI는 무엇을 의미합니까?

EDI는 전자 데이터 교환을 의미하며, 시스템 간에 비즈니스 문서를 구조화하여 교환하는 것입니다. 물류에서 이러한 문서에는 배송 통지서, 운송 지시서, 송장 및 배송 상태 메시지가 포함될 수 있습니다.

이메일로 보낸 PDF는 EDI 문서입니까?

그 자체로는 아닙니다. PDF는 비즈니스 문서를 전자적으로 표시할 수 있지만 EDI에는 수신 시스템이 합의된 사양에 따라 해석할 수 있는 구조화된 정보가 필요합니다.

EDI는 API와 같은 것입니까?

아닙니다. EDI는 표준화된 비즈니스 문서 교환과 관련되고, API는 소프트웨어가 다른 서비스와 상호작용하는 방식을 정의합니다. 하나의 통합에서 두 기술을 모두 사용할 수 있습니다.

EDI 승인은 주문이 승인되었다는 의미입니까?

반드시 그렇지는 않습니다. 승인은 비즈니스 승인보다 전송 또는 구조적 검증을 확인하는 것일 수 있습니다. 메시지 유형과 거래 파트너 간 합의가 그 의미를 결정합니다.

출처

• UNECE: UN/EDIFACT — 행정, 상업 및 운송 데이터의 구조화된 전자 교환을 위한 공식 프레임워크입니다.
• X12: Transaction Sets — 구매 주문서, 송장, 배송 통지서 및 승인서를 포함한 비즈니스 거래 세트의 공식 설명입니다.
• GS1: Electronic Data Interchange — 비즈니스 메시지 표준과 GS1 EDI, EANCOM 및 GS1 XML 간의 관계를 설명합니다.
• RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — AS2 전송, 보안 메커니즘 및 수신 알림을 설명합니다.