Bab ini akan menjelaskan penggunaan CAATT untuk ekstraksi dan analisi
data. CAATT sangat diperlukan auditor dalam menjalankan tugasnya. Dengan CAATT
ini dapat membantu auditor dalam mengumpulkan data akuntansi untuk menguji
pengendalian aplikasi dan dalam melakukan uji substantif. Berbeda dengan bab
sebelumnya, dibahas bagaimana CATT digunakan untuk menguji pengendalian
aplikasi secara langsung. Alat ekstraksi data yang akan dibahas pada bab ini
digunakan untuk menganalisis data yang diproses oleh sutau aplikasi, bukan untuk
menganalisis aplikasi itu sendiri. Dengan menganalisis daya yang ditelusuri dari file
komputer, auditor bisa menarik kesimpulan mengenai keberadaan dan fungsionalitas
pengendalian dalam aplikasi yang memproses data.
Penggunaan penting lainnya dari peranti lunak ekstraksi data adalah dalam
pelaksanaan uji substantif Kebanyakan pengujian audit terjadi dalam tahap pengujian
substantive dari audit. Prosedur-prosedur ini disebut uji substantive karena digunakan
untuk, namun tidak terbatas pada berikut ini:
Dalam lingkungan TI, record dibutuhkan untuk melakukan uji semacam ini
disimpan dalam file computer dan basis data. Sebelum uji substantive dilaksanakan,
data perlu diekstraksi dari sistem host dan disajikan ke auditor dalam format yang
mudah digunakan.
Bab ini diawali dengan kajian struktur data. Struktur data merupakan susunan
data secara fisik dan logis dalam file dan basis data. Pemahaman mengenai cara
mengatur dan mengakses data merupakan hal penting dalam menggunakan alat
ekstraksi data. Peranti lunak ekstraksi data terdiri atas dua kategori umum, yaitu:
STRUKTUR DATA
Struktur data memiliki dua komponen dasar: organisasi dan metode akses.
Organisasi mengacu pada cara catatan yang diatur secara fisik pada perangkat
penyimpanan sekunder. Sedangkan metode akses mengacu pada teknik yang
digunakan untuk mencari catatan dan menavigasi melalui database atau file.
Sementara beberapa teknik khusus digunakan secara umum, mereka dapat
diklasifikasikan sebagai akses langsung atau metode akses berurutan.
Dalam pengoperasian pengolahan file terdiri dari :
1. Ambil catatan dari file berdasarkan kunci primernya.
2. Masukkan catatan ke dalam file
3. Perbarui rekaman dalam file.
4. Baca file catatan lengkap
5. Temukan catatan selanjutnya dalam file
6. Pindai file untuk catatan dengan kunci sekunder umum
7. Hapus catatan dari file
Contoh 1 (1,1).
Asumsikan bahwa perusahaan memiliki 1.000 karyawan tetapi hanya 100 dari
mereka adalah staf penjualan. Asumsikan juga bahwa setiap penjual diberi nomor
mobil perusahaan, tetapi staf non-penjualan tidak. Saat menentukan nilai
kardinalitas dalam asosiasi entitas, pilih satu kejadian (catatan) dari satu entitas
dan jawab pertanyaan berikut: berapa jumlah minimum dan maksimum catatan
yang mungkin terkait dengan satu catatan yang telah dipilih? Misalnya, memilih
catatan entitas karyawan dan melihat ke arah entitas perusahaan mobil, kita
melihat dua kemungkinan nilai. Jika catatan karyawan yang dipilih adalah dari
seorang tenaga penjualan, maka dia ditugaskan satu (dan hanya satu) mobil
perusahaan. Catatan karyawan tertentu ini, terkait dengan hanya satu catatan
dalam entitas perusahaan mobil. Namun, jika catatan karyawan yang dipilih adalah
catatan seorang non-penjualan, maka individu tersebut akan diberi no (nol) mobil.
Catatan karyawan dalam kasus ini dikaitkan dengan nol catatan perusahaan mobil.
Jadi, kardinalitas minimum nol dan kardinalitas maksimum adalah satu. Lingkaran
dan garis pendek yang memotong garis yang menghubungkan dua entitas
menggambarkan tingkat kardinalitas ini. Perhatikan bahwa dari perspektif entitas
karyawan, kardinalitas ditunjukkan pada akhir Perusahaan Mobil dari garis
asosiasi. Sekarang pilih catatan Perusahaan Mobil dan lihat kembali entitas
karyawan karena setiap mobil perusahaan ditugaskan hanya untuk satu karyawan,
baik jumlah minimum dan maksimum dari catatan terkait adalah satu. Dua garis
berpotongan pendek di bagian akhir karyawan dari garis asosiasi menandakan
kardinalitas ini.
Contoh 2 (1:1).
Contoh 2 mengilustrasikan situasi dimana setiap catatan dalam satu entitas
selalu dikaitkan dengan satu (dan hanya satu) catatan dalam entitas terkait. Dalam
hal ini setiap komputer laptop perusahaan ditugaskan hanya untuk satu manajer,
dan setiap manajer hanya diberi satu komputer. Dua garis pendek yang memotong
garis penghubung di kedua ujungnya menggambarkan kardinalitas ini.
Contoh 3 (1:M).
Contoh 3 menyajikan hubungan antara pelanggan dan entitas order penjualan.
Perhatikan bahwa jumlah minimum catatan order penjualan per catatan pelanggan
adalah nol dan maksimumnya banyak. Hal ini karena dalam periode tertentu (satu
tahun atau bulan) yang terkait dengan entitas order penjualan, pelanggan tertentu
mungkin tidak membeli apa pun (nol catatan order penjualan) atau membeli
beberapa kali (banyak catatan). Namun, dari perspektif entitas order penjualan,
setiap catatan dikaitkan dengan satu dan hanya satu pelanggan. Simbol kaki
burung gagak (yang memberikan bentuk notasi ini namanya) menggambarkan
banyak kardinalitas pada akhir urutan penjualan dari garis asosiasi.
Contoh 4 (1:M)
Contoh 4 mewakili suatu situasi dimana setiap item spesifik persediaan
dipasok oleh satu dan hanya satu Vendor, dan setiap Vendor memasok satu atau
banyak persediaan yang berbeda kepada perusahaan. Bandingkan hubungan
(1:M) ini dengan contoh 5 berikutnya.
Contoh 5 (M:M)
Untuk mengilustrasikan asosiasi banyak-ke-banyak, kami kembali
menggunakan hubungan Vendor dan Inventaris dalam contoh 5. Kali ini,
bagaimanapun, perusahaan memiliki kebijakan untuk membeli jenis inventaris
yang sama dari beberapa pemasok. Manajemen dapat memilih untuk melakukan
ini untuk memastikan bahwa mereka mendapatkan harga terbaik atau menghindari
ketergantungan pada pemasok tunggal. Di bawah kebijakan tersebut, setiap
catatan Vendor terkait dengan satu atau banyak catatan Inventaris, dan setiap
catatan Inventaris terkait dengan satu atau banyak Vendor. Contoh 4 dan 5
menunjukkan bagaimana kardinalitas mencerminkan aturan bisnis yang ada dalam
suatu organisasi. Perancang database harus mendapatkan pemahaman
menyeluruh tentang bagaimana klien-perusahaan dan pengguna tertentu
melakukan bisnis untk mendesain model data dengan tepat. Jika model data
salah, tabel basis data yang dihasilkan juga akan salah. Contoh 4 dan 5 keduanya
sah, tetapi opsi yang berbeda dan, seperti yang akan kita lihat, memerlukan desain
basis data yang berbeda.
User Views
Tampilan pengguna adalah kumpulan data yang dilihat oleh pengguna
tertentu. Contoh pandangan pengguna adalah layar komputer untuk memasukkan
atau melihat data, laporan manajemen, atau dokumen sumber seperti faktur.
Tampilan mungkin digital atau fisik (kertas), tetapi dalam semua kasus, mereka
berasal dari tabel database yang mendasari. Pandangan sederhana dapat
dibangun dari satu tabel, sementara pandangan yang lebih kompleks mungkin
memerlukan beberapa tabel. Selanjutnya, satu tabel dapat menyumbangkan data
ke banyak pandangan yang berbeda.
Organisasi besar akan memiliki ribuan tampilan pengguna yang didukung oleh
ribuan tabel individual. Tugas mengidentifikasi semua pandangan dan
menerjemahkannya ke dalam tabel yang dinormalisasi adalah tanggung jawab
yang penting dari perancang basis data yang memiliki implikasi kontrol internal.
Masalah dan teknik yang terkait dengan tugas ini diperiksa selanjutnya.
Insertion Anomaly
Untuk menunjukkan efek anomali penyisipan, asumsikan bahwa vendor baru
telah memasuki pasar dan organisasi belum membeli dari vendor tetapi mungkin
ingin melakukannya di masa depan.
Deletion Anomaly
Penghapusan anomali melibatkan penghapusan data yang tidak disengaja dari
tabel. Kehadiran anomali penghapusan kurang mencolok, tetapi berpotensi lebih
serius daripada pembaruan dan penyisipan anomali.
Normalisasi Tabel
Anomali database yang dijelaskan diatas adalah gejala masalah structural
dalam tabel yang disebut dependensi. Secara khusus ini dikenal sebagai
repeating groups, partial dependencies, dan transitive dependencies. Proses
normalisasi melibatkan identifikasi dan penghapusan dependensi struktural dari
tabel yang sedang dikaji. Tabel yang dihasilkan kemudian akan memenuhi dua
kondisi:
1. Semua atribut nonkunci (data) dalam tabel bergantung pada (ditentukan oleh)
kunci primer.
2. Semua atribut non-key tidak bergantung pada atribut non-key lainnya.
Dengan kata lain tabel 3NF adalah tabel di mana kunci utama dari tabel
sepenuhnya dan secara unik mendefinisikan setiap atribut dalam tabel.
Agen pembelian
Dengan asumsi bahwa organisasi hanya memiliki satu agen pembelian, maka
calon Agen Pembelian gagal Kondisi 1. Jika ada lebih dari satu agen, Kondisi 1
terpenuhi tetapi Kondisi 2 mungkin menjadi masalah. Jika kita berasumsi bahwa tabel
Karyawan sudah ada sebagai bagian dari sumber daya manusia atau sistem
penggajian, maka data dasar tentang agen sebagai karyawan ditangkap dalam tabel
itu. Kita perlu menentukan data tentang agen yang unik untuk perannya dalam
penempatan pesanan yang perlu ditangkap. Perhatikan bahwa kami tidak mengacu
pada data tentang pesanan, tetapi data tentang agen. Karena kami tidak memiliki
informasi mengenai hal ini dalam uraian singkat kami tentang sistem, kami akan
menganggap tidak ada data khusus agen yang diambil. Oleh karena itu, kandidat
Agen Pembelian bukanlah entitas yang dimodelkan.
Menerima Petugas
Argumen sebelumnya juga berlaku untuk entitas Pegawai Penerimaan. Kita
akan berasumsi bahwa tidak ada data khusus petugas yang perlu ditangkap yang
memerlukan tabel khusus.
Inventaris
Entitas Inventaris memenuhi kedua kondisi tersebut. Deskripsi menunjukkan
bahwa organisasi menyimpan banyak item inventaris, sehingga entitas ini akan berisi
beberapa kejadian. Juga, kita dapat secara logis berasumsi bahwa atribut yang
mendefinisikan Inventaris entitas tidak disediakan melalui tabel lain. Entitas
Inventarisasi adalah entitas yang harus dimodelkan.
Pemasok
Deskripsi menyatakan bahwa beberapa vendor menyediakan persediaan;
maka entitas pemasok memenuhi syarat pertama. Kita juga dapat berasumsi bahwa ia
memenuhi kondisi kedua karena tidak ada entitas lain yang secara logis akan
menyediakan data pemasok. Entitas Pemasok, karena itu, akan dimasukkan dalam
model data.
Laporan Status Inventarisasi
Laporan Status Inventarisasi adalah tampilan pengguna yang berasal dari
entitas Inventarisasi dan Pemasok. Meskipun mengandung beberapa kejadian, itu
bukan entitas karena tidak memenuhi Kondisi 2. Pandangan ini berasal sepenuhnya
dari entitas yang ada dan tidak memberikan data tambahan yang membutuhkan
entitas yang terpisah. Akan tetapi, pandangan akan dianalisis secara hati-hati untuk
memastikan bahwa semua atribut yang diperlukan untuknya dimasukkan dalam
entitas yang ada.
Pesanan pembelian
Entitas pesanan pembelian memenuhi kedua kondisi. Banyak pesanan
pembelian akan diproses dalam suatu periode, sehingga entitas akan memiliki banyak
kejadian. Sementara beberapa data pesanan pembelian dapat berasal dari entitas lain
(inventory dan Supplier) dalam model, beberapa atribut yang unik untuk acara
pembelian seperti tanggal pesanan dan kuantitas pesanan akan membutuhkan entitas
terpisah yang perlu dimodelkan.
Menerima laporan
Laporan penerima memenuhi kedua kondisi. Banyak peristiwa penerimaan
akan berlangsung dalam periode tersebut, dengan demikian entitas Laporan
Penerimaan akan memiliki beberapa kejadian entitas. Laporan Penerimaan akan
berisi atribut seperti tanggal diterima dan kuantitas yang diterima yang unik untuk
entitas ini dan dengan demikian tidak dipagari oleh entitas lain dalam model. Pada titik
ini, pencarian kami telah mengungkapkan empat entitas: Inventarisasi, pemasok,
Pesanan pembelian, dan Laporan Penerimaan. Ini akan digunakan untuk membangun
model data dan, akhirnya, tabel database fisik.
Atribut Part Number, Description, Order Quantity, dan Unit Cost mengulang
data grup. Ini berarti bahwa ketika pesanan pembelian tertentu berisi lebih dari
satu item, kemudian beberapa nilai perlu diambil untuk atribut ini. Untuk
mengatasi, grup data yang berulang ini dipindahkan ke entitas Item Detil PO baru.
Entitas baru diberi kunci utama yang merupakan gabungan dari Nomor Bagian
dan Nomor PO. Pembuatan keseluruhan baru juga menyelesaikan hubungan M:M
antara order Pembelian dan entitas Inventarisasi dengan menyediakan tautan.
3. Ketergantungan Transitif
The Purchase order dan Receiving Report entitas berisi atribut yang berlebihan
dengan data dalam entitas inventarisasi dan pemasok. Redudansi ini terjadi
karena dependensi transitif dalam entitas Purchase Order and Receiving Report
dan dijatuhkan.
Membangun Database Fisik
Kunci utama dan asing yang menghubungkan tabel diwakili oleh garis putus-
putus. Setiap catatan dalam tabel Detail Item Laporan Rek merepresentasikan setiap
item pada laporan penerimaan. Tabel memiliki kunci gabungan yang terdiri dari Rec
Rept Number dan Part Number. Kunci gabungan ini diperlukan untuk mengidentifikasi
atribut kuantitas dan kondisi masing-masing dari setiap detail item secara unik. Bagian
Rec Rept Number dari kunci menyediakan tautan ke tabel Laporan Penerimaan yang
berisi data umum tentang peristiwa penerimaan. Pada Bagian Nomor kunci digunakan
untuk mengakses tabel inventaris. The PO Item Detail table menggunakan kunci
primer gabungan dari PO Number dan Bagian Nomor untuk mengidentifikasi atribut
quantity order secara unik. Komponen PO Number dari kunci komposit menyediakan
tautan ke tabel pesanan Pembelian. Program perlu ditulis untuk mentransfer data
organisasi yang disimpan secara aman dalam file datar atau database warisan ke
tabel relasional baru. Data yang saat ini disimpan di dokumen kertas mungkin perlu
dimasukkan ke dalam tabel database secara manual. Setelah ini selesai, tampilan
pengguna fisik dapat dihasilkan.
Tujuan dari EAM, yang juga dikenal sebagai audit kontinyu, adalah untuk
mengidentifikasi transaksi penting ketika mereka sedang diproses dan mengekstrak
salinan secara real time. EAM adalah modul yang diprogram khusus yang tertanam
dalam aplikasi host untuk menangkap jenis transaksi yang telah ditentukan untuk
analisis selanjutnya.
Karena transaksi yang dipilih sedang diproses oleh aplikasi host, salinan
transaksi sedang disimpan dalam file audit untuk peninjauan berikutnya. Pendekatan
EAM memungkinkan transaksi yang dipilih untuk ditangkap selama periode audit.
Untuk memulai penangkapan data, auditor menetapkan parameter EAM dan
ambang materialitas dari transaksi yang ditetapkan untuk ditangkap. Sebagai contoh,
asumsikan bahwa auditor menetapkan ambang batas materialitas $ 50.000 untuk
transaksi yang diproses oleh sistem pemrosesan pesanan penjualan. Transaksi yang
sama atau lebih besar dari $ 50.000 akan disalin ke file audit. Dari serangkaian
transaksi ini, auditor dapat memilih subset yang akan digunakan untuk pengujian
substantif. Transaksi yang jatuh di bawah ambang batas ini akan diabaikan oleh EAM.
Kekurangan EAMs
Popularitas GAS yang tersebar luas disebabkan oleh empat faktor: (1) bahasa
GAS mudah digunakan dan hanya membutuhkan sedikit latar belakang ilmu komputer
bagi auditor; (2) banyak produk GAS dapat digunakan pada sistem mainframe dan
PC; (3) auditor dapat melakukan pengujiantanpa melibatkan staf layanan komputer
klien; dan (4) GAS dapat digunakan untuk mengaudit data yang disimpan di sebagian
besar struktur dan format file.
Menggunakan GAS untuk Mengakses Struktur Sederhana
Mendapatkan akses ke struktur file datar adalah proses yang relatif mudah,
seperti yang diilustrasikan pada Figure 8.27. Dalam contoh ini, file persediaan dibaca
langsung oleh GAS, yang mengekstraksi informasi penting yang dibutuhkandalam
audit, termasuk kuantitas barang di gudang, nilai uang, dan lokasi gudang daritiap
barang persediaan. Tugas auditor adalah memverifikasi keberadaan dan nilai dari
Definisi Data
Sistem klien dapat menyimpan data menggunakan sejumlah filedatar atau
struktur basisdata, termasuk fileberurutan, fileISAM, daftar yang terhubung, dan tabel
relasional. Salah satu kelebihan ACL adalah kemampuannya untuk membaca data
yang disimpan dalam hampir semua format. ACL menggunakan fitur definisi data
untuk tujuan ini. Untuk membuat definisi data, auditor perlu mengetahui lokasifisikfile
sumber dan tata letak strukturfield-nya. Fileyang kecil dapat diimpor melalui file teks
atau spreadsheet. File yang sangat besar mungkin perlu diakses langsung dari
komputer mainframe. Ketika ini terjadi, auditor harus mendapatkan hak akses ke
direktori tempat filedisimpan. Jika memungkinkan, satu salinan file harus disimpan
dalam direktori pengujian terpisah atau diunduh ke PC auditor. Langkah ini biasanya
membutuhkan bantuan dari ahli sistem. Auditor harus memastikan bahwa dia
menyimpan versi fileyang benar, lengkap, dan bahwa dokumentasi struktur filetetap
utuh. Pada titik ini, auditor siap untuk melakukan definisi data ke ACL.
Layar definisi data ACL memungkinkan auditor menentukan karakteristik
pebting file sumber, termasuk panjang record keseluruhan, nama yang diberikan ke
tiap field, jenis data (contohnya, numeris atau karakter) yang terdapat dalam tiap field,
serta titik awal dan panjang tiap field dalam file tersebut.
Menyesuaikan Tampilan
Tampilan hanyalah cara melihat data dalam file, auditor jarang menggunakan
semua data yang berada dalam file. ACL memungkinkan auditor untuk menyesuaikan
tampilan asli yang dihasilkan dari proses definisi data menjadi tampilan yang dapat
memenuhi kebutuhan auditnya dengan lebih baik. Auditor dapat membuat dan
memformat ulang tampilan baru tanpa mengubah atau menghapus data dalam
filedasarnya. Hanya cara penyajian data saja yang berubah.
Memfilter Data
ACL menyediakan pilihan yang canggih untuk menyaring data yang
mendukung berbagai uji audit. Filter adalah ekspresi yang mencari record yang sesuai
dengan kriteria penyaringannya. Expression builder dari ACL memungkinkan
auditormenggunakan operator logis seperti AND, OR, <, >, NOT dan lainnya untuk
menentukan serta menguji kondisi kompleks, dan hanya memproses record yang
sesuai kondisi yang telah ditentukan. Contohnya, auditor dapat mencari
dalamfilepersediaan untuk recordyang memiliki nilai jumlahdi gudang nol atau negatif.
Tampilan expression builder dan saringan yang diperlukan untuk pengujian ini
diilustrasikan pada Figure 8.34.
memilih untuk mengubah ukuran dan jumlah interval atau hanya mempelajarisebagian
dari file.
Analisis Statistik
ACL menawarkan banyak metode pengambilan sampel untuk analisis statistik.
Dua metode yang paling sering digunakan adalahrecordsampling dan monetary unit
sampling (MUS). Setiap metode memungkinkan pengambilan sampel secara acak dan
interval. Pilihan metode akan bergantung pada strategi auditor dan komposisi file yang
diaudit. Di satu sisi, ketika record dalam file terdistribusi merataantar strata, maka
auditor mungkin menginginkan sampel yang tidak bias,hingga memilih pendekatan
record sampling. Menggunakan tabel persediaansebagai ilustrasi, tiap record, berapa
pun nilai uangnyadalam field nilai persediaan, memiliki peluang yang sama untuk
dimasukkan dalam sampel. Di sisi lain, jika file tersebut cenderung condongke salah
satu sisi dengan nilai persediaan yang besar, auditor dapat memilih pendekatan MUS,
karena akan menghasilkan sampel yang memasukkan semua nilai persediaan yang
lebih besar.
KESIMPULAN
Hall, James A; dan Tommie Singleton. 2007. Audit Teknologi Informasi dan Assurance
Edisi 2 Buku 1. Jakarta Selatan: Salemba Empat.