Dear bung didigomo, Setelah melihat-lihat file / aplikasi nya, siti hanya dapat memberikan comments saja:
Usaha bung didi untuk berpegang pada dalil: bahwa data harus hanya tercatat sekali, dan bila suatu data harus hadir di lain tempat maka harus sekedar hasil pemanggilian dari masterSheet, itu bagus dan sesuai undang-undangnya! Semua sheets selain Master-nya menghadirkan PartNo dan PartName berdasarkan rumus, Oke ! Kemudian hasil rumus (yg berarti variables) disandingkan di tiap records dengan data yg di key-in (yg berarti : = konstanta), ndak masalah ! Yg menjadi masalah adalah ketika pada masterSheet ditambah data dengan cara menginsert baris, records yg ada di SlaveSheets juga "seakan-akan" terinsert baris baru (terinsert secara logical, bukan secara fisikal), tetapi tentu saja penggeseran tempat tadi hanya berlaku pada data VARIABLE /ex rumus, dan tidak akan menggeser data KONSTANTA (ex key-in). Akibatnya: Tabel sudah tidak ber-relasi lagi, artinya data-data yg semula di-Keyed-in untuk PartNo X sekarang sudah mejadi milik PartNo Y atau PartNo lain. Dalam bermain-main dengan "databasae" terjadinnya hal seperti ini termasuk larangan nomor wahid. Ikut terpikir oleh siti, bgmana cara agar data konstanta ikut bergeser &/ tetap ber-relasi dengan Account nya, tetapi ndak punya pemecahannya. Sebetulya sistem pencatatan bung itu sudah bagus, yaitu : Mutasi/Transaksi telah disediakan tempat/cellnya Semua bulan sudah mendapat SHEET-nya, Semua tanggal sudah mempunyai CELLnya Jumlah-jumlah per bulan / per saat ini sudah dipasang RUMUS-nya. Jadi setiap hari petugas hanya memasukkan data di SHEET dan CELL yg tepat saja, dan Report sudah tercipta dengan sendirinya. Kerjaan memilih sheet dan cell YG TEPAT ini apakah menjadi kendala tersendiri, barangkali. Karena bila ada 12 sheet dgn setiap sheet rata-rata ada 30 tanggal, dan tiap sheet mengandung 300 PartaName berarti, memilih cell yg tepat adalah urusan memilih SATU diantara 12*30*300 (=108.000) tempat. Mungkin ini sudah ada antisipasinya oleh bung didi. Misalnya menambah Items PartNo/PartName langsung ke URUTAN alfabetik dengan cara menginsert row baru (yg menimbulkan problem)itu dilaksanakan bukan dengan meng-insert, tetapi ditambahkan di bawah records terakhir, kemudian dengan rumus tertentu data disort; kayaknya problem yg sama masih tetap muncul. (sudah dicoba?) Ini karena : pada saat memasukkan data mutasi/transaksi harian, kita memasukkannya ke cell yg sejajar dengan PartNo / PartName yg "menurut penglihatan mata kita" adalah PartNo/PartName yg tepat. Sedangkan "yg kelihatan oleh mata kita" itu ternyata sebuah variable yg nilainya tergantung oleh "pihak lain", jika pihak lain berubah, maka berubah pula dia, termasuk: bisa berubah menjadi "blank". Hal seperi itu (variable bersanding dengan konstanta dalam suatu table) tidak ada masalah selama tidak ada tindakan (ex manual, rumus, maupun makroh) yg memutuskan relasi / keterhubungan datan se-records / sefield-nya. Melihat dari segi lain: Secara keseluruhan bahan yg dicatat oleh bung didi itu, adalah data standar, maksudnya type-nya banyak terjadi di berbagai sistem pencatatan, misalnya pembukuan. ciri khasnya:
ada Master Nama-Nama Item (dlm pembukuan = MasterAccount) tiap saat ada perubahan "Jumlah" (salah satu field pada) tiap Item,
dicatat secara kronologis (urut waktu). pencatatan kronologis ini dlm pembukuan sering disebut jurnalTransaksi / mutasi.
setiap saat diinginkan laporan per Item & Summary-nya.
Ketiga ciri khas ini ada / persis terjadi di pencatatan bung didi. Berdasarkan penglihatan spt itu, pencatatan dapat dilakukan dengan cara lain sbb: "MasterPart" dibuat tabel sendiri (Tbl1) Tbl1 mencakup fields: PartNo, PartName, Attribut-lain, dan StokAwal. bisa juga ditambah kolom yg secara bulanan ditambahkan: sbg StokAwalBulanItu. Pada Tbl1 ini dimungkinkan adanya perubahan (Add, Delete, Edit: Records) dan sorting. "CatatMutasi" dibuat dlm tabel sendiri (Tbl2) Tbl2 mencatat mutasi secara kronologis, mencakup field: Tgl, PartNo, Qty, HalLain (Qty In / Out bisa dicatat dengan bilangan Positip / Negatip.) Report yg diperlukan: dibuat dalam satu sheet sendiri, yaitu hasil pemfilteran dari Tbl2 dengan kriteria-kriteria: misal: TglAwal, TglAkhir, PartNo. Menciptakan tabel report ini, paling sedikit ada 3 cara: dengan formula, dengan makro, dengan Query Sql. (dari Excel kita dapat meImport Data tidak hanya dari database lain (dbf, mdb, dsb..) tetapi juga dapat "mengimpor" dari sesama ExcelSheet pula, dan ada fasilitas Query-nya) Dgn cara ini kendala "kejenuhan mengisi data mutasi" dapt diatasi dengan formulir (userform yg sebagian mengotomatiskan / memudahkan & mencegah kesalahan pengisian) Barangkali cara standar itulah salah satu solusinya, agar penambahan Item tidak menimbulkan problem.. dan ini hanyalah sebuah pendangan saja.. sambil menunggu solusi-solusi dari teman-teman lain. best regards, siti Vi On 12/27/06, didigomo <[EMAIL PROTECTED]> wrote:
Dear XL-mania Saya ada kasus seperti terlampir. File ini digunakan untuk report control material perbulan. Sheet sep'06~Aug'07 digunakan untuk menginput data in dan out material perhari. Sheet Monthly Summary digunakan untuk report print out perbulannya. Sedangkan sheet master data adalah database untuk part number. (jumlah part number lebih dari seratus) Permasalahannya bila ada part number baru/update dan akan di insert row diantara No. 2 dan 3 agar part number urut (dalam sheet master data) otomatis sheet monthly s/d sheet Aug07 akan ikut berubah sesuai dengan sheet master data,hal ini bisa dilakukan hanya untuk part No. dan part name saja (karena memakai formula array),tetapi angka/quantitynya yang terdapat di sheet monthly s/d sheet Aug07 tidak ikut berubah (row tidak turun) bagaimana menyiasatinya? Apa ada ide lain untuk merubah format report ini agar lebih mudah? Mohon saran dari para pakar xl sekalian Terima kasih salam didigomo
