Approval Policy

Approval Policy adalah DocType konfigurasi sentral yang mendefinisikan kapan, bagaimana, dan oleh siapa alur approval dipicu. Setiap kebijakan menentukan kondisi di mana approval diperlukan dan perilaku dari proses approval yang dihasilkan.

Gambaran Umum

Approval Policy bertindak sebagai template yang secara otomatis membuat System Approvals ketika kondisi spesifik terpenuhi. Mereka memberikan kontrol penuh atas:

• Kondisi pemicu - Event DocType mana yang memulai alur approval
• Kriteria filter - Kondisi bisnis yang harus dipenuhi
• Persyaratan approval - Siapa yang harus menyetujui dan dengan cara apa
• Penguncian dokumen - Apakah dokumen harus dikunci selama approval
• Efek pasca-keputusan - Tindakan yang diambil setelah penyelesaian approval
• Manajemen SLA - Waktu, pengingat, dan aturan eskalasi

Referensi Kolom

Konfigurasi Dasar

Opsi DocType Event

• After Insert - Memicu kebijakan ketika dokumen baru dibuat
• After Save - Memicu kebijakan ketika dokumen disimpan (baru atau yang sudah ada)
• After Submit - Memicu kebijakan ketika dokumen disubmit
• After Cancel - Memicu kebijakan ketika dokumen yang disubmit dibatalkan
• After Delete - Memicu kebijakan ketika dokumen dihapus
• After Save (Submitted Document) - Memicu kebijakan ketika dokumen yang disubmit dimodifikasi

Kondisi Filter

Sistem filter menggunakan antarmuka yang sama seperti Business Rules, memungkinkan logika kondisional kompleks berdasarkan nilai kolom dokumen.

⚠️ Penting untuk Mencegah Pengulangan Rekursi: Kondisi filter harus dirancang dengan hati-hati untuk menghindari pemicuan ulang approval ketika efek pasca-keputusan memodifikasi dokumen.

Konfigurasi Approval

Opsi Penguncian Dokumen

• Hard Lock - Dokumen tidak dapat dimodifikasi hingga approval selesai
• None - Dokumen tetap dapat dimodifikasi selama proses approval (Catatan: Hanya satu approval per dokumen yang diizinkan terlepas dari perilaku lock)

Opsi Approval Mode

• All - Setiap approver yang ditunjuk harus menyetujui
• Any One - Hanya memerlukan satu approval dari approver yang ditunjuk
• Count(n) - Jumlah approval yang diperlukan (diatur melalui kolom Approval Count)

Opsi Approval Source

• Users - Approver dipilih dari daftar pengguna spesifik
• User Groups - Approver dipilih dari anggota grup pengguna saat alur approval berjalan

Efek Pasca-Keputusan

Konfigurasi Field Setter

Setiap baris field setter berisi:

• Field: Nama kolom target dalam dokumen referensi
• Value: Nilai yang akan diatur dalam kolom target

⚠️ Peringatan Kritis - Mencegah Pengulangan Rekursif: Field setter dapat secara tidak sengaja memicu kebijakan approval yang sama lagi, menciptakan pengulangan rekursif. Selalu pastikan kondisi filter mengecualikan nilai yang Anda tetapkan.

SLA dan Eskalasi

Pengaturan Notifikasi

Prosedur

Membuat Kebijakan Approval

1. Navigasikan ke Policies: Pergi ke daftar Approval Policy di workspace Develop
2. Buat Baru: Klik Add Approval Policy
3. Setup Dasar:
   • Masukkan Policy Name yang deskriptif
   • Pilih target Reference DocType
   • Pilih DocType Event yang memicu
   • Tautkan ke Application yang sesuai
   • Centang Active untuk mengaktifkan kebijakan
4. Konfigurasi Kondisi (Penting untuk Pencegahan Rekursi):
   • Gunakan antarmuka Filter List untuk mendefinisikan kapan kebijakan harus dipicu
   • Penting: Sertakan kondisi yang mengecualikan dokumen yang dimodifikasi oleh efek pasca-keputusan
   • Biarkan kosong untuk memicu pada semua dokumen dari target DocType (tidak direkomendasikan)
5. Atur Persyaratan Approval:
   • Pilih Lock Behavior (Hard Lock direkomendasikan untuk proses kritis)
   • Pilih Approval Mode berdasarkan kebutuhan Anda
   • Atur Approval Count jika menggunakan mode Count(n)
   • Pilih Approval Source (Users atau User Groups)
   • Konfigurasi approver spesifik berdasarkan pilihan sumber Anda
6. Konfigurasi Efek (Penting untuk Pencegahan Rekursi):
   • Tambahkan field setter untuk skenario On Approve dan On Reject
   • Pastikan kondisi filter mengecualikan nilai yang Anda tetapkan
   • Tautkan Script Functions untuk pemrosesan pasca-keputusan yang kompleks
   • Script functions tidak boleh memodifikasi kolom yang dapat memicu ulang kebijakan
7. Atur Aturan SLA (Opsional):
   • Definisikan Due In Hours untuk batas waktu approval
   • Konfigurasi Reminder Every Hours untuk notifikasi berkala
   • Atur aturan eskalasi dengan Escalate After Hours dan target
8. Aktifkan Notifikasi:
   • Centang saluran notifikasi yang diinginkan (Email, SMS, Slack)
   • Pastikan konfigurasi yang tepat dalam pengaturan sistem untuk saluran yang dipilih
9. Simpan dan Uji: Simpan kebijakan dan uji dengan dokumen sampel

Validasi Policy

Sistem secara otomatis memvalidasi kebijakan selama penyimpanan:

Validasi Approval Mode

• Mode Count(n) memerlukan Approval Count yang valid
• Approval Count tidak dapat melebihi jumlah approver yang tersedia
• Approval Count harus minimal 1

Validasi Approver

• Sumber Users memerlukan setidaknya satu pengguna dalam tabel Approval Users
• Sumber User Groups memerlukan setidaknya satu grup dengan anggota aktif
• Grup divalidasi untuk memastikan mereka berisi pengguna aktif

Validasi Eskalasi

• Escalate After Hours memerlukan Escalate To User atau Escalate To Role
• Target eskalasi divalidasi untuk keberadaan dan status aktif

Contoh Pencegahan Rekursi dengan Filter

# Jika menetapkan approval_status = "Approved" saat approve
approval_status != "Approved"

# Jika menetapkan workflow_state = "Pending Approval" 
workflow_state != "Pending Approval"

# Pertimbangan beberapa kolom
approval_status != "Approved" AND approval_status != "Rejected" AND processed != 1

Praktik Terbaik untuk Pencegahan Rekursi

Desain Field Setter

1. Selalu Kecualikan Nilai Target: Jika menetapkan status = "Approved", tambahkan kondisi status != "Approved"
2. Pertimbangkan Semua Kolom yang Dimodifikasi: Sertakan semua kolom yang diatur dalam logika pengecualian Anda
3. Gunakan Kolom Status/Flag: Buat kolom khusus seperti approval_processed untuk mencegah pemicuan ulang
4. Uji Secara Menyeluruh: Selalu uji efek pasca-keputusan untuk memastikan tidak terjadi rekursi

Desain Script Function

1. Periksa Flag Pemrosesan: Gunakan flag untuk mencegah pemrosesan duplikat
2. Hindari Memicu Event: Hati-hati ketika memanggil doc.save() dari script
3. Gunakan Logika Kondisional: Periksa status approval sebelum membuat perubahan
4. Dokumentasikan Modifikasi: Dokumentasikan dengan jelas kolom apa yang dimodifikasi script Anda

Contoh Pola Aman

Konfigurasi Field Setter yang Aman

Policy: Sales Order approval when amount > 10000
Filter: amount > 10000 AND approval_status != "Approved" AND approval_status != "Rejected"
On Approve Set Field: approval_status = "Approved"
On Reject Set Field: approval_status = "Rejected"

Pola Script Function yang Aman

# Script Function: process_approval_completion
if not doc.get('approval_processed') and approval.status in ['Approved', 'Rejected']:
    # Aman untuk diproses karena kita memeriksa flag
    doc.approval_processed = 1

    if approval.status == 'Approved':
        doc.state = 'Approved'
        doc.approved_by = approval.completed_on
    else:
        doc.state = 'Rejected'
        doc.rejection_reason = 'Failed approval process'

    doc.save()

Satu Approval Per Dokumen

Pembatasan Penting: Sistem hanya mengizinkan satu approval aktif per dokumen pada satu waktu, terlepas dari perilaku penguncian dokumen:

Hard Lock Policies

• Jika ada approval dengan hard lock, tidak akan dibuat approval tambahan
• Ini mencegah status lock yang bertentangan dan mencegah kebingungan pengguna

Advisory (None) Policies

• Bahkan kebijakan non-blocking terbatas pada satu approval per dokumen
• Ini mencegah spam notifikasi duplikat dan kebingungan pengguna
• Beberapa kebijakan mungkin cocok, tetapi hanya yang kebijakan pertama dieksekusi akan membuat approval

Prioritas Kebijakan

• Kebijakan dievaluasi dalam urutan mereka diproses
• Kebijakan pertama yang cocok akan membuat approval
• Kebijakan berikutnya yang cocok diabaikan hingga approval diselesaikan
• Pertimbangkan desain kebijakan dengan hati-hati untuk memastikan kebijakan paling penting dipicu terlebih dahulu

Praktik Terbaik

Desain Kebijakan

• Penargetan Spesifik: Buat kebijakan yang fokus untuk skenario bisnis tertentu
• Penamaan yang Jelas: Gunakan nama kebijakan deskriptif yang menunjukkan tujuan dan ruang lingkup
• Rollout Bertahap: Mulai dengan proses non-kritis dan perluas secara bertahap
• Pencegahan Rekursi: Selalu desain filter dan efek untuk mencegah rekursi pemicuan

Konfigurasi Approval

• Hard Lock proses Kritis: Gunakan Hard Lock untuk proses yang memerlukan kontrol ketat
• Mode Approval Seimbang: Pilih mode yang menyeimbangkan keamanan dengan efisiensi
• Fleksibilitas Berbasis Grup: Gunakan User Groups untuk manajemen approver yang lebih mudah

Pertimbangan Performa

• Kondisi Terarah: Gunakan kondisi filter untuk membatasi eksekusi kebijakan
• Eskalasi Efisien: Atur kerangka waktu eskalasi yang wajar
• Optimasi Notifikasi: Aktifkan hanya saluran notifikasi yang diperlukan

Manajemen Perubahan

• Pelatihan Pengguna: Pastikan approver memahami tanggung jawab mereka
• Protokol Pengujian: Uji perubahan kebijakan di lingkungan pengembangan
• Pengujian Rekursi: Secara khusus uji efek pasca-keputusan untuk mencegah rekursi tak hingga

Integrasi dengan Komponen Lain

Pembuatan System Approval

Ketika kebijakan cocok dengan kondisi dokumen, secara otomatis membuat:

• Satu record System Approval untuk pelacakan keseluruhan
• Beberapa record Approval Request untuk approver individual

Integrasi Script Function

Script pasca-keputusan menerima konteks termasuk:

• doc: Dokumen asli yang memicu approval
• approval: Record System Approval
• requests: Daftar semua record Approval Request

Pelacakan Update Set

Semua perubahan kebijakan dilacak melalui sistem Update Set, memungkinkan:

• Riwayat perubahan dan audit trail
• Deployment konfigurasi approval lintas environment