Belajar ms Access

Archive for May, 2007

Arsitekture Sub Sistim Stock 1

 Sub Sistim Stock

Catatan:

  • Lihat halaman POS Site Map untuk mempermudah navigasi aplikasi contoh POS ini. 
  • Untuk saat ini UI applikasi hanya satu yaitu Kategori.
  • Kami memberikan source code untuk memasukan data kategori barang.
  • Semua detil hubungan transaksi dengan stok ada dalam stok objek.
  • Koneksi ke RDBMS ada dalam system DB.  Mengapa? Jika kita ingin koneksinya diganti dengan MS SQL dan bukan ke ms Access maka kita hanya merubah pemanggilannya saja.  Dengan memisah misahkan sistim sistim seperti ini maka bila kita memang menginginkan upsize ke ms sql server maka perubahannya minimal.  Seorang pengarang menamakan teknik ini Data Portal. 
  • Kami telah mendemonstrasikan bagaimana ms Access dapat di desain dengan menggunakan beberapa tier sehingga memudahkan dalam perubahannya.  Namun ada kelemahan dalam ms access yaitu bila terjadi perubahan pada sistim yang paling rendah hierarkinya, dalam hal ini system message, maka semua harus dicompile ulang dan semua harus diganti.  Masalah ini telah diatasi pada teknologi NET yaitu dengan adanya teknik side by side execution.     (kami belum terlalu dalam mempelajari teknologi NET sehingga belum melakukan percobaan untuk kasus seperti ini.)
  • Download Sub Sistim Stok Architecture Step 1

Source Code untuk Form Stock Category. 

  • Experiment dengan stok categori yang diberikan dalam contoh.
  • Buat satu buah aplikasi dengan ms Access
  • Buat satu buah form sama seperti form stock contoh.
  • Buatlah referensi seperti gambar diatas. 
  • Buat control yang diperlukan.
  • Cobalah apakah anda bisa membuat sama seperti contoh yang diberikan.

Recursive Relationship

Recursive Relationship 

 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?

teknologi informasi

membantu mengerjakan skripsi/tugas akkir yang berkaitan dengan TI or SI

juga menerima pembuatan web design,web program,data base sist,web e-commerse dan progr lain yang berkaitan dengan IT

hubungi Andy(boni_yah80@yahoo.com)

081325671090

Relationship Database Stok Percobaan ke 3

 Relationship stock database

 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 ???

Relationship Database Stok Percobaan ke 2

Relatioship of Stock Database Second Attempt 

 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 ???

Relationship Database Stok Langkah 1

Relationship Database Stok

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 ???

Laporan Stok Barang

Maksud : Memberikan total harga stok yang bisa dipilih berdasarkan kategori. Inilah hasil dari menu untuk mencetak laporan stok.

Judul Laporan
Category : (Pemilihan categori: None,All, …)

Code           Name         Description             QTY            COGS                        Total
——————————————————————————-

________________________________________________________
Total ………………………………………………………………………                       Rp xxxxxxx

Tanggal:                      Halaman:

Laporan Transaksi Penjualan POS

 Nama dan alamat toko
___________________________________
Kode    Jumlah Barang   Harga Satuan    Total
___________________________________
ABC           2                     10,000               20,000

___________________________________
Total Harga                                            Rp 20.000.
____________________________________

Terima kasih telah berbelanja di toko xxxxxxxxx

Proses Posting Transaksi

Â

  • Lihat pada proses melihat data stok.
  • Bagaimana transaksi akan diposting
    • Langsung merubah stok
    • Tidak langsung merubah stok
  • Siapa yang melakukannya.

Untuk saat sekarang kami lebih memilih untuk pemostingan tidak langsung merubah stok karena posting akan dilakukan oleh level admin. Ada yang tidak setuju???

Proses Melihat Data Stok

Â

  • Data stok perlu mudah untuk diakses informasinya.
  • stok jumlah data ini akan digunakan oleh bagian penjualan untuk mengetahui jumlah stok.
  • Tergantung bagaimana kita akan memposting transaksi maka jumlah data stok
    • Jumlah yang terbaru.  Jika transaksi langsung merubah stok maka stok akan diberikan jumlah terbaru.  Masalahnya adalah bagaimana caranya memeriksa validitas transaksi.
    • Jumlah tidak memberikan stok yang terbaru.  Dengan cara ini transaksi tidak langsung merubah stok.  Walaupun tidak memberikan informasi yang terbaru namun cara ini ada juga kelebihannya yaitu sebelum transaksi bisa merubah stok seseorang dengan level admin harus memeriksa validitas transaksi sebelum memposting untuk merubah stok
  • Pada waktu mencari stok bisa dipilih berdasarkan
    • Kategori barang
    • Kode barang pemilik
    • Kode Barang dari pabrik

Ada yang dilupakan ???