Pengantar Pertukaran Data Elektronik

Tulisan berikut merupakan pembelajaran ulang dari bagian pertama buku berikut R. Stultz, Demystifying EDI. Plano, Tex.: Wordware Pub., 2001.
Electronic Data Interchange atau terjemahan bahasa Indonesianya Pertukaran Data Elektronk, adalah alir informasi bisnis secara elektronik antar aplikasi, antar organisasi secara langsung yang terintegrasi dengan menggunakan standar UN/EDIFACT melalui jaringan komputer yang dikelola Provider (sumber: DIREKTORAT JENDERAL BEA DAN CUKAI). EDI pertama kali diciptakan oleh Edward Guilbert untuk menghubungkan Du Pont dan Chemical Leahman Tank Lines, Inc. di tahun 1960an [1][2][3], di sektor ritel dipelopori oleh Kmart dan Sears dengan berbagai pemasok pada awal 1970an, lalu akhirnya badan standarisasi membentuk standar pada tahun 1979 bernama ANSI ASC X12, lalu PBB membentuk standar EDIFACT pada tahun 1987.
Berikut Contoh-Contoh Surat EDI menurut standar dari PBB/EDIFACT:
                                                                                                                                                                                                        

Topik PesanPenjelasanORDERSSebuah dokumen yang menentukan detil dari barang atau jasa yang dipesan di bawah kondisi yang disepakati antara penjual dan pembeli.INVOICSebuah dokumen yang mengklaim pembayaran atas barang atau jasa yang telah diberikan di bawah kondisi yang disepakati antara penjual dan pembeli.DESADVSebuah dokumen yang memberikan detil untuk barang yang telah dikirim atau siap untuk dikirim di bawah kondisi yang disepakati.INVRPTSebuah dokumen yang menspesifikasikan informasi terkait persediaan yang ada digudang. Dokumen laporan persediaan dimaksudkan untuk dibuat baik oleh penjual maupun pembeli.SLSRPTSebuah dokumen yang berisi aktivitas produk yang terkait dengan penjualan produk atau jasa, seperti lokasi kegiatan, tanggal, waktu atau periode, kuantitas, harga, jumlah moneter, sektor pasar, pihak yang terlibat dan data lainnya yang memungkinkan berbagai analisis penjualan. Informasi aktivitas tersebut memungkinkan pemasok untuk melakukan analisis statistik dan kuantitatif dalam mendukung produksi, perencanaan, pemasaran, pengisian, dan proses lainnya.PRICATSebuah dokumen yang berisi informasi mengenai harga dan rincian katalog untuk barang dan jasa yang ditawarkan oleh penjual kepada pembeli.ORDCHGSebuah dokumen dari pembeli ke penjual yang menspesifikasikan detil permintaan pembeliuntuk mengubah pesanan pembelian yang terlanjur terkirim.ORDRSPSebuah dokumen yang dikirim penjual ke pembeli atas respon terhadap permintaan pesanan pembelian atau perubahan pesanan pembelian.IFTSTASebuah dokumen untuk melaporkan status transportasi dan/atau perubahan status transportasi (misalnya kejadian) antara kedua belah pihak.CUSDECPemberitahuan pabean yang berisi data PEB dan PKBE serta dokumen pelengkap pabean dengan standar UN/EDIFACT yang dikirim oleh eksportir/ kuasanya, konsolidator atau PJT ke Kantor Pabean.CUSRESRespon dengan standar UN/EDIFACT yang dikirim oleh Kantor atas Cusdec yang telah diterima sebelumnya.Menurut pendapat pribadi yang pernah utak-atik SQL, EDI itu rada-rada mirip, karena sama-sama dikirimkan ke sebuah nomor port tujuan yang disepakati pihak bisnis yang terlibat. Protokol untuk bertukar EDI bisa berupa SMTP, HTTP, FTP, ataupun turunan dari ketiga protokol tersebut yaitu AS1 (RFC 3335), AS2 (RFC 4130), AS3 (RFC 4832). Walmart [http://lib.ui.ac.id/detail?id=20369097] dan Amazon [http://s.id/a6y, http://s.id/a6z] memilih AS2 sebagai sarana bertukar surat EDI, AS2 untuk perusahaan masing-masing beralamat di http://gem.wal-mart.com:5080, EDI Indonesia di x2.edi-indonesia.co.id, sedangkan amazon di http://as2.amazonsedi.com/, as2-jp.amazonsedi.com, as2-eu.amazonsedi.com, as2-cn.amazonsedi.com, dan spscommerce di as2-01.spscommerce.net:7779/b2b,. Menurut dokumen Walmart Getting Started with EDI Implementation Guide yang diterbitkan pada bulan april 2014, perusahaan anda pantas menggunakan AS2 jika perusahaan anda mengirim lebih dari 5500 invoice per tahun, jika kurang bisa menggunakan AS2atauWebEDI. Sama seperti SQL, EDI juga ada badan yang mengatur standarisasinya, antara lain ANSI ASC X12, UN/EDIFACT, GS1 EANCOM, sedangkan format proprietary milik SAP sendiri yaitu iDoc, dan terakhir inovasi Microsoft bersama SAP bernama BizTalk Document tapi bentuknya berupa XML.

Berdagang cara lama sebelum 1970an di Kmart

Kmart adalah toserba dengan gudang yang tersebar di kota-kota besar di Amerika Serikat. SlimFast adalah salah satu pemasok penting untuk Kmart, atau mitra dagang. Tingkat inventaris Kmart telah mencapai titik pemesanan kembali (Reorder Point) untuk beberapa Stock-Keeping Unit (SKU) yang berbeda.
Pesanan PembelianPegawai bagian pembelian Kmart yang bertanggung jawab untuk rekening SlimFast menjalankan laporan Reorder Point dan menemui bahwa tingkat persediaan untuk beberapa SKU pada posisi atau dibawah Reorder Point. Setiap SKU mempunyai nomer bagian SlimFast unik, deskripsi, harga satuan kotak karton, berat (yang penting untuk perhitungan ongkos kirim), dan diskon grosir. Dengan metode tradisional, bagian pembelian menyiapkan formulir Permintaan Pembelian (Purchase Requisition) berwujud kertas dan menyerahkan kepada bagian Pembelian yang bertanggung jawab menyiapkan dan mengirim Pesanan Pembelian (Purchase Order) kepada pemasok Kmart.
Setelah Purchase Requisition di setujui, informasinya termasuk nomer SKU, jumlah, deskripsi barang, dimasukkan ke sistem pembelian Kmart dan kertas Purchase Order dicetak pada kertas. Dikarenakan jumlah pesanan yang besar, dokumen diletakkan kedalam amplop dan dikirimkan kepada manufaktur menggunakan jasa kilat khusus, sedangkan faksimile lebih sering digunakan untuk pemesanan kecil.
Faktur PenjualanKetika surat pesanan pembelian Kmart tiba di SlimFast, lalu surat tersebut diberikan kepada bagian pengolahan pesanan. Operator entri data menghabiskan hampir seharian penuh mengetik informasi pesanan pembelian kedalam sistem pengolahan pesanan SlimFast. Faktur penjualan dan slip kemasan dicetak. Sistem juga mengkredit rekening persediaan, pastinya juga mendebit rekening harga pokok penjualan. Selain itu juga menentukan berat berdasarkan nomer bagian dan jumlah yang dimasukkan oleh bagian pengolahan pesanan.
Lead TimeSlip kemasan diberikan kepada bagian pengiriman dan faktur tagihan dikirimkan kepada Kmart. Seluruh siklus mulai dari pesanan pembelian hingga penerimaan faktur tagihan menghabiskan waktu lebih dari seminggu. Ketika barang dagangan yang dipesan datang, beberapa SKU sudah habis. Keterlambatan pengiriman memaksa beberapa pelanggan toserba Kmart mencari toserba alternatif untuk minuman diet. Kmart punya tanggung jawab terhadap pelanggan mereka, dan tidak ingin pelanggan mereka beralih ke toserba lain. Memelihara loyalitas pelanggan adalah hal vital dalam sebuah bisnis yang kompetitif. Oleh sebab itu, toserba alternatif dicari untuk minuman diet yang biasanya disediakan Kmart. Hal ini adalah masalah serius untuk Kmart dan SlimFast, karena kepercayaan terhadap Kmart dan SlimFast terkikis oleh pelayanan yang buruk dan ceroboh.
KekeliruanAda masalah lain memperburuk situasi ini. Dikarenakan kekeliruan manusia sangat berpotensial terjadi yang dikarenakan oleh pengentrian manual informasi pembelian dan faktur penagihan, penanganan dokumen, salah alamat dan/atau pengiriman surat yang tertunda entah dengan berbagai kejadian yang tidak terduga, beberapa produk yang salah terlanjur diantarkan. Situasi out-of-stock di Kmart semakin memburuk, dan SilmFast harus membayar denda ongkos kirim untuk produk yang salah dikirim. Hal ini adalah lumrah adanya, dan tetap masih lumrah, untuk banyak perusahaan yang menggunakan transaksi berbasis kertas.
Pengaruh pada rekening piutang dan penagihan piutang yang jatuh tempoSetiap perusahaan yang mutakhir memonitor syarat dan ketentuan penjualan, dokumen rekening piutang yang jatuh tempo, dan penagihan. Perusahaan yang dikelola dengan baik melakukan berbagai macam cara yang bisa dilakukan untuk menetapkan dan lalu mencapai target penjualannya. Dan karena waktu dan uang adalah satu-kesatuan, penagihan berupa peringatan jatuh tempo dan pemungutan piutang dengan mendatangi pelanggan harus diberi prioritas. Dengan kata lain, setelah pesanan pembelian pelanggan yang jatuh tempo ditagih, pemungutan harus dilakukan segera dalam rangka menegakkan syarat termin pembayaran yang telah disepakati bersama. Menggunakan dokumen pemesanan dan penagihan yang diproduksi secara manual bisa memolorkan siklus penagihan beberapa hari dan bahkan minggu. Kekeliruan bisa memperpanjang transaksi-transaksi lebih jauh. Hal ini berarti bahwa sebuah perusahaan melalaikan target penjualan yang berlaku dikarenakan faktur yang terlambat dan pemungutan yang tertunda. Sebuah perusahaan yang menggunakan kredit berjangka mungkin diharuskan untuk membuat tarikan tambahan untuk memenuhi kewajiban yang berlaku. Hal ini meningkatkan pembayaran utang perusahaan dan akhirnya menurunkan profitabilitas perusahaan.
Ada LagiKekeliruan dan keterlambatan pengolahan dokumen yang dialami di pihak ritel-ke-manufaktur dari rantai pasok hanya mewakili bagian tambahan dari masalah. Isu-isu yang sama juga ada diantara bagian pembelian SlimFast dengan bagian pengelolaan pesanan pemasok bahan mentah yang digunakan dalam pengolahan bahan mentah.

Berdagang cara baru ala Kmart dengan menggunakan EDI

Pertukaran surat EDISekarang perhatikan transaksi yang sama antara Kmart dan SlimFast menggunakan EDI. Pertama, Kmart menerima katalog elektronik berupa dokumen EDI PRICAT dari SlimFast untuk memastikan bahwa semua nomer bagian, harga, dan kode status persediaan masih berlaku dan akurat. Sebagai tambahan, kedua perusahaan mempunyai sambungan data antara sistem pengendalian persediaan, pembelian, dan EDI.

Proses Bisnis Purchase Order dengan EDI

Sistem persediaan milik bagian pembelian Kmart secara otomatis memproduksi laporan permintaan pembelian, entah kalau sekarang pakai CRON Job atau apa. Laporan ini mengusulkan apa yang harus dipesan berdasarkan saldo rekening persediaan sekarang dan volume penjualan (atau perputaran persediaan). Bagian pembelian memeriksa pesanan dan membuat penyesuaian berdasarkan informasi tambahan yang mungkin memerlukan perubahan. Sebagai contoh, jika model baru yang akan diluncurkan menggantikan SKU yang ada, maka pihak pembeli mungkin ingin memesan item baru dan membatalkan pesanan untuk produk yang lama. Jika pelanggan ritel mempunyai indikasi untuk meningkatkan jumlah pesanan untuk SKU tertentu, maka bagian pembelian ritel harus meningkatkan jumlah pemesanan berdasarkan pengetahuan tersebut, adapun rumus-rumus untuk memprediksi tren atau musiman sebuah SKU antara lain diterangkan lebih lanjut di artikel Data Mining: Algoritma Forecast untuk Meramal Permintaan Pencukur Bulu di Toserba Waljinah (bag. 1). Oleh sebab itu, manusia berkuasa atas sistem, karena mereka mempunyai informasi yang tidak bisa diantisipasi oleh sistem.
Setelah pembeli mengeluarkan pesanannya, pesanan pembelian elektronik dihasilkan sebagai surat EDI dan dimasukkan kedalam kotak surat elektronik SlimFast. Ketika SlimFast memeriksa kotak masuk EDI mereka, mereka mengunduh surat EDI Kmart bersamaan dengan surat EDI lainnya yang mungkin juga ada. Surat digolongkan kedalam map yang berbeda yang biasanya digunakan untuk menyimpan surat dari setiap pelanggan atau pemasoknya SlimFast. Ketika surat EDI dari Kmart diolah, paling tidak delapan hal yang dihasilkan:    

1. Surat resi penerimaan (CONTRL)
2. Surat faktur tagihan (INVOIC)
3. Slip pengepakan untuk pelanggan (DESADV)
4. Tiket pengambilan untuk bagian pengiriman
5. Pendebitan rekening riil aktiva piutang dagang untuk Kmart
6. Pengkreditan rekening nominal penjualan
7. Pendebitan rekening nominal Harga Pokok Penjualan (Cost of Goods Sold)
8. Pengkreditan rekening riil akiva persediaan

Seberapa lama waktu yang dibutuhkanDalam beberapa menit, SlimFast mengirim surat EDI CONTRL (balasan fungsional) yang mirip-mirip seperti proses jabat tangan di protokol TCP atau tanda terima resi dari Bapak POS dan surat EDI INVOIC (faktur tagihan) kepada Kmart dengan memasukkan dokumen tersebut kedalam kotak keluar  milik pihak ketiga penyedia jasa VAN seperti IBM Advantis (gabungan IBM & Sears) atau General Electric melalui modem 3270 BISYNC mereka.
Pihak penyedia jasa VAN secara otomatis menyampaikan surat EDI untuk Kmart kedalam kotak masuk milik Kmart, dimana kotak masuk tersebut menunggu (listen kalau dalam pemrograman socket) pengambilan surat. Seluruh transaksi, dari pesanan pembelian hingga faktur penagihan, dapat terjadi dalam hitungan menit tentu saja tergantung pada seberapa sering setiap mitra dagang memeriksa (pull kalau istilah di protokol POP3) kotak surat EDI. Langkah terakhir dalam proses adalah ketika Kmart mengambil dan mengolah surat EDI INVOIC dari SlimFast. Ketika hal ini selesai dilakukan, Kmart mengirimkan surat EDI CONTRL (balasan fungsional) kepada SlimFast untuk menotifikasi SlimFast bahwa faktur telah diterima dan selesai diolah.
Seberapa banyak kekeliruan yang terjadiHal ini tidaklah mungkin terjadi kekeliruan, sepanjang informasi orisinal sudah akurat. Ketika informasi yang dimasukkan adalah sampah dalam pertukaran EDI, (kok saya jadi teringat konsep cleaning didalam proses ETL ya?), hal ini hampir selalu tertangkap dalam transaksi awal. Jika data sampah berasal dari pesanan pembelian bagian pembelian perusahaan, kekeliruan akan ditandai karena data tidak cocok dengan data yang ada di basis data vendor. Hal ini benar jika sistem pembelian memasukkan data yang berasal dari katalog elektronik yang dihasilkan oleh manufaktur berupa dokumen EDI PRICAT. Katalog elektronik ini umumnya dihasilkan dari basis data persediaan manufaktur. Oleh karena itu, hal ini akan cocok secara akurat dengan informasi dari manufaktur. Lebih lanjut lagi, data hasil komputer terisolasi dari kekeliruan entri data manual, menjamin reliabilitas yang tinggi.
Berapa banyak BURUH yang terlibat?Dalam hal surat EDI yang dihasilkan oleh sistem, satu buruh untuk setiap perusahaan mitra dagang umumnya mencukupi semua pertukaran surat tersebut (lihat lowongan dari perusahaan SlimFast berikut dari indeed.com Order Desk Analyst). Tentu saja, terkecuali gudang yang otomatis seperti Amazon.com dibawah berikut, bagian pengiriman dan penerimaan masih harus menggunakan tenaga buruh untuk memilih, memuat, mengirimkan, menerima, membongkar, dan menyimpan pesanan. Sistem otomasi yang tinggi tersebut melibatkan biaya tetap yang tinggi pula dan biasanya disebut teknologi padat modal (Capital Intensive)

hqdefault.jpg

Motif PribadiMotif saya itu hanya heran dengan CURRICULUM VITAE-nya Roy Thomas Fielding yang berada di dalam disertasinya, beliau itu merancang RESTful WEB API sudah Mei 1998 di Microsoft Research, Redmond, Washington, dengan judul presentasi Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction. Selain itu ada pula Dave Winer pada hari Jum'at, tanggal 27 Februari 1998, beliau itu membuat tulisan RPC over HTTP via XML, membahas mengenai XML-RPC yang juga digunakan oleh Matt Mullenweg penemu WordPress di CMS miliknya, Blogger yang dibeli Google itupun juga punya Blogger API yang memakai XML-RPC hasil pemikiran Dave Winer, dan sejak WordPress 4.4 sedang heboh RESTful, aneh gak?, pun Drupal 8 selesai diubah ke RESTful, selain itu ada pula Alex Hopmann pembuat XMLHttp di peramban Internet Explorer 1999 silam, berikut tulisannya The story of XMLHTTP, dan juga ada Don Box yang menulis A Brief History of SOAP, menceritakan kalau beliau mengembangkan SOAP bersama-sama Dave Winer, Bob Atkinson, dan Mohsen Al-Ghosein di awal 1998, tapi baru dipublikasikan ke publik melalui IETF pada tanggal 13 September 1999 berikut SOAP: Simple Object Access Protocol, tapi sayangnya draft tersebut tidak pernah menjadi RFC, lah terus objek XMLHTTP yang dibuat oleh Alex Hopmann tersebut di dalam buku XML and SOAP Programming for BizTalk™ Servers digunakan untuk memanggil SOAP server milik manufaktur guna mengantarkan Purchase Order yang berwujud BizTalk Document. Tapi buku itu terbit sudah 30 Agustus 2000, sedangkan Biztalk Server 2000 baru aja diluncurkan hari Selasa, 12 Desember 2000, tepat bersamaan waktunya dengan PBB bersama SUN Microsystem mengumumkan pencapaian bersama standar ebXML, Microsoft and Sun in new clash. Hm, tapi kalau bingung tentang ide paragraf saya ini, gambaran besar tentang interaksi SOAP Web Service, ERP, dan segalanya sudah dijelasken panjang lebar oleh tautan berikut Microsoft Commerce Server 2000: Commerce and BizTalk Server Integration, lha karena tulisan saya ini tulisan teknis, bagi yang ingin mencerna dengan bahasa CEO gituh ya silahkan baca sendiri pidatonya Bill Gates tanggal 4 Maret 1999 berikut ini Remarks by Bill Gates, Microsoft Corporation, Commerce Solutions Briefing, namun entah kenapa tautan http://microsoft.com/billgates/speeches/03-04csb.htm ketika langsung dibuka tanpa melalui web.archive.org, malah dialihkan ke transkrip pidatonya Bill Gates yang lain di tahun 2008, Bill Gates Keynote: Microsoft Tech•Ed 2008 — Developers.
Kapan-kapanKapan-kapan pengen belajar Kelas dan Metode berikut ah

1. Microsoft.CommerceServer.Runtime.Dictionary
2. Microsoft.CommerceServer.Interop.DictionaryXMLTransforms
3. Microsoft.Biztalk.BTSInterchange.submit()
4. com.seeburger.dt.security.smime.SMIMEEnvelopedGenerator
5. System.Security.Cryptography.Pkcs.SignedCms
6. iaik.security.smime.SignedContent
7. org.bouncycastle.mail.smime.SMIMESignedGenerator
8. com.sap.conn.idoc.IDocDocument
9. com.sap.conn.idoc.IDocXMLProcessor
10. com.sap.conn.idoc.jco.JCoIDoc.send()
11. com.sun.xml.messaging.jaxm.ebxml.EbXMLMessageImpl
12. javax.xml.messaging.ProviderConnection.send()
13. com.google.firebase.messaging.RemoteMessage
14. com.google.firebase.messaging.FirebaseMessaging.send()
15. openssl_pkcs7_sign
16. metroplex-systems\Metroplex\Edifact\Message
17. AS2Client
18. forge.pkcs7.createSignedData