Panduan Integrasi Monitor ERP untuk Penjadwalan Produksi dengan SkyPlanner APS

Antarmuka integrasi Monitor G5 yang terdokumentasi adalah Monitor ERP API v1. Antarmuka ini memadukan CQRS dan REST dengan JSON melalui HTTPS. (Monitor ERP API)

• Queries membaca data dengan GET dan menerima opsi bergaya OData: $filter, $select, $expand, $orderby, $top, dan $skip.
• Commands menulis data dengan POST, misalnya Manufacturing/ManufacturingOrderOperations/Update.
• Batch menjalankan beberapa perintah dalam satu transaksi melalui POST /api/v1/Batch: semuanya berhasil atau tidak ada yang diterapkan. Tambahkan /Simulate atau /Validate untuk menguji batch lalu membatalkan perubahannya. Inilah cara aman untuk menulis seluruh jadwal. (Batch)

URL dasarnya adalah https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Nomor perusahaan menggabungkan nomor basis data dan ID perusahaan, misalnya 004.1.

Mengenai lisensi, Monitor menyatakan: “It is free to query and extract information from the API for all our customers. However, in order to use commands and write data to the ERP system, you need to purchase Monitor ERP API.” (Semua pelanggan kami dapat menjalankan kueri dan mengambil informasi dari API secara gratis. Namun, untuk menggunakan perintah dan menulis data ke sistem ERP, Anda harus membeli Monitor ERP API.) Masukkan lisensi untuk akses tulis ke dalam rencana proyek sejak hari pertama. (api.monitor.se)

Referensi Monitor ERP API tidak mendokumentasikan webhook atau langganan peristiwa. Perubahan dideteksi melalui polling:

• Common/EntityChangeLogs (mulai 2.33) mengembalikan ChangeType (Update, Create, Delete), EntityTypeId, EntityId, dan ModifiedTimestamp. Lakukan polling setiap beberapa menit dan ambil hanya rekaman yang berubah. (EntityChangeLog)
• Filter kueri perintah produksi agar hanya mencakup perintah yang masih terbuka, lalu gunakan $top dan $skip untuk paginasi.

SkyPlanner mengirim webhook saat status atau jadwal berubah, sehingga penulisan kembali data dipicu oleh peristiwa.

1. Pemuatan awal master data. Baca data work center, baris operasi, baris operasi alternatif, baris material, item, dan jadwal. Petakan setiap work center ke stasiun kerja SkyPlanner dengan cermat. Work center bertipe Pool menjadi kelompok stasiun kerja, sedangkan work center yang tergabung di dalamnya menjadi stasiun kerja yang dapat dipilih oleh mesin penjadwalan.

2. Sinkronisasi perintah produksi. Baca perintah produksi yang masih terbuka beserta node, operasi, dan materialnya, serta data stok dan pesanan pembelian yang masih terbuka. SkyPlanner menganggap material yang dipesan tersedia pada tanggal pengiriman PO dan memperbarui stok saat PO ditandai Delivered. Setelah pemuatan pertama, Common/EntityChangeLogs menjadi dasar untuk mengambil perubahan data.

3. Penulisan kembali jadwal. Untuk setiap operasi yang ditempatkan atau dipindahkan oleh mesin penjadwalan, SkyPlanner mengirim ManufacturingOrderOperations/Update dengan PlannedStartDate dan PlannedFinishDate. Jika mesin penjadwalan memindahkan operasi ke mesin lain dalam satu pool, SetWorkCenter dikirim terlebih dahulu. Perintah untuk satu perintah produksi dimasukkan ke dalam satu Batch, sehingga Monitor menerima semuanya atau tidak menerima satu pun. Jalankan batch melalui /Validate selama pengujian.

Pada versi Monitor sebelum 24.5, tanggal yang direncanakan tidak dapat ditulis melalui Update. Sebagai gantinya, gunakan ManufacturingOrders/ReplanOperation (mulai 2.40) dengan StartDate dan FinishDate, lalu atur RestrictToOrderBounds sesuai aturan Anda.

4. Konfirmasi dari lantai produksi. Gunakan satu saluran pelaporan saja:

• Monitor tetap menjadi saluran pelaporan. Operator melaporkan pekerjaan melalui Recording terminal atau integrasi mesin seperti saat ini. SkyPlanner membaca ManufacturingOrderOperationReportings sebagai data kemajuan dan menyusun ulang jadwal.
• SkyPlanner menjadi saluran pelaporan. Operator mencatat pekerjaan dengan Mobile Confirmations atau Production Timer, lalu SkyPlanner mengirim ReportManufacturingOrderOperation ke Monitor.

Pelaporan dari kedua sistem menyebabkan waktu dan kuantitas tercatat ganda.

5. Aturan kepemilikan data dan penanganan konflik. Dokumentasikan aturan ini sebelum sistem mulai digunakan:

Sumber konflik utama adalah perencana yang masih mengubah rencana prioritas. Rescheduling according to New finish dan tindakan menyeret baris di Priority planning menimpa tanggal yang ditulis SkyPlanner. Setelah SkyPlanner mengendalikan urutan operasi, Priority planning hanya digunakan sebagai tampilan. Dengan Autopilot, SkyPlanner menjadwalkan ulang secara otomatis saat terjadi perubahan produksi.

• Faktor ketersediaan. Monitor mengurangi kapasitas bruto menjadi kapasitas neto dengan faktor ketersediaan, yang secara default bernilai 80 % pada work center baru. Terapkan faktor ini satu kali saja, baik sebagai efisiensi di SkyPlanner maupun dengan memperpendek shift, jangan keduanya.
• Ketelitian waktu. Work center yang menggunakan Day planning menyimpan kapasitas sebagai waktu dasar per hari, tanpa waktu shift. Petakan shift aktual di SkyPlanner berdasarkan jadwal produksi agar pekerjaan dijadwalkan dalam jam kerja.
• Waktu antre dan tumpang tindih. Baris operasi memuat waktu antre dan tumpang tindih dalam %. Tentukan pemetaan masing-masing ke SkyPlanner saat penentuan lingkup. Jika tidak, waktu penyelesaian akan berubah setelah sistem mulai beroperasi.
• Kelompok work center. Work center dalam kelompok direncanakan melalui Pool planning, bukan Priority planning. Baca data work center yang tergabung di dalamnya, bukan hanya baris kelompoknya.
• Persyaratan versi. Penulisan tanggal rencana melalui Update memerlukan versi 24.5. Kolom kapasitas work center dalam API memerlukan versi 24.3, sedangkan OIDC memerlukan versi 25.8. Periksa build sebelum penentuan lingkup.
• Jaringan dan sertifikat. Monitor yang dipasang di server lokal menyediakan API pada port 8001 dengan sertifikat yang ditandatangani sendiri. SkyPlanner berjalan di cloud, jadi siapkan aturan firewall atau relay dan atur agar sertifikat tersebut dipercaya secara eksplisit.
• Lisensi. Setiap aplikasi pihak ketiga yang menulis data memerlukan pengguna dengan lisensi API tersendiri. Setiap sistem sudah dilengkapi satu pengguna API dengan akses hanya baca.