Sistem Informasi Perusahaan 10. View Integration & Implementation Compromises. Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

dokumen-dokumen yang mirip
Sistem Informasi Perusahaan 9. The Acquisition/Payment Business Process. Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

Sistem Informasi Perusahaan 13. The Financing Business Process. Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

Sistem Informasi Perusahaan The Sales/Collection Business Process. Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

Ratu Alyada. Sistem Informasi Perusahaan SUMMARY Chapter 8 13 By : Ratu Alyada

Sistem Informasi Perusahaan 15. ERP Systems and E-Commerce: Intra- and Inter-Enterprise Modeling. Ratih Dyah Kusumastuti Source: Dunn et al.

Summary Sistem Informasi Enterprise. The Financing Business Process

[Summary] Sistem Informasi Perusahaan Chapter 3

PERSEDIAAN DAN BIAYA PERSEDIAAN YANG TERJUAL

BAB III PEMBUATAN MODEL DATA DAN DESAIN DATABASE

PEMBUATAN MODEL DATA DAN DESAIN DATABASE (lanjutan)

PERKIRAAN PENGHUBUNG (ACCOUNT INTERFACE)

PERTEMUAN 6 MANAJEMEN DESAIN DATABASE

Sistem Informasi Perusahaan 12. Proses Bisnis SDM. Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

[Summary] Sistem Informasi Perusahaan Chapter 6

PENILAIAN PERSEDIAAN: PENDEKATAN DASAR BIAYA

PERANCANGAN BASIS DATA

PEMBUATAN MODEL DATA DAN DESAIN DATABASE

BAB III LANDASAN TEORI. 2001) suatu sistem mempunyai karakteristik atau sifat-sifat tertentu seperti:

[Data Warehouse] [6/C2 & 6/D2]

BINUS UNIVERSITY. Jurusan Sistem Informasi Skripsi Sarjana Komputer Semester Ganjil Tahun 2007/2008

TINJAUAN MENYELURUH PROSES BISNIS

BAB II LANDASAN TEORI

BAB III LANDASAN TEORI

PERANCANGAN BASIS DATA. Alif Finandhita, S.Kom

Jurnal Khusus (Special Journals)

PENDAHULUAN. Alif Finandhita, S.Kom

Prosedur Menjalankan Program

BAB 2 LANDASAN TEORI

PEMODELAN DATA DAN DESAIN DATABASE

BAB II BAHAN RUJUKAN

Database Systems: Ch. 3: The Relational Model. History of The Relational Model. Learning Objectives

Persediaan (Inventory)

cek, wesel (kiriman uang atau money orders), dan uang yang tersimpan di bank yang penarikannya tidak dibatasi (Warren et al. 2006).

BAB 7 PERANCANGAN DATA BASE

SISTEM BASIS DATA (Lanjutan) :

SQL Server merupakan program yang dirancang khusus untuk berkomunikasi dengan database relasional guna mendukung aplikasi dengan arsitektur

Analisis Sistem Akuntansi Persediaan

2. Masukan detail barang secara lengkap lalu tekan tombol add ujung kiri bawah.

BAB III LANDASAN TEORI. adalah sebagai berikut: Sistem adalah suatu jaringan kerja dari prosedur-prosedur

Pertemuan Transformasi ER-MODEL INDIKATOR. 1. Memahami ER model 2. Menerapkan transformasi ER- Model ke Model Relasional.

AKUNTANSI KEUANGAN MENENGAH I

Semester Ganjil 2014 Fak. Teknik Jurusan Teknik Informatika Universitas Pasundan. Caca E. Supriana, S.Si.,MT.

Entity Relationship Model

PEMBUATAN MODEL DATA DAN DESAIN DATABASE (lanjutan)

Metodologi Perancangan basis data secara konseptual

BASIS DATA MODEL BASIS DATA

Week 10 SISTEM INFORMASI AKUNTANSI SIKLUS PENGELUARAN. Awalludiyah Ambarwati

BAB 2 LANDASAN TEORI

MEMAHAMI KONSEP DATABASE. Oleh : Yuhefizar, S.Kom

Praktek STMIK AMIK Parna Raya Manado 1/26

Daftar Isi. 5. Pembelian dan Hutang. SIMAK Accounting Pembelian dan Hutang

BAB 2 LANDASAN TEORI. beberapa pakar. Definisi tersebut antara lain yaitu : dari beberapa file dokumen yang terhubung secara logis.

Akuntansi untuk Perusahaan Dagang

Sistem Informasi Perusahaan UAS

Model Data. Universitas Darwan Ali Kalimantan Tengah. Author : Minarni, S.Kom.,MM

BAB II. 2.1 Model Data High Level Data Model (Conceptual Data Model)

Sistem Basis Data BAB 8 MODEL DATA DAN ENTITY RELATIONSHIP MODEL. Komponen model data dapat dikategorikan menjadi 3 (tiga) bagian yang meliputi:

SATUAN ACARA PERKULIAHAN(SAP)

Gambar Halaman Detail Supplier. Spesifikasi Penggunaan modul halaman Detail Supplier.

SATUAN ACARA PERKULIAHAN(SAP)

BAB III LANDASAN TEORI. bertahan dalam jangka waktu tertentu. Menurut (Kristanto, 2008:1) sistem

BAB II LANDASAN TEORI. pembuatan tugas akhir ini. Teori-teori yang digunakan adalah:

ERD, EERD DAN PEMETAAN KE MODEL RELASIONAL

ER (Entity-Relationship) Model dan Mapping ke Model Relasional. Politeknik Elektronika Negeri Surabaya

BAB II TINJAUAN PUSTAKA

PEMBUATAN MODEL DATA DAN DESAIN DATABASE

UNIVERSITAS BINA NUSANTARA. Jurusan Teknik Informatika Skripsi Sarjana Komputer Semester Ganjil tahun 2006/2007

ANALISA & PERANCANGAN SISTEM

Model Entity Relationship Bagian I

BAB II LANDASAN TEORI. Antrian sering dijumpai dalam kehidupan sehari-hari contohnya dalam

BAB II LANDASAN TEORI. Institut merupakan Perguruan Tinggi yang menyelenggarakan pendidikan

Modul Penjualan. Menu penjualan dapat diakses dari menu utama Data Entry [Daftar Transaksi] Sales [Penjualan] atau langsung dari menu Navigator.

-DATABASE (BASIS DATA)- Nama : Novriansyah Kelas : 2.DB.10 NPM : Dosen : Leli Safitri

MODEL DATA DAN DESAIN DATABASE

MYOB 18 Ed PT ADI JAYA (UKK2013) Abdul Rahman, S.Pd. [2014] PEMBAHASAN STUDI KASUS PT ADI JAYA (UKK PAKET 3 - AVERAGE)

Basis Data. Bab 1. Sistem File dan Basis Data. Sistem Basis Data : Perancangan, Implementasi dan Manajemen

BAB II LANDASAN TEORI. bagian dalam sistem penggajian, formulir, database serta sistem pengendalian internal.

PEMODELAN DATA (ER-D) Basis Data -1 / Dian Dharmayanti

Soal-soal Kartu Persediaan (Inventory Card) Metode Periodik (Periodic Inventory System) Metode Perpetual (Perpectual Inventory System)

BAB II LANDASAN TEORI

View Detail Supplier yang berfungsi untuk menampilkan data detail dari. Supplier Confirmation. Admin dapat pula menghapus supplier yang terdapat di

Teknik Informatika. Bab III: Perancangan BasisData

BAB III LANDASAN TEORI

SISTEM BASIS DATA Presented By

1 Januari 2014/ 31 Desember January 2014/ December 31, 2013

ANALISIS DAN PERANCANGAN SISTEM BASIS DATA PENJUALAN, PEMBELIAN DAN PERSEDIAAN PADA PT. HARRISMA AGUNG JAYA

PENDEKATAN MODEL REA DALAM PERANCANGAN DATABASE SISTEM INFORMASI AKUNTANSI SIKLUS PENDAPATAN

Manajemen Keuangan. Bentuk Bentuk Laporan Keuangan Perusahaan. Basharat Ahmad. Modul ke: Fakultas Ekonomi dan Bisnis. Program Studi Manajemen

ENTITY RELATIONSHIP DIAGRAM SISTEM BASIS DATA

II.7.3 Stored Procedured II.7.4 Trigger II.8 C# II.9 Akuntansi II.9.1 Laba Rugi II.9.2 Average Method II.9.

MODUL 4 Account Receivable

BAB 3 ANALISIS DAN PERANCANGAN. menentukan dan mengungkapkan kebutuhan sistem. Kebutuhan sistem terbagi menjadi

KODE MK : ST 126 UT3. Pemodelan Data. Agus Romadhona

BAB III LANDASAN TEORI. Menurut Herlambang dan Tanuwijaya (2005:116), definisi dari sistem

PERUM PERCETAKAN UANG INDONESIA DAN ENTITAS ANAK REPUBLIK INDONESIA AND ITS SUBSIDIARIES LAPORAN POSISI KEUANGAN KONSOLIDASIAN

COST ACCOUNTING MATERI-9 BIAYA BAHAN BAKU. Universitas Esa Unggul Jakarta

Perancangan Database

Bab 9 KONSEP e SUPPLY CHAIN DALAM SISTEM INFORMASI KORPORAT TERPADU

BASIS DATA I/2011-GANJIL MODEL RELASIONAL. Oleh Team Teaching Database. 12 Oktober 2011 BASIS DATA I/2011-GANJIL 1

UNIVERSITAS BINA NUSANTARA. Jurusan Teknik Informatika Program Studi Strata-1 Skripsi Sarjana Komputer Semester Ganjil tahun 2005/2006

Transkripsi:

Sistem Informasi Perusahaan 10. View Integration & Implementation Compromises Ratih Dyah Kusumastuti Source: Dunn et al. (2006)

Outline Pengantar View integration Kompromi dalam implementasi Kebutuhan informasi yang membutuhkan data dari beberapa proses bisnis

View Modeling & View Integration Dalam perancangan sistem informasi, model digunakan untuk mengurangi kompleksitas dan menyederhanakan realita menjadi manageable pieces Pemodelan terpisah dari tiap siklus transaksi disebut sebagai view modeling Penggabungan model-model menjadi suatu kesatuan yang lengkap disebut sebagai view integration

View Integration (1) Dapat dilakukan sebagai suatu tahapan normal dalam perancangan basis data untuk suatu perusahaan Atau dapat dilakukan untuk mengkonsolidasikan beberapa basis data terpisah untuk kasus corporate merger, akuisisi ataupun berbagai bentuk konsolidasi bisnis lainnya View integration terdiri dari 3 langkah

View Integration (2) Langkah 1: Identifikasi entitas yang sama pada dua conceptual level views Tiap pasangan siklus yang terhubung dalam rantai nilai, paling tidak memiliki satu resource yang sama Banyak siklus yang paling tidak memiliki satu agen yang sama Cash receipt events dan Cash disbursement events biasanya terdapat di beberapa siklus

View Integration (3) Langkah 2: Gabungkan entitas yang sama, selesaikan konflik antar entitas dan atributnya Konflik nama entitas Sinonim: dua atau lebih nama entitas yang berbeda digunakan untuk merepresentasikan entitas yang sama Homonyms: satu nama entitas digunakan untuk merepresentasikan dua atau lebih entitas yang berbeda Konflik atribut Beberapa atribut yang berbeda digunakan untuk menjelaskan entitas yang sama pada berbagai view Termasuk semua atribut yang dibutuhkan oleh semua siklus transaksi sebagai atribut entitas pada model terintegrasi

View Integration (4) Langkah 3: Selesaikan konflik antar relasi, termasuk konflik nama dan konflik struktural Pastikan tiap relasi memiliki nama yang unik Pastikan kardinalitas partisipasi yang tepat untuk semua relasi, setelah entitas-entitas yang sama digabungkan

Revenue Cycle View

Acquisition Cycle View

Identifikasi entitas yang sama

Gabungkan entitas yang sama

Selesaikan konflik nama relasi

Kompromi pada tahap implementasi (1) Kompromi pada tingkatan konseptual Tidak-dimasukkannya suatu entitas (biasanya suatu resource) karena ketiadaan alat-alat pengukuran (measurement tools) Contoh: tenaga kerja dan penggunaan aset tetap, persediaan, dan berbagai jasa pada proses-proses nonkonversi Tidak dimasukkannya suatu relasi karena inadequate traceability atau karena ketiadaan informasi keputusan yang dibutuhkan dari relasi tersebut Hal ini harus dilakukan secara hati-hati, karena informasi keputusan mungkin dibutuhkan di masa yang akan datang

Kompromi pada tahap implementasi (2) Konsolidasi entitas yang kongruen secara konseptual Contoh: events yang biasa terjadi secara simultan

Kompromi pada tahap implementasi (3) Perwujudan tasks sebagai entitas Contoh: Request for Quote, Receive Bids Gunakan kriteria apa yang dibutuhkan untuk melakukan perencanaan, pengendallian dan pelaksanaan untuk menentukan kapan pemodelan langkah-langkah yang dibutuhkan untuk menyelesaikan suatu event dilakukan secara terpisah Jika atribut dibutuhkan untuk tujuan pengambilan keputusan dan atribut tersebut tidak dapat disimpan pada entitas event yang ada, biasanya tasks harus diwujudkan sebagai entitas

Kompromi pada tahap implementasi (4) Kompromi pada tingkatan logika Pertimbangan load yang dibahas pada bab 6 sebenarnya merupakan suatu kompromi pada tahap implementasi Basis data relasional yang sesungguhnya seharusnya tidak menyertakan nilai null

Kompromi pada tahap implementasi (5) Posting keys dari entitas-entitas yang serupa dalam satu kombinasi untuk menghindari nilai null atau menggabungkan entitas-entitas yang serupa tanpa suatu relasi generalisasi Contoh: membuat satu kolom Payee pada cash disbursement untuk memungkinkan posting suatu foreign key dari Pemasok, Karyawan (untuk cek gaji), kreditur (untuk pembayaran pinjaman), dll tanpa menyebabkan nilai null Mengakibatkan referential integrity tidak dapat diterapkan Lebih baik menggabungkan entitas-entitas yang serupa menjadi suatu entitas dan kemudian membuat relasinya Contoh: Buku alamat Peoplesoft Enterprise One menggabungkan Pelanggan, pemasok, Karyawan

Combined entity key posting

Combined entity key posting Kekurangan dari kompromi (combined entity key posting) ini: referential integrity tidak dapat diberlakukan

Penggabungan himpunan entitas tanpa generalisasi Pada kompromi ini, Participate1 menjelaskan relasi antara Cash disbursement dan agen internal, Participate2 menjelaskan relasi antara Cash disbursement dan agen eksternal. Referential integrity sekarang bisa diterapkan.

Kompromi pada tahap implementasi (6) Kompromi pada tingkatan fisik Penyimpanan derivable attributes Penyimpanan static derivable attribute disarankan bila dapat memfasilitasi querying; penyimpanan volatile derivable attribute harus dilakukan bila perangkat lunak memiliki kemampuan untuk men-trigger (yang disimpan untuk volatile derivable attributes adalah formula bukan nilai data) Event History Roll-up Salah satu manfaat dari basis data adalah virtual close yaitu kemampuan untuk menghasilkan financial statements tanpa benar-benar menutup buku. Kekurangannya adalah basis data dapat menjadi terlalu besar untuk pemrosesan yang efisien Solusi: begitu data even tidak lagi dibutuhkan dalam format ter-disagregasi, roll it up dalam suatu event

Event History Roll-up

Kebutuhan informasi dari beberapa siklus Banyak kebutuhan informasi menggabungkan data dari beberapa siklus transaksi Cash balance Quantity on Hand dari tipe-tipe inventori Nilai biaya total inventori Cost of Goods Sold Lainnya

Query untuk Cash Balance (1) 1. Tentukan tabel mana yang berisi cash receipt date (biasanya tabel cash receipt event) dan pastikan bahwa tabel yang sama juga berisi cash receipt amount field 2. Tentukan tabel mana yang berisi cash disbursement date (biasanya tabel cash disbursement event) dan pastikan tabel yang sama juga berisi cash disbursement amount field 3. Buatlah suatu query yang menentukan batasan ending date (tanpa batasan beginning date) dan jumlahkan cash receipt dollar amount yang diidentifikasi pada langkah 1 4. Buatlah suatu query yang menentukan batasan ending date (tanpa batasan beginning date) dan jumlahkan cash disbursement dollar amount yang diidentifikasi pada langkah 2 5. Buatlah suatu query yang mengurangkan total pada langkah 4 dari total pada langkah 3

Query untuk Cash Balance (2) Langkah 1: Identifikasi tabel dengan kolom cash receipt date dan amount Cash Receipt (Economic Increment) Event CashReceiptID Date Dollar Total CashAccountID FK CustomerID FK CashierID FK RA20 5/19/2010 $3,060.00 Ca123501 C2323 E111 RA21 5/24/2010 $3,050.00 Ca123501 C4731 E111 RA22 5/31/2010 $25,000.00 Ca123501 E111 Langkah 2: Identifikasi tabel dengan kolom cash disbursement date dan amount Cash Disbursement (Economic Decrement) Event DisbVoucherID VoucherDate DollarAmount CheckNbr CashAcctID FK APClerkID FK PayeeID FK 39 5/15/2010 $746.57 41234 Ca123501 E36 E23 40 5/25/2010 $28,450.00 41235 Ca123501 E36 V7 41 5/29/2010 $398.12 41236 Ca123501 E36 E41

Query untuk Cash Balance (3) Langkah 3: Query untuk menjumlahkan cash receipts sampai batasan ending date Langkah 4: Query untuk menjumlahkan cash disbursements sampai batasan ending date

Query untuk Cash Balance (4) Langkah 5: Hitung Cash Balance (Langkah 3 Langkah 4) Hasil hingga 31 Mei 2010

Query untuk Inventory Type Quantity on Hand (1) 1. Tentukan tabel mana yang berisi purchase date Biasanya tabel purchase event 2. Tentukan tabel mana yang berisi purchase quantity dan inventory item id-nya Biasanya tabel relasi stockflow purchase-inventory 3. Tentukan tabel mana yang berisi purchase return date Biasanya tabel purchase return event 4. Tentukan tabel mana yang berisi quantity returned dan inventory item id-nya Biasanya tabel relasi stockflow purchase return-inventory

Query untuk Inventory Type Quantity on Hand (2) 5. Tentukan tabel mana yang berisi sale date Biasanya tabel sale event 6. Tentukan tabel mana yang berisi quantity sold dan inventory item id-nya Biasanya tabel relasi stockflow sale-inventory 7. Gabungkan tabel-tabel yang diidentifikasi pada langkah 1 dan 2 (dengan purchase dates & quantities), group by inventory item, tentukan batasan ending date (tanpa batasan beginning date) dan jumlahkan quantity purchased untuk mendapatkan total quantity purchased per inventory item Sertakan atribut inventory item id pada hasil query result untuk menyediakan sarana untuk menghubungkannya ke intermediate results lainnya

Query untuk Inventory Type Quantity on Hand (3) 8. Gabungkan tabel-tabel yang diidentifikasi pada langkah 3 dan 4 (dengan purchase return dates dan quantities), group by inventory item, tentukan batasan ending date (tanpa batasan beginning date) dan jumlahkah quantity returned untuk mendapatkan total quantity returned per inventory item. Sertakan atribut inventory item id pada query result untuk menyediakan sarana untuk menghubungkannya ke intermediate results lainnya 9. Gabungkan tabel-tabel yang diidentifikasi pada langkah 5 dan 6 (dengan sale dates dan quantities), group by inventory item, tentukan batasan ending date (tanpa batasan beginning date) dan jumlahkah quantity sold untuk mendapatkan total quantity sold per inventory item Sertakan atribut inventory item id pada query result untuk menyediakan sarana untuk menghubungkannya ke intermediate results lainnya

Query untuk Inventory Type Quantity on Hand (4) 10. Gabungkan hasil pada langkah 7 (purchase quantities by item id) dan 8 (purchase return quantities by item id). Ubah tipe join untuk mengikutsertakan semua records dari total quantity purchased query dan pasangannya dari total quantity returned query Fungsi null to zero (Nz) dibutuhkan dalam kalkulasi untuk mengurangkan total quantity returned dari total quantity purchased Contoh: Nz(SumPurchaseQty) Nz(SumQtyReturned).

Query untuk Inventory Type Quantity on Hand (5) 11. Gabungkan hasil dari langkah 10 (unreturned purchase quantities by item id) dan 9 (quantities sold by item id). Ubah tipe join untuk mengikutsertakan semua records dari total unreturned quantities purchased query dan pasangannya dari total quantity sold query Fungsi null to zero (Nz) dibutuhkan dalam kalkulasi untuk mengurangkan total quantity sold dari total unreturned purchase quantity Contoh: Nz(SumUnreturnedPurchaseQty) Nz(SumSaleQty) query ini menghasilan total quantity on hand yang terpisah untuk tiap inventory type

Query untuk Inventory Type Quantity on Hand (6) Purchase (Economic Increment) Event Receiving Dollar Receiving ReportID Date Amount ClerkID FK Vendor FK SupplierID Invoice# Invoice Cash Amount DisbID FK RR18 4/30/2010 $28,450.00 E111 V7 VI4167 $28,450.00 40 RR19 5/8/2010 $1,100.00 E111 V14 821536 $1,100.00 RR21 5/10/2010 $3,240.00 E111 V14 821983 $3,240.00 RR22 5/12/2010 $2,000.00 E111 V7 VI5213 $2,000.00 RR25 5/12/2010 $480.00 E111 V90 312353 $480.00 Stockflow Relationship (Purchase Inventory Type) PurchaseID ItemID PurchaseQuantity ActualUnitCost RR18 BIS1 100 $20.00 RR18 LIS1 200 $35.50 RR18 HUS1 150 $29.00 RR18 TIS1 300 $50.00 RR19 MIN1 20 $55.00 RR21 MIN1 60 $54.00 RR22 BIS1 100 $20.00 RR25 TTP12 48 $10.00 Langkah 1, 2, dan 7 Batasi purchase date, jumlahkan quantities purchased untuk tiap inventory type

Query untuk Inventory Type Quantity on Hand (7) Purchase Return (Economic Increment Reversal) Event Purchase Dollar Packing Debit Receiving Dept Shipping ReturnID Date Amount Slip# Memo# ReportID FK SupplierID FK FK SuperID ClerkID FK PR3 5/17/2010 $480.00 22 3 RR25 V90 E5 E41 Stockflow Relationship (Purchase Return Inventory Type) PurchReturnID Item ID QuantityReturned ActualUnitCost PR3 TTP12 48 $10.00 Langkah 3, 4, dan 8: Batasi purchase return date; jumlahkan quantities returned by inventory type

Query untuk Inventory Type Quantity on Hand (8) Sale (Economic Decrement) Event Sale ID Date Dollar Total PickListID PackListID BOL# SalesRepID FK CustomerID FK CashReceiptID FK 12 5/5/2010 $1,100.00 15 15 15 E23 C2323 RA20 13 5/7/2010 $3,050.00 16 16 16 E26 C4731 RA21 14 5/8/2010 $2,100.00 17 17 17 E23 C2323 RA20 15 5/10/2010 $2,205.00 18 18 18 E23 C2323 Stockflow Relationship (Sale Inventory) Sale ID Item ID Quantity Sold Actual Unit Price 12 LIS1 2 70.00 12 TIS1 10 96.00 13 BIS1 40 60.00 13 HUS1 13 50.00 14 MIN1 20 105.00 15 MIN1 21 105.00 Langkah 5, 6, dan 9: Batasi sale date; jumlahkan quantities sold untuk tiap inventory type

Query untuk Inventory Type Quantity on Hand (9) Langkah 10: Gabungkan Quantities purchased & returned untuk menghitung unreturned purchase quantities

Query untuk Inventory Type Quantity on Hand (10) Langkah 11: Gabungkan net purchase quantities dan quantities sold untuk menghitung quantity on hand Hasil untuk 31 Mei 2010

Query untuk Inventory Type Cost Value (1) Untuk menghitung inventory cost value Jika menerapkan suatu asumsi inventory costing seperti weighted average unit cost, first-in-first-out (FIFO), atau lastin-first-out (LIFO) Buatlah queries untuk quantity on hand Buatlah queries untuk menentukan assumed unit costs Kalikan Quantity on Hand dengan Assumed Unit Cost Bila menerapkan actual costs berdasarkan identifikasi tertentu Membutuhkan queries untuk secara khusus mengidentifikasi inventory item mana yang disertakan pada tiap sale dan tetapkan biaya yang sesuai FIFO, LIFO,dan actual costs berdasarkan identifikasi spesifik membutuhkan queries yang sangat kompleks dengan pemrograman diluar cakupan mata kuliah ini

Query untuk Inventory Type Cost Value (2) Query untuk menghitung Weighted Average Unit Cost Purchase (Economic Increment) Event Receiving Dollar Receiving ReportID Date Amount ClerkID FK SupplierID FK Vendor Invoice# Invoice Cash Amount DisbID FK RR18 4/30/2010 $28,450.00 E111 V7 VI4167 $28,450.00 40 RR19 5/8/2010 $1,100.00 E111 V14 821536 $1,100.00 RR21 5/10/2010 $3,240.00 E111 V14 821983 $3,240.00 RR22 5/12/2010 $2,000.00 E111 V7 VI5213 $2,000.00 RR25 5/12/2010 $480.00 E111 V90 312353 $480.00 Stockflow1 Relationship (Purchase Inventory Type) PurchaseID ItemID PurchaseQuantity ActualUnitCost RR18 BIS1 100 $20.00 RR18 LIS1 200 $35.50 RR18 HUS1 150 $29.00 RR18 TIS1 300 $50.00 RR19 MIN1 20 $55.00 RR21 MIN1 60 $54.00 RR22 BIS1 100 $20.00 RR25 TTP12 48 $10.00

Query untuk Inventory Type Cost Value (3) Query untuk menghitung Weighted Average Unit Cost: Batasi purchase end date, hitung purchase line extensions

Query untuk Inventory Type Cost Value (4) Query untuk menghitung Weighted Average Unit Cost: jumlahkan purchase quantities dan purchase line extensions

Query untuk Inventory Type Cost Value (5) Query untuk menghitung Weighted Average Unit Cost: Bagi total purchase line extensions dengan quantities untuk mendapatkan weighted average unit costs

Query untuk Inventory Type Cost Value (6) kalikan QOH dengan WAUC untuk mendapatkan total cost value per item

Query untuk Inventory Type Cost Value (7) Jumlahkan cost values per item untuk mendapatkan total inventory cost value Hasil untuk 31 Mei 2010

Query untuk Cost of Goods Sold (1) 1. Tentukan tabel mana yang berisi sale date Biasanya pada tabel yang merepresentasikan sale event 2. Tentukan tabel mana yang berisi sale quantities Biasanya pada tabel yang merepresentasikan relasi stockflow antara sale dan inventory 3. Gabungkan tabel-tabel tersebut; tentukan batasan tanggal untuk awal dan akhir periode income statement; group by inventory id, dan jumlahkan quantity sold 4. Gabungkan hasil dari suatu query untuk weighted average unit cost dan hasil query untuk quantities sold; kalikan quantity sold dengan weighted average unit cost dapatkan total weighted average cos terpisah berdasarkan inventory items 5. Buatlah suatu query akhir yang menjumlahkan weighted average cost per inventory item sold untuk mendapatkan total COGS untuk income statement

Query untuk Cost of Goods Sold (2) Sale SaleID Date DollarTotal PickListID PackListID BOL# SalesRepID CustomerID CashReceiptID 12 5/5/2010 $1,100.00 15 15 15 E23 C2323 RA20 13 5/7/2010 $3,050.00 16 16 16 E26 C4731 RA21 14 5/8/2010 $2,100.00 17 17 17 E23 C2323 RA20 15 5/10/2010 $2,205.00 18 18 18 E23 C2323 StockflowSaleInventory SaleID ItemID QuantitySold ActualUnitSellingPrice 12 LIS1 2 $70.00 12 TIS1 10 $96.00 13 BIS1 40 $60.00 13 HUS1 13 $50.00 14 MIN1 20 $105.00 15 MIN1 21 $105.00 Langkah 1, 2, 3: Batasi sale date, group by inventory item ID, dan jumlahkan sale quantity

Query untuk Cost of Goods Sold (3) Langkah 4: Kalikan quantities sold dengan weighted average unit costs untuk mendapatkan cost of goods sold per item

Query untuk Cost of Goods Sold (4) Langkah 5: Jumlahkan cost of goods sold per item untuk mendapatkan total cost of goods sold Hasil untuk 31 Mei 2010

Ringkasan Untuk mengurangi kompleksitas, pada prakteknya model komseptual dibuat secara terpisah berdasarkan view yang berbeda (views dapat dipisahkan oleh siklus transaksi ataupun oleh batasan lainnya) Setelah tiap view dimodelkan, views harus diintegrasikan untuk membentuk model konseptual yang lengkapdan kemudian dikonversikan ke tingkatan logika Kompromi kadang harus dilakukan pada theoretic ideal dari model-model tingkatan konseptual, logika ataupun fisik akibat ketiadaan teknik pengukuran yang memadai, pertimbanganpertimbangan praktis serta pertimbangan lainnya Queries sering membutuhkan integrasi data dari berbagai siklus transaksi berbeda; suatu basis data terintegrasi mendukung queries yang kompleks tersebut