JD Edwards EDI自動化最佳實踐

EDI已經存在了超過一代人的時間，EDI行業在這一點上基本上是成熟的，一些更大的參與者，如SPS Commerce控製著很大的市場份額。也就是說，最後一個經常被忽視的EDI前沿仍然存在:直接將流程集成到像JD Edwards這樣的erp中。

現在大多數EDI提供商隻是簡單地將文件放入ftp文件夾中，然後就洗手不幹了。對於擁有大型IT部門和Oracle開發人員的大型組織來說，這種方法幾乎沒有任何缺陷。他們將在翻譯器中進行映射，並自行編排成JD Edwards。他們將構建儀表板，以便監控數據流，並為客戶服務、財務等提供報告。異常可以由他們的EDI團隊直接處理。

問題是，許多組織並沒有無限的IT和EDI資源，而且隨著這一代EDI專業人員開始退休以及外包的宏觀趨勢的繼續，這些資源正在變得越來越稀薄。由於沒有預算或資源來構建Oracle的功能，異常會消失在黑洞中，客戶不能及時登錄(如果有的話)，訪問基本信息很麻煩，至少可以說是痛苦的。

SPS特別認識到這一差距，並將其EDI服務擴展到包括端到端集成和EDI自動化進入像JD Edwards這樣的erp．解決方案:係統自動化技術優於映射和轉換工具，同時將事務直接自動化到JD Edwards System 47數據庫表。

下麵是它的工作原理:

業務規則，而不是映射工具

大多數EDI解決方案使用映射工具作為轉換引擎，該工具允許您將數據字段從入站事務連接到另一個字段，假定是在最終將導入ERP的出站文件中。

有些工具通過拖放功能、基本轉換規則和其他花哨的功能讓體驗變得令人愉快，但問題往往是相同的:

• 轉換器將映射數據，但它不會驗證數據是否幹淨和有用
• 翻譯人員缺乏處理複雜問題的能力
• 翻譯人員在沒有幹預的情況下無法豐富數據

SPS JD Edwards EDI自動化技術解決問題的方法大不相同。通過利用可配置到每個組織的獨特流程的業務規則，您就有了一個規則庫來傳遞數據，以確保其幹淨和有用。這包括:

• 驗證數據是否存在，並且它具有正確的字符數量和類型
• 自動追加數據或添加數據，如PO號
• 複雜的轉換，如分割830計劃時間表發送給多個供應商

端到端可見性

當翻譯器不能驗證數據時，它就不可能提供對它一開始就無法檢測到的錯誤的可見性。你可以擁有你想要的所有花哨的儀表盤和報告，但如果你看不到錯誤以及錯誤發生在哪裏，每天就變成了一場尋寶(大海撈針式的尋寶)。

EDI自動化使用可配置的儀表板和報告提供端到端可見性從它離開零售商的那一刻，到它到達JD Edwards的那一刻(反之亦然)。錯誤報告構建在業務規則引擎之上，並基於庫中特定於流程的業務規則顯示異常。誘人的是，System Automation儀表板可以配置為用戶角色，特別是根據客戶端和事務類型等。

成功的人力工作流程

如果你不能提供一種機製來修複錯誤，那麼表麵錯誤隻是戰鬥的一半，而大多數翻譯人員都沒有。我們經常發現，在JD Edwards用戶意識到數據問題後，他們必須深入研究實際的EDI代碼來修複它。這對IT資源來說是一種負擔，通常需要一張票據來解決，並且像滾雪球一樣，可能會導致倉庫的延遲以及隨之而來的退款和費用。

如果您猜異常處理儀表板和表單是係統自動化的一部分，那麼您猜對了。我們稱之為人工工作流因為它使業務用戶能夠以人類可讀的形式查看錯誤，並直接使用儀表板視圖中的表單解決這些錯誤。通過允許業務用戶在現場重新處理事務，IT的負擔大大減輕，雪球永遠不會滾下山。

融入JD Edwards

至於集成本身，大多數EDI提供者都將向您提供一個包含已翻譯數據的文件。它可能是您需要的格式，數據在正確的字段中，但您將需要將其導入JD Edwards，所有這些小錯誤都在等待出錯。

當然，提供一個允許編排、可見性和人工工作流的應用程序是一件大事。另一個大問題是將數據直接放入System 47數據庫表中。

SPS通過在防火牆的一側安裝一個輕量級代理來實現這一點，該代理隻與出站通信，並向係統自動化平台尋求指令。這個過程可以根據您的業務要求安排得盡可能少或盡可能頻繁。

也許最好的部分是係統自動化是包括在SPS商務全麵服務解決方案．沒錯，我們不指望你學會如何使用這個平台——我們將在這個過程中與你合作，並為你提供所需的所有實現和支持資源。

聯係我們，了解更多關於JD Edwards EDI自動化，並查看我們的係統自動化平台的演示．