Detil Fitur PR/PO Workflow Application

Tulisan adalah lanjutan pembahasan tentang aplikasi besar Purhcase Order, dimana tulisan sebelumnya dibahas tentang integration antara Purchase Order Workflow dengan ERP atau backend system.

Berikut ini modul-modul yang terdapat dalam aplikasi PR/PO Workflow:

1. Budget: modul yang menangani proses persetujuan pembuatan budget, perhitungan penggunaan budget melalui PR, pengontrolan PR budget supaya tidak melebihi nilai budget
2. Purchase Requisition: modul yang menangani pembuatan permohonan PR atau pembuatan PR otomatis yang merupakan hasil MRP dari sistem lain, keterkaitan dengan budget, pengontrolan angka PR dengan budget, persetujuan PR sesuai besar dan tipe PR, pengisian detil spesifikasi produk, pencatatan hasil bidding, penunjukan pemenang bidding
3. Purchase Order: pembuatan PO berdasarkan PR yang sudah ditentukan pemenang bidding nya, pengisian perjanjian yang disetujui bersama pihak Supplier, persetujuan penerbitan PO, pencetakan PO, pencatatan penandatangan PO oleh salah satu Penyetuju, pengiriman PO disetujui ke sistem ERP
4. Good Receipt: pencatatan penerimaan untuk penerimaan yang dilakukan di aplikasi PR/PO Workflow, pencetakan Good Receipt untuk diserahkan ke Supplier, perhitungan penerimaan terhadap PO, pengiriman Jurnal Good Receipt ke ERP

MODUL BUDGET

Modul Budget adalah modul yang menangani tentang masalah budget. Budget dalam PR/PO adalah daftar perencanaan/budget seluruh pembelian yang direncakan untuk direalisasikan di tahun berjalan atau tahun berikutnya. Fitur dalam modul budget adalah:

1. Opening budget setiap awal tahun.  Opening budget ini bisa dilakukan persetujuannya didalam modul Budget atau alternatif nya proses persetujuan dilakukan diluar sistem, hasil dari persetujuan di entry ke dalam sistem untuk dipakai sebagai Opening Budget.
2. Revisi budget berupa penambahan kode budget baru: yaitu pengajuan budget baru untuk kode yang baru. Yang dimaksud kode budget baru adalah untuk tipe budget baru. Budget baru bisa muncul di tahun berjalan dikarenakan perubahan struktur organisasi, penambahan account biaya di accounting, perubahan proses kerja antar departemen
3. Revisi budget berupa penambahan terhadap kode budget yang ada, yaitu penambahan angka rupiah terhadap kode budget yang sudah ada. Kode budget tersebut adalah opening budget awal tahun atau revisi budget penambahan kode baru.

Berdasarkan transaksi diatas maka sistem akan memiliki value budget per masing-masing departemen per masing-masing account biaya/fix asset. Dalam hal account secara garis besar budget dibagi menjadi 3 bagian, yaitu: pembelian Capex, Opex dan pembelian untuk produksi (Raw/Packaging Material). Sedangkan dari sisi departemen adalah tentang Cost Center yang dicatat didalam ERP. Meskipun demikian Cost Center PR/PO bisa bebeda pengertiannya dengan Cost Center dalam ERP/Accounting. Dalam hal ini perbedaannya adalah skope atau skala. Biasanya Cost Center dalam aplikasi PR/PO lebih detil dibandingkan dengan yang ada dalam Accounting, karena keperluan dalam PR/PO lebih detil dibanding dengan Accounting.

Setelah sistem memiliki nilai budget, berupa total kalkulasi dari Opening Budget dan Revisi, selanjutnya nilai budget akan direalisasikan melalui pembuatan PR. Yang menjadi masalah adalah angka realisasi PR adalah angka yang sifatnya tentative atau berubah-ubah. Karena PR sendiri baru berupa permohonan dan belum berupa perjanjian pembelian antara Customer dengan Supplier. Jadi dalam hal ini budget harus bisa melakukan perhitungan menggunakan angka real sesuai perkembangan dari PR. Pada umumnya perubahan angka PR yang mungkin terjadi adalah:

1. Angka perkiraan awal oleh pemohon
2. Angka perkiraan oleh departemen terkait yang mengerti tentang barang yang akan dibeli
3. Angka penawaran awal dari Supplier
4. Angka final dari Supplier pemenang

Fitur kunci dari budget adalah pengontrolan pembukaan PR, dimana PR yang dibuat dengan menunjuk kode budget tertentu harus di kontrol supaya tidak melebihi nilai budget. Bagaimana jika PR yang dibuat melebihi sisa budget ? Solusi nya adalah dengan membuat alternatif PR Non Budget atau mengajukan revisi kode budget. Perbedaannya adalah PR Non Budget persetujuannya ada di dalam PR, sedangkan budget revisi persetujuannya ada di dalam budget revisi itu sendiri.

MODUL PURCHASE REQUISITION

Modul Purchase Requisition (PR) adalah modul yang menangani pembuatan permohonan pembelian berupa pengisian formulir Purchase Requisition (PR) baik secara manual atau otomatis hasil dari sistem lain. Yang dimaksud dengan manual adalah pengisian dilakukan didalam modul PR ini, sedangkan yang dimaksud dengan otomatis adalah pengisian dilakukan di sistem lain (fungsi MRP, Minimum Order, Direct Purchase, Work Order ke Third Party). Setelah pengisian dilakukan di sistem lain, maka PR akan diletakkan disebuah interface tabel, kemudian modul PR akan membaca interface tabel dan membuat PR berdasarkan isi dari Interface tabel tersebut disertai dengan validasi.

Seperti yang dijelaskan diatas bahwa PR adalah realisasi dari budget. Untuk itu maka dalam PR disediakan kolom untuk mengaitkan budget baik secara otomatis maupun manual. Otomatis hanya bisa dilakukan jika terdapat pattern tertentu seperti tipe biaya, sedangkan manual dilakukan oleh pemohon PR. Dalam hal keterkaitan dengan Budget, PR bisa dikategorikan menjadi 2, yaitu:

1. PR Budget: PR yang dikaitkan dalam budget dan angka sisa budget masih lebih besar atau sama dengan nilai PR
2. PR Non Budget: PR yang tidak bisa dikaitkan dengan budget dikarenakan belum ada kode budget atau sisa budget tidak mencukupi

Untuk itu pengontrolan angka PR ddibanding dengan sisa budget harus dilakukan secara realtime dan uptodate. Uptodate karena angka PR berubah-ubah dan status PR yang berubah-ubah yang berpengaruh terhadap sisa budget. Menurut pendapat pribadi, inilah fitur kunci dari aplikasi PR/PO Workflow dimana fitur ini (pengontrolan sisa budget berdasarkan perkembangan dari PR-PR yang terkait) tidak bisa dilakukan baik secara manual maupun menggunakan workflow PR/PO di ERP. Dalam hal ini bukan di proses persetujuannya yang tidak bisa tapi kepada perhitungan realtime-nya.

Aplikasi ini adalah workflow berarti semua proses persetujuan ada didalam aplikasi ini. Dalam hal ini fitur workflow yang disediakan adalah workflow dibuat flexible sesuai dengan peraturan Perusahaan. Biasanya panjangnya proses persetujuan tergantung dari angka PR, tipe barang yang dibeli, tipe atau status PR berdasarkan budget. Kesemua parameter ini bisa dipakai sebagai parameter kemana PR akan diteruskan untuk proses persetujuan.

PR adalah permohonan yang diisi oleh User. Ada user yang mengerti detil spesifikasi barang yang akan dibeli, tetapi ada juga yang tidak. Untuk itu didalam proses PR akan dilewati pengisian detil fitur barang yang akan dibeli, jika dibutukan. Dengan demikian maka PO yang akan dihasilkan akan berisi daftar barang yang secara spesifikasi lengkap atau tidak menimbulkan kesalahan interprestasi.

Proses bidding dalam aplikasi PR/PO dilakukan  di modul PR. Mungkin hal ini menimbulkan beberapa pertanyaan, kenapa baru PR sudah bidding ? Bukannya bidding adalah bagian dari PO ? Berikut ini alasan kenapa proses bidding ada di modul PR, yaitu karena angka dalam PR yang digunakan untuk memotong budget. Jadi angka dalam PR adalah angka yang sudah matang. Karena angka yang diharapkan adalah angka matang yang akan digunakan untuk memotong budget, maka proses bidding dimasukkan ke dalam modul PR. Jadi dalam hal ini cukup mengubah mind set saja dari proses bidding menjadi dalam PR. Sedangkan selebihnya tidak ada katian.

Meskipun demikian apakah angka final dari PR saat dibuatkan PO masih bisa diubah ? Jawabannya bisa, tapi hal ini membutuhkan proses approval ulang.

MODUL PURCHSE ORDER (PO)

Modul PO adalah modul yang menangani pembuatan PO berdasarkan PR yang sudah ditentukan final (sudah ada pemenang bidding nya). Dalam modul PO ini tidak diperkenankan melakukan pengubahan item barang, jumlah yang dibeli, spesifikasi, harga, currency, dst. Hal yang boleh diubah-ubah dalam PO adalah isi perjanjian diluar hal-hal diatas, seperti Term of Paymen, format pencetakan PO, penggantian Supplier, dst. Itinya perubahan yang boleh dilakukan di PO adalah perubahan yang tidak ada kaitannya dengan angka PO itu sendiri. Karena pemotongan budget hanya ada di modul PR. Jika ingin melakukan pengubahan yang berhubungan dengan angka, maka semuanya dilakukan di modul PR (dalam hal ini sub modul Item PO, jika PR sudah dalam status ACCOMPLIHSED).

Dalam modul PO meskipun sudah mencantumkan angka final, tetap akan melewati proses persetujuan. Persetujuan yang dimaksud adalah persetujuan menyangkut isi perjanjian (diluar item, harga dan jumlah barang yang dibeli). Selain itu karena tetap PO akan melewati proses pencetakan, karena ini menyangkut pihak luar jadi butuh PO fisik, maka proses petujuan juga meliputi persetujuan menerbitkan PO. Seperti halnya PR proses persetujuan ini bisa berjenjang tergantung pada angka, jenis barang dalam PO.

Pencetakan PO adalah mencetak PO yang sudah berstatus disetujui, baik secara PR (item, harga, jumlah) maupun isi perjanjian (term of payment). PO dicetak karena pihak Supplier masih membutuhkan bukti fisik dari PO. Selain itu karena PO adalah dikirim ke pihak Supplier, maka tetap akan melewati tandatangan fisik terhadap PO yang sudah dicetak.

Jika PO akan dilakukan proses penerimaan di sistem lain (ERP, EAM), maka fitur yang akan ada adalah pengiriman PO disetujui ke sistem lain secara otomatis.

MODUL GOOD RECEIPT

Modul Good Receipt (GR) adalah pencatatan penerimaan untuk penerimaan yang dilakukan didalam aplikasi PR/PO Workflow. Kenapa dijelaskan diterima di aplikasi PR/PO Workflow ? Karena tidak semua penerimaan ada di aplikasi ini, seperti yang dijelaskan di modul PR. Jadi ada penerimaan yang dilakukan di sistem lain, seperti pembelian Raw Material/Packaging Material dilakukan di ERP, pembelian Spare part dan Supplies dilakukan di Enterprise Asset Management (EAM). Nah seperti apa pembelian yang diterima di modul ini ? Biasanya penerimaan yang dilakukan di modul ini adalah untuk pembelian barang-barang yang tidak di kontrol secara stok, apakah itu ? Seperti barang fix asset, stationary, office supplies, dst. Fitur pencatatan penerimaan ini meliputi keterkaitan dengan PO, proteksi penerimaan tidak boleh melampaui PO. Proses penerimaan bisa dilakukan lebih dari 1 kali terhadap sebuah PO.

Proses lanjutan dari pencatatan penerimaan adalah pencetakan Good Receipt untuk diserahkan ke Supplier. Jadi tandaterima barang tidak boleh dikeluarkan dari sistem lain, karena kalau dari sistem lain atau manual bisa menimbulkan kesalahan dalam hal item atau jumlah.

Seperti halnya PR dan PO yang memiliki proses persetujuan atau approval, dalam hal GR pun ada proses persetujuan. Untuk apa ada proses persetujuan dalam GR ? Berikut ini adalah fungsi dan alasan persetujuan dalam GR:

1. GR dilakukan oleh departemen store
2. Departemen store menerima barang hanya berdasarkan PO (part dan jumlah)
3. Untuk memastikan barang diterima sesuai spesifikasi dibutuhkan persetujuan oleh pemohon barang atau pembuat PR
4. Selain itu pemohon perlu menerima notifikasi bahwa barang yang diminta dalam PR sudah ada di store

Setiap penerimaan barang akan menimbulkan transaksi di accounting. Nah salah fitur yang ada dalam modul ini adalah pembuatan  Jurnal Good Receipt secara otomatis ke ERP. Dengan proses otomatis, maka pencatatan journal akan realtime dan mengurangi Human Error.

Advertisement

Tagged: po, pr, purchase order, Purchase Requisition

Posted in: Domino Application