사용하기 쉬운 기술에도 불구하고이 구식 형식이 계속 사용되는 이유는 무엇입니까? 그것은 내가 보지 못하는 어떤 이점을 제공합니까? XML과 같이 관리하기 쉽고 사용하기 쉬운 것이 아니라 많은 양의 공급 업체가이 형식으로만 데이터를 제공하고있는 것으로 보입니다. 최소한 두 형식 모두를 제공하는 것이 나에게 맞는 것입니다.EDI가 아직 사용되고 있으며이를 처리하는 이유는 무엇입니까?
EDI를 처리하고 사용하는 다른 방법은 없지만 사용하는 좋은 방법은 무엇입니까? BizTalk와 같은 것은 너무 비싸기 때문에 의문의 여지가 없습니다. EDI를 더 쉽게 사용할 수 있도록하는 무료/오픈 소스 응용 프로그램이 있습니까?
EDI는 사용하는 구분 기호에 익숙해지면 이해하기가 어렵지 않습니다. 왜 누군가가 여전히 CSV 또는 탭으로 구분 된 데이터를 사용하는지 스스로에게 질문 할 수 있습니다.
대답은 아마도 이러한 형식이위원회에서 정의되고 특정 업계에서 표준화 된 "도메인 특정 언어"이며 해당 형식을 지원하는 데 많은 돈이 투자되었다는 것입니다. 그 모든 것을 다시 던질 비즈니스 케이스는 어디입니까?
나는 EDI도 사용해야하고 동의합니다. BizTalk를 사용하여 잘 작동하는지도를 그렸습니다. 많은 시스템이 EDI (XML 이전)에 구축되었습니다.
BizTalk를 사용하고 있다면 문제가 없을 수도 있지만 불행히도 솔루션 가격은 너무 비싸서 해결책으로 고려하기가 너무 어렵습니다. –
한 단어, 관성. 서로 다른 의제를 가진 여러 회사와 조직 사이에서위원회에 의해 EDI 형식을 개발하는 것은 악몽이었습니다 (내가 거기에 있었다고 말하는 것은 슬픈 일이었습니다).
웹 서비스 API 표준에 동의하는 또 다른위원회 라운드에서 이들을 포기할 것을 요청하면 전자 형식을 비 기술적 인 보드로 바꾸는 아이디어를 어떻게 판매합니까? 그것이 가능한 어떤 busness 우위가 그들을 준다. 원래 전자 교환의 이점은 분명했지만 다른 것을 대체 한 것은 아닙니다. 우리는 여기서 큰 회사를 말하고 있습니다.
XML로 전환하면 라인 형식을 디버그하기가 다소 쉬워집니다.
일반적으로 설정하고 그대로두면 원시 EDI 피드로 재생할 필요가 없으며 표준을 포기하고 다시 시작하기에 충분하지 않습니다.
FAX와 같은 표준이 많아서 읽을 수 있지만 변경할 필요가 없습니다.
EDIFACT 주문과 같은 간단한 EDI 형식을 검토 한 적이 있습니까? 쉽게 사용하고 연장 할 수있는 도구는 무엇입니까? XML이 무료로 제공하는 것을 얻기 위해 몇 가지 통화가 필요합니다. – AnthonyWJones
+1 AnthonyWJones. EDI와 관련된 문제 - XML을 쉽게 소비하고 확장 할 수있는 반면 파싱하기가 무척 어렵습니다. –
그것은 약간 쉬운 문제가 아닙니다. EDI는 XML보다 정확하게 수행하기가 훨씬 더 어렵습니다. – Kibbee
"파손되지 않은 경우 고치지 마십시오."
이러한 조직의 대부분은 EDI를 사용하여 방대한 양의 데이터를 처리하고 있으며 설득력없는 이유없이 더 현대적인 것으로 변경하려고하지 않습니다. 제 3 자 개발자가 쉽게 만들 수 있다고 말하는 것은 슬픈 일입니다.
EDI는 매우 컴팩트 한 형식이며 가능한 한 작은 데이터 교환에서 대역폭 사용을 유지하는 데 자주 사용됩니다. 예를 들어 독일 세관에서는 매일 대량의 데이터를 교환하기 위해 ATLAS 시스템에서 사용합니다.
구문 분석하기 어렵고 읽기가 어렵지만 결과 데이터의 크기가 중요한 경우 큰 선택 일 수 있으며 대부분의 큰 비즈니스 응용 프로그램에서 지원됩니다.
이 점에 가깝게 가치있는 네트워크 (VAN)는 여전히 kilocharacter rate를 부과합니다. 문자가 많으면 많을수록 비용이 많이 듭니다. – direct
EDI는 XML 이전부터 사용되어 왔습니다. 두 당사자가 둘 다 작동하는 EDI 형식을 미리 협상 할 수 있다는 사실 외에도 VAN (부가가치 네트워크)의 일부를 고려해야합니다.)
경우에 따라 VAN은 메시지의 유효성 검사를 수행하거나 메시지를 읽고 해당 콘텐츠를 기반으로 추가 당사자에게 메시지를 복사하는 등의 작업을 수행합니다.
EDI를 실제로 사용하는 유일한 이유는 "항상 완료된 방식이므로"이를 지원하기 위해 많은 기존 인프라가 있기 때문입니다. 필요가 없을 때 XML로 전환하는 이유는 무엇입니까? 그리고 XML을 JSON으로 대체하지 말고 다른 것으로 대체 될 것입니다.
JSON은 데이터 용이고 XML은 문서 용입니다. 그것은 중요한 차이입니다. –
무슨 뜻인지 설명해주십시오. –
EDI는 많은 산업 분야에서 다작입니다. 이미 작동중인 기술을 새로운 기술로 교체하는 것은 엄청나게 비쌀 것입니다.
이것을 고려해 볼 때 월마트는 EDI를 사용하여 공급 업체, 상점, 유통망 등과 통신합니다. 수만 개의 공급 업체와 거래하고 있다고 생각합니다. 그들 모두는 EDI 기술에 수천 달러의 돈을 쏟아 부었습니다. Walmart가 XML로 전환하기로 결정했다면, Walmart뿐만 아니라 수천 개의 회사에 영향을 미치는 결정이었습니다.
모든 EDI 사용자에게 해당됩니다. 결국 거래 파트너간에 사용되는 표준입니다.
동의합니다. EDI는 작동 할 고통입니다. 그러나 '그날의 위로', 그것은 우리가 가진 전부입니다.
그걸 다룰 때의 고통을 덜어주기 위해 무엇인가 권유하는 것이 중요합니까? 나의 좌절은 나의 회사가 벤더를 바꾸었고이 새로운 하나의 * only *가 EDI 포맷의 데이터를 제공하기 때문이다. (예전의 제품도 텍스트로 제공했다.) 그래서 나는 우리 시스템과 그것을 통합하는 방법을 찾기 위해 뒤범벅을하고있다. –
@ WayneM 뭔가 빠져있을 수도 있지만 XSLT를 사용하여 XML을 EDI로 변환 할 수는 없습니까? XML-> XSLT-> EDI는 EDI-> CustomeParser-> XML보다 훨씬 쉬워 보인다 ... 다시 한번 나는 단순화 된 것일 수있다. – null
XML을 사용하지 않습니다. 데이터 추출 만하면됩니다. XML이 필요한 데이터를 쉽게 파싱 할 수 있기 때문에 공급자가 XML을 사용하고 EDI는 사용하지 않기를 바랬습니다. –
공식적으로 설립 된 표준 (실제로 매우 광범위하고 포괄적 인 표준 집합)이기 때문에. 그리고 이는 표준의 장점 중 하나입니다. 오랫동안 아무것도 변경할 필요가 없습니다.
변경하려면 2 명 이상 (수천 명 이상 수천 명)의 거래 파트너 (경쟁사 모두 포함)간에 동의해야합니다.
EDI 포맷은 중요한 신호 대 잡음비를 가지고 있기 때문에 중요합니다. EDI를 알고 이해하는 사람은 XML을보고 "쇠고기 (데이터)는 어디에 있습니까?"라고 말합니다.
아주 소수의 개발자가 자체 파서를 작성합니다. 사용할 수있는 많은 좋은 매퍼가 있습니다 (많은 레거시 및 엔터프라이즈 응용 프로그램이 내장되어 있습니다). 따라서 통증에는 많은 안심이 가능합니다 (SourceForge의 오픈 소스 앱 중 적어도 하나 포함).
관심있는 모든 정보가 조금 있습니다. EDI는 기본적으로 XML 같은 데이터 형식화 규칙을 설정하는 것뿐만 아니라 2 개 회사간에 전송 될 수있는 각 문서를 정의하는 데 필요한위원회 데이터 교환 형식에 의한 디자인입니다. 따라서 회사간에 교환 할 수있는 데이터가 있으면 각 문서에 무엇이 있어야하는지에 대한 정확한 정의를 내놓았습니다. 물론 아무도 2 개 회사가 교환하고자하는 모든 데이터를 예측할 수는 없습니다. 그래서 당신은 1 가지로 정의 된 필드를 사용하는 회사로 끝나고 다른 정보에 사용됩니다.
당신이 결론 지었던 것은 많은 사람들이 표준을 따르지 않는 사용자 지정 정보를 보내야하기 때문에 표준을 따르지 않는 매우 복잡한 데이터 형식입니다. 결국 결국 사용자 정의 XML 인터페이스를 사용하는 사람에게 가서해야 할 것처럼, 구현하려는 모든 작은 특질을 알아 내야합니다. EDI의 경우 형식을 구문 분석하기가 어렵고 쓰기가 더 어려워서 사용자 지정 XML 솔루션을 가지고 같은 생각을 할 때 문서를 보내기 만하면됩니다. 여러 번 문제가 줄어들었다.
하지만 동일한 데이터와 동일한 목적으로 XML 형식을 광범위하게 확장하는 거래 파트너를 얻을 수 있으므로 동일한 결과가 발생합니다. 우리 모두는 다른 사람들보다 우리 자신의 망치를 더 좋아하지만 때로는 반쯤 비뚤어진 손톱을 몰고 다닙니다. – dkretz
저의 요점은 전체 산업 분야에서 보낸 문서를 표준화하려고 할 수 없다는 것입니다. 대신, 모든 사람이 하나의 DTD 또는 데이터 형식에 동의하도록하는 대신 XML을 사용하고 다른 사람들이 준수하도록 DTD를 정의하는 것이 더 좋을 것입니다. – Kibbee
메시지 교환 요구 사항의 100 %를 표준화 할 수 없기 때문에 모든 접근 방식에 대해 무료로 투표하는 이유는 아닙니다. –
하나의 해결책은 비용이 많이 들지만 ADX 같은 회사로 이동하는 것입니다.이 도구에는 EDI 형식을 CSV와 같은 더 기쁜 형식으로 변환하는 데 사용할 수있는 도구가 있습니다. 거래량 및 거래 유형에 따라 비용 부담이 적고 스트레스가 적습니다. 나는 과거에 제품을 사용 해왔고, 설치 작업이 조금 있지만 견적을 잘 작성하고 안정적입니다. EDI의 역사로 인해 비슷한 서비스를 제공하는 수백 개의 다른 회사를 찾을 수 있습니다.
불행히도 내 예산은 $ 0.00입니다. 나는 그것을 사용할 필요가 있기 때문에 그것을 명심 할 것이다. –
그들은 일을하기 위해 당신에게 0.00 달러를 지불하고 있습니까? 그렇지 않은 경우 솔루션을 위해 다른 사람에게 비용을 지불하는 것보다 훨씬 적은 비용으로 완료 할 수 있다고 주장해야합니다. – Kibbee
다음과 같은 프로젝트에 관심이있을 수 :
http://bots.sourceforge.net/en/index.shtml Google code archive
또 다른 이유는 같은 순서와있는 비즈니스 메시지가. 인보이스, 신용 정보 등 거래에 많은 재정적 가치가 있으며 보안이 필요하지만 더 중요한 것은 검증 및 검증은 물론 부인 방지가 필요합니다.
예를 들어 나는 상품의 1/2 백만 유로 상당의 주문을 보내고, 나에게 물건을 보내면 주문 정보를 "잃어 버리고"내가 지불하지 않는다고 말합니다. 표준과 VANS의 결합은이 문제를 거의 추적 할 수 없도록하거나 적어도 감사 추적을 통해이를 추적합니다. 이것이 왜 "오, EDIFACT와 VANS 대신 xml과 인터넷을 사용합시다"는 실패하는 경향이 있습니다. 누군가가 응답하면, 관성이지만 안정되고 효과적이고 안전하며 신뢰할 수 있고 잘 이해 된 시스템에 기초한 관성입니다.
저렴한 가격으로 판매하는 것이 항상 선택 가능한 것은 아닙니다.
'87 년 처음 EDI를 구현했을 때 위안이라면 사실상 소프트웨어가 없었기 때문에 Interbridge 테이블을 얻었고 Cognos 소프트웨어와 HP Mini를 사용하여 영국 TRADACOMS 표준 용 파서를 작성했습니다. 잘 했어. 다른 EDI 파트너와 거래한다고 가정하면 비용은 VAN을 사용할 필요가있을 것입니다.
IMHO EDIFACT에는 몇 가지 문제가 있습니다.
요약하면 다음과 같습니다. 목에 통증이 있습니다.
Edifact는 문서 교환을 할 때 최고의 표준 중 하나입니다. 대부분의 문제는 거래 상대방이 표준화되지 않은 문서를 보내는 경우 발생합니다.
네, 그게 이상한 형식이고 지루하고 잘 모르겠다면 그것도 XML을 위해 간다.
정말 XML을 통해 Edifact를 원하십니까? XML 표준 인 peppol (pan-european public procurement online)이 비판적이며 읽기가 힘듭니다.
시스템에 오류가 없으면 UBL 문서의 문제 해결보다 형식에 익숙해지면 문제 해결을 쉽게 할 수 있습니다.
프로젝트에 사용할 0.00 달러가 있습니까? 회사에서 실제로 수행 한 수작업의 양과 EDI가 제공 할 수있는 비용 편익을 조사해야 비용 편익 분석이 편리 할 수 있습니다.
edidev, stylusstudio 또는 연락 책을보십시오 연락 책 무료 프로그램이 있습니다 EDI 메모장 (edifact에 익숙하지 않은 경우 매우 유용합니다) 오픈 소스가되어야하는 경우 상당수의 자바 파서가 있습니다 BizTalk는 비트 prizy하지만 너무 큰 ERP 시스템, 그 컨텍스트에서 상을 봐야합니다 :-) – plykkegaard
EDI를 통해 어떤 유형의 정보를 교환 할 수 있습니까? - •
정보
예약 - • 선하 증권 정보를- • 인보이스
- • 전자
:
비즈니스 정보 교환의 종류의 다양한 포함 EDI를 통해 볼 수 있습니다 송금
- • 도착 통지 정보
- • 출하 상태 정보
EDI를 선택하면 어떤 이점이 있습니까? - 그것은 당신과 APL
사이의 통신 과정을 간소화 • - 그것은 용지 처리 및 문서에 대한 필요성을 제거 • -이 데이터를 다시 입력 할 필요하므로 제거 오류 및 정보를
을 다시 할 필요가 없습니다 • 저장
- 그것은 turntime 및 데이터
의 정확도를 향상 • - 그것은
을 팩스 필요가 없습니다 • 내가 사용했습니다 EDI (ANSI X12 및 EDI FACT)를 해양 운송 로지스틱스에 관한 2 개 프로젝트에서 검토하여 이들이 서로 다른 시스템 간의 표준 통신 방법으로이를 채택한 대다수의 해양 운송 업체 및 무역 파트너에게 유용하다는 사실을 알게되었습니다.
그래서 EDI 형식은 여전히 표준으로 사용되고 있으며 수천 개의 회사가 그들 주위에 시스템을 개발했으며 대체하기 때문에 EDI 형식은 계속 사용되며 계속 사용됩니다.
주저 및 논증 : '암호', '제로 센스', 다른 시스템은 '더 효과적', '두통 분석', '고풍' '사용하기 쉬운' '중국어 읽기'를 참조하십시오. –
@ Gortok : 예, 그는 주관적입니다. 그러나 EDI 형식의 장단점은 무엇입니까? –
EDI는 Human Data Interchange가 아닌 Electronic Data Interchange를 나타냅니다. 인간이 읽을 수있는 것이 아닙니다. 그 작고 잘 정의 된. 필자는 7MB EDI 파일을 XML로 변환했으며 결국 45MB +가되었습니다. 전환 크기가 선형이 아닙니다. 더 큰 EDI 파일은 커질 수 있습니다. –