BAB 2 LANDASAN TEORI
2.1
Aplikasi Database Aplikasi database merupakan salah satu bentuk dari rekayasa piranti lunak. Rekayasa Piranti Lunak menurut Pressman(2001, p20) adalah pembangunan dan penggunaan prinsip rekayasa suara untuk mendapatkan piranti lunak yang ekonomis dan bekerja secara efisien dalam mesin. Untuk pengembangan piranti lunak terdapat empat kunci elemen, yaitu : a.
Fokus pada kualitas Landasan awal yang mendukung rekayasa piranti lunak.
b.
Proses Aktivitas yang menggabungkan layer teknologi dan mengembangkan piranti lunak pada komputer. Proses mendefinisikan framework untuk sekumpulan KPA (Kunci Proses Area) yang harus dibangun untuk pengiriman teknologi piranti lunak yang efektif. Kunci Proses Area membentuk basis untuk kontrol manajemen proyek piranti lunak
dan
membangun
konteks
dimana
metode
teknikal
diaplikasikan, produk kerja (model, dokumen, data, laporan, formulir) diproduksi, milestones dibangun, kualitas diyakinkan, dan perubahannya diatur secara biasa. c.
Metode
6
7 Menyediakan secara teknis bagaimana cara membangun piranti lunak. Metode menunjukkan sekumpulan tugas seperti analisis kebutuhan, perancangan, konstruksi program, testing dan dukungan. Metode rekayasa piranti lunak tergantung dengan sekumpulan prinsip dasar yang mengatur setiap area dari teknologi dan memasukkan aktivitas pemodelan dan teknik lainnya. d.
Alat Bantu (Tools) Alat bantu rekayasa piranti lunak menyediakan dukungan otomatisasi atau semi otomatis untuk bagian proses dan metode. Disini menggunakan CASE (Computer-aided Software Engineering) yang menggabungkan piranti lunak, piranti keras, dan database rekayasa piranti lunak.
2.1.1
Model Proses Piranti Lunak Incremental Model adalah model proses dengan menggabungkan elemen
pada
model
linear
sekuensial.
Incremental
model
mengaplikasikan urutan linear dalam kondisi yang bertingkat sebagai proses kalender waktu. Setiap urutan proses linear memproduksi peningkatan piranti lunak sebagai pengembangan piranti lunak. Ketika model incremental digunakan, perkembangan pertama digunakan sebagai produk utama. Lalu kebutuhan dasar dialamatkan tetapi beberapa fitur pendukung tetap tidak dikirimkan. Produk utama digunakan oleh pelanggan untuk review. Hasilnya berupa rencana untuk dikembangkan
8 pada proses pengembangan berikutnya. Proses ini diulang sampai piranti lunak lengkap sesuai dengan permintaan pelanggan.
2.2
Database 2.2.1
Data Menurut Turban Rainer Potter (2003, p352), Data adalah fakta mentah yang belum terorganisir untuk menjelaskan arti yang spesifik. Menurut Laudon(2003, p8), data merupakan aliran fakta yang mewakili kejadian yang terjadi dalam organisasi atau dalam lingkungan fisik sebelum mereka diatur menjadi sebuah bentuk yang dapat dimengerti dan digunakan oleh pengguna. Jadi, dapat disimpulkan bahwa data adalah fakta yang telah terjadi, memiliki arti, dan dapat disimpan serta dapat diatur sedemikian rupa sehingga dapat digunakan untuk berbagai tujuan.
2.2.2
Pengertian Basis Data Basis data (database) menurut Connolly dan Begg (2005, p15), basis data adalah sekumpulan data yang saling berhubungan dimana dirancang untuk mencapai informasi yang diperlukan dalam suatu organisasi. Artinya basis data adalah tempat penyimpanan data yang besar dimana bisa digunakan secara simultan atau secara bersamaan oleh banyak departemen dan pemakai lainnya (user). Di dalam basis data semua item data diintegrasikan untuk menghindarkan duplikasi data. Basis data tidak hanya mengandung data operasional organisasi, tetapi juga deskripsi dari data tersebut.
9 Selain itu, menurut O’Brien (2005, p211) Database adalah kumpulan integrasi elemen data yang secara logikal saling berhubungan. Database mengonsolidasikan berbagai catatan yang dahulu disimpan dalam file-file terpisah kedalam satu gabungan umum elemen data yang menyediakan data untuk banyak aplikasi. Jadi, Database berisi berbagai elemen data yang mendeskripsikan berbagai entitas dan hubungan antar entitas.
2.2.3
Sistem Manajemen Basis Data (Database Management System) Menurut Connolly dan Begg (2005, p16), sistem manajemen basis data (Database Management System) disingkat menjadi DBMS adalah sistem perangkat lunak yang dapat memungkinkan pemakai untuk mendefinisikan, membuat, dan memelihara database dan menyediakan control akses untuk database tersebut. DBMS berinteraksi dengan program aplikasi pemakai dan basis data. DBMS menghasilkan fasilitas sebagai berikut : •
Mengijinkan pemakai untuk medefinisikan basis data biasanya melalui Data Definition Language (DDL). DDL mengizinkan user untuk menspesifikasi tipe data dan struktur serta batasan data yang dapat disimpan di basis data.
•
Mengizinkan pemakai untuk melakukan insert, update, delete dan retrieve data dari basis data biasanya melalui Data Manipulation Language (DML).
10 •
Menghasilkan akses pengendalian basis data seperti : 1. Security system untuk membatasi penggunaan basis data. 2. Integrity
system
untuk
menangani
konsistensi
untuk
menangani
penyimpanan data. 3. Control
concurrency
system
penggunaan bersama basis data. 4. Control recovery system untuk menyimpan kembali basis data saat terjadi kesalahan pada perangkat keras maupun perangkat lunak. 5. User accessible catalog berisi deskripsi data di dalam basis data. Selain itu menurut Connolly dan Begg (2005, p18), suatu DBMS menyediakan fasilitas lainnya yang dikenal sebagai suatu view mechanism, yang memperbolehkan setiap pemakai (user) mempunyai view nya sendiri dari basis data (suatu view adalah didalam pokok suatu subset dari basis data). View mempunyai beberapa keuntungan lainnya, yaitu : •
View menyediakan suatu tingkatan (level) dari keamanan (security). View dapat dibentuk untuk meniadakan data dari beberapa pemakai yang sebaiknya tidak dilihat.
•
View menyediakan suatu mekanisme untuk mengatur apa yang ditampilkan dari basis data.
11 •
Suatu view dapat menghadirkan sebuah konsistensi, gambaran yang tidak berubah dari struktur basis data, bahkan dengan kondisi jika yang mendasari basis data diubah (sebagai contoh, fields dari data yang ditambah atau dihapus, hubungan yang berubah, file-file yang di-split, restrukturisasi, atau penamaan ulang). Adapun komponen-komponen DBMS menurut Connoly (2005,
p18), terdiri atas : 1.
Hardware Untuk menjalankan DBMS dan aplikasi. Berupa personal computer, mainframe, dan jaringan komputer. Untuk menjalankan DBMS memerlukan kecepatan memory dan kapasitas harddisk tertentu.
2.
Software Software mencakup DBMS, program aplikasi, dan sistem operasi.
3.
Data Penghubung antar komponen mesin (hardware dan software) dengan komponen manusia (prosedur dan orang).
4.
Prosedur Instruksi dan aturan yang mengatur perancangan dan penggunaan basis data.
5.
Orang
12 Semua orang yang terlibat sistem. Antara lain :
2.2.4
-
DBA (Database Administrator)
-
Pengembang aplikasi
-
Pengguna akhir.
Database Languages 2.2.4.1
Data Definition Language (DDL) Data Definition Language (DDL) merupakan sebuah bahasa yang memungkinkan Database Administrator (DBA) maupun pengguna untuk menggambarkan dan menamai entity, atribut, dan hubungan yang dibutuhkan pada aplikasi bersamaan dengan beberapa associated integrity dan batasan keamanan (Connolly, 2005, p40). Hasil dari kompilasi perintah DDL adalah kumpulan tabel yang disimpan dalam file khusus yang disebut Kamus Data (Data Dictionary). Menurut McLeod (2001, p387), kamus data adalah suatu penjelasan tertulis mengenai data yang berada di dalam basis data. Kamus data ini dimaksudkan untuk melengkapi pembuatan model proses yang menggunakan diagram alir data (Data Flow Diagram). Beberapa statement DDL (Connolly, 2005, p169) : 1.
Create Table Untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom.
2.
Alter Table
13 Untuk menambah atau membuang kolom dan constraint. 3.
Drop Table Untuk membuang atau menghapus tabel beserta semua data yang terkait di dalamnya.
4.
Create Index Untuk membuat indeks pada suatu tabel.
5.
Drop Index Untuk membuang atau menghapus indeks yang telah dibuat sebelumnya.
2.2.4.2
Data Manipulation Language (DML) Menurut Manipulation
Connolly Language)
(2005,
p41),
DML
(Data
adalah
suatu
bahasa
yang
menyediakan kumpulan operasi yang akan diinginkan untuk mendukung operasi manipulasi data utama pada data yang diperoleh dalam basis data. Menyediakan operasi dasar manipulasi data pada data yang ada dalam basis data, yaitu : •
Penyisipan data baru ke dalam basis data (insertion).
•
Mengubah atau modifikasi data yang disimpan di dalam basis data (modify).
•
Pemanggilan data yang ada dalam basisdata (retrieve).
14 •
Menghapus data dari basis data (delete).
Menurut
Connolly
(2005,
p41),
penulis
dapat
membedakan DML menjadi 2 tipe yang berbeda yaitu : a.
Procedural DML Procedural DML adalah suatu bahasa yang
memungkinkan
pengguna
(umumnya
programmer)
untuk memberi instruksi ke sistem mengenai data apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). Artinya pengguna harus menjelaskan operasi pengaksesan
data
yang
akan
digunakan
dengan
menggunakan prosedur yang ada untuk mendapatkan informasi yang dibutuhkan. b.
Non-Procedural DML Non-Procedural
DML
adalah
bahasa
yang
memungkinkan pengguna untuk menentukan data apa yang dibutuhkan dengan menyebutkan spesifikasinya tanpa
menspesifikasikan
bagaimana
cara
mendapatkannya. 2.2.4.3
Fourth Generation Languages Menurut Connoly (2005, p42), Fourth-Generation Languages
(4GLs)
procedural
yang
adalah lebih
bahasa
sederhana
pemrograman dibandingkan
nonbahasa
pemrograman generasi ke tiga (3GL).Beberapa jenis 4GLs (Connoly, 2005, p42) :
15 •
Forms Generators Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa yang akan disajikan, komponen warna pada layar dan karakteristik lainnya.
•
Report Generators Membuat laporan (report) yang datanya diambil dari database. Memungkinkan user untuk mengambil data yang diperlukan
untuk
laporan.
Lebih
menekankan
pada
rancangan output, yaitu bagaimana suatu laporan akan disajikan. •
Graphic Generators Digunakan untuk mengambil data dari database, dan menampilkannya dalam bentuk grafik seperti bar, chart, pie chart, line chart dan lain-lain.
•
Application Generators Fasilitas untuk menghasilkan program yang berhubungan dengan data, menentukan bagaimana menampilkan fungsifungsi.
Adapun contoh 4GLs adalah SQLdan QBE.
16 2.2.5
Siklus Hidup Aplikasi Basis Data (Database System Development Lifecycle) Untuk merancang aplikasi sistem basis data diperlukan beberapa tahapan terstruktur yang harus diikuti dan dinamakan dengan Siklus Hidup Aplikasi Basis Data (Database System Development Lifecycle) atau disingkat dengan SDLC. Dikarenakan sistem basis data adalah komponen dasar dalam sistem informasi organisasi yang lebih besar dan luas, daur hidup aplikasi basis data berkembang terhubung dengan daur hidup sistem informasi. Adalah penting untuk mengetahui bahwa tahapan daur hidup sistem informasi tidaklah harus berurutan, tetapi melibatkan beberapa jumlah pengulangan tahap sebelumnya melalui feed-back loops. Berikut ini akan ditunjukkan tahapan daur hidup aplikasi basis data pada gambar di bawah ini :
17
Gambar 2.1 Tahap - Tahap Siklus Hidup Aplikasi Basis Data (Sumber : Connolly, 2005, p284)
2.2.5.1 Perencanaan Basis Data (Database Planning) Perencanaan
Basis
Data
(Database
Planning)
merupakan aktivitas-aktivitas manajemen yang memungkinkan tahap-tahap dalam aplikasi basis data direalisasikan seefisien dan seefektif mungkin (Connolly, 2005, p285). Perencanaan
18 basis data harus diintegrasikan dengan keseluruhan sistem informasi suatu organisasi. Ada 3 (tiga) persoalan pokok yang terlibat dalam perumusan suatu strategi sistem informasi : •
Identifikasi rencana, sasaran (goals) dan tujuan perusahaan dengan penentuan kebutuhan sistem informasi.
•
Evaluasi sistem informasi yang sedang berjalan untuk menentukan kelebihan dan kekurangan yang ada.
•
Penilaian
terhadap
peluang
IT
apakah
mampu
menghasilkan keuntungan yang kompetitif. Tahapan dalam perencanaan basis data juga harus menjelaskan : •
Mission statement dari proyek basis data. Mission statement ini menjelaskan tujuan utama aplikasi basis data, juga membantu menjelaskan tujuan proyek basis data, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly, 2005, p286). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basis data ini maka diharapkan dapat
lebih
memfokuskan
pekerjaan
pada
tahap
selanjutnya. •
Mission objectives. Selain merumuskan tujuan dari sebuah proyek basis data, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basis data tersebut.
19 Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basis data, dengan asumsi jika basis data mendukung mission objective, maka mission statement nya juga akan sesuai (Connolly, 2005, p286). Di dalam perencanaan basis data juga meliputi perkembangan standar yang akan menentukan bagaimana suatu data akan dikumpulkan, bagaimana format yang harus ditetapkan, lalu dokumentasi apa saja yang akan dibutuhkan, serta bagaimana desain dan implementasi harus dikerjakan nantinya. 2.2.5.2
Pendefinisian Sistem (System Definition) Pendefinisian sistem (system definition) menjelaskan bidang dan batasan aplikasi basis data serta pandangan pengguna (user view) secara umum (Connolly, 2005, p286). Hal ini sangat penting dilakukan dalam suatu proses perancangan basis data agar dapat melakukan proses identifikasi mengenai batasan sistem yang akan dirancang, serta bagaimana sistem tersebut akan berhubungan dengan bagian sistem informasi pada organisasi yang lain. Selain itu batasan sistem sebaiknya tidak hanya sesuai dengan bidang dan batasan aplikasi basis data serta pandangan pengguna yang telah ada saja pada saat ini, namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.
20 Pandangan
pengguna
sangat
diperlukan
untuk
mengidentifikasi informasi-informasi yang dibutuhkan oleh pengguna (user). Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan dan transaksi yang akan dijalankan terhadap data itu (Connolly, 2005, p287).
2.2.5.3
Pengumpulan
Kebutuhan
dan
Analisis
(Requirements
Collection and Analysis) Pada tahap ini dilakukan proses pengumpulan dan analisa informasi mengenai bagian organisasi yang harus didukung oleh aplikasi basis data, dan penggunaan informasi ini berguna untuk mengidentifikasi persyaratan pengguna terhadap sistem yang baru (Connolly, 2005, p288). Tahap ini meliputi pengumpulan dan analisis informasi mengenai bagian perusahaan yang harus dilayani oleh basis data. Ada 3 (tiga) pendekatan utama untuk pengaturan kebutuhan aplikasi basis data dengan multiple user views, yakni: •
Pendekatan centralized
21 Kebutuhan-kebutuhan untuk setiap user view digabung
dalam
suatu
kumpulan
kebutuhan
tunggal untuk aplikasi basis data baru. •
Pendekatan view integration Kebutuhan-kebutuhan untuk setiap user view digunakan untuk membangun sebuah model data yang terpisah untuk merepresentasikan pengguna itu sendiri. Hasil dari model data akan digabung pada tahap perancangan basis data.
•
Kombinasi antara centralized dan view integration Ada banyak cara untuk mengumpulkan informasi pada suatu proses resmi dalam menggunakan teknik-teknik seperti wawancara atau kuesioner untuk mengumpulkan fakta-fakta tentang sistem dan kebutuhan-kebutuhannya dinamakan dengan teknik fact-finding (Connolly, 2005, p314).
2.2.5.4
Perancangan Basis Data (Database Design) Perancangan basis data merupakan proses menciptakan perancangan untuk basis data yang akan mendukung operasi dan tujuan perusahaan (Connolly, 2005, p291). Terdapat 2 (dua) pendekatan dalam perancangan basis data (Connolly, 2005, p291), yaitu :
22 •
Bottom-up Pendekatan ini dimulai dari tingkat paling dasar dari atribut (yakni properti dari entity dan hubungan relasional) dimana melalui analisis gabungan antara atribut-atribut, dikelompokkan ke dalam relasi-relasi yang merepresentasikan tipetipe entity dan hubungan antara entity. Pendekatan ini lebih cocok untuk perancangan basis data yang sederhana dengan jumlah atribut yang relatif kecil.
•
Top-down Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan relasional dan entity tingkat tinggi.
Perancangan basis data terdiri dari 3 tahap utama (Connolly, 2005, p293), yaitu : 1.
Perancangan
Basis
Data
Konseptual
(Conceptual Database Design) Perancangan Basis Data Konseptual adalah proses membangun
suatu
model
informasi
yang
digunakan oleh perusahaan atau organisasi yang tidak
tergantung
dari
(Connolly, 2005, p293).
pertimbangan
fisik
23 2.
Perancangan
Basis
Data
Logikal
(Logical
Database Design) Logical database design adalah proses pembuatan suatu model informasi yang digunakan pada perusahaan berdasarkan pada model data yang spesifik, tetapi tidak tergantung dari Database Management System (DBMS) yang khusus dan pertimbangan fisik lain (Connolly, 2005, p294). 3.
Perancangan
Basis
Data
Fisikal
(Physical
Database Design) Physical database design adalah suatu proses untuk menghasilkan gambaran dari implementasi basis data pada tempat penyimpanan, menjelaskan dasar dari relasi, organisasi file dan indeks yang digunakan
untuk
efisiensi
data
dan
menghubungkan beberapa integrity constraints dan tindakan keamanan (Connolly, 2005, p294).
2.2.5.5
Pemilihan DBMS (DBMS Selection) Merupakan pemilihan dari suatu DBMS yang tepat untuk mendukung aplikasi basis data (Connolly, 2005, p295). Tahaptahap pemilihan DBMS : •
Menentukan istilah referensi studi
24 Istilah referensi studi untuk pemilihan DBMS sudah ditetapkan, penetapan objektif dan ruang lingkup studi, dan tugas-tugas yang harus dilakukan. Dokumen ini juga termasuk deskripsi kriteria yang digunakan untuk mengevaluasi produk DBMS, daftar-daftar produk yang mungkin dipakai, dan semua constraints yang perlu dan skala waktu untuk studi. •
Membuat daftar sementara 2 (dua) atau 3 (tiga) produk Kriteria yang dipertimbangkan untuk menjadi kritis agar implementasi dapat berjalan lancar dapat digunakan untuk membuat daftar awal persiapan produk DBMS untuk
evaluasi.
Sebagai
contoh,
keputusan
untuk
mengikutsertakan produk DBMS mungkin tergantung pada anggaran yang tersedia, tingkat dukungan vendor, kesesuaian dengan software lain, dan apakah produk dapat berjalan pada hardware tertentu. Informasi-informasi tambahan
lainnya
diperoleh
dengan
mengenai
produk
menghubungi
DBMS
dapat
pengguna
yang
menyediakan rincian spesifik tentang seberapa baik dukungan vendor, bagaimana produk dapat mendukung aplikasi tertentu, dan apakah hardware platform tertentu lebih bermasalah dari yang lain. World Wide Web (WWW)
25 adalah sumber informasi terbaik yang dapat digunakan untuk mengidentifikasi kandidat DBMS yang potensial. •
Mengevaluasi produk Ada berbagai fitur yang dapat digunakan untuk mengevaluasi
produk
DBMS.
Sebagai
tujuan
dari
evaluasi, fitur-fitur ini dapat dinilai sebagai kelompok (sebagai contoh, definisi data) atau perorangan (sebagai contoh,
ketersediaan
memungkinkan
tipe
untuk
data).
Fitur-fitur
evaluasi
produk
yang DBMS
dikelompokkan berdasarkan data definition (defenisi data), physical definition (defenisi fisik), accessibility (pengaksesan), transaksi),
transaction utilities
(penanganan
handling
(kegunaan),
development
(pengembangan), dan fitur-fitur lainnya. Data definition meliputi pemberian primary key, spesifikasi foreign key, keberadaan tipe data, perluasan tipe
data,
spesifikasi
domain,
kontrol
integritas,
mekanisme view, kamus data, kebebasan data. Physical definition meliputi keberadaan struktur file, pemeliharaan struktur file, mengurangi reorganisasi, pemberian
indeks,
variabel
panjang
fields/records,
kompresi data, encryption routines, kebutuhan memori, kebutuhan penyimpanan.
26 Accessibility meliputi query language, compliant, interface ke 3GLs, multi-user, security: access controls (kontrol akses) dan authorization mechanism (mekanisme otorisasi). Transaction
handling
meliputi
backup
dan
recovery routines, strategi resolusi deadlock, kemajuan model transaksi, parallel query processing. Utilities meliputi performance measuring, tuning, fasilitas load/unload, user usage monitoring, database administration support. Development meliputi 4GL/5GL tools, CASE tools, kemampuan windows, prosedur penyimpanan, triggers, rules, web development tools. Fitur-fitur lainnya meliputi upgradibility, stabilitas vendor, user base, training dan user support, dokumentasi, sistem operasi, biaya, online help, pengunaan standard, skalabilitas,
mendukung
untuk
analytical
tools,
interoperabilitas dengan DBMS lain sistem lain. •
Merekomendasikan
Pilihan
dan
Memproduksi
Laporan Langkah terakhir dari pemilihan DBMS adalah mendokumentasikan prosesnya dan membuat pernyataan dalam penemuan dan rekomendasi atas produk DBMS tertentu (Connolly, 2005, p299).
27 2.2.5.6
Perancangan Aplikasi (Application Design) Merupakan perancangan user interface dan program aplikasi yang menggunakan dan memproses basis data. Ada 2 (dua) aspek penting dalam perancangan aplikasi, yakni: •
Perancangan Transaksi (Transaction Design) Transaksi merupakan sebuah aksi, atau serangkaian aksi yang dilakukan oleh seorang pengguna atau program aplikasi yang mengakses atau mengubah isi dari basis data. Tujuan dari perancangan transaksi adalah untuk menetapkan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basis data, yang termasuk : 1. Data yang digunakan dalam transaksi. 2. Karakteristik fungsional dari transaksi. 3. Keluaran (output) dari transaksi. 4. Kepentingan pengguna. 5. Nilai yang diharapkan dari pemakaian. Perancangan ini harus dilakukan lebih awal dalam proses perancangan untuk memastikan bahwa basis data yang diimplementasikan mampu mendukung semua transaksi yang dibutuhkan. Ada 3 (tiga) jenis transaksi, yaitu :
28 1. Retrieval transactions, digunakan untuk mendapatkan kembali data untuk ditampilkan di layar atau dalam laporan. 2. Update transactions, digunakan untuk menambah data, menghapus data lama, atau memodifikasi data yang ada dalam basis data. 3. Mixed
Transactions,
melibatkan
retrieval
(pemanggilan) dan update (perubahan) data atau kombinasi antara keduanya. •
Perancangan Antarmuka (User Interface Design) Sebelum mengimplementasikan suatu form atau laporan, ada perlunya merancang tampilan (layout) terlebih dahulu. Berikut pedoman yang berguna dalam perancangan laporan : 1. Judul yang berarti, diusahakan pemberian nama suatu form cukup jelas menerangkan kegunaan dari suatu form atau laporan. Informasi yang disampaikan sebuah judul harus jelas dan terhindar dari ambigu. 2. Instruksi
yang
dapat
dipahami,
menggunakan
terminologi yang lazim dalam menyampaikan instruksi kepada pengguna. Instruksi harus diuraikan dengan singkat dan jelas, dan ketika membutuhkan informasi lebih lanjut, layar bantuan harus tersedia. Instruksi
29 harus ditulis dengan tata bahasa yang baku dengan menggunakan pola standar. 3. Pengelompokan logis dan pengurutan field, field yang berhubungan harus ditempatkan secara bersama dalam suatu form/laporan. Pengurutan field harus logis dan konsisten. 4. Tampilan permohonan layout form/laporan secara visual, form/laporan harus menarik perhatian bagi pengguna. Hindari area form yang kosong terlalu banyak atau field yang berlebihan. 5. Nama field yang lazim, agar tidak menimbulkan kebingungan bagi pengguna. 6. Terminologi dan singkatan yang digunakan harus konsisten. 7. Penggunaan warna secara konsisten dan berarti. 8. Ruang
yang
tampak
dan
batasan
untuk
field
pemasukan data, seorang pengguna harus secara visual menyadari jumlah ruang yang tersedia untuk setiap field. 9. Pergerakan kursor yang baik, seorang pengguna harus dengan mudah mengenal operasi yang dibutuhkan untuk menggerakkan kursor di seluruh form/laporan. 10. Perbaikan kesalahan untuk karakter individual dan field secara keseluruhan.
30 11. Pesan kesalahan untuk nilai yang tidak dapat diterima sistem. 12. Field-field yang bersifat pilihan harus ditandai dengan jelas. 13. Pesan-pesan untuk field yang bersifat menjelaskan. Ketika suatu pengguna menempatkan kursor pada suatu field, informasi tentang field tersebut seharusnya muncul dalam suatu posisi yang teratur pada layar. 14. Tanda penyelesaian Indikator yang menjelaskan bahwa suatu proses telah selesai dilaksanakan. Begitu juga ketika proses pengisian dalam field pada suatu form lengkap.
2.2.5.7
Prototipe (Prototyping) Merupakan pembuatan suatu model kerja dari aplikasi basis data. Suatu prototipe adalah model yang bekerja yang tidak mempunyai semua fitur-fitur yang diperlukan atau menyediakan semua fungsionalitas dari sistem terakhir. Tujuan utama dari pengembangan suatu aplikasi basis data prototipe adalah memungkinkan pengguna menggunakan prototipe tersebut untuk menentukan fitur-fitur dari sistem yang bekerja dengan baik, dan jika mungkin mengusulkan peningkatan atau bahkan fitur-fitur baru pada aplikasi basis data. Ada 2 (dua) strategi prototyping pada zaman sekarang:
31 •
Requirements
Prototyping,
menggunakan
suatu
prototipe untuk menentukan kebutuhan-kebutuhan dari aplikasi basis data yang diusulkan dan suatu waktu
kebutuhan-kebutuhan
tersebut
lengkap,
prototipe dibuang. •
Evolutionary Prototyping, digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototipe tidak dibuang tetapi dengan perkembangan yang lebih jauh menjadi aplikasi basis data yang digunakan.
2.2.5.8
Implementasi (Implementation) Merupakan realisasi fisik dari perancangan basis data dan aplikasi. Pada penyelesaian tingkat-tingkat perancangan (dimana mungkin atau tidak melibatkan prototyping), sekarang penulis dalam posisi mengimplementasikan basis data dan program aplikasi. Implementasi basis data dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau graphical user interface (GUI), dimana menyediakan fungsionalitas yang sama ketika menyembunyikan pernyataan DDL tingkat-rendah. Pernyataan DDL tersebut digunakan untuk membuat struktur basis data dan file basis data kosong.
Program
aplikasi
diimplementasikan
dengan
32 menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL). Bagian dari program aplikasi ini adalah transaksi basis data, dimana diimplementasikan dengan menggunakan Data Manipulation Language (DML) dari DBMS sasaran, yang mungkin disimpan dalam sekumpulan bahasa pemrograman, seperti Visual Basic. Juga mengimplementasikan komponenkomponen lainnya dari perancangan aplikasi seperti layar menu, form pemasukan data, dan laporan.
2.2.5.9
Perubahan dan Pengambilan Data (Data Conversion and Loading) Merupakan pemindahan data yang ada ke dalam basis data baru dan mengubah aplikasi yang ada untuk beroperasi pada basis data yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data baru menimpa sistem yang lama.
2.2.5.10 Pengetesan (Testing) Merupakan proses pengeksekusian program aplikasi dengan
maksud
pencarian
kesalahan-kesalahan.
Sebelum
ditunjukkan secara langsung, aplikasi basis data yang baru dikembangkan seharusnya diuji sepenuhnya.
33 2.2.5.11 Perawatan Operasional (Operational Maintenance) Merupakan proses pengawasan dan pertahanan sistem berikut instalasi. Pada langkah sebelumnya, aplikasi basis data telah diimplementasikan dan diuji sepenuhnya. Sekarang sistem memasuki langkah perawatan, yang melibatkan aktivitasaktivitas berikut : •
Mengawasi kinerja sistem.
•
Mempertahankan dan meng-upgrade aplikasi basis data (ketika dibutuhkan).
2.2.6
DFD (Data Flow Diagram) Pengertian dari DFD adalah teknik grafis yang menggambarkan aliran data melalui sebuah sistem dan merubah data yang bergerak dari input ke output. DFD dapat juga disebut dengan Bubble chart, Data Flow Graph (Roger, 2001, p309). Simbol-simbol yang terdapat dalam DFD : •
Menggambarkan external entity (terminal) dari sistem. •
Menggambarkan diselesaikan.
proses
atau
pekerjaan
yang
harus
34 • Objek Data; Menggambarkan aliran data atau input/output dari dan menuju proses. •
Menggambarkan penyimpanan data atau biasa disebut basis data (data store). Penyimpanan data dapat disamakan dengan seluruh bagian dari entity tunggal dalam model data. Tingkatan pada DFD : a. Diagram konteks Menggambarkan seluruh input ke atau output ke sistem. Diagram konteks ini merupakan level tertinggi dari DFD. b. Diagram nol Merupakan rincian dari diagram konteks dan memperlihatkan data store yang digunakan. c. Diagram rinci Merupakan rincian diagram diatasnya. Keuntungan pengunaan DFD : 1. Proses
dalam
DFD
dapat
beroperasi
secara
paralel.
Maksudnya beberapa proses dapat bekerja secara bersamaan sesuai dengan cara kerja bisnis. 2. DFD menunjukkan aliran data yang melalui sistem. Panahnya mewakili arah dimana data tersebut mengalir. Perulangan dan
35 percabangan
biasanya
tidak
diperlihatkan.
Flowchart
menunjukkan tahap-tahap dari proses atau operasi dalam algoritma/program. 3. DFD menunjukkan proses yang memiliki perbedaan waktu yang dramatis. Misalnya suatu DFD tunggal mungkin akan memasukkan proses yang terjadi perjam, perhari, perminggu, pertahun, dan sesuai permintaan.
2.2.7
Entity-Relationship Modelling (E-R Modelling)
a.
Entity Type Entity type ialah sekumpulan objek yang memiliki properti yang sama yang diidentifikasi dalam perusahaan serta keberadaannya independen (Connolly, 2005, p343). Setiap objek yang diidentifikasikan secara unik disebut entity occurence (Connolly, 2005, p333).
Gambar 2.2 Representasi Diagram Dari Entity Type Staff dan Branch (Sumber : Connolly, 2005, p345)
36 b.
Relationship Type Relationship Type ialah sekumpulan entity yang mempunyai hubungan dan memiliki arti (Connolly, 2005, p346).
Gambar 2.3 Representasi Diagram Dari Entity Branch Has Staff Relationship Type (Sumber : Connolly, 2005, p347)
c.
Attributes Menurut Connolly (2005, p350), atribut adalah properti dari sebuah entity atau relationship type. Sedangkan attribute domain adalah sekumpulan nilai yang dibolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan sebagai: 1. Simple dan Composite Attribute Simple attribute adalah sebuah atribut yang disusun oleh sebuah komponen tunggal dengan keberadaan yang independen. Simple attribute tidak dapat dipecah menjadi komponen yang lebih kecil lagi (Connolly, 2005, p351). Sebagai contoh simple attributte ialah atribut position dan salary pada entity Staff. Sedangkan Composite attribute
37 adalah sebuah atribut yang disusun oleh banyak komponen yang independen. Atribut ini bisa dipecah menjadi atribut yang lebih kecil. Contohnya atribut address dalam entity Branch dengan nilai (163 Main St, Blasgow, G11 9QX) dapat dipecah menjadi street (163 Main St), city (Glasgow), dan postcode (G11 9QX). 2. Single-valued dan Multi-Valued Attribute Single-valued attribute adalah sebuah atribut yang mempunyai nilai tunggal untuk setiap kejadian dalam sebuah entity (Connolly, 2005, p351). Contohnya pada entity Branch mempunyai
nilai
tunggal
pada
masing-masing
atribut
branchNo. Multi-valued attribute adalah sebuah attribut yang mempunyai nilai lebih dari satu untuk setiap kejadian pada entity (Connolly, 2005, p353). Contoh setiap atribut pada entity Branch dapat mempunyai telNo lebih dari satu (Misalnya cabang dengan branchNo B003 mempunyai telNo 0141-339-2178 dan 0141-339-4439). 3. Derived Attributes Derived
attribute
adalah
atribut
yang
merepresentasikan sebuah nilai yang bisa diperoleh dari nilai dari atribut yang berkaitan (Connolly, 2005, p352). d.
Keys
38 Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly, 2005, p352). Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas (Connolly, 2005, p353). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, 2005, p353). Pada sebuah tipe entitas biasanya terdapat lebih dari satu candidate key yang salah satunya harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut, jumlah minimal atribut yang diperlukan, dan keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih menjadi primary key, atau biasa disebut dengan secondary key (Whitten, 2004, p298). Foreign key adalah sebuah primary key pada sebuah entitas yang digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship (Whitten, 2004, p301).
Gambar 2.4 Representasi Diagram dari Entity Branch Beserta AtributAtributnya (Sumber : Connolly, 2005, p354)
39 2.2.8
Normalisasi Menurut Connolly (2005, p388), normalisasi adalah sebuah teknik untuk menghasilkan relasi dengan properti-properti yang diinginkan, memberikan kebutuhan data dari sebuah perusahaan. Tujuan normalisasi adalah terjaminnya struktur yang konsisten, kerangkapan yang minimal, dan stabilitas struktur data yang maksimal. Manfaat normalisasi adalah sebagai berikut : 1. Meminimalkan
jumlah
kapasitas
penyimpanan
yang
diperlukan untuk menyimpan data. 2. Meminimalkan resiko data yang tidak konsisten dalam suatu basis data. 3. Meminimalkan kemungkinan update dan delete anomally. 4. Memaksimalkan stabilitas dari struktur data. Proses normalisasi tabel secara detil dibagi menjadi lima tahap sehingga dikenal bentuk-bentuk tabel normal sesuai dengan tahapan normalisasi yang telah dilakukan yaitu bentuk normal pertama, kedua, ketiga, Boyce-Codd, keempat, dan kelima. 1.
First Normal Form (1NF) Menurut Connolly (2005, p403), First Normal Form adalah relasi dimana pertemuan antar setiap baris dan kolom terdiri 1 (satu) dan hanya 1 (satu) nilai. Bentuk normal pertama dicapai bila tiap nilai atribut adalah tunggal. Kondisi ini dapat diperolah dengan melakukan eliminasi terjadinya data
40 ganda (repeating groups). Pada kondisi normal pertama ini kemungkinan masih terjadi adanya data rangkap. 2.
Second Normal Form (2NF) Menurut Connolly (2005, p407), Second normal form (2NF) adalah merupakan sebuah relasi dalam 1NF dan setiap atribut non-primary key bersifat Full Function Dependency pada primary key dari relasi tersebut. Dalam normalisasi kedua ini, atribut yang tergantung pada sebagian dari suatu composite key sebuah tabel dipindahkan ke sebuah tabel yang terpisah.
3.
Third Normal Form (3NF) Menurut Connolly (2005, p409), Third normal form (3NF) adalah sebuah relasi yang memenuhi normal pertama dan normal kedua dimana tidak terdapat atribut non primary key yang bersifat transitively dependent dari primary key-nya. Dalam normalisasi ketiga ini, atribut yang tidak memberikan kontribusi terhadap penjelasan karakteristik primary key, akan
dipindahkan
ke
sebuah
tabel
yang
terpisah.
Keuntungan dari tabel relasional dalam 3NF adalah menghilangkan data yang berulang-ulang dengan tujuan menghemat tempat dan mengurangi keanehan manipulasi. 4.
Boyce-Codd Normal Form (BCNF)
41 Menurut Connolly (2005, p419) BCNF adalah sebuah relasi di mana setiap penentu atau determinan adalah candidate key. Untuk menguji apakah suatu relasi sudah dalam bentuk BCNF, dilakukan identifikasi semua determinan dan memastikan bahwa determinan tersebut adalah candidate key. Determinan adalah sebuah atribut, atau kumpulan atribut, dimana beberapa atribut yang lain masih bergantung penuh secara fungsional (full functional dependency). Perbedaan antara 3NF dan BCNF dalam hal functional dependency. A→B, 3NF mengizinkan ketergantungan ini dalam sebuah relasi jika B adalah atribut primary key dan A bukan
candidate
key.
Sedangkan
dalam
BCNF
ketergantungan ini tetap ada di dalam sebuah relasi, dimana A harus sebuah candidate key. 5.
Fourth Normal Form (4NF) Menurut Connolly dan Begg (2005, p430), normalisasi keempat dilakukan untuk menghilangkan multi-valued dependency.
Dimana
multi-valued
dependency
merepresentasikan ketergantungan antara atribut-atribut (contohnya terdapat atribut A,B,C) dalam relasi, misalnya untuk setiap nilai dari A adalah nilai dari B dan nilai dari C. Dalam hal ini nilai dari B dan C tidak saling bergantung satu dengan yang lain (Connoly, 2005, p429).
42 6.
Fifth Normal Form (5NF) Menurut Connolly (2005, p431), normalisasi kelima menyebabkan relasi tidak mempuyai join dependency.
2.3
Teori Khusus 2.3.1
Sales Order Sales
order
adalah
dokumen
elektronik
yang
berisi
permintaan/pembelian suatu barang/jasa dari customer (Yunarto, p7). Sales Order terdiri dari : -
Informasi Customer
-
Informasi barang/jasa
-
Jumlah Barang/Jasa
-
Harga Barang/Jasa
-
Jadwal Delivery dan Informasi Shipping
-
Informasi Billing (invoice)
-
Informasi Kantor Penjualan
-
Informasi Komisi
Menurut Yunarto, mekanisme pembentukan PO (purchase order) bisa beberapa macam, yaitu : -
Ketika ada order penjualan, langsung terbentuk PO ke suppliernya.
-
PO
akan
terbentuk
(Penggantian Stock).
dari
mekanisme
replenishment
43 -
PO terbentuk dari mekanisme production planning, misalnya dengan MPS (Master Production Schedule) dan MRP (Material Requirement Planning).
Terdapat beberapa tipe sales order dan masing-masing memiliki karakter transaksi yang berbeda-beda. Beberapa tipe sales order adalah sebagai berikut (Yunarto, p145) : 1. Standard Order : SO dengan langkah normal. Barang/Jasa dikenai harga dan muncul di invoice. 2. Cash Order : Pemberian berupa tanda terima ketika kasir mengentry cash sales order yang biasanya tidak dicetak. 3. Consignment Order : Penjualan konsinyasi ketika perusahaan mengirim barang kepada customer, namun barang masih menjadi hak milik perusahaan. Setelah barang dipakai atau terjual oleh customer, barang itu baru dinyatakan terjual dari perusahaan. 4. Free of Charge Order : transaksi penjualan dengan harga nol. 5. Quotation : Penawaran harga dari penjual ke pembeli yang merupakan aktivitas dari pre-sales. 6. Contract : Disebut juga blanket order, yang merupakan perjanjian jual-beli antara penjual dan pembeli. Dalam kontrak, penjual dan pembeli sepakat dalam hal kuantitas kontrak, harga, tanggal delivery, metode pembayaran , dll. 7. Direct from Supplier : Sales order dimana barang dikirim langsung oleh supplier.
44 8. Stock Transfer Order : Sales order untuk penjualan antara dua perusahaan yang biasanya masih dalam lingkup perusahaan induk. 9. Intercompany Order : Mirip dengan penjualan dimana barangnya
dikirim
langsung
dari
supplier
namun
perbedaannya adalah supplier pada perusahaan intercompany adalah dalam lingkup satu holding company (perusahaan induk). 10. Credit/Debit Memo : Tipe SO yang dibuat jika ada kesalahan dalam invoice. Disebut Credit Memo jika nilai invoice lebih besar dari harga sebenarnya. Disebut Debit Memo jika nilai invoice lebih kecil dari harga sebenarnya. 11. Return Order : Dibuat karena barang yang diterima pembeli tidak sesuai spesifikasinya, barang yang diterima salah barang, atau kuantitas dari barang tidak sesuai. Ada 15 Fungsi Sales order (Yunarto, p153) : 1. Quantity Booking : Terjadi ketika ada customer memesan barang tetapi perusahaan belum mengirimkan barang tersebut ke customer kemudian sales administration atau customer service akan mengentry sales order. Ketika sales order dientry maka stock barang di gudang akan dibooking sebanyak kuantitas yang dientry di sales order.
45 2. Availability Check : Pengecekan ketersediaan barang. Availability bisa bernilai minus karena permintaan lebih besar dari persediaan. 3. Available to Promise (ATP) : inventory perusahaan yang belum
dialokasikan
ke
replenishment(penambahan
sales
order
inventory).
sebelum Dapat
waktu
dilakukan
dengan work order(produksi barang), Purchase Order (pembelian barang), atau stock transfer(mutasi barang dari plant lain). Karena ada ATP tersebut, bagian sales belum dapat menjual barang tersebut. Jadi pada saat customer akan membeli suatu barang, bagian sales dapat menjamin dan menjanjikan bahwa barang yang tersedia dengan melihat informasi ATP ini. 4. Sales order Hold : digunakan untuk menghalangi sales order ke proses selanjutnya. Kontrol setiap perusahaan berbeda pada penanganan hold ini. 5. Credit Limit Check : batasan kredit yang digunakan untuk mengontrol besarnya kredit yang sudah diambil oleh customer. Penentuan besar credit limit, customer harus menyerahkan bank garansi.Bank garansi adalah surat jaminan dari bank berupa jaminan uang/asset dari customer. 6. Order Template : Pola pesanan customer yang sering terjadi berulang-ulang. Tujuannya agar proses pembuatan sales order menjadi lebih cepat.
46 7. Backorder : Pesanan customer yang tak terlayani karena tidak adanya inventory atau stock yang cukup. Informasi backorder berguna untuk langkah inventory sourcing sehingga dapat melihat barang apa aja yang backorder sehingga dapat dibuat segera
purchase
order
untuk
mengisi
inventory
(replenishment). 8. Substitute
Material
:
Suatu
material
alternatif
untuk
menggantikan materi lain yang tidak tersedia. 9. Cross Reference Material : Jembatan antara material perusahaan dengan material customer yang berfungsi sebagai konversi material perusahaan. 10. Multi currency and Unit of Measure (UOM) : Sales order harus dapat dientry dengan menggunakan banyak currency dan juga banyak unit of measure (UOM). 11. Product Configuration : Kumpulan Produk dalam bentuk suatu paket. Perusahaan dapat menjual produk baik satuan ataupun dalam bentuk paket. 12. Tax Determination : Sales order dapat dibuat apakah merupakan penjualan pajak atau non pajak. Penjualan tanpa pajak karena barang yang dijual adalah barang tidak kena pajak atau wilayah penjualan yang terjadi pada wilayah bebas pajak.
47 13. Commission : Komisi yang diberikan ke tenaga penjual. Beberapa
perusahaan
menggunakan
hal
ini
untuk
mendongkrak kemampuan sales force-nya. 14. Pricing : Sales order memiliki fungsi pricing. Maksudnya adalah memasukkan harga secara langsung oleh sales administration atau dihitung dengan aturan tertentu. 15. Data Exchange : digunakan untuk mempercepat operasional di bagian penjualan. Teknologinya adalah EDI (Electronic Data Interchange) yang berfungsi sebagai media pertukaran data antara perusahaan dengan customernya. Tujuan adalah akses informasi dapat dilakukan dengan sangat cepat dan tidak perlu ada input ulang oleh sales information.
2.3.2
Pembelian Menurut Mulyadi (2001, page 299), pembelian didefinisikan sebagai suatu usaha yang digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian menurut Mulyadi, dapat digolongkan menjadi dua, yaitu : •
Pembelian lokal Pembelian dari pemasok dalam negeri
•
Pembelian impor Pembelian dari pemasok luar negeri
48 Fungsi – fungsi yang terkait dalam sistem pembelian adalah: 1. Fungsi gudang, bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang. 2. Fungsi pembelian, bertanggung jawab untuk mengeluarkan order pembelian kepada pemasok. 3. Fungsi penerimaan, bertanggung jawab menerima barang yang dikirim dari pemasok dan melakukan pemeriksaan guna menentukan layak tidaknya barang untuk diterima. 4. Fungsi akuntansi, fungsi yang terkait dalam hal ini adalah fungsi pencatatan utang dan fungsi pencatatan persediaan. (Mulyadi, cetakan 3, page 299) Jaringan prosedur yang membentuk sistem pembelian menurut Mulyadi (cetakan 3, page 301) adalah sebagai berikut: 1. Prosedur permintaan pembelian Fungsi gudang mengajukan permintaan pembelian dalam formulir
surat
permintaan
pembelian
kepada
fungsi
pembelian. 2. Prosedur Permintaan Penawaran Harga dan Pemilihan Pemasok Dalam prosedur ini, fungsi pembelian mengirimkan surat permintaan penawaran harga kepada para pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain, untuk memungkinkan pemilihan
49 pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan
oleh
perusahaan.
Perusahaan
sering
kali
menentukan jenjang wewenang dalam pemilihan pemasok sehingga sistem akuntansi pembelian dibagi menjadi sebagai berikut: (1) Sistem akuntansi pembelian dengan pengadaan langsung. (2) Sistem akuntansi pembelian dengan penunjukan langsung. (3) Sistem akuntansi pembelian dengan lelang. Persediaan di antara sistem akuntansi pembelian tersebut di atas terletak pada prosedur pemilihan pemasok. 3. Prosedur order pembelian Fungsi pembelian mengirim surat order pembelian kepada pemasok dan memberitahukan kepada unit – unit lain (misalnya fungsi penerimaan, fungsi yang meminta barang, fungsi pencatatan utang) mengenai order pembelian yang sudah dikeluarkan. 4. Prosedur penerimaan barang Fungsi penerimaan melakukan pemeriksaan terhadap barang yang diterima dari pemasok, dan kemudian membuat laporan penerimaan barang. 5. Prosedur pencatatan utang Fungsi akuntansi memeriksa dokumen - dokumen yang berhubungan dengan pembelian dan menyelenggarakan pencatatan utang.
50 6. Prosedur distribusi pembelian Prosedur ini meliputi distribusi rekening yang didebit dari transaksi pembelian untuk kepentingan pembuatan laporan manajemen.
2.3.3
Persediaan Menurut Mulyadi (2001, page 553), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntansi biaya produksi. Dalam perusahaan manufaktur, persediaan terdiri dari persediaan produk jadi, persediaan produk dalam proses, persediaan suku cadang. Dalam perusahaan dagang, persediaan hanya terdiri dari satu golongan yaitu persediaan barang dagangan yang merupakan barang yang akan dibeli dengan tujuan untuk dijual kembali. Ada dua macam metode pencatatan persediaan menurut Mulyadi (2001, page 556), yaitu : o
Metode mutasi persediaan Dalam metode ini, setiap mutasi persediaan dicatat dalam kartu persediaan.
o
Metode persediaan fisik
51 Dalam metode ini, hanya tambahan persediaan dari pembelian saja yang dicatat sedangkan mutasi berkurangnya persediaan karena pemakaian tidak dicatat dalam kartu persediaan. Menurut Mulyadi (2001, page 576), fungsi yang terkait dalam sistem perhitungan fisik persediaan, yaitu : 1. Panitia
perhitungan
fisik
persediaan
berfungsi
untuk
melaksanakan perhitungan fisik persediaan dan menyerahkan hasil perhitungan tersebut kepada bagian kartu persediaan untuk digunakan sebagai dasar penyesuaian terhadap catatan persediaan dalam kartu persediaan.
2. Fungsi akuntansi, bertanggung jawab untuk : a. Mencantumkan harga pokok sistem persediaan yang dihitung dalam daftar hasil perhitungan fisik. b. Mengalihkan kuantitas dan harga pokok persatuan yang tercantum dalam hasil perhitungan fisik. c. Mencantumkan harga pokok total dalam daftar hasil perhitungan fisik. d. Melakukan
penyesuaian
terhadap
kartu
persediaan
berdasarkan data hasil perhitungan fisik persediaan. e. Membuat bukti memorial untuk mencatat penyesuaian data persediaan
dalam
jurnal
perhitungan fisik persediaan.
umum
berdasarkan
hasil
52 3. Fungsi gudang bertanggung jawab untuk melakukan penyesuaian data kuantitas persediaan yang dicatat dalam kartu gudang berdasarkan hasil perhitungan fisik persediaan. Menurut Mulyadi (2001, page 559), jaringan prosedur yang membentuk sistem penghitungan fisik persediaan adalah ; 1. Prosedur pencatatan produk jadi Prosedur ini merupakan salah satu prosedur dalam sistem akuntansi biaya produksi. Dalam prosedur ini dicatat harga pokok produk jadi yang didebitkan ke dalam rekening persediaan produk jadi dan dikreditkan ke dalam rekening barang dalam proses. Catatan akuntansi yang digunakan dalam prosedur pencatatan produk jadi adalah kartu gudang, kartu persediaan, dan jurnal umum. 2. Prosedur pencatatan harga pokok produk jadi yang dijual Prosedur ini merupakan salah satu prosedur dalam sistem penjualan di samping prosedur lainnya seperti prosedur order penjualan, prosedur persetujuan kredit, prosedur pengiriman barang, prosedur penagihan, prosedur pencatatan piutang. Catatan akuntansi yang digunakan dalam prosedur pencatatan harga pokok produk jadi yang dijual adalah kartu gudang, kartu persediaan, dan jurnal umum. 3. Prosedur pencatatan harga pokok produk jadi yang diterima kembali dari pembeli.
53 Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur barang. Jika produk jadi yang telah dijual dikembalikan oleh pembeli, maka transaksi retur penjualan ini akan mempengaruhi persediaan produk jadi. Catatan akuntansi yang digunakan dalam prosedur pencatatan produk jadi adalah kartu gudang, kartu persediaan, dan jurnal umum atau jurnal retur persediaan jika perusahaan menggunakan jurnal khusus. 4. Prosedur pencatatan tambahan dan penyesuaian kembali harga pokok persediaan produk dalam proses. Pencatatan
persediaan
produk
dalam
proses
biasanya
dilakukan oleh perusahaan pada akhir periode, pada saat dibuat laporan keuangan bulanan dan laporan keuangan tahunan pencatatan persediaan produk dalam jurnal umum. 5. Prosedur pencatatan harga pokok persediaan yang dibeli. Prosedur ini merupakan salah satu prosedur yang membentuk sistem pembelian. Dalam prosedur ini dicatat harga pokok persediaan yang dibeli. 6. Prosedur
pencatatan
harga
pokok
persediaan
yang
dikembalikan kepada pemasok. Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur pembelian. Jika persediaan yang telah dibeli dikembalikan pembelian
ini
bersangkutan.
kepada akan
pemasok,
maka
mempengaruhi
transaksi
retur
persediaan
yang
54 7. Prosedur permintaan dan pengeluaran barang gudang Prosedur ini merupakan salah satu prosedur yang membentuk sistem akuntansi biaya produksi. Dalam prosedur ini dicatat harga pokok persediaan bahan baku, bahan penolong, bahan habis pakai pabrik, dan suku cadang yang dipakai dalam kegiatan produksi dan kegiatan non produksi. 8. Prosedur pencatatan tambahan harga pokok persediaan karena pengembalian barang gudang. Prosedur ini melakukan transaksi pengembalian barang gudang mengurangi dan menambah persediaan barang di gudang. Jurnal yang dibuat untuk mencatat transaksi tersebut dalam jurnal umum. 9. Sistem perhitungan fisik persediaan. Sistem perhitungan fisik persediaan pada umumnya digunakan oleh perusahaan untuk menghitung secara fisik persediaan yang disimpan di gudang, yang hasilnya digunakan untuk meminta pertanggungjawaban bagian gudang mengenai pelaksanaan fungsi penyimpanan, dan pertanggung jawaban bagian gudang mengenai pelaksanaan fungsi penyimpanan, dan pertanggung jawaban bagian kartu persediaan mengenai keandalan catatan persediaan yang diselenggarakan, serta untuk melakukan penyesuaian terhadap catatan persediaan di bagian kartu persediaan.
55 Dokumen – dokumen yang digunakan untuk merekam, meringkas, dan membukukan hasil perhitungan fisik persediaan adalah (Mulyadi, 2001, page 575): 1. Kartu perhitungan fisik (inventory tag). 2. Daftar hasil perhitungan fisik (inventory summary sheet). 3. Bukti memorial.
