Integrasi data maklon paling mudah terlihat berhasil ketika pengiriman dan penerimaan normal. Masalah justru muncul saat vendor mengirim hasil dua kali, memperbaiki kuantitas setelah transaksi diproses, atau melaporkan konsumsi setelah pesanan ditandai selesai. Kontrak data perlu dirancang untuk kejadian tersebut sejak awal.
Fokus artikel ini adalah pertukaran informasi antara perusahaan pemilik pekerjaan dan pengolah eksternal. Model berikut merupakan rekomendasi arsitektur operasional. Pilihan API, portal, atau impor berkas bergantung pada kemampuan kedua pihak; perubahan hak akses dan kontrak komersial memerlukan persetujuan tersendiri.
Definisikan Kejadian Bisnis Sebelum Endpoint
Daftar kejadian awal dapat mencakup bahan dikirim, bahan diterima vendor, pemakaian dilaporkan, hasil dikirim, hasil diterima, sisa diretur, dan koreksi diajukan. Bedakan pengiriman laporan dari persetujuan transaksi. Pesan “hasil dikirim” dari vendor tidak otomatis sama dengan penerimaan fisik atau pelepasan mutu oleh perusahaan.
Standar GS1 EPCIS menjelaskan pertukaran informasi visibilitas mengenai objek, waktu, lokasi, dan konteks kejadian. Prinsip tersebut membantu menyusun pertanyaan data. Menggunakan prinsipnya tidak sama dengan menyatakan integrasi telah memenuhi EPCIS; kesesuaian standar memerlukan penelaahan tersendiri.
Tentukan Identitas Pesan dan Referensi Bisnis
| Field | Tujuan | Kesalahan yang Dicegah |
|---|---|---|
| event_id | Identitas kejadian yang stabil | Pesan ulang dianggap transaksi baru |
| order_id dan shipment_id | Hubungan pesanan dan pengiriman | Konfirmasi masuk ke kiriman salah |
| material, lot, quantity, unit | Objek dan ukuran transaksi | Jumlah berbeda satuan dijumlahkan |
| occurred_at dan received_at | Waktu kejadian dan waktu diterima sistem | Urutan terlambat disamarkan |
| correction_of | Referensi koreksi | Angka baru menimpa bukti lama |
Sepakati format identitas bersama vendor. Nomor yang hanya unik dalam satu cabang perlu digabung dengan identitas entitas atau lokasi. Jangan memakai tanggal dan nomor urut lokal sebagai identitas global tanpa aturan. Jika berkas spreadsheet dipakai, simpan identitas kejadian sebagai kolom wajib yang tidak berubah saat berkas dikirim ulang.
Pesan Duplikat Harus Mengembalikan Hasil yang Konsisten
Ketika koneksi putus setelah server memproses transaksi, pengirim mungkin tidak menerima jawaban. Pengiriman ulang dengan identitas yang sama perlu dibaca sebagai kejadian yang sama. Simpan status pemrosesan dan hasilnya, lalu kembalikan referensi transaksi yang sudah dibuat. Jangan hanya mengandalkan operator untuk mengingat bahwa pesan pernah dikirim.
Jika identitas sama datang dengan isi berbeda, tahan sebagai konflik. Membiarkannya menjadi pembaruan otomatis dapat mengubah saldo tanpa proses koreksi. Simpan hash payload atau versi data sebagai alat pembanding, tetapi jangan memperlakukannya sebagai pengganti identitas bisnis dan bukti persetujuan.
Hasil Parsial Memerlukan Identitas Penerimaan Sendiri
Bayangkan satu pesanan menghasilkan dua pengiriman hasil. Masing-masing mempunyai identitas, tanggal, lot, serta jumlah. Integrasi perlu menampilkan hasil kumulatif dan sisa pekerjaan tanpa menghitung ulang keseluruhan laporan pertama. Nomor pesanan saja tidak cukup untuk membedakan penerimaan parsial.
Jika hasil kedua datang sebelum konfirmasi bahan awal, sistem dapat menahannya pada antrean pengecualian. Pemilik proses menentukan apakah ada dokumen yang terlambat, proses yang memang diizinkan, atau kesalahan pemetaan. Integrasi tidak seharusnya membuat bahan penerimaan fiktif hanya agar urutan transaksi lolos.
Pisahkan Koreksi, Pembatalan, dan Penghapusan
Koreksi kuantitas harus menunjuk kejadian awal dan menjelaskan alasan. Pembatalan mempunyai dampak berbeda dari pengiriman data pengganti. Tetapkan aturan apakah koreksi memerlukan persetujuan, bagaimana transaksi turunan diperiksa, dan apa yang terjadi bila periode sudah ditutup. Penyimpanan riwayat memungkinkan investigasi tanpa menebak versi mana yang benar.
- Validasi struktur memeriksa field dan tipe data.
- Validasi referensi memeriksa vendor, lokasi, pesanan, dan lot yang dikenal.
- Validasi bisnis memeriksa status serta batas transaksi yang diizinkan.
- Persetujuan menentukan apakah kejadian yang valid boleh menjadi transaksi operasional.
Hak vendor perlu dibatasi ke datanya sendiri. Pesan tidak boleh memperoleh akses hanya karena menyebut nomor pesanan yang benar. Tentukan identitas pengirim, cakupan entitas, serta informasi yang boleh dikembalikan dalam pesan kesalahan. Hindari memasukkan data sensitif ke log operasional yang dapat dilihat lintas vendor.
Pantau Antrean yang Membutuhkan Tindakan
Jumlah pesan sukses berguna untuk kesehatan transport, tetapi tidak membuktikan seluruh pesanan selesai direkonsiliasi. Pantau pesan belum dipasangkan, konflik identitas, koreksi menunggu persetujuan, serta kejadian yang terlambat. Masing-masing perlu PIC, usia antrean, dan tindakan berikutnya. Jangan mengirim ulang semua pesan gagal tanpa melihat apakah transaksi sebenarnya sudah terjadi.
Sebelum meminta penawaran integrasi sistem dan API Layana.ID, siapkan contoh pesan normal, hasil parsial, pesan ganda, serta koreksi. Sertakan sistem sumber, sistem tujuan, identitas pengirim, dan bukti yang diharapkan setelah pemrosesan. Ini membantu menetapkan kontrak data dan skenario penerimaan yang dapat ditinjau bersama.
Hubungan dengan Alur Maklon Lainnya
Arti setiap kejadian harus konsisten dengan pembagian tanggung jawab produksi maklon dan model saldo bahan di subkontraktor. Jika kuantitas bersumber dari perangkat, rancang pula hubungan sesi timbang IoT dengan surat jalan agar angka dapat ditelusuri ke dokumen yang benar.
Pertanyaan Implementasi
Haruskah Vendor Langsung Menyediakan API?
Tidak. Impor terstruktur dapat menjadi tahap awal selama identitas, validasi, dan koreksi konsisten. Pertimbangkan volume kejadian, frekuensi, serta kemampuan dukungan sebelum memilih transport.
Apakah Respons Sukses Berarti Barang Sudah Diterima?
Respons sukses hanya membuktikan tahap yang didefinisikan kontrak API. Penerimaan fisik, pemeriksaan mutu, dan persetujuan harus mempunyai bukti serta status terpisah.