BAB 2 LANDASAN TEORI
2.1 Teori-teori Basis Data 2.1.1 Basis Data 2.1.1.1 Definisi Basis Data Menurut Connolly-Begg (2002, p14), basis data adalah suatu kumpulan yang dapat digunakan bersama dari data yang saling berhubungan secara logis, dan suatu gambaran dari data ini, yang dirancang untuk memenuhi kebutuhan informasi dari sebuah organisasi. Menurut Date (2000, pp5 -10), basis data adalah suatu kumpulan data persisten yang digunakan dengan sistem aplikasi dalam suatu perusahaan. Sedangkan sistem basis data adalah sistem penyimpanan record terkomputasi yang keseluruhannya bertujuan untuk menyimpan informasi dan untuk memungkinkan user untuk retrieve dan update informasi yang dibutuhkan.
2.1.1.2 Konsep Basis Data Menurut Connolly-Begg (2002, p15), pendekatan yang digunakan dalam sistem basis data, yaitu memisahkan struktur data dari program aplikasinya dan menyimpannya dalam sebuah database. Jika ada penambahan struktur data baru atau struktur yang telah ada dimodifikasi maka program aplikasi tidak terpengaruh, karena program aplikasi tersebut tidak tergantung pada apa yang dimodifikasi. Contohnya, jika kita menambahkan sebuah field baru pada sebuah
6
7 record atau menciptakan sebuah file baru, maka aplikasi yang sedang digunakan tidak terpengaruh. Akan tetapi, jika kita menghapus sebuah field dari sebuah file yang sedang digunakan oleh sebuah program aplikasi, maka hal ini berpengaruh pada program aplikasi tersebut dan harus segera dimodifikasi.
2.1.2 Database Management System (DBMS) 2.1.2.1 Definisi DBMS Menurut Connolly-Begg (2002, p16), DBMS adalah suatu sistem perangkat lunak
yang memungkinkan user untuk mendefinisikan, menciptakan,
memelihara, dan mengontrol akses ke suatu basis data. DBMS merupakan perangkat lunak yang berinteraksi dengan program aplikasi user dan basis data. Secara khusus, DBMS menyediakan fasilitasfasilitas sebagai berikut : 1. Memungkinkan user untuk menspesifikasikan tipe dan struktur data dan batasan
dari data yang akan disimpan pada database, melalui Data
Definition Language (DDL). 2. Memungkinkan user untuk insert, update, delete, dan retrieve data dari database, biasanya melalui Data Manipulation Language (DML). Dengan memiliki penyimpanan pusat untuk semua data dan deskripsi data, memungkinkan DML untuk menyediakan fasilitas inquiry umum untuk data, yang disebut dengan query language. Query language yang paling umum adalah SQL (Structured Query Language). 3. Menyediakan akses yang terkendali pada basis data. Contohnya :
8 -
Sistem keamanan, yang mencegah user yang tidak terdaftar untuk mengakses database.
-
Sistem integritas, yang memelihara konsistensi data yang tersimpan.
-
Sistem control konkurensi, yang memungkinkan akses bersama pada sebuah database.
-
Sistem control recovery, yang mengembalikan database ke keadaaan sebelumnya yang konsisten jika hardware atau software mengalami kegagalan.
2.1.2.2 Komponen-Komponen Lingkungan DBMS Menurut Connolly-Begg (2002, pp18-20), ada lima komponen utama pada lingkungan DBMS yaitu : 1. Hardware ( perangkat keras ) DBMS dan aplikasi membutuhkan perangkat keras agar dapat berjalan. Perangkat keras itu dapat berkisar dari sebuah komputer pribadi ke sebuah mainframe, sampai pada sebuah jaringan dari komputer. Perangkat keras tertentu mungkin diperlukan, tergantung pada kebutuhan organisasi dan DBMS yang digunakan. 2. Software ( perangkat lunak ) Komponen perangkat lunak terdiri dari perangkat lunak DBMS itu sendiri dan program aplikasi, bersama-sama dengan sistem operasi, mencakup perangkat lunak jaringan jika sebuah DBMS digunakan melalui sebuah jaringan. Secara khusus, program aplikasi ditulis dalam bahasa pemrograman generasi ketiga (3GL), seperti Visual Basic atau menggunakan bahasa
9 pemrograman generasi keempat (4GL), seperti SQL, yang tertanam dalam 3GL. 3. Data Data merupakan komponen DBMS yang terpenting. Data berperan sebagai penghubung/jembatan antara komponen mesin dan komponen manusia. 4. Prosedur Prosedur adalah instruksi atau aturan yang mengatur perancangan dan penggunaan dari sebuah database. User dari sebuah sistem dan staf yang mengatur database membutuhkan prosedur yang terdokumentasi tentang bagaimana menggunakan atau menjalankan suatu sistem. Prosedur mungkin terdiri atas instruksi tentang bagaimana : masuk ke sebuah DBMS, menggunakan fasilitas DBMS atau program aplikasi yang khusus, memulai dan menghentikan DBMS, membuat salinan backup database, menangani kesalahan hardware atau software, mengubah struktur table, menata kembali database pada multiple disk, meningkatkan performance, atau menyimpan data ke secondary storage. 5. People ( Manusia ) Adalah komponen terakhir yang terlibat dalam sebuah sistem. Ada empat jenis peran atau tugas manusia dalam lingkungan DBMS, yaitu: data administrator dan database administrator, logical database designer dan physical database designer, application developer, dan end-user (naïve user dan sophisticated user).
10 2.1.2.3 Keuntungan dan kerugian DBMS Menurut Connolly-Begg (2002, pp25-30), keuntungan dari DBMS adalah sebagai berikut : 1. Kontrol terhadap redundansi/pengulangan data Pendekatan database berusaha menghilangkan redundansi dengan menggabungkan file-file sehingga salinan yang banyak dari data yang sama tidak disimpan. 2. Konsistensi data Dengan menghilangkan atau mengontrol redundansi, maka kita mengurangi resiko inkonsistensi terjadi. 3. Lebih banyak informasi dari sejumlah data yang sama Dengan penggabungan data operasional, memungkinkan organisasi untuk memperoleh informasi tambahan dari data yang sama. 4. Penggunaan data bersama File adalah milik orang atau departemen yang menggunakannya. Sedangkan database adalah milik suatu organisasi dan dapat dibagi pada user yang terdaftar dalam organisasi tersebut. 5. Meningkatkan integritas data Integritas database mengacu pada validitas dan konsistensi dari data yang disimpan. 6. Meningkatkan keamanan Keamanan database adalah perlindungan database dari user yang tidak terdaftar. Mungkin dapat dilakukan dengan cara mendaftarkan username dan
11 password untuk mengenali orang-orang yang berhak untuk menggunakan basis data. Sedangkan kerugian dari DBMS adalah sebagai berikut : 1. Kompleksitas Ketentuan fungsionalitas yang kita harapkan dari sebuah DBMS yang baik membuat DBMS seolah-olah seperti sepotong bagian yang ekstrim dan rumit dari sebuah perangkat lunak 2. Ukuran Kompleksitas dan luasnya fungsionalitas membuat DBMS seperti sepotong bagian yang ekstrim dan besar dari sebuah perangkat lunak, menempati beberapa mega byte dari disk space dan membutuhkan sejumlah memori untuk dijalankan secara efisien. 3. Harga dari DBMS Harga dari DBMS bervariasi secara signifikan, tergantung pada lingkungan dan fungsionalitas yang disediakan. 4. Harga konversi Dalam situasi tertentu, harga dari DBMS dan perangkat keras tambahan mungkin
tidak
signifikan
bila
dibandingkan
dengan
harga
untuk
mengkonversi/mengubah aplikasi yang ada untuk dijalankan pada DBMS dan perangkat keras yang baru. 5. Performance ( Kinerja ) DBMS ditulis untuk hal-hal yang lebih umum, untuk melayani banyak aplikasi lebih dari satu kali. Sehingga beberapa aplikasi mungkin tidak berjalan dengan cepat.
12 6. Pengaruh yang besar dari sebuah kesalahan Karena semua user dan aplikasi bergantung pada tersedianya sebuah DBMS, maka kesalahan dari sebuah komponen dapat membuat proses kerja terhenti.
2.1.3 Entity-Relationship (ER) Modeling 2.1.3.1 Definisi ER Modeling Menurut Connolly-Begg (2002, p330), ER modeling adalah pendekatan topdown pada perancangan database yang dimulai dengan mengidentifikasikan data yang penting yang disebut entity dan relationship (hubungan) diantara data yang harus direpresentasikan dalam model tersebut. Selanjutnya kita menambahkan data-data yang lebih detil seperti informasi yang ingin kita kuasai mengenai entity dan relationship, yang disebut atribut dan juga batasan-batasan pada setiap entity, relationship dan atribut.
2.1.3.2 Entity Type Menurut
Connolly-Begg
(2002,pp331-333),
entity
type
merupakan
sekumpulan objek dengan sifat yang sama, yang diidentifikasikan oleh perusahaan karena memiliki keberadaan yang bebas. Sedangkan entity occurrence adalah objek yang dapat diidentifikasikan secara unik dari sebuah entity type. Setiap entity type ditampilkan sebagai sebuah persegi panjang yang diberi nama sesuai dengan nama dari entity, yang umumnya adalah kata benda tunggal.
13
nama entity
Staf
Cabang
Gambar 2.1 : Representasi diagram dari entity type Staf dan Cabang ( Sumber : Connolly-Begg, 2002, p333 )
2.1.3.3 Relationship type Menurut Connolly-Begg (2002,pp334-335), relationship type adalah serangkaian keterhubungan yang memiliki arti antara entity type yang ada. Sedangkan relationship occurrence, yaitu sebuah keterhubungan yang dapat diidentifikasikan secara unik, mencakup satu keberadaan dari setiap entity type yang berpartisipasi. Setiap relationship type ditampilkan sebagai sebuah garis penghubung antara entity type yang berhubungan, diberi nama sesuai dengan nama dari relationship.
14
nama relationship
Mempunyai Staf
Cabang
'Cabang mempunyai staf'
Gambar 2.2 : Representasi diagram dari relationship type Cabang mempunyai Staf ( Sumber : Connolly-Begg, 2002, p335 )
2.1.3.4 Attributes Menurut Connolly-Begg (2002,pp338-340), atribut adalah sebuah sifat dari suatu entity type atau relationship type. Misalnya sebuah entity type Staf mungkin digambarkan melalui atribut noStaf, nama, posisi, dan gaji. Sedangkan attribute domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Atribut dapat dikelompokkan menjadi sebagai berikut : 1. Simple attribute dan composite attribute Simple attribute, yaitu sebuah atribut yang terdiri dari sebuah komponen tunggal dengan keberadaan yang bebas dan tidak dapat dibagi lagi menjadi komponen yang lebih kecil. Sementara composite attribute adalah sebuah atribut yang terdiri dari banyak komponen, setiap komponen memiliki
15 keberadaan yang bebas. Misalnya atribut alamat dapat dianggap sebagai simple attribute, tetapi dapat juga dianggap sebagai composite attribute jika dibagi menjadi komponen jalan, kota dan kode pos. 2. Single-valued attribute dan multi-valued attribute Single-valued attribute
yaitu sebuah atribut yang mempunyai nilai
tunggal untuk setiap kejadian dari sebuah entity type. Contohnya untuk setiap kejadian dari entity type Cabang mempunyai nilai tunggal untuk atribut nomor cabang (noCabang). Sementara multi-valued attribute adalah sebuah atribut yang memiliki banyak nilai untuk setiap kejadian dari sebuah entity type. Misalnya untuk setiap kejadian dari entity type Cabang dapat mempunyai banyak nilai untuk atribut noTelp. 3. Derived attribute (atribut turunan) Adalah sebuah atribut yang mewakili suatu nilai yang dapat diturunkan dari nilai suatu atau sekumpulan atribut yang berhubungan, tidak harus dalam entity type yang sama. Misalnya nilai untuk atribut durasi dari entity Sewa dihitung dari atribut mulaiSewa dan selesaiSewa, juga dari entity type Sewa. Di sini atribut durasi adalah atribut turunan, karena nilainya diturunkan dari atribut mulaiSewa dan selesaiSewa.
2.1.3.5 Key Menurut Connolly-Begg (2002,pp340-341), key terdiri dari : 1. Candidate key yaitu kumpulan kecil dari atribut yang secara unik mengidentifikasikan setiap kejadian dari sebuah entity type. Misalnya atribut
16 noCabang adalah candidate key untuk entity type Cabang, dan mempunyai nilai yang berbeda untuk setiap kejadian dari entity Cabang. 2. Primary
key
merupakan
candidate
key
yang
dipilih
untuk
mengidentifikasikan secara unik setiap kejadian dari sebuah entity type. Sebuah entity type mungkin memiliki lebih dari satu candidate key. Candidate key yang tidak dipilih sebagai primary key disebut sebagai alternate key. 3. Composite key adalah sebuah candidate key yang terdiri dari dua atau lebih atribut. Misalnya entity type Iklan mungkin mempunyai composite primary key yang terdiri dari atribut noProperti, namaKoran, dan tglIklan.
2.1.3.6 Strong and weak entity type Menurut Connolly-Begg (2002,pp342-343), strong entity type adalah sebuah entity type yang keberadaannya tidak tergantung pada beberapa entity type yang lain. Karakteristik dari strong entity type adalah bahwa setiap kejadian entity dapat diidentifikasi secara unik menggunakan atribut primary key dari entity type tersebut. Misalnya, kita dapat mengidentifikasi setiap anggota staf secara unik menggunakan atribut noStaf, yang merupakan primary key untuk entity type Staf. Sedangkan weak entity type adalah sebuah entity type yang keberadaannya tergantung pada beberapa entity type yang lain. Karakteristik dari weak entity type adalah bahwa setiap kejadian dari entity tidak dapat diidentifikasikan secara unik dengan hanya menggunakan atribut yang berhubungan dengan entity type tersebut.
17 2.1.3.7 Structural constraints Menurut Connolly-Begg (2002,pp344-351), tipe batasan utama pada sebuah relationship disebut multiplicity, yaitu jumlah atau jangkauan dari kejadian yang mungkin terjadi pada sebuah entity type yang mungkin berhubungan dengan kejadian tunggal dari sebuah entity type yang terkait melalui sebuah relationship khusus. Tingkat relationship yang paling umum adalah binary, yang secara umum terbagi menjadi one-to-one ( 1:1 ) relationship, one-to-many ( 1:* ) relationship, dan many-to-many ( *:* ) relationship. Contoh one-to-one ( 1:1 ) relationship adalah relationship Mengatur, yang menghubungkan entity type Staf dengan Cabang. Dalam relationship ini, disimpulkan bahwa seorang anggota staf dapat mengatur satu cabang atau tidak sama sekali, dan setiap cabang diatur oleh satu anggota staf saja, seperti ditunjukkan oleh gambar berikut ini :
'Setiap cabang diatur oleh satu anggota staf'
' Satu anggota staf dapat mengatur nol atau satu cabang'
Mengatur
Staf noStaf
Cabang 0..1
1..1
noCabang
Multiplicity
Gambar 2.3 : Multiplicity dari one-to-one ( 1:1 ) relationship Staf mengatur Cabang ( Sumber : Connolly-Begg, 2002, p346 )
18 Contoh one-to-many ( 1:* ) relationship adalah relationship Mengawasi, yang menghubungkan entity type Staf dengan PropertiPenyewaan. Dalam relationship ini, disimpulkan bahwa seorang anggota staf dapat mengawasi nol atau lebih properti penyewaan, dan sebuah properti penyewaan diawasi oleh nol atau satu anggota staf, seperti ditunjukkan oleh gambar berikut ini :
'Setiap properti penyewaan diawasi oleh nol atau satu anggota staf'
Mengawasi
Staf noStaf
' Setiap anggota staf mengawasi nol atau lebih properti penyewaan'
0..1
PropertiPenyewaan 0..*
noProperti
Gambar 2.4 : Multiplicity dari one-to-many ( 1:* ) relationship Staf mengawasi PropertiPenyewaan ( Sumber : Connolly-Begg, 2002, p347 )
Contoh many-to-many ( *:* ) relationship adalah relationship Mengiklankan, yang menghubungkan entity type SuratKabar dengan PropertiPenyewaan. Dalam relationship ini, disimpulkan bahwa satu surat kabar dapat mengiklankan satu atau lebih properti penyewaan, dan satu properti penyewaan diiklankan dalam nol atau lebih surat kabar, seperti ditunjukkan oleh gambar berikut ini :
19
'Setiap properti penyewaan diiklankan dalam nol atau lebih surat kabar'
SuratKabar namaSuratKabar
' Setiap surat kabar mengiklankan satu atau lebih properti penyewaan'
PropertiPenyewaan
Mengiklankan 0..*
1..*
noProperti
Gambar 2.5 : Multiplicity dari many-to-many ( *:* ) relationship SuratKabar mengiklankan PropertiPenyewaan ( Sumber : Connolly-Begg, 2002, p348 )
Multiplicity sesungguhnya terdiri dari dua batasan yang terpisah yang dikenal sebagai cardinality dan participation. Cardinality menggambarkan jumlah maksimum dari kejadian relationship yang mungkin untuk sebuah entity yang berpartisipasi dalam tipe relationship tersebut. Cardinality dari sebuah binary relationship mengacu pada hubungan one-to-one ( 1:1 ), one-to-many ( 1:* ) dan many-to-many ( *:* ). Sedangkan participation menggambarkan apakah semua kejadian entity berpartisipasi dalam sebuah relationship (disebut sebagai mandatory participation) atau hanya beberapa saja (disebut sebagai optional participation).
2.1.4 Normalisasi 2.1.4.1 Definisi Normalisasi Menurut Connolly-Begg (2002,p376), normalisasi adalah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifat-sifat yang diinginkan, memenuhi
20 kebutuhan data pada sebuah perusahaan. Tujuan utama dari perancangan basis data relasional adalah untuk mengelompokkan atribut-atribut ke dalam relasirelasi untuk meminimalkan redundansi (pengulangan) data dan sekaligus mengurangi ukuran penyimpanan file yang dibutuhkan oleh relasi dasar yang terimplementasi. Relasi atau tabel yang mempunyai data yang berulang mungkin diakibatkan oleh update anomalies, yaitu adanya kesalahan dalam melakukan penambahan, penghapusan atau pemodifikasian data yang menyebabkan data menjadi tidak konsisten. Salah satu konsep utama yang berhubungan dengan normalisasi adalah functional dependency (ketergantungan fungsional), yang menggambarkan hubungan antara atribut-atribut. Proses normalisasi dimulai dengan menganalisa relasi berdasarkan primary key dan functional dependency antar atribut. Proses normalisasi paling tidak harus melalui tiga langkah yaitu first-normal form (1NF), second normal form (2NF) dan third-normal form (3NF).
2.1.4.2 First Normal Form ( 1NF ) Menurut Connolly-Begg (2002,p388), first normal form (1NF) adalah sebuah relasi di mana irisan dari setiap baris dan kolom mengandung satu dan hanya satu nilai. Kita memulai proses normalisasi dengan pertama-tama mengubah data dari sumbernya ke dalam bentuk tabel dengan baris dan kolom. Dalam format ini, tabel dalam unnormalized form (UNF) dan diartikan sebagai tabel yang tidak normal. Unnormalized form (UNF) adalah sebuah tabel yang mengandung satu atau lebih group yang berulang (repeating group).
21 Untuk mentransformasi dari tabel yang tidak normal ke dalam 1NF, kita harus mengidentifikasi dan menghilangkan repeating group dalam tabel tersebut. Sebuah repeating group adalah sebuah atau sekumpulan atribut dalam sebuah tabel yang memiliki banyak nilai untuk sebuah kejadian tunggal dari atribut kunci yang dianjurkan untuk tabel tersebut. Ada dua pendekatan umum untuk menghilangkan repeating group dari tabel tidak
normal.
Pertama,
kita
menghilangkan
repeating
group
dengan
memasukkan data yang sesuai dalam kolom yang kosong dari baris yang mengandung data yang berulang. Kedua, kita menghilangkan repeating group dengan menempatkan data yang berulang dengan salinan dari atribut kunci yang sesungguhnya ke dalam relasi yang terpisah.
2.1.4.3 Second Normal Form ( 2NF ) Menurut Connolly-Begg (2002,p392), second normal form (2NF) adalah sebuah relasi yang merupakan first normal form dan setiap atribut yang bukan primary key tergantung fungsional secara penuh terhadap primary key. Second normal form (2NF) didasarkan pada konsep ketergantungan fungsional secara penuh (fully functionally dependency), yang mengindikasikan bahwa jika A dan B adalah atribut dari sebuah relasi, maka B tergantung fungsional secara penuh pada A jika dan hanya jika B tergantung fungsional pada A, tetapi bukan pada himpunan bagian dari A. Sebuah ketergantungan fungsional A->B disebut tergantung sebagian (partially dependent) jika ada beberapa atribut yang dapat dihilangkan dari A dan ketergantungannya masih ada.
22 Proses normalisasi dari relasi 1NF ke 2NF mencakup penghapusan ketergantungan sebagian (partial dependency). Jika sebuah partial dependency masih ada, maka kita menghilangkan atribut dari relasi yang tergantung fungsional dengan menempatkannya ke dalam sebuah relasi baru dengan salinan dari determinannya.
2.1.4.4 Third Normal Form ( 3NF ) Menurut Connolly-Begg (2002,p394), third normal form (3NF) adalah sebuah relasi yang merupakan first normal form dan second normal form, dan tidak ada atribut yang bukan primary key tergantung secara transitif pada primary key. Proses normalisasi dari relasi 2NF ke 3NF mencakup proses penghapusan ketergantungan transitif (transitive dependency). Transitive dependency adalah suatu kondisi dimana A, B, dan C adalah atribut-atribut dari sebuah relasi sehingga jika A -> B (A tergantung fungsional pada B) dan B-> C (B tergantung fungsional pada C), maka C tergantung secara transitif pada A melalui B. Jika sebuah transitive dependency masih ada, maka kita menghilangkan atributatribut
dari
relasi
yang
tergantung
secara
transitif
tersebut
dengan
menempatkannya dalam sebuah relasi baru dengan salinan dari determinannya.
2.1.5 Database Application Lifecycle Karena sebuah sistem basis data adalah komponen mendasar dari sistem informasi sebuah organisasi yang besar, maka daur hidup aplikasi basis data (database application lifecycle) secara temurun berhubungan dengan daur hidup dari
23 sebuah sistem informasi. Tahapan- tahapan dari database application lifecycle tidak berurutan secara tepat, tetapi melibatkan sejumlah pengulangan dari tahapan sebelumnya melalui feedback loop, seperti ditunjukkan pada gambar berikut : Database planning
System definition
Requirement collection and analysis
Database design
DBMS selection (optional)
Conceptual database design Application design Logical database design Physical database design
Prototyping (optional)
Implementation
Data conversion and loading
Testing
Operational maintenance
Gambar 2.6 : Tahapan-tahapan dari database application lifecycle ( Sumber : Connolly-Begg, 2002, p272 )
24
2.1.5.1 Database Planning ( Perencanaan Basis Data ) Menurut Connolly-Begg (2002,pp273-274),
database planning adalah
aktifitas manajemen yang memungkinkan tahapan-tahapan dari aplikasi basis data untuk direalisasikan seefisien dan seefektif mungkin. Database planning harus diintegrasikan dengan keseluruhan strategi sistem informasi dari suatu organisasi. Ada tiga permasalahan utama yang berkaitan dengan perumusan sebuah strategi sistem informasi, yaitu : 1. Identifikasi rencana dan sasaran perusahaan disertai dengan penentuan kebutuhan sistem informasi selanjutnya. 2. Evaluasi sistem informasi yang telah ada untuk menentukan kekuatan dan kelemahan yang ada. 3. Penilaian kesempatan teknologi informasi yang mungkin dapat memberikan keuntungan kompetitif. Langkah awal yang penting dalam database planning adalah secara jelas mendefinisikan mission statement (pernyataan misi) untuk proyek basis data. Mission statement mendefinisikan tujuan utama dari aplikasi basis data. Sebuah mission statement membantu memperjelas kegunaan dari proyek basis data dan menyediakan alur yang lebih jelas menuju pada penciptaan aplikasi basis data yang dibutuhkan secara efisien dan efektif. Setelah mendefinisikan mission statement, maka langkah selanjutnya adalah mengidentifikasikan mission objective (sasaran misi). Setiap mission objective seharusnya mengidentifikasikan tugas khusus yang harus didukung oleh basis data. Mission statement dan mission objective dapat dilengkapi dengan beberapa
25 informasi tambahan yang menspesifikasikan pekerjaan yang akan dilakukan, sumber daya yang digunakan, dan biaya yang dikeluarkan untuk semua itu. Database planning juga seharusnya mencakup pengembangan standarstandar yang mengatur bagaimana data akan dikumpulkan, bagaimana menspesifikasikan format data, dokumentasi penting apakah yang akan diperlukan
dan
bagaimana
perancangan
dan
implementasi
seharusnya
system
definition
dilaksanakan.
2.1.5.1 System Definition ( Pendefinisian Sistem ) Menurut
Connolly-Begg
(2002,pp274-275),
menggambarkan ruang lingkup dan batasan dari aplikasi basis data dan pandangan user (user view) yang utama. Sebelum mencoba untuk merancang sebuah aplikasi basis data, sangatlah perlu bagi kita untuk pertama-tama mengidentifikasikan batasan-batasan sistem yang sedang diteliti dan bagaimana sistem tersebut berkaitan dengan bagian lain dari sistem informasi organisasi tersebut. Kita juga perlu memasukkan batasan sistem kita tidak hanya pada pengguna dan lingkup aplikasi saat ini saja, tetapi juga untuk pengguna dan aplikasi yang akan datang. Dan perlu juga dimasukkan user view utama yang didukung oleh aplikasi. User view mendefinisikan apa yang dibutuhkan oleh sebuah aplikasi basis data dari pandangan seorang pemegang peranan kerja khusus (seperti manajer atau pengawas) atau lingkup aplikasi perusahaan (seperti pemasaran, personalia, atau pengawas stok). Sebuah aplikasi basis data mungkin memiliki satu atau lebih user view. Mengidentifikasikan user view adalah aspek penting dalam
26 mengembangkan sebuah aplikasi basis data karena user view membantu meyakinkan bahwa pengguna utama dari basis data tidak ada yang terlupakan ketika mengembangkan kebutuhan untuk aplikasi baru. User view mendefinisikan apa yang dibutuhkan dari sebuah aplikasi basis data dalam hal data apa yang diinginkan dan transaksi apa yang ingin dilakukan pada data tersebut (dengan kata lain, apa yang user ingin lakukan pada data tersebut). Kebutuhan dari sebuah user view mungkin berbeda atau saling melengkapi dengan user view lain, seperti ditunjukkan oleh gambar berikut :
User view 6 User view 1
User view 5
User view 2
User view 4
User view 3
Database Database application
Gambar 2.7 : Representasi dari sebuah aplikasi basis data dengan banyak user view : user view (1, 2, dan 3) dan (5 dan 6) mempunyai kebutuhan yang saling melengkapi (seperti ditunjukkan dengan daerah yang diarsir), sementara user view 4 mempunyai kebutuhan yang berbeda ( Sumber : Connolly-Begg, 2002, p275 )
27 2.1.5.3 Requirements Collection and Analysis ( Analisis dan Pengumpulan Kebutuhan ) Menurut Connolly-Begg (2002,pp276-279), requirements collection and analysis merupakan proses pengumpulan dan penganalisaan informasi mengenai bagian dari organisasi yang didukung oleh aplikasi basis data, dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan user terhadap sistem yang baru. Informasi yang dikumpulkan untuk setiap user view utama (baik itu peranan kerja ataupun lingkup aplikasi perusahaan) mencakup sebuah gambaran dari data yang digunakan atau dihasilkan, detil mengenai bagaimana data digunakan atau dihasilkan, dan kebutuhan tambahan lainnya untuk aplikasi basis data yang baru. Kegiatan penting lainnya berkaitan dengan tahapan ini yaitu memutuskan bagaimana berhubungan dengan situasi dimana ada lebih dari satu user view untuk sebuah aplikasi basis data. Ada tiga pendekatan utama untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan banyak user view, yaitu : 1. Centralized approach ( Pendekatan terpusat ) , dimana kebutuhan untuk setiap user view digabungkan ke dalam satu kumpulan tunggal kebutuhan untuk aplikasi basis data yang baru. 2. View integration approach ( Pendekatan integrasi pandangan ), dimana kebutuhan untuk setiap user view digunakan untuk membangun sebuah model data terpisah untuk merepresentasikan user view tersebut. Model data yang dihasilkan untuk selanjutnya digabung dengan tahapan perancangan basis data. 3. Kombinasi dari kedua pendekatan itu
28 2.1.5.4 Database Design ( Perancangan Basis Data ) Menurut Connolly-Begg (2002,p279), database design merupakan proses penciptaan sebuah rancangan untuk suatu basis data yang akan mendukung operasional dan sasaran dari perusahaan. Ada dua pendekatan utama dalam perancangan sebuah basis data yaitu pendekatan bottom-up dan pendekatan top-down. Pendekatan bottom-up dimulai pada tingkat atribut yang paling dasar (baik itu sifat-sifat entity maupun relationship),
yang
melalui
proses
analisis
keterkaitan
antar
atribut,
dikelompokkan ke dalam relasi yang merepresentasikan tipe dari entity dan relationship antar entity. Sedangkan pendekatan top-down dimulai dengan pengembangan model data yang mengandung sedikit entity dan relationship tingkat tinggi dan kemudian menerapkan perbaikan top-down berturut-turut untuk mengidentifikasi entity, relationship dan atribut terkait pada tingkat yang lebih rendah. Pendekatan lain dalam perancangan basis data yaitu pendekatan inside-out dan pendekatan mixed strategy (strategi gabungan). Pendekatan inside-out mirip dengan pendekatan bottom-up tetapi dibedakan karena dalam pendekatan ini pertama-tama kita mengidentifikasi sekumpulan entity utama dan kemudian menyebarkannya untuk mempertimbangkan entity, relationship dan atribut terkait lainnya dengan yang pertama diidentifikasikan tadi. Sedangkan pendekatan mixed strategy menggunakan baik pendekatan bottom-up dan topdown untuk bagian model yang bervariasi sebelum akhirnya menggabungkan semua bagian itu bersama-sama.
29 Perancangan basis data dibangun dari tiga tahapan utama, yaitu conceptual database design, logical database design dan physical database design.
2.1.5.4.1 Conceptual database design ( Perancangan basis data konseptual) Menurut Connolly-Begg (2002,p281), conceptual database design adalah suatu proses membangun sebuah model informasi yang digunakan dalam sebuah perusahaan, bebas dari semua pertimbangan fisiknya. Ini merupakan tahapan awal dari perancangan basis data, dan melibatkan penciptaan model data konseptual dari bagian perusahaan yang menarik untuk dimodelkan. Conceptual database design bebas dari detil implementasi seperti perangkat lunak DBMS yang dituju, program aplikasi, bahasa pemrograman, platform perangkat keras, atau pertimbangan fisik lainnya. Melalui proses pengembangan model data konseptual, model tersebut diuji dan divalidasi terhadap kebutuhan-kebutuhan user. Model data konseptual dari sebuah perusahaan adalah sumber informasi untuk tahapan berikutnya, yaitu logical database design.
2.1.5.4.2
Logical
database
design
(
Perancangan
basis
data
secara logis ) Menurut
Connolly-Begg
(2002,p281),
logical
database
design
merupakan suatu proses membangun sebuah model informasi yang digunakan dalam sebuah perusahaan berdasarkan pada sebuah model data khusus, tetapi bebas dari DBMS tertentu dan pertimbangan fisik lainnya. Ini
30 adalah tahapan kedua dari perancangan basis data yang menghasilkan penciptaan sebuah model data logis dari bagian perusahaan yang menarik untuk dimodelkan. Teknik normalisasi digunakan untuk menguji kebenaran dari sebuah model data logis. Model data logis adalah sumber informasi untuk tahapan selanjutnya, yaitu physical database design. Model data logis juga memegang peranan penting selama tahapan pemeliharaan operasional dari database application lifecycle.
2.1.5.4.3
Physical
database
design
(
Perancangan
basis
data
secara fisik ) Menurut Connolly-Begg (2002,p282), physical database design adalah suatu proses yang menghasilkan sebuah gambaran dari implementasi basis data pada penyimpanan kedua; juga menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses data yang efisien, dan batasan integritas terkait lainnya dan ukuran keamanan. Ini adalah tahapan ketiga dan terakhir dari proses perancangan basis data, dimana dalam tahap ini perancang memutuskan bagaimana basis data diimplementasikan. Secara umum, tujuan utama dari physical database design adalah untuk menggambarkan bagaimana kita mengharapkan implementasi perancangan basis data logis secara fisik. Untuk model relasional, hal ini mencakup : 1. penciptaan serangkaian tabel relasional dan batasan pada tabel-tabel ini dari informasi yang ditampilkan dalam model data logis
31 2. identifikasi struktur penyimpanan khusus dan metode akses data untuk mencapai sebuah tampilan optimal dari sistem basis data 3. perancangan perlindungan keamanan untuk sistem tersebut
2.1.5.5 DBMS Selection ( Pemilihan DBMS ) Menurut Connolly-Begg (2002,p284), DBMS selection adalah pemilihan sebuah DBMS yang sesuai untuk mendukung aplikasi basis data. Tahap-tahap utama dalam memilih sebuah DBMS yaitu : 1. Mendefinisikan terminologi dari referensi studi, yang mencakup penentuan sasaran dan ruang lingkup studi serta tugas yang harus dilaksanakan. 2. Mendaftarkan dua atau tiga produk, yang mungkin tergantung pada anggaran yang tersedia, tingkat dari dukungan vendor, kesesuaiannya dengan perangkat lunak yang lain, dan apakah produk berjalan pada perangkat keras khusus. 3. Mengevaluasi produk yang dilakukan dengan cara memberi bobot pada fitur dan atau kumpulan fitur dibandingkan terhadap kepentingan organisasi, dan untuk memperoleh keseluruhan nilai bobot yang digunakan untuk membandingkan produk. 4. Merekomendasikan
pilihan
dan
membuat
laporan,
yaitu
tahap
pendokumentasian proses dan penyediaan pernyataan mengenai penemuan dan rekomendasi atas produk DBMS tertentu.
32 2.1.5.6 Application Design ( Perancangan Aplikasi ) Menurut Connolly-Begg (2002,p287), application design adalah proses perancangan antarmuka pemakai (user interface) dan program aplikasi yang menggunakan dan memproses basis data. Ada dua aspek utama dari application design yaitu : 1. Transaction design ( perancangan transaksi ) Transaksi adalah sebuah tindakan, atau serangkaian tindakan, yang dilakukan oleh user atau program aplikasi tunggal, yang mengakses atau mengubah isi dari sebuah basis data. Tujuan dari transaction design adalah untuk mendefinisikan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basis data tersebut, meliputi data yang digunakan oleh transaksi, karakteristik fungsional dari transaksi, hasil transaksi, kepentingan user, dan tingkat kegunaan yang diharapkan. Ada tiga tipe utama dari sebuah transaksi, yaitu retrieval transaction yang digunakan untuk mendapatkan data untuk ditampilkan dalam layar atau untuk membuat suatu laporan; update transaction yang digunakan untuk menambah record baru, menghapus record lama, atau memodifikasi record yang telah ada dalam basis data; dan mixed transaction mencakup baik pengambilan (retrieval) maupun perbaikan (updating) data. 2. User interface design ( perancangan antarmuka pemakai ) Tahap ini mencakup perancangan tampilan (layout). Ada beberapa panduan dalam merancang tampilan, diantaranya judul yang berarti, instruksi yang berkesinambungan, pengelompokan logis dan pengurutan field,
33 konsisten
terhadap
terminologi
dan
singkatan,
konsisten
terhadap
penggunaan warna dan lain-lain.
2.1.5.7 Prototyping Menurut Connolly-Begg (2002,p291), prototyping adalah membangun model kerja dari suatu aplikasi basis data. Sebuah prototype adalah model kerja yang secara normal tidak mempunyai semua fitur yang dibutuhkan atau menyediakan semua fungsionalitas dari sistem akhir. Tujuan utama membangun sebuah prototype dari suatu aplikasi basis data adalah
untuk
mengijinkan
user
menggunakan
prototype
untuk
mengidentifikasikan fitur dari sistem yang bekerja dengan baik, atau yang tidak mencukupi, dan jika mungkin untuk menyarankan perbaikan atau bahkan penambahan fitur baru bagi aplikasi basis data. Ada dua strategi prototyping yang digunakan sekarang, yaitu requirements prototyping yang menggunakan sebuah prototype untuk menentukan kebutuhan dari aplikasi basis data yang diusulkan dan ketika kebutuhan terpenuhi prototype tersebut dibuang dan evolutionary prototyping yang digunakan untuk tujuan yang sama, perbedaan utamanya adalah prototype tidak dibuang tetapi dengan pengembangan lebih lanjut menjadi aplikasi kerja basis data.
2.1.5.8 Implementation (Implementasi) Menurut Connolly-Begg (2002,p292), implementation adalah realisasi fisik dari perancangan aplikasi dan basis data. Implementasi basis data dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau
34 graphical user interface (GUI), yang menyediakan fungsionalitas yang sama ketika menyembunyikan pernyataan DDL tingkat rendah. Pernyataan DDL digunakan untuk menciptakan struktur basis data dan file basis data yang kosong. User view yang telah ditentukan akan diimplementasikan dalam tahapan ini.
2.1.5.9 Data Conversion and Loading ( Mengisi dan Mengubah Data ) Menurut Connolly-Begg (2002,p292), data conversion and loading adalah mengirimkan data yang telah ada ke dalam basis data yang baru dan mengubah aplikasi yang telah ada untuk berjalan pada basis data yang baru itu. Tahap ini diperlukan hanya ketika sebuah basis data yang baru menggantikan sistem yang lama. Sekarang ini, sangatlah umum bagi sebuah DBMS untuk memiliki fungsi yang dapat mengirimkan file-file yang ada ke dalam basis data yang baru. Juga dimungkinkan bagi pengembang untuk mengubah dan menggunakan program aplikasi dari sistem lama untuk digunakan oleh sistem yang baru. Kapanpun tahap ini dibutuhkan, setidaknya kita harus merencanakannya terlebih dahulu untuk meyakinkan sebuah peralihan yang halus bagi keseluruhan operasional.
2.1.5.10 Testing ( Pengujian ) Menurut
Connolly-Begg
(2002,p293),
testing
adalah
suatu
proses
mengeksekusi program aplikasi dengan maksud untuk menemukan kesalahan. Sebelum digunakan, aplikasi basis data yang baru dikembangkan seharusnya diuji terlebih dahulu. Hal ini dilakukan dengan menggunakan strategi pengujian terencana dan data realistik sehingga proses pengujian data yang masuk dapat dilakukan sesuai dengan metodologi yang ada. Sama seperti proses perancangan
35 basis data, user dari sistem yang baru seharusnya dilibatkan dalam proses pengujian ini.
2.1.5.10 Operational Maintenance ( Pemeliharaan Operasional ) Menurut Connolly-Begg (2002,p293), operational maintenance merupakan proses mengawasi dan memelihara sistem setelah diinstal. Dalam tahapan sebelumnya, aplikasi basis data telah diimplementasikan dan diuji secara penuh. Sekarang sistem bergerak ke tahapan pemeliharaan, yang melibatkan aktivitas sebagai berikut : 1. Mengawasi kinerja sistem. Jika kinerja turun di bawah level yang disetujui, penataan organisasi kembali dari basis data mungkin diperlukan. 2. Memelihara dan upgrade aplikasi basis data (jika dibutuhkan). Kebutuhan baru tidak tergabung dalam aplikasi basis data melalui tahapan lifecycle sebelumnya.
2.2 Teori-teori Persediaan, Pembelian dan Penjualan Menurut Mulyadi (2001,p5). Dalam membahas sistem akuntansi perlu dibedakan pengertian sistem dan prosedur, agar diperoleh gambaran yang jelas mengenai berbagai sistem yang menghasilkan berbagai macam formulir yang diolah dalam sistem akuntansi. Definisi sistem dan prosedur adalah sebagai berikut : 1. Sistem adalah suatu jaringan prosedur yang dibuat menurut pola yang terpadu untuk melaksanakan kegiatan pokok perusahaan
36 2. Prosedur adalah suatu urutan kegiatan klerikal, biasanya melibatkan beberapa orang dalam satu departemen atau lebih, yang dibuat untuk menjamin penanganan secara seragam transaksi perusahaan yang terjadi berulang-ulang
2.2.1 Persediaan Menurut Dyckman(1996,p376), persediaan terdiri dari barang-barang yang dimiliki suatu bisnis dan disimpan baik untuk digunakan membuat produk atau sebagai produk yang siap untuk dijual. Kita biasanya berpikir bahwa persediaan adalah bahan baku, barang dalam proses, barang jadi, atau barang dagang yang disimpan oleh pengecer. Namun tergantung pada sifat bisnis perusahaan, persediaan bisa terdiri dari semua barang atau bahan terwujud. Suatu persediaan bisa terdiri dari komponen peralatan, komoditi beras seperti gandum dan tepung, bensin yang ditumpuk untuk dijual selama musim dingin atau ruangan penyimpanan yang tak terpakai. Mesin-mesin dan peralatan, misalnya, dianggap sebagai aktiva operasional oleh perusahaan yang membelinya, tetapi belum dijual mereka merupakan bagian persediaan perusahaan yang membuatnya. Bahkan suatu bangunan, selama periode konstruksi, merupakan item persediaan bagi pembangunnya. Menurut Mulyadi (2001,p553), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan digudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntasi biaya produksi. Dalam perusahaan manufaktur, persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan bahan penolong, persediaan bahan habis pakai pabrik, persediaan suku cadang. Dalam perusahaan dagang, persediaan hanya terdiri
37 dari satu golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli untuk tujuan dijual kembali. Sedangkan untuk metode pencatatan persediaan dibagi menjadi dua yaitu : metode mutasi persediaan dan metode persediaan fisik. Dalam metode mutasi persediaan, setiap mutasi persediaan dicatat dalam kartu persediaan. Dalam metode persediaan fisik, hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak dicatat dalam kartu persediaan. Menurut Mulyadi(2001,p559), sistem dan prosedur yang bersangkutan dengan sistem 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. 2. Prosedur pencatatan harga pokok produk jadi yang dijual Prosedur ini merupakan salah satu prosedur dalam sistem penjualan disamping prosedur lainnya seperti : prosedur order penjualan, prosedur persetujuan kredit, prosedur pengiriman barang, prosedur penagihan, prosedur pencatatan piutang. 3. Prosedur pencatatan harga pokok produk jadi yang diterima kembali dari pembeli Jika produk jadi yang telah dijual dikembalikan oleh pembeli, maka transaksi retur penjualan ini akan mempengaruhi persediaan produk jadi, yaitu menambah kuantitas produk jadi dalam kartu gudang yang diselenggarakan oleh bagian
38 gudang dan menambah kuantitas dan harga pokok produk jadi yang dicatat oleh bagian kartu persediaan dalam kartu persediaan produk jadi. 4. Prosedur pencatatan harga pokok persediaan produk dalam proses Pencatatan persediaan produk dalam proses umumnya dilakukan oleh perusahaan pada akhir periode, pada saat dibuat laporan keuangan bulanan dan laporan keuangan tahunan. Pencatatan persediaan produk dalam proses dicatat 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 Jika persediaan yang telah dibeli dikembalikan kepada pemasok, maka transaksi retur pembelian ini akan mempengaruhi persediaan yang bersangkutan, yaitu mengurangi kuantitas persediaan dalam kartu gudang yang diselenggarakan oleh bagian gudang dan mengurangi kuantitas dan harga pokok persediaan yang dicatat oleh bagian kartu persediaan dalam kartu persediaan yang bersangkutan. Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur pembelian. 7. Prosedur permintaan dan pengeluaran barang gudang Prosedur ini merupakan salah satu prosedur yang membentuk sistem akuntansi biaya produksi. Dalam proses 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 pengembalian barang gudang
39 Transaksi pengembaliaan barang gudang mengurangi biaya dan menambah persediaan barang di gudang. 9. Sistem penghitungan fisik persediaan Sistem penghitungan fisik persediaan umumnya digunakan oleh perusahaan untuk menghitung secara fisik persediaan yang disimpan digudang, yang hasilnya digunakan untuk meminta pertanggungjawaban bagian gudang mengenai pelaksanaan fungsi penyimpanan, dan pertanggungjawaban bagian kartu persediaan mengenai keandalan catatan persediaan yang diselenggarakan, serta untuk melakukan penyesuaian terhadap catatan persediaan di bagian kartu persediaan. Menurut
Mulyadi(2001,p579),
Fungsi
yang
terkait
dengan
sistem
penghitungan fisik persediaan adalah : 1. Panitia penghitungan fisik persediaan yang berfungsi dalam pelaksanaan penghitungan fisik persediaan dan menyerahkan hasil penghitungan tersebut kepada bagian kartu persediaan untuk digunakan sebagai dasar penyesuaian terhadap catatan persediaan dalam kartu persediaan. 2. Fungsi Akuntasi bertanggungjawab untuk : a. Mencantumkan harga pokok satuan persediaan yang dihitung kedalam daftar hasil penghitungan fisik. b. Mengalikan kuantitas dan harga pokok per satuan yang tercantum dalam daftar hasil penghitungan fisik. c. Mencantumkan harga pokok total dalam daftar hasil penghitungan fisik d. Melakukan penyesuaian terhadap kartu persediaan berdasar data hasil penghitungan fisik persediaan
40 e. Membuat bukti memorial untuk mencatat penyesuaian data persediaan dalam jurnal umum berdasarkan hasil penghitungan fisik persediaan. 3. Fungsi Gudang bertanggungjawab untuk melakukan penyesuaian data kuantitas persediaan yang dicatat dalam kartu gudang berdasarkan hasil penghitungan fisik persediaan.
2.2.1.1 Klasifikasi Persediaan Menurut Dyckman (1996,p377) persediaan dapat diklasifikasikan menjadi : 1. Persediaan barang dagang (merchandise inventory), yaitu barang yang ada digudang (goods on hand) yang dibeli oleh pengecer atau perusahaan perdagangan seperti importer atau eksportir untuk dijual kembali. Biasanya, barang yang diperoleh untuk dijual kembali secara fisik tidak diubah oleh perusahaan pembeli; barang-barang tersebut tetap dalam bentuk yang telah jadi seperti ketika meninggalkan pabrik pembuatnya. Dalam beberapa hal, dapat terjadi beberapa komponen dibeli untuk kemudian dirakit menjadi barang jadi. Misalnya, sepeda yang dirakit dari kerangka, roda, gir, dan sebagainya serta dijual oleh pengecer sepeda adalah salah satu contoh. 2. Persediaan manufaktur (manufacturing inventory) adalah persediaan gabungan dari entitas manufaktur, yang terdiri dari : a. Persediaan Bahan Baku Yaitu barang berwujud yang dibeli atau diperoleh dengan cara lain (misalnya, dengan menambang) dan disimpan untuk penggunaan langsung dalam membuat barang untuk dijual kembali. Bagian atau
41 suku cadang yang diproduksi sebelum digunakan kadang-kadang diklasifikasikan sebagai persediaan komponen suku cadang. b. Persediaan Barang dalam Proses Yaitu barang-barang yang membutuhkan pemrosesan lebih lanjut sebelum penyelesaian dan penjualan. Barang dalam proses, juga disebut persediaan barang dalam proses, meliputi biaya bahan langsung, tenaga kerja langsung, dan alokasi biaya overhead pabrik yang terjadi sampai tanggal tersebut. c. Persediaan Barang Jadi Adalah barang-barang manufaktur yang telah diselesaikan dan disimpan untuk dijual. Biaya persediaan barang jadi meliputi biaya bahan langsung, tenaga kerja langsung, dan alokasi biaya overhead pabrik yang berkaitan dengan manufaktur d. Persediaan Perlengkapan Manufaktur Merupakan barang-barang seperti minyak pelumas untuk mesin-mesin, bahan pembersih, dan barang lainnya yang merupakan bagian yang kurang penting dari produk jadi. 3. Persediaan Rupa-rupa Mencakup barang-barang seperti peralatan kantor, kebersihan, dan pengiriman. Persediaan jenis ini biasanya digunakan segera dan biasanya dicatat sebagai beban penjualan atau umum(selling or general expenser) ketika dibeli. Klasifikasi utama persediaan tergantung pada operasi bisnis. Suatu usaha perdagangan grosir atau eceran membeli barang dagang untuk dijual kembali.
42 Suatu perusahaan manufaktur membeli bahan baku dan suku cadang, memproduksi barang jadi, dan kemudian menjualnya.
2.2.2 Pembelian Menurut Mulyadi(1997,p301), pembelian digunakan untuk pengadaaan barang yang diperlukan oleh perusahaan.
2.2.2.1 Jenis-jenis Pembelian Berdasarkan cara pembayarannya pembelian dibagi menjadi dua yaitu : 1. Pembelian Tunai, yaitu saat barang telah diterima pada saat itu juga pembayaran dilakukan 2. Pembelian Kredit, yaitu pembayaran tidak dilakukan pada saat barang diterima tetapi pada waktu tertentu yang telah ditentukan bersama dengan pihak pemasok. Sedangkan berdasarkan pemasoknya pembelian dibagi menjadi : 1. Pembelian Lokal adalah pembelian dari pemasok dalam negeri 2. Pembelian Impor adalah pembelian dari pemasok luar negeri
2.2.2.2 Fungsi Yang Terkait Dalam Pembelian Menurut Mulyadi (2001,p300) fungsi yang terkait dengan sistem pembelian mencakup : 1. Fungsi Gudang
43 Fungsi ini bertanggung jawab dalam pengajuan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan menyimpan barang yang telah diterima oleh fungsi penerimaan. 2. Fungsi Pembelian Fungsi ini memiliki tanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang serta mengeluarkan order pembelian kepada pemasok yang dipilih. 3. Fungsi Penerimaan Fungsi ini bertanggung jawab terhadap pemeriksaan jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. 4. Fungsi Akuntansi Fungsi akuntansi yang terkait dengan transaksi pembelian adalah fungsi pencatatan utang dan fungsi pencatatan persediaan.
2.2.2.3 Jaringan Prosedur Yang Membentuk Sistem Pembelian Menurut Mulyadi (2001,p301), jaringan prosedur yang membentuk sistem pembelian adalah 1. Prosedur Permintaan Pembelian Pada prosedur ini fungsi gudang mengajukan permintaan pembelian dalam formulir surat permintaan pembelian kepada fungsi pembelian 2. Prosedur Permintaan Penawaran Harga dan Pemilihan Pemasok
44 Dalam prosedur ini, fungsi pembelian mengirimkan surat permintaan penawaran harga kepada para pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian lainnya. 3. Prosedur Order Pembelian Dalam prosedur ini fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit organisasi lainnya(misalnya fungsi penerimaan, fungsi meminta barang, dan fungsi pencatat utang) 4. Prosedur Penerimaan Barang Pada prosedur ini fungsi penerimaan melakukan pemerikasaan jenis, kuantitas, dan mutu barang yang diterima dari pemasok, dan kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut. 5. Prosedur Pencatatan Utang Dalam prosedur ini fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan
dengan
pembelian
(surat
order
pembelian,
laporan
penerimaan barang, dan faktur dari pemasok) dan menyelenggarakan pencatatan utang atau mengarsipkan dokumen sumber sebagai catatan utang. 6. Prosedur Distribusi Pembelian Prosedur ini meliputi distribusi rekening yang didebit dari transaksi pembelian untuk kepentingan pembuatan laporan manajemen.
45 2.2.2.4 Sistem Retur Pembelian Menurut Mulyadi(2001,p335), sistem retur pembelian digunakan dalam perusahaan untuk pengembalian barang yang sudah dibeli kepada pemasoknya. Adapun barang yang sudah diterima dari pemasok terkadang tidak sesuai dengan barang yang dipesan menurut surat order pembelian. Ketidaksesuaian itu terjadi kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang tercantum dalam surat order pembelian, barang mengalami kerusakan dalam pengiriman, atau barang diterima melewati tanggal pengiriman yang dijanjikan oleh pemasok. Fungsi yang terkait dalam sistem retur pembelian adalah : 1. Fungsi Gudang Fungsi ini bertanggung jawab untuk menyerahkan barang kepada fungsi pengiriman seperti yang tercantum dalam tembusan memo debit yang diterima dari fungsi pembelian 2. Fungsi Pembelian Fungsi ini bertanggung jawab untuk mengeluarkan memo debit untuk retur pembelian 3. Fungsi Pengiriman Fungsi ini bertanggung jawab untuk mengirimkan kembali barang kepada pemasok sesuai dengan perintah retur pembelian dalam memo debit yang diterima dari fungsi pembelian 4. Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat :
46 a. Transaksi retur pembelian dalam jurnal retur pembelian atau jurnal umum. b. Berkurangnya harga pokok persediaan karena retur pembelian dalam kartu persediaan c. Berkurangnya utang yang timbul dari transaksi retur pembelian dalam arsip bukti kas keluar yang belum dibayar atau dalam kartu utang. Menurut Mulyadi(2001,p339), sistem retur pembelian terdiri dari jaringan prosedur berikut ini : 1. Prosedur perintah retur pembelian Retur pembelian terjadi atas perintah fungsi pembelian kepada fungsi pengiriman untuk mengirimkan kembali barang yang telah diterima oleh fungsi penerimaan kepada pemasok yang bersangkutan. Dokumen yang digunakan oleh fungsi pembelian untuk memerintahkan fungsi pengiriman mengembalikan barang ke pemasok adalah memo debit. 2. Prosedur pengiriman barang ke pemasok Fungsi pengiriman mengirimkan barang kepada pemasok sesuai dengan perintah retur pembelian yang tercantum dalam memo debit dan membuat laporan pengiriman barang untuk transaksi retur pembelian tersebut. 3. Prosedur pencatatan utang Fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan dengan retur pembelian dan menyelenggarakan pencatatan berkurangnya utang dalam kartu utang atau mengarsipkan dokumen memo debit sebagai pengurang utang.
47 2.2.3 Penjualan Menurut Mulyadi (2001,p202), kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun tunai. Pembayaran yang dilakukan dibedakan berdasarkan cara transaksinya, yaitu : 1. Penjualan kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya 2. Penjualan Tunai, ketika perusahaan telah menerima kas dari pembeli maka barang atau jasa baru diserahkan oleh perusahaan kepada pembeli.
2.2.3.1 Fungsi Yang Terkait dalam Sistem Penjualan Menurut Mulyadi (2001,p204), Fungsi yang terkait dalam sistem penjualan kredit adalah : 1. Fungsi Kredit Fungsi yang bertanggung jawab atas pemberian kartu kredit kepada pelanggan
terpilih.
Fungsi
ini
mengumpulkan
informasi
tentang
kemampuan keuangan calon anggota dengan meminta fotocopy rekening koran bank, keterangan gaji atau pendapatan calon anggota dari perusahaan tempat ia bekerja dan dari sumber-sumber lain. 2. Fungsi Penjualan Fungsi ini yang melayani kebutuhan barang pelanggan. 3. Fungsi Gudang
48 Fungsi yang menyediakan barang yang diperlukan oleh pelanggan sesuai dengan yang tercantum dalam tembusan faktur pemjualan kartu kredit yang diterima dari fungsi penjualan. 4. Fungsi Pengiriman Fungsi ini bertanggung jawab untuk menyerahkan barang yang kuantitas, mutu dan spesifikasinya sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu kredit. 5. Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat transaksi bertambahnya piutang kepada pelanggan kedalam kartu piutang berdasarkan faktur penjualan kartu kredit yang diterima dari fungsi pengiriman. 6. Fungsi Penagihan Fungsi ini yang bertanggung jawab membuat surat tagihan secara periodik kepada pemegang kartu kredit. Menurut Mulyadi(2001,p462), fungsi yang terkait dalam sistem penerimaan kas dari penjualan tunai adalah : 1. Fungsi Penjualan Fungsi ini bertanggung jawab untuk menerima order dari pembeli, mengisi faktur penjualan tunai, dan menyerahkan faktur tersebut kepada pembeli untuk kepentingan pembayaran harga barang ke fungsi kas. 2. Fungsi Kas Fungsi ini bertanggung jawab sebagai penerima kas dari pembeli. 3. Fungsi Gudang
49 Fungsi ini bertanggung jawab untuk menyimpan barang yang dipesan oleh pembeli, serta menyerahkan barang tersebut ke fungsi pengiriman. 4. Fungsi Pengiriman Fungsi ini bertanggung jawab untuk membungkus barang dan menyerahkan barang yang telah dibayar harganya kepada pembeli 5. Fungsi Akuntansi Fungsi ini bertanggung jawab sebagai pencatat transaksi penjualan dan penerimaan kas dan pembuatan laporan penjualan
2.2.3.2 Jaringan Prosedur Yang Membentuk Sistem Menurut Mulyadi (2001,p209), jaringan prosedur yang membentuk sistem penjualan kredit adalah : 1. Prosedur order penjualan Fungsi penjualan menerima order dari pembeli dan menambahkan informasi penting pada surat order dari pembeli. Fungsi penjualan kemudian membuat faktur penjualan dan mengirimkannya kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut memberikan kontribusi dalam melayani order dari pembeli. 2. Prosedur pengiriman barang Pada fungsi ini fungsi gudang menyiapkan barang yang diperlukan oleh pembeli dan fungsi pengiriman mengirimkan barang kepada pembeli sesuai dengan informasi yang tercantum dalam faktur penjualan yang diterima dari fungsi gudang 3. Prosedur pencatatan piutang
50 Dalam prosedur ini fungsi akuntansi mencatat tembusan faktur penjualan ke dalam kartu piutang. 4. Prosedur penagihan Dalam prosedur ini fungsi penagihan menerima faktur penjualan dan mengarsipkannya sesuai abjad. Secara periodik fungsi penagihan membuat surat tagihan dan mengirimkannya kepada pemegang kartu kredit perusahaan. 5. Prosedur pencatatan penjualan Dalam prosedur ini fungsi akuntansi mencatat transaksi penjualan kartu kredit ke dalam jurnal penjualan. Menurut Mulyadi(2001,p469), jaringan prosedur yang membentuk sistem penerimaan kas dari penjualan tunai adalah sebagai berikut : 1. Prosedur order penjualan Fungsi penjualan menerima order dari pembeli dan membuat faktur penjualan tunai untuk memungkinkan pembeli melakukan pembayaran harga barang ke fungsi kas dan untuk memungkinkan fungsi gudang dan fungsi pengiriman menyiapkan barang yang akan diserahkan kepada pembeli. 2. Prosedur penerimaan kas Fungsi kas menerima pembayaran harga barang dari pembeli dan memberikan tanda pembayaran(berupa pita register kas dan cap ”lunas” pada faktur penjualan tunai) kepada pembeli untuk memungkinkan pembeli tersebut melakukan pengambilan barang yang dibelinya dari fungsi pengiriman.
51 3. Prosedur penyerahan barang Fungsi pengiriman menyerahkan barang kepada pembeli. 4. Prosedur pencatatan penjualan tunai Fungsi akuntansi melakukan pencatatan transaksi penjualan tunai dalam jurnal penjualan dan jurnal penerimaan kas. Disamping itu fungsi akuntansi juga mencatat berkurangnya persediaan barang yang dijual dalam kartu persediaan. 5. Prosedur penyetoran kas ke bank Sistem pengendalian intern terhadap kas mengharuskan penyetoran dengan segera ke bank semua kas yang diterima pada suatu hari. Dalam prosedur ini fungsi kas menyetorkan kas yang diterima dari penjualan tunai ke bank dalam jumlah penuh. 6. Prosedur pencatatan penerimaan kas Fungsi akuntansi mencatat penerimaan kas ke dalam jurnal penerimaan kas berdasar bukti setor bank yang diterima dari bank melalui fungsi kas. 7. Prosedur pencatatan harga pokok penjualan Fungsi akuntansi membuat rekapitulasi harga pokok penjualan berdasarkan data yang dicatat dalam kartu persediaan. Berdasarkan rekapitulasi harga pokok penjualan ini, fungsi akuntansi membuat bukti memorial sebagi dokumen sumber untuk pencatatan harga pokok penjualan ke dalam jurnal umum.
52 2.2.3.3 Sistem Retur Penjualan Menurut Mulyadi(2001,p226), Transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan. Pengembalian barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Sedangkan fungsi yang terkait dalam melaksanakan transaksi retur penjualan adalah : 1. Fungsi penjualan Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan kembali barang yang telah dijual tersebut dilakukan dengan cara membuat memo kredit yang dikirimkan kepada fungsi penerimaan. 2. Fungsi penerimaan Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan otorisasi yang terdapat dalam memo kredit yang diterima dari fungsi penjualan. 3. Fungsi gudang Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat oleh fungsi gudang dalam kartu gudang. 4. Fungsi akuntansi Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke dalam
jurnal
umum
dan
pencatatan
berkurangnya
piutang
dan
bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan
53 kartu persediaan. Disamping itu, fungsi ini juga bertanggung jawab untuk mengirimkan memo kredit kepada pembeli yang bersangkutan. Menurut Mulyadi(2001,p234), jaringan prosedur dalam sistem retur penjualan adalah sebagai berikut : 1. Prosedur pembuatan memo kredit Fungsi penjualan membuat memo kredit yang memberikan perintah kepada fungsi penerimaan untuk menerima barang dari pembeli tersebut dan kepada fungsi akuntansi untuk pencatatan pengurangan piutang kepada pembeli yang bersangkutan. 2. Prosedur penerimaan barang Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari memo kredit yang diterima dari fungsi penjualan. Atas penerimaan barang tersebut fungsi penerimaan membuat laporan penerimaan barang untuk melampiri memo kredit yang dikirim ke fungsi akuntansi. 3. Prosedur pencatatan retur penjualan Dalam prosedur ini transaksi berkurangnya piutang dagang dan pendapatan penjualan akibat dari transaksi retur penjualan dicatat oleh fungsi akuntansi ke dalam jurnal umum atau jurnal retur penjualan dan ke dalam buku pembantu piutang. Dalam prosedur ini pula berkurangnya harga pokok penjualan dan bertambahnya harga pokok persediaan dicatat oleh fungsi akuntansi ke dalam jurnal umum dan dalam buku pembantu persediaan.
