Integrasi ATP dan CTP membantu menghubungkan pertanyaan sales tentang tanggal pesanan dengan bukti stok, pasokan, dan kemampuan produksi. Tantangan utamanya bukan sekadar mengembalikan sebuah tanggal melalui API. Sistem perlu menjelaskan tanggal apa, untuk kuantitas berapa, berdasarkan data kapan, dan apakah jawabannya sudah mengikat sumber daya.
Artikel ini ditujukan bagi sales operations dan integration lead yang merancang alur konfirmasi pesanan lintas aplikasi. ATP dan CTP memiliki rincian implementasi berbeda antarproduk. Karena itu, sepakati makna hasil pemeriksaan pada sistem perusahaan sebelum menyamakan nama fitur.
Bedakan Pemeriksaan Stok dan Kemampuan Memenuhi
Secara umum, available-to-promise memeriksa pasokan yang dapat dijanjikan sesuai aturan perhitungan produk. Capable-to-promise dapat melibatkan kemampuan memenuhi kebutuhan melalui perencanaan produksi atau pengadaan. Jangan menganggap seluruh implementasi ATP menghitung kapasitas mesin atau semua CTP langsung membuat reservasi.
Dokumentasi primer Microsoft Dynamics 365, Order promising, menjelaskan beberapa metode pemeriksaan tanggal, termasuk ATP dan CTP. Ini referensi istilah dari vendor. Kontrak integrasi berikut adalah rekomendasi desain yang perlu disesuaikan dengan mesin perencanaan, versi produk, dan konfigurasi aktual.
Rancang Permintaan yang Cukup Spesifik
Permintaan pemeriksaan minimal membawa identitas baris pesanan, item dan revisi yang relevan, kuantitas, satuan, lokasi pemenuhan, tujuan, serta tanggal yang diminta pelanggan. Bila satu pesanan boleh dipenuhi sebagian, nyatakan batas minimum atau aturan pembagiannya.
Tambahkan identitas versi permintaan. Perubahan kuantitas atau alamat pengiriman harus menghasilkan pemeriksaan baru ketika memengaruhi pemenuhan. Jawaban lama tidak boleh ditempelkan pada pesanan yang sudah berubah hanya karena nomor pesanan tetap sama.
Untuk pesanan yang perlu diproduksi, jawaban perlu mempertimbangkan kelayakan jadwal pada finite capacity ERP. Ketika kondisi lapangan berubah, status mesin IoT untuk penjadwalan dapat memicu review kapasitas sebelum tanggal diperiksa kembali.
Jawaban Harus Menyatakan Kondisi
- Tanggal barang siap, tanggal berangkat, dan tanggal tiba dibedakan.
- Kuantitas yang dapat dipenuhi dicatat per gelombang bila ada pengiriman sebagian.
- Sumber data dan waktu perhitungan terlihat.
- Ketergantungan material atau persetujuan yang belum selesai dijelaskan.
- Masa berlaku serta status reservasi dinyatakan.
- Alasan tidak dapat memenuhi tanggal diminta tersedia bagi petugas berwenang.
Jika sistem belum dapat menghitung tanggal tiba, kembalikan tanggal kirim dan tandai tanggal tiba belum tersedia. Mengisi keduanya dengan angka yang sama menciptakan kepastian palsu. Waktu angkut memerlukan acuan rute, layanan, kalender, dan kondisi yang sesuai.
Pisahkan Check dari Commit
Pemeriksaan memberi gambaran kelayakan. Commit membuat komitmen yang disepakati, misalnya reservasi stok atau pengikatan rencana. Pemisahan ini berguna selama antarmuka jelas: sales tidak boleh mengartikan jawaban check sebagai konfirmasi final bila sumber daya masih bisa dipakai pesanan lain.
Dalam skenario ilustratif, dua permintaan membaca sisa stok yang sama. Ketika keduanya dikonfirmasi, hanya jumlah yang benar-benar tersedia boleh terikat. Desain perlu menangani persaingan secara atomik pada sistem pemilik stok atau mekanisme yang setara. Mengurangi stok di aplikasi sales saja tidak mengendalikan transaksi dari kanal lain.
Tangani Timeout sebagai Ketidakpastian
Jika permintaan commit timeout, jangan langsung mengirim ulang sebagai transaksi baru. Simpan identitas operasi yang stabil dan baca status pada sistem tujuan. Jawaban jaringan yang hilang tidak membuktikan reservasi gagal. Pengulangan tanpa deduplikasi dapat membuat pesanan terikat dua kali.
Gunakan status yang bisa ditindaklanjuti: menunggu verifikasi, berhasil terikat, ditolak dengan alasan, atau perlu review. Status teknis seperti error umum tidak cukup bagi sales untuk menjelaskan apakah pesanan boleh dikonfirmasi. Proses pemulihan harus mempertahankan identitas transaksi awal.
Perubahan dan Pembatalan Memerlukan Rekonsiliasi
Ketika kuantitas diturunkan, pastikan bagian reservasi yang tidak diperlukan dilepas pada sistem pemiliknya. Jika pembatalan di sales berhasil tetapi pelepasan di ERP belum selesai, tandai pekerjaan pemulihan. Jangan menganggap kedua aplikasi konsisten hanya karena pesan pembatalan sudah dikirim.
Untuk pergantian lokasi pemenuhan, tentukan apakah reservasi lama harus dilepas sebelum yang baru dibuat. Ada tradeoff antara menahan dua sumber daya sementara dan kehilangan ketersediaan. Pemilik proses perlu memilih perilaku serta batas waktunya, lalu mengujinya dengan kondisi gagal di tengah alur.
Uji dari Sudut Pandang Petugas
Gunakan skenario dua pengguna bersamaan, jawaban terlambat, pengiriman sebagian, konversi satuan, tanggal libur, pesanan berubah setelah check, dan pembatalan parsial. Periksa pesan yang diterima pengguna, hak untuk override, serta catatan siapa yang menyetujui pengecualian.
Hasil yang dicari adalah konfirmasi yang dapat ditelusuri dan dipulihkan, bukan sekadar API yang merespons sukses. Ukur jumlah komitmen ganda, antrean verifikasi, dan waktu penyelesaian exception. Batas penerimaan harus disepakati sebelum pilot; jangan diturunkan setelah pengujian gagal.
Siapkan diagram aplikasi, contoh payload tersanitasi, serta aturan reservasi untuk pembahasan integrasi sistem dan API. Diskusikan integrasi konfirmasi pesanan bersama Layana.ID agar kepemilikan transaksi dan jalur pemulihannya terdefinisi sebelum implementasi.