Validasi Data Transaksi

Saat kita sedang membuat atau merancang aplikasi database, hampir dapat dipastikan kita akan menemukan yang namanya data transaksi, selain data master tentu saja. Data transaksi ini merupakan rekaman dari transaksi-transaksi yang dilakukan di dalam aplikasi. Biasanya transaksi-transaksi ini melibatkan data master sebagai acuan atau referensi. Dan kali ini saya ingin menulis tentang validasi data transaksi dalam aplikasi, yang terutama berhubungan dengan proses lain. so, mari kita mulai …

Kali ini yang akan kita ambil sebagai contoh adalah data penjualan, bagi mereka yang pernah membuat aplikasi pos atau aplikasi yang memiliki modul penjualan pastinya sudah tidak asing lagi. Tapi jika ternyata Anda belum pernah membuat aplikasi yang memiliki modul penjualan juga tidak masalah, saya tidak akan membahas ini terlalu teknis, lebih kepada pendekatan metode nya saja. Karena jika terlalu teknis, maka setiap programmer memiliki style mereka masing-masing dan begitu pun dengan Anda bukan ?

Transaksi penjualan biasanya melibatkan beberapa data master antara lain, data master barang, data master pembeli atau langganan (jika ada), data master stock (untuk mengetahui apakah item dimaksud masih memiliki stock yang cukup untuk transaksi penjualan) dan data konversi satuan (jika modul penjualan mengakomodasi multi satuan). Sebagai contoh sederhana kita ambil transaksi penjualan dengan satu satuan saja.

Saat transaksi penjualan terjadi dengan 5 item di dalamnya kemudian transaksi tersebut telah di simpan, tidak serta merta data penjualan tersebut meng-update stock barang di tabel stock. (misalnya aturan yang dipakai adalah stock ter-update saat pembayaran terhadap penjualan dilakukan). Jadi data transaksi masih hanya berupa data transaksi saja, belum terkait dengan data stock.

Di tahap ini, jika ternyata data transaksi mengalami perubahan atau penambahan item maka user diperbolehkan meng-edit data penjualan karena data tersebut masih belum terkait dengan stock barang. Tapi pada saat transaksi tersebut sudah dibayar, dan data transaksi penjualan telah di validasi, maka seharusnya data transaksi tersebut sudah TIDAK BOLEH lagi diubah. Dan sudah menjadi data yang fix / mati.

Kenapa? karena pada saat validasi, terdapat proses update stock barang. Jika ternyata data transaksi diubah baik ditambah item atau dikurangi item atau diubah qty nya, maka aplikasi perlu melakukan update ke data stock juga, tapi mekanisme ini akan jauh lebih merepotkan dan tidak konsisten jika kita memakai kartu stock untuk mengontrol keluar masuk barang di aplikasi kita.

Oleh karena itu, pada saat proses validasi selesai dilakukan, data dinyatakan sebagai data yang sudah fix atau mati. Kemudian bagaimana jika ternyata data tersebut salah ? atau terdapat salah entri di dalamnya?? ada beberapa metode yang bisa dilakukan dan kali ini saya hanya akan menunjukkan 2 diantaranya.

1. Batal Validasi
Sebelum mengubah data, maka dilakukan proses batal validasi. Proses ini mengembalikan stock semua item yang ada di data transaksi penjualan dengan qty yang sesuai dengan yang ada di dalam transaksi. Jika di dalam transaksi terjual 10 pc, maka di stock barang akan dikembalikan 10 pc juga, dan seterusnya.

Dengan demikian setelah proses Batal Validasi ini, stock barang yang ada di transaksi seolah-olah dibatalkan, tapi di kartu stock tetap tercatat sebagai pembatalan validasi dari nota penjualan tersebut. Setelah itu baru dilakukan perubahan data transaksi, entah itu mengurangi item, menambah item atau mengubah qty item. Setelah perubahan selesai, kemudian dilakukan kembali proses validasi yang akan meng-update kembali data stock barang sesuai dengan data transaksi yang telah diperbaiki.

Proses ini memiliki resiko bahwa di kartu stock kita akan menjadi lebih panjang dan banyak itemnya jika sering terjadi proses pembatalan transaksi seperti ini. Tapi paling tidak, kita bisa mengetahui kenapa transaksi tersebut dibatalkan, dan jika ternyata banyak transaksi serupa, berarti kita perlu mempertanyakan kinerja dari user entri datanya.

2. Transaksi Koreksi
Pendekatan kedua adalah transaksi koreksi, dimana kita membuat transaksi koreksi dengan mengubah data transaksi yang sudah ada tapi dengan menggunakan transaksi yang berbeda. Jika ternyata ada salah satu item yang ingin dibatalkan di data transaksi tersebut, maka kita bisa membuat transaksi yang menyatakan bahwa item itu di nota penjualan no sekian dinyatakan dibatalkan (dengan flag batal misalnya), dan saat transaksi koreksi ini di validasi, maka dilakukan update data stock barang sesuai dengan transaksi koreksi.

Pendekatan ini hanya fokus pada item yang salah saja, jadi tidak semua item perlu dikembalikan ke data stock barang terlebih dahulu, namun hanya item yang ternyata salah entri saja. Di kartu stock kita masih akan mendapati bahwa terdapat transaksi koreksi dari item tersebut dan kembali lagi, jika ternyata banyak transaksi koreksi yang terjadi, maka kita harus mempertanyakan kembali kinerja user entri data.

Dari kedua pendekatan tersebut, kita bisa memilih salah satunya, yang kemungkinan lebih sesuai dengan kondisi dan situasi yang ada di tempat klien kita, tapi tujuan dari adanya proses seperti di atas adalah agar perubahan di data transaksi tetap dapat terekam dan tercatat di dalam database, serta efek yang ditimbulkan dari perubahan data transaksi tersebut tetap bisa meng-update data stock barang dengan benar.

Gimana? bingung ya? ya sudah tidak apa-apa kalo masih bingung, silahkan baca pelan-pelan lagi dari awal. Tapi jika memang ada yang mau ditanyakan, silahkan komen di post ini atau kontak saya di email yang ada di halaman ME.

Mudah-mudahan bermanfaat !

#me #data #transaksi #validasi

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s