Bung Aksan dan master2 lain di belajar-access,
Ya bung,persentase hanya dihitung berdasarkan stock atau quantity barang tanpa memperdulikan nilai perolehannya. Mengenai aktivitas gudang dan perpindahan barang, sebenarnya asumsi gudang pusat sebagai gudang/counter yang setara hanyalah didasarkan pada contoh database yang saya lihat pada salah satu sample accounting software buatan Indonesia yang pernah ditawarkan pada kami, dan saya juga lihat bahwa hal tersebut baik karena dengan begitu jika ada penambahan gudang di pusat maka system database tidak terlalu bermasalah. Itu yang dimaksud dengan scalability bukan bung ? saya kebetulan juga lagi baca mengenai hal tersebut dan juga normalisasi yang saya sejujurnya masih kurang paham untuk saat ini. Mengenai business processnya saat ini, penentuan pengiriman ke counter sebenarnya sepenuhnya didasarkan pada keputusan dari pusat, permintaan barang dari counter selalu ke divisi consignment di pusat dan nantinya divisi consignment memutuskan pengiriman tersebut, jadi permintaan barang dari counter hanya sebagai referensi. Pengiriman barang pada kegiatan normalnya semua berasal dari pusat tetapi pada kjadian kghusu tidak menutup kemungkina pengiriman antar counter tetapi atas instruksi dari pusat. Oh iya pak, saat ini asumsinya bahwa counter kami tidak memiliki database ataupun POS. System kami dapat dikatakan terpusat pak. Thanks PS: jika ada yang memiliki contoh database access dengan multi gudang lengkap dengan query untuk stock gudang/productnya jika memungkinkan harap di kirimkan sebagai bahan pembelajaran. Thanks in advance Best regards, Marc From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of aksan kurdin Sent: Tuesday, April 22, 2008 12:08 PM To: [email protected] Subject: Re: [belajar-access] Re: contoh database gudang Marc, Kita coba bahas untuk stock Laporan yang anda berikan memperlihatkan stok dipengaruhi oleh transaksi: - saldo awal - kirim (penerimaan di counter) - penjualan - retur (pengeluaran dari counter) * persentase performance dihitung hanya berdasarkan _jumlah_ yang terjual di banding dengan _jumlah_ kirim, jadi bukan kepada nilai / harga * penerimaan barang di counter mengabaikan harga perolehan anda sebutkan ada aktifitas perpindahan barang antar counter, gudang pusat pun dianggap sebagai counter. Jadi inventory pun harus di atur per counter, bagaimana sistemnya ? Contoh untuk sistem terpusat: - jika counter membutuhkan suatu barang ia akan membuat list kebutuhan barang tersebut dan mengirimnya ke pusat - pusat memeriksa list barang untuk menentukan akan mengambil barang dari counter mana saja untuk mencukupi kebutuhan list tersebut. - pusat mengirimkan list kebutuhan barang yang tidak ada di pusat ke counter2 lain yang available berdasarkan database - counter tsb membalas list tersebut dengan mengeluarkan list pengeluaran barang ke pusat - pusat menerima list barang dan merekamnya dalam transaksi penerimaan barang - pusat mengeluarkan list pengiriman barang ke counter semula yang membutuhkan - counter semula menerima kiriman dari pusat dan merekamnya dalam database, agar permintaannya tidak outstanding lagi - semua aliran data ke pusat dulu baru ke counter, walaupun secara fisik, barang langsung dikirimkan ke counter lawan dari sistem ini adalah sistem desentralisasi, pengiriman tidak diatur pusat, tetapi setiap counter bisa bebas meminta dan mengirim barang antar counter. yang mana sistem anda ? On 4/22/08, Marc Christoph <[EMAIL PROTECTED]> wrote: Dear Pak Aksan, Benar sekali pak, untuk design id memang menempel pada produk dimana setiap produk hanya memiliki satu design yang menempel. Mengenai kolom stock, hasil stock adalah : [stock awal periode counter tersebut] + [total pengiriman selama period eke counter tsb] - [total retur selama priode ke countr tsb] - [total penjualan selama periode ke counter tsb] Oh iya pak, mohon maaf sedikit tertinggal mengenai laporan bahwa sebenarnya juga ada gudang pusat, jadi kalau saya lihat di software2 accounting yg multi warehouse biasa dianggap setara dengan counter ya pak ? Jadi transaksi pengiriman barang ke counter dianggap sebagai pindah barang antara gudang/counter yang satu ke gudang/counter yang lain. Kalau saya coba terapkan sesuai dengan business process yang berjalan saat ini (saya coba belajar ya pak, mohon di analisa dan di tuntun dan di koreksi) oleh karena itu saya kemudian harus membuat table-tabel berikut (asumsi counter adalah juga bisa sebagai gudang) : - Tabel Customer = (customerID, Nama Customer) - Tabel pindah barang = ( pindahbarangID, tanggal, dari counter[counterID], ke counter[counterID] ) - Tabel pindah barang detail = (pindahbarangdetailID, pindahbarangID, produkID, Quantity) - Tabel penjualan = ( penjualanID, tanggal, dari counter[counterID], customerID ) - Tabel Penjualan Detail = (penjualandetailID, penjualanID, produkID, Quantity) Dianggap bahwa pengriman barang dan retur barang dapat menggunakan table pindah barang. Mengenai Laporan 6 pak, jadi harga yang tercantum pada harga produk merupakan harga yang include PPn, dimana sebagai contoh : contohcempal 18cm x 18cm dengan harga 9900, maka subtotal =9.900, maka PPn =[subtotal]-([subtotal]/1.1) = [9900]-[9900/1.1]=[9900]-[9000]=900, dan total after tax =[subtotal]/1.1 =9900/1.1 =9000, dengan asumsi tax = 10% maka nilai harga = 100% + 10% = 110% = 1.1. Ini berdasarkan cara perhitungan yang selama ini kami gunakan pak pada excel. Mohon dituntun Best regards, Marc From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of aksan kurdin Sent: Tuesday, April 22, 2008 9:21 AM To: [email protected] Subject: Re: [belajar-access] Re: contoh database gudang Marc, dari laporan yang anda berikan, kita bisa membentuk dasar-dasar databasenya. Jika ada kesempatan, coba browsing mengenai rdbms dan normalisasi, nerangkannya sih panjang lebar, jadi singkat ke ujung saja, saya ambil dari lap-001, secara hukum normalisasi, laporan ini terdiri dari tabel-tabel: - master produk (produkid, produk name) - master kategori (kategoriid, kategoriname) - master design (designid, designname) - master counter (counterid, countername) untuk master produk, kategori selalu lengket pada setiap jenis produk bukan ? sehingga kategoriid bisa dimasukkan dalam master produk. untuk design, apakah setiap jenis produk selalu hanya boleh digolongkan dalam satu design saja ? ataukah nanti lihat di transaksinya baru ditentukan masuk dalam design yang mana ? jika setiap produk selalu terkait dengan satu design, maka designid bisa masuk di master produk, akan tetapi jika design ditentukan pada saat transaksi di input, maka designid nantinya akan diletakkan di tabel transaksi. saya anggap kemungkinan pertama, jadi setiap produk sudah tertentu untuk design tertentu. -> master produk(produkid, produkname, kategoriid, designid) Untuk laporan satu, kita butuh tahu angka di total stock setiap couter berasal dari transaksi apa saja (keluar lewat transaksi apa, masuk lewat transaksi apa), berarti itu adalah hasil perhitungan dari tabel lain. Untuk laporan dua, kita simpulkan ini total sales berdasarkan suatu tabel transaksi penjualan untuk setiap counter. Untuk laporan tiga, kita simpulkan ini total pengembalian berdasarkan suatu tabel transaksi pengembelian di setiap counter. Untuk laporan empat, saya simpulkan : - kolom stock awal adalah stock di awal periode - kolom kirim adalah jumlah penerimaan barang di counter yang bersangkutan - kolom jual adalah jumlah penjualan barang di counter tsb - kolom harga adalah harga rata-rata penjualan dalam sebulan. Untuk laporan lima, belum perlu di analisa, karena semuanya adalah hasil olahan data, bukan transaksi. Untuk laporan enam, ini mencerminkan tabel transaksi jual. Coba ajarkan saya bagaimana menurunkan rumus : - ppn menjadi subtotal - (subtotal/1.1) - total after tax = subtotal/1.1 (bersambung) aksan kurdin On 4/18/08, Marc Christoph <[EMAIL PROTECTED]> wrote: Dear Bung Aksan, Berikut contoh laporan yang rencana ingin dihasilkan. Best regards, Marc . Error! Filename not specified. -- Aksan Kurdin -- Aksan Kurdin
