Catatan:

• Inilah salah satu cara untuk membuat hubungan dengan dirinya sendiri (Recursive Relationship).
• Kelemahan dengan menggunakan teknik ini adalah keterbatasan dalam tingkat level yang bisa ditampilkan. 
• Untuk gambar diatas maka level yang bisa dibuat adalah 7 level kebawah setelah root atau totalnya delapan buah kategori.
• Kita juga bisa membuat hubungan ini tampa bantuan Query yaitu dengan programming yaitu dengan fungsi recursive.  Kami pernah mencoba memecahkan masalah ini dengan fungsi tampa bantuan query namun percobaan kami ada kelemahannya yaitu kecepatannya.
• Apakah ada yang pernah mencoba menggunakan fungsi recursive untuk memecahkan masalah ini dan kecepatannya tidak jauh berbeda dengan menggunakan bantuan Query?

Posted: May 31st, 2007 under POS Database.
Comments: none

 

 Catatan:

Ada perubahan dan penambahan database desain dari yang terdahulu yaitu:

• tblStok
  • factorycode dirubah menjadi manufactureCode
  • Tambahan ManufacturerID untuk menyimpan pabrik, brand name atau merek
• tblCategori
  • Tambahan Typeid untuk membedakan antara kategori group barang dan kategori merek atau asal pabrik barang.  kami lebih memilih menambah satu field di tblCategori daripada membuat satu buah tabel untuk memasukan asal barang (pabrik atau merek)
  • TypeID=1 berarti group barang
  • Typeid=2 berarti asal barang (pabrik, merek)
• Menghilangkan hubungan relasi antara stok dan categori.  Pada tabel stok akan langsung dihubungkan dengan tblCategory

Desain ini masih bersiftat sementara.  Ada yang kurang atau salah ???

Posted: May 28th, 2007 under POS Database.
Comments: 1

 

 Catatan:

Ada perubahan dan penambahan database desain dari yang terdahulu yaitu:

• Penambahan tabel stok serialized.  Barang serialized seperti misalnya motor dengan nomor mesin dan nomor rangka.  Untuk barang dengan warna seperti baju juga bisa dimasukan dalam tabel ini.  Barang barang seperti baju bisa mempunyai harga yang berbeda karena perbedaan warna walaupun merek dan tipenya sama.  Ini bisa dimasukan dalam tabel serialized. 
• Penambahan tabel pengembalian barang baik untuk penjualan ataupun pembelian.  Pengembalian barang harus dilihat dari transaksi sebelumnya.  Jika misalnya terjadi penjualan barang A sebanyak 5 buah dan ternyata terjadi pengembalian barang 2 buah maka transaksi penjualannya harus dijadikan sebagai referensi dan pengambalian barangnya harus dimasukan dalam barang tersebut.  Ini akan memudahkan dalam penghitungan Current Cost, Highest cost dan Lowest Cost.
• Penambahan tabel Stok Cost untuk memisahkannya dengan tabel utama.  Hubungannya  One to One
• Menghilangkan di tabel transaksi atribut empeID dan SupplierID atau CustomerID di tabel transaksi. Mungkin tidak tepat memasukan atribut tersebut kedalam database stok karena database stok tidak memperhatikan darimana barang ini dibeli dan kemana barang dijual.  Itu mungkin bukan tugas dari aplikasi stok tetapi proses penjualan atau proses pembelian.
• Mengenail proses import atau export.  Bagaimana transaksi ini dimasukan dalam database stok?  Apakah proses pembelian atau proses penjualan yang mengekspornya kedalam database stok atau proses stok yang mengimportnya dari database transaksi?  Kami lebih memilih proses import karena database stok harus menyadari apa yang terjadi dengan data data didalamnya.
• Demikian pula pada saat General ledger ingin mendapatkan total stok pada suatu periode maka Aplikasi General ledger yang harus mengimpornya dari database stok. Bukan aplikasi stok mengeksportnya kedalam database GL.
• Proses Stok awal.  Pada saat melakukan proses stok awal untuk barang tertentu maka harus dilihat StockInit dan COGS.  Jika keduanya kosong maka proses stok awal dapat dilakukan untuk barang tersebut tetapi jika sudah terisi maka proses itu tidak boleh dilakukan lagi.
• Proses penjualan tidak harus dilakukan setelah melakukan transaksi stok awal.  Setelah melakukan penjualan barang A sebanyak 10 buah kemudian akan dilakukan proses stok awal yang berjumlah 15 maka pada saat melakukan proses stok awal jumlah yang harus dimasukan adalah 25.
• Untuk usaha yang sering melakukan banyak pembelian barang akan terjadi proses perhitungan yang lama pada saat mencari nilai total stok. Misalkan terjadi pembelian setiap hari sebanyak 500 item barang maka dalam 300 hari akan ada 150,000 data.  Memproses data yang cukup besar ini akan membutuhkan waktu.  Untuk data transaksi yang besar seperti ini perlu dibuat atribut atau field di tblPropertyStok untuk menyimpan ringkasan transaksi tersebut.Â
  Pada saat proses stok mengimpor data dari database transaksi total stok langsung dihitung dan disimpan dalam tabel propertyStok.  Dengan demikian akan menghemat waktu.  Pada saat pembelian total stok ditambahkan dan pada saat pengembalian barang total stok dikurangkan.
• GL akan mengimpor total nilai stok ini setiap hari atau setiap saat diperlukan.  Perlu ada cara bagaimana proses ini dapat dilakukan dengan cepat tanpa perlu adanya penghitungan ulang.

Desain ini mungkin masih bersiftat sementara.  Ada yang kurang atau salah ???

Posted: May 27th, 2007 under POS Database.
Comments: 1

Catatan:
Beberapa properti dari tabel stok bisa diambil langsung dari transaksi stok misalnya saja Highest cost, current cost (Pembelian terakhir) , atau lowest cost.  Ada beberapa kerugian dengan cara mengambil dari tabel transaksi dimana aplikasi akan selalu mencari di tabel transaksi sehingga sedikit membebani komputer.  Mana yang dipilih langsung memberikannya ke tabel stok atau memprosesnya pada saat melihat stok yang bersangkutan???

Ketika proses penutupan tahunan, semua transaksi stok akan di backup dan dihapus sehingga kita tetap membutuhkan informasi yang bersangkutan.  Jadi kita membutuhkan ketiga properti tersebut di tabel stok.  Pertanyaannya sekarang adalah apakah kita merubah properti tersebut pada saat transaksi pembelian atau hanya pada saat melihat transaksi stok yang bersangkutan.

Masalah:
Bagaimana bila transaksi pembelian yang merubah properti itu kemudian terjadi proses pengembalian barang pembelian?  Masalah itu perlu kita waspadai bagaimana kita mengatasinya.  Pertimbangkan database desain untuk transaksi di database transaksi untuk membuat tiga level transaksi:

• Transaksi : (Siapa, tanggal, pengiriman)
• Line Transaksi (barang, harga)
• Detail Line Transaksi (Transaksi Detail barang jika diperlukan misalnya terjadi pengembalian barang)

Untuk beberapa fitur aplikasi seperti banyak gudang, untuk mempercepat pengembangan aplikasi maka pada saat awal aplikasi akan membuat gudang dengan nama default.  Dengan demikian walaupun Arsitektur database bisa menampung fitur banyak gudang tetapi kita akan mengembangkannya dari yang sederhana.

Bagi mereka yang sudah mengerti apa itu recursive relationship, dapat dilihat ada dua tabel yang di desain dengan hubungan tipe ini yaitu categori dan wharehouse(Gudang).  Misalnya untuk gudang, kita bisa mempunyai gudang A, Rak 1, Baris 2 dan seterusnya.  Untuk gudang yang tidak mempunyai keterangan detail tambahan dapat diberikan parentID nya = 0 secara default.

Desain ini masih bersiftat sementara

Ada yang kurang ???

Posted: May 26th, 2007 under POS Database.
Comments: none

Database Stok
Database Transaksi
Database Master
Database GL

Posted: May 24th, 2007 under POS Database.
Comments: none

Database Stok

Tabel Stok                    : Informasi mengenai stok

Tabel Stok Properti       : Informasi tambahan mengenai stok

Tabel Stok Transaksi    : Informasi transaksi stok yang mempengaruhi atribut stok

Tabel Stok Categori      : Kategori stok 

Hubungan Antar Tabel
Satu Stok bisa mempunyai banyak informasi tambahan
Satu stok bisa mempunyai banyak transaksi
Satu kategori stok bisa mempunyai banyak stok

Tabel Stok
id
code
name
ID categori
Stok Awal
Keterangan

Tabel Stok Property
id
ParentID
PropertyName
PropertyValue

Property Tambahan Untuk Stok
Manufacturer Code
Image
Informasi Harga Terakhir(Tidak bisa dirubah manual)
Jumlah Persediaan (Tidak bisa dirubah manual)
Jumlah Reorder Point
Harga Penjualan Retail
Supplier1
Supplier2

Tabel Stok Transaksi
id
ParentID
Date
Tipe Transaksi
EmpeID
CustOrSupID
Jumlah
Harga
Keterangan

Tabel Stok Category
id
parentID
Name
Keterangan

Kategori bisa mempunyai kategori lagi (Recursive relationship)

Ada yang kurang ??

Catatan:
Bagaimana dengan stok yang bisa mempunyai warna atau serial Number.
Untuk stok jenis seperti itu kita perlu mempunyai tabel tersendiri, misalnya diberi nama stok detail yang bisa mempunyai atribut (id,parentid,warna,serial number 1, serial number 2, jumlah.)
Untuk saat ini kita tidak membuatnya.

Posted: May 18th, 2007 under POS Database.
Comments: none