HAS IL ANALIS A DAN REKOMENDAS I
4.1. Gap Analysis
Untuk melakukan evaluasi, dilakukan pengumpulan dan analisis data-data dari PT M IE Tbk yang terkait dengan proses bisnis dan sistem yang berjalan. Pengumpulan data ini digunakan untuk mengevaluasi kinerja sistem yang berjalan. Sistem yang dievaluasi adalah sistem ERP TSD. Sistem ini dikembangkan untuk mendukung semua kegiatan serta kinerja DC (Direct Cover) dimana proses bisnis utamanya adalah proses bisnis penjualan produk. Evaluasi yang dilakukan pada sistem ERP TSD menggunakan metode Gap Analysis.
Gap Analysis dilakukan untuk mengidentifikasi apakah sistem yang ada sekarang telah memenuhi kebutuhan atau tidak. Apabila diidentifikasi adanya gap, maka akan dicatat dalam format yang telah ditentukan. Dengan menggunakan metode ini, akan dilakukan pencatatan terhadap kebutuhan pengguna terkait kinerja dari sistem ERP TSD pada M odul Financial Accounting. Setelah itu akan dilakukan pemaparan solusi terhadap permasalahan yang ditemukan. Langkah selanjutnya adalah proses penentuan ranking untuk setiap requirement yang bertujuan untuk memberikan gambaran dan memastikan team berfokus pada hal yang benar-benar penting bagi peningkatan kinerja sistem ERP perusahaan. Tiga jenis ranking dalam Gap Analysis, yaitu : High, Medium, dan Low. Proses penentuan ini dilakukan melalui observasi dan wawancara kepada para user untuk menentukan ranking dari setiap proses bisnis yang dijalankan.
Tabel 4.1 Tabel Gap Analysis pada M odul Financial Accounting
No Requirements Rank Level Comments Alternatives
A Setiap DC (Direct Cover) hanya boleh memiliki satu account Bank Incoming Clearing yang digunakan dalam pencatatan transaksi yang berhubungan dengan M odul Cash and Bank. Satu account Bank Incoming
Clearing harus memiliki nilai
yang sama baik pada Trial Balance dan Cash and Bank Statement.
H G Terjadi kesalahan prosedur dimana sebelumnya DC (Direct Cover) sudah menggunakan sebuah account Bank Incoming Clearing dan kemudian menggantinya dengan membuat account Bank Incoming Clearing baru yang mengakibatkan muncul 2 account Bank Incoming Clearing. Hal ini mengakibatkan pada pencatatan di Trial Balance, kode GL account Bank Incoming Clearing yang digunakan adalah 00-11231-00-70, sedangkan di Cash and Bank Report kode
GL account Bank Incoming Clearing yang
digunakan adalah 00-11211-00-90. Selain
Ketika ada perubahan account GL atas Bank Incoming Clearing, maka harus dibuat account Bank Incoming Clearing baru tanpa mengubah master lama. Setelah itu dapat dilakukan transfer (melalui transaksi DDP atau Dana Dalam Perjalanan) dari account Bank Incoming Clearing lama ke account Bank Incoming Clearing baru. Dengan demikian, akan dibuat jurnal dengan account DDP pada debit dan account Bank Incoming Clearing lama pada kredit, serta jurnal dengan account Bank Incoming Clearing baru pada debit dan account DDP pada kredit.
itu, Adanya transaksi Bank Incoming Clearing yang tercatat pada Trial Balance tetapi tidak tercatat pada Cash and Bank Statement. Hal ini juga menyebabkan account Bank Incoming Clearing yang digunakan dalam Trial balance dan Cash and Bank Statement tidak konsisten.
update by script ke transaksi kecuali dilakukan oleh seorang developer.
B Saldo PPN Keluaran pada Trial balance dan formulir yang akan dilaporkan kepada Direktorat Pajak (Print Form 1107A) harus memiliki nilai yang sama
H G Pencatatan yang dilakukan pada Print Form 1107A untuk PPN Keluaran sistem ERP TSD untuk transaksi retur dicatat dengan angka 0, sehingga terjadi kemungkinan perbedaan antara laporan keuangan dengan pelaporan ke Direktorat Pajak.
Pencatatan pada Print Form 1107A PPN Keluaran untuk transaksi retur harus dicatat sebesar jumlah retur. Nilai jumlah transaksi retur harus ditampilkan dalam tanda kurung sebagai pengurang nilai PPN Keluaran.
C Pencatatan diskon atas transaksi penjualan harus dilakukan pemisahan berdasarkan prinsipal.
L G Pencatatan diskon yang dilakukan secara keseluruhan tanpa adanya pemisahan
account piutang klaim promo berdasarkan
M elakukan penambahan parameter account piutang klaim promo yang dibedakan berdasarkan prinsipal.
prinsipal akan menyulitkan dalam mendeteksi diskon tersebut berasal dari prinsipal yang mana.
D Nilai kas kecil pada Balance Sheet dan Cash and Bank Statement harus sama.
H G Pencatatan nilai kas kecil yang berbeda di Balance Sheet dengan Cash and Bank Statement dimana nilai kas kecil pada Balance Sheet lebih kecil dari pada kas kecil yang ada di Cash and Bank Statement.
M elakukan recalculation pada M odul Cash and Bank sehingga sistem akan melakukan penyesuaian nilai pada table CB_VOUCHER_TXN dan table CB_RPT_BANK_BALANCE_STATEM ENT sehingga nilai kas kecil pada Balance Sheet dan Cash and Bank Statement sama.
E Nilai piutang pada Laporan Account Receivable Balance harus sama dengan Balance Sheet.
H G Pada saat dilakukan rekonsiliasi terhadap Account Receivable Balance dan Balance Sheet, ditemukan ketidaksesesuaian nilai account receivable dari kedua laporan tersebut.
M engotomatisasikan fungsi Batch Poster yang mana fungsi Batch Poster digabungkan dalam fungsi Subledger Interface A/R, sehingga kemungkinan transaksi tidak dilakukan Batch Poster dapat diminimalisir.
Financial Accounting sistem ERP TSD.
database modul Financial Accounting sistem ERP TSD sehingga sulit untuk mengetahui relasi antar table serta pengecekan kesalahan terkait sistem.
modul Financial Accounting Sistem ERP TSD dalam bentuk ERD.
Keterangan :
1. Requirement, menjelaskan kebutuhan user.
2. Rank (Ranking), terdiri dari :
a. H (High / Kebutuhan Penting), yaitu kebutuhan yang kritis, penting untuk operasi dan tanpa mereka organisasi tidak dapat berfungsi, mereka juga meliputi kebutuhan pelaporan eksternal dan internal. b. M (Medium / Kebutuhan Penambah Nilai), yaitu kebutuhan yang
jika dipenuhi, akan meningkatkan proses bisnis secara signifikan, kebutuhan ini biasanya kurang kritis untuk bisnis organisasi, tetapi jika dipenuhi akan memberikan keuntungan biaya signifikan pada organisasi.
c. L (Low / Kebutuhan yang Diinginkan), adalah kebutuhan yang baik untuk dimiliki dan hanya akan menambah nilai kecil ke proses bisnis dan mungkin dipertemukan melalui workaround atau perubahan proses bisnis.
3. Level, terdiri dari :
a. F (Fit), artinya kebutuhan secara penuh dipenuhi oleh perangkat lunak.
b. G (Gap), artinya perangkat lunak tidak memenuhi semua kebutuhan ini.
c. P (Partial Fit), artinya perangkat lunak memiliki fungsionalitas yang memuaskan kebutuhan user.
4. Comment adalah deskripsi dari kondisi perusahaan yang sedang berlangsung.
5. Alternatives adalah solusi alternatif yang digunakan untuk menyelesaikan
permasalahan (Gap/Partial/Fit) yang ditemukan. 4.2. Risk Analysis
Setelah dilakukan analisis terhadap kebutuhan menggunakan Gap Analysis, selanjutnya akan dilakukan Risk Analysis. Risk Analysis dilakukan untuk mengidentifikasi resiko yang mungkin timbul apabila fungsi yang direkomendasikan pada tahap sebelumnya tidak digunakan. Risk Analysis ini dilakukan terhadap kebutuhan yang memiliki Degree of Fit berupa Gap dan terdapat rekomendasi atas kebutuhan tersebut.
Setelah resiko diidentifikasi, akan dilakukan penilaian terhadap kemungkinan timbulnya suatu resiko bagi aktivitas perusahaan secara keseluruhan beserta dampak yang ditimbulkan dari resiko-resiko tersebut. Penilaian ini dilakukan terhadap masing-masing resiko yang telah diidentifikasi. Kemungkinan timbulnya resiko dinilai dengan beberapa kategori penilaian, diantaranya :
Tabel 4.2 Probability Rank
Peringkat Penjelasan
High Kemungkinan akan timbulnya resiko relatif tinggi
jika fungsi tidak digunakan.
Medium Kemungkinan akan timbulnya resiko cukup tinggi
Low Kemungkinan akan timbulnya resiko relatif rendah jika fungsi tidak digunakan.
Sedangkan dampak yang ditimbulkan oleh resiko (impact) diukur dengan penilaian :
Tabel 4.3 Risk Impact Rank
Peringkat Penjelasan
High Dampak yang ditimbulkan dari resiko akan
mempengaruhi aktivitas utama proses bisnis perusahaan.
Medium Dampak yang ditimbulkan dari resiko
cukup mempengaruhi aktivitas utama proses bisnis perusahaan , namun tidak menghambat proses bisnis.
Low Dampak yang ditimbulkan dari resiko
sangat kecil bahkan tidak mempengaruhi aktivitas utama proses bisnis perusahaan.
Tabel 4.4 Risk Analysis
No Requirement Recommendation Risk Identification Probability Impact
A Setiap DC (Direct Cover) hanya boleh memiliki satu account Bank Incoming Clearing yang digunakan dalam pencatatan transaksi yang berhubungan dengan M odul Cash and Bank. Satu account Bank Incoming
Clearing harus memiliki nilai
yang sama baik pada Trial Balance dan Cash and Bank Statement.
Ketika ada perubahan account GL atas Bank Incoming Clearing, maka harus dibuat account Bank Incoming Clearing baru tanpa mengubah master lama. Setelah itu dapat dilakukan transfer (melalui transaksi DDP atau Dana Dalam Perjalanan) dari account Bank Incoming
Clearing lama ke account Bank Incoming
Clearing baru. Dengan demikian, akan dibuat jurnal dengan account DDP pada debit dan account Bank Incoming Clearing lama pada kredit, serta jurnal dengan account Bank Incoming Clearing baru pada debit dan account DDP pada kredit.
1. Informasi untuk Trial Balance
dan Cash and Bank Statement
menjadi kurang akurat.
2. Trial Balance dan Cash and
Bank statement menjadi tidak reliable.
3. Pengambilan keputusan menjadi kurang akurat dan arus informasi ke level eksekutif perusahaan menjadi tidak valid dan tidak terpercaya. H H M M M M
Selain itu, dianjurkan untuk tidak melakukan update by script ke transaksi kecuali dilakukan oleh seorang developer.
B Saldo PPN Keluaran pada Trial balance dan formulir yang akan dilaporkan kepada Dirjen Pajak (Print Form 1107A) harus memiliki nilai yang sama.
Pencatatan PPN Keluaran untuk transaksi retur harus dicatat sebesar jumlah retur. Nilai jumlah transaksi retur harus ditampilkan dalam tanda kurung sebagai pengurang nilai PPN Keluaran.
1. Dapat terjadi kesalahan dalam pembayaran nilai pajak ke Direktorat Jendral Pajak dimana dapat terjadi lebih bayar.
2. Kesalahan pencatatan nilai PPN Keluaran dalam Formulir 1107 A ini akan menyebabkan
perusahaan mengalami kerugian. H H L L
C Pencatatan diskon atas transaksi penjualan harus dilakukan pemisahan berdasarkan prinsipal.
M elakukan penambahan parameter account piutang klaim promo yang dibedakan berdasarkan prinsipal.
1. Tidak dapat mengetahui rincian diskon per prinsipal yang telah memberikan jumlah diskon tertentu melalui PT M IE Tbk.
2. Tidak dapat melakukan perhitungan prinsipal mana saja yang berkontribusi memberikan keuntungan terbanyak bagi perusahaan.
3. Kurang tepat dalam pengambilan keputusan yang
berhubungan dengan kerjasama antar prinsipal dan
perusahaan. H H M L L M
Sheet dan Cash and Bank Statement harus sama.
Cash and Bank sehingga sistem akan melakukan perhitungan ulang atas transaksi yang pernah dilakukan.
dan Cash and Bank Statement
menjadi kurang akurat.
2. Pengambilan keputusan menjadi kurang akurat dan arus informasi ke level eksekutif perusahaan menjadi tidak valid dan tidak terpercaya.
3. Balance Sheet dan Cash and
Bank Statement menjadi tidak reliable.
M
H
M
M
E Nilai piutang pada Laporan Account Receivable Balance harus sama dengan Balance
M engotomatisasikan fungsi Batch Poster yang mana fungsi Batch Poster digabungkan dalam fungsi Subledger
1. Kesalahan penentuan
kebijakan dalam memberikan limit kredit kepada outlet.
Sheet. Interface A/R, sehingga kemungkinan transaksi tidak dilakukan Batch Poster dapat diminimalisir.
2. Informasi yang ditampilkan pada laporan tidak akurat.
H M
F Ada dokumentasi database modul Financial Accounting sistem ERP TSD.
M endokumentasikan table-table database modul Financial Accounting sistem ERP TSD dalam bentuk ERD.
1. Kesulitan tracking penyebab masalah dan membutuhkan waktu yang cukup lama dalam memecahkan masalah tersebut. 2. Akan mempersulit karyawan
baru dalam mempelajari dan memahami sistem ERP TSD, terutama karyawan yang berperan dalam pengembangan dan pengimplementasian.
M
L
L
Resiko-resiko yang telah diidentifikasi kemudian akan dipetakan ke dalam Probability-Impact Matrix berikut ini:
Tabel 4.5 Probability/Impact Matrix
HIGH B1, B2 C1, C2 A1,A2, D1, D3 E1, E2 M EDIUM F1 A3, C3, D2 LOW F2
LOW M EDIUM HIGH
Probability/Impact Matrix menunjukkan Probability secara vertikal dan Impact secara horizontal sehingga dapat diperoleh kriteria HL (High Low), HM (High Medium), HH (High High), M L (Medium Low), MM (Medium Medium), MH (Medium High), LL (Low Low), LM (Low Medium), dan LH (Low High).
a. Kriteria HL (High Low)
Kriteria HL (High Low) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya tinggi dan akan berdampak sangat kecil bahkan relatif tidak berpengaruh pada aktivitas utama proses bisnis perusahaan.
Resiko B1 dan B2 adalah resiko saat terjadi kesalahan pencatatan PPN Keluaran. Bila resiko-resiko ini tidak diatasi, maka resiko-resiko tersebut akan sering terjadi
karena pelaporan dan pembayaran pajak dilakukan pada setiap bulan. Resiko-resiko itu berpengaruh pada aktivitas utama proses bisnis perusahaan karena setiap transaksi penjualan maupun transaksi retur, perlu dicatat nilai PPN-nya. Namun, hal ini tidak sampai menghambat jalannya proses bisnis utama perusahaan.
Resiko C1 dan C2 adalah resiko yang muncul akibat tidak adanya pemisahaan diskon per prinsipal. Resiko-resiko ini sering terjadi karena prinsipal-prinsipal PT MIE Tbk kerap memberikan diskon kepada pelanggannya. Resiko C1 dan C2 relatif tidak berpengaruh pada aktivitas utama proses bisnis utama perusahaan karena jika resiko-resiko tersebut terjadi, aktivitas penjualan perusahaan tetap berjalan seperti biasa. b. Kriteria HM (High Medium)
Kriteria HM (High Medium) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya tinggi dan dampak yang ditimbulkan dari resiko cukup mempengaruhi aktivitas utama proses bisnis perusahaan , tetapi tidak menghambat proses bisnis.
Resiko A1 dan A2 adalah resiko mengenai laporan yang melibatkan account Bank Incoming Clearing. Resiko-resiko ini memiliki kemungkinan terjadi tinggi karena resiko A1 dan A2 dapat terjadi setiap bulannya. Resiko A1 dan A2 mempengaruhi aktivitas utama proses bisnis perusahaan karena laporan akan digunakan sebagai pertimbangan untuk membuat kebijakan atau pun keputusan sehingga dapat berpengaruh pada proses bisnis utama.
Resiko D1 dan D3 dikategorikan sebagai resiko High Medium karena resiko nilai kas kecil yang tidak sama pada Trial Balance dan Cash and Bank Statement akan terjadi
dalam frekuensi sering dan cukup mempengaruhi aktivitas utama perusahaan khususnya dalam hal pengeluaran operasional sehari-hari perusahaan.
Resiko E1 dan E2 berapa pada kelompok High Medium,dimana resiko-resiko terkait dengan Account Receivable yang memiliki intensitas kejadian tinggi serta cukup mempengaruhi proses bisnis yang berjalan.
c. Kriteria HH (High High)
Kriteria HH (High High) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya tinggi dan akan berdampak sangat besar terhadap aktivitas utama proses bisnis perusahaan.
d. Kriteria M L (Medium Low)
Kriteria M L (Medium Low) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya cukup tinggi dan dapat berdampak relatif rendah pada aktivitas utama proses bisnis perusahaan.
Resiko F1 berada pada kategori Medium Low karena resiko kesulitan dalam memecahkan permasalahan tertentu sehubungan dengan sistem ERP TSD ini dapat terjadi cukup sering dan sedikit berpengaruh pada proses bisnis utama perusahaan. e. Kriteria MM (Medium Medium)
Kriteria MM (Medium Medium) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya cukup tinggi dan dampak yang ditimbulkan dari resiko cukup mempengaruhi aktivitas utama proses bisnis perusahaan , namun tidak menghambat proses bisnis.
Resiko A3, C3, dan D2 dikategorikan sebagai Medium Medium, karena ketiga resiko tersebut berhubungan dengan arus informasi ke level eksekutif sebagai dasar
pengambilan keputusan yang tentunya akan berhubungan dengan proses bisnis, sehingga akan mempengaruhi jalannya proses bisnis itu sendiri.
f. Kriteria M H (Medium High)
Kriteria M H (Medium High) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya cukup tinggi dan akan berdampak sangat besar terhadap aktivitas utama proses bisnis perusahaan.
g. Kriteria LL (Low Low)
Kriteria LL (Low Low) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya relatif rendah dan dampak yang ditimbulkan dari resiko sangat kecil bahkan tidak mempengaruhi aktivitas utama proses bisnis perusahaan.
Resiko F2, dimana dengan tidak adanya dokumentasi akan menyulitkan karyawan baru khususnya di divisi TI untuk mempelajari sistem secara mendalam dikategorikan sebagai resiko Low Low. Hal ini dikarenakan frekuensi pergantian karyawan baru tidak terlalu tinggi serta tidak memiliki dampak signifikan pada proses bisnis perusahaan. h. Kriteria LM (Low Medium)
Kriteria LM (Low Medium) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya relatif rendah dan dampak yang ditimbulkan dari resiko cukup mempengaruhi aktivitas utama proses bisnis perusahaan , namun tidak menghambat proses bisnis.
Kriteria LH (Low High) menunjukkan bahwa resiko yang dipetakan ke dalam kriteria ini memiliki probability/kemungkinan terjadinya relatif rendah dan dampak yang ditimbulkan dari resiko akan mempengaruhi aktivitas utama proses bisnis perusahaan.
4.3. Rekomendasi Pengembangan
Berdasarkan hasil Gap yang telah dipetakan di atas, maka diberikan solusi yang berguna untuk mengatasi masalah yang telah ditemukan. Solusi-solusi tersebut sebagai berikut :
A. Membuat account Bank Incoming Clearing baru tanpa mengubah master lama dan melakukan transfer (melalui transaksi DDP atau Dana Dalam Perjalanan) dari account Bank Incoming Clearing lama ke account Bank Incoming Clearing baru.
Bank Incoming Clearing (BIC) merupakan Cash & Bank Master yang berfungsi untuk menerima pembayaran piutang dari outlet-outlet atau piutang atas klaim prinsipal PT M IE Tbk. Dalam Bank Incoming Clearing ini dijelaskan beberapa attribute antara lain Bank Group, Bank ID, Bank Type, Address, dan nomor Account. Setiap transaksi dengan tipe Bank Incoming Clearing secara otomatis akan mencatat ke nomor account
Bank Incoming Clearing. Pada awal penentuan Chart of Account, account Bank
Incoming Clearing memiliki nomor 00-1-1231-00-70 yang kemudian diganti menjadi nomor account 00-1-1211-00-90.
Gambar 4.1 Cash & Bank Master
Semua transaksi Bank Incoming Clearing dilakukan pada transaksi other cash &
bank receipt entry. Selanjutnya transaksi yang ada harus dilakukan interface pada menu
Subledger Jurnal Interface. Dengan demikian maka transaksi Cash and Bank akan dicatat ke dalam Cash and Bank Statement. Agar transaksi Bank Incoming Clearing ini tercatat dalam Trial Balance, maka harus terlebih dahulu dilakukan Batch Poster. Kemudian pada setiap akhir bulan, akan dilakukan rekonsiliasi terhadap kedua laporan tersebut. Rekonsiliasi terhadap kedua laporan sangat bermanfaat bagi perusahaan dalam pengambilan keputusan yang tepat atas value yang diberikan dari kinerja sistem serta memberi gambaran terhadap posisi keuangan perusahaan . Ketidaksesuaian pencatatan pada kedua laporan harus mendapatkan perhatian penting bagi perusahaan.
Rekonsiliasi yang dilakukan pada account Bank Incoming Clearing periode M ei 2011 dan sebelumnya antara Balance Sheet dan Cash and Bank Statement menunjukkan nilai yang berbeda dengan selisih saldo sama/konstan setiap bulannya yaitu sebesar Rp 156.149.236,-. Sementara rekonsiliasi account Bank Incoming Clearing periode Juni 2011 dan Juli 2011 antara Balance Sheet dan Cash and Bank Statement menunjukkan nilai yang sama.
Selain itu, untuk periode M ei 2011 dan sebelumnya, terjadi perbedaan dalam
account Bank Incoming Clearing yang ditampilkan pada Balance Sheet dan Cash and
Bank Statement. Pada Balance Sheet periode M ei 2011 dan sebelumnya, account Bank
Incoming Clearing yang digunakan adalah 00-11231-00-70. Sedangkan pada Cash and Bank Statement. account Bank Incoming Clearing yang digunakan adalah
00-11211-00-90. Hal ini menyebabkan tidak ada sinkronisasi antara Balance Sheet dan Cash and Bank Statement.
Ketidaksesuaian-ketidaksesuaian di atas disebabkan terdapat dua account Bank
Incoming Clearing pada Chart of Account, dimana terjadi perpindahan account Bank
Incoming Clearing yang terjadi pada bulan Juni 2011 dari account Bank Incoming
Clearing 00-11231-00-70 ke account Bank Incoming Clearing 00-11211-00-90.
Ketidaksesuaian atas nilai yang ada di Trial balance dan Cash and Bank Statement dikarenakan oleh kesalahan sistem dalam pencatatan terhadap sejumlah piutang yang tidak diperhitungkan dan tidak ter-update pada Cash and Bank Statement (CR11) tetapi tercatat secara lengkap pada Trial Balance perusahaan yang merupakan dampak dari terciptanya dua account Bank Incoming Clearing. Pada beberapa transaksi, sumber bank id tidak teridentifikasi. Hal ini disebabkan oleh perubahan transaksi melalui script (query SQL) sehingga tidak diperhitungkan dalam pencatatan Cash and Bank Statement.
Untuk mengatasi masalah-masalah tersebut, maka ketika ada perubahan account GL atas Bank Incoming Clearing, harus dibuat Cash & Bank Master Bank Incoming Clearing baru tanpa mengubah master lama. Untuk membuat sebuah Cash & Bank
Master Bank Incoming Clearing baru, dapat dilakukan pada submodul Cash & Bank –
Gambar 4.3 Cash and Bank Master
Akan muncul window baru untuk membuat sebuah Cash & Bank Master Bank Incoming Clearing baru seperti gambar di bawah ini.
Gambar 4.4 Cash & Bank Master Bank Incoming Clearing baru
Setelah muncul window tersebut, maka dapat di-input data yang diperlukan sehubungan dengan Cash & Bank Master Bank Incoming Clearing lalu klik “ok”. Gambar di bawah adalah contoh data yang di-input.
Gambar 4.5 Input data Cash & Bank Master Bank Incoming Clearing baru
Dengan adanya dua Cash & Bank Master Bank Incoming Clearing, maka akan menegaskan penggunaan account Bank Incoming Clearing dimana Cash & Bank Master
Bank Incoming Clearing BIC akan menggunakan account Bank Incoming Clearing
00-11211-00-90. Sedangkan Cash & Bank Master Bank Incoming Clearing BIC2 akan menggunakan account Bank Incoming Clearing 00-11231-00-70.
Setelah itu dapat dilakukan transfer (melalui transaksi DDP atau Dana Dalam Perjalanan) dari account Bank Incoming Clearing lama ke account Bank Incoming
Clearing baru. Dengan demikian, akan dibuat jurnal dengan account DDP pada debit
dan account Bank Incoming Clearing lama pada kredit, serta jurnal dengan account
ini dapat dilakukan pada submodul General Ledger Sistem – Gl Entry – General Journal Entry & Listing (GT18). Selain itu, dianjurkan untuk tidak melakukan update by script ke transaksi kecuali dilakukan oleh seorang developer. Contoh jurnal pembalik untuk memindahkan nilai account:
00-1-1490-00-10 Dana Dalam Perjalanan xxx
00-1-1231-00-70 Bank Incoming Clearing xxx
Gambar 4.6 General Journal Entry & Listing
Gambar 4.6 menjelaskan pemindahan nilai account dari account Bank Incoming Clearing 00-1-1211-00-70 yang merupakan account Bank Incoming Clearing lama ke account DDP (Dana Dalam Perjalanan). Account DDP berguna untuk menampung sementara dana yang akan dipindahkan. Selanjutnya, jurnal yang harus dibuat:
00-1-1490-00-10 Dana Dalam Perjalanan xxx
Gambar 4.7 General Journal Entry & Listing
Gambar 4.7 menjelaskan pemindahan nilai account dari account DDP (Dana Dalam Perjalanan) ke account Bank Incoming Clearing 00-1-1211-00-90 yang merupakan account Bank Incoming Clearing yang digunakan saat ini.
Dengan demikian, untuk transaksi yang berhubungan dengan Cash & Bank Master Bank Incoming Clearing dapat dipilih Bank Id BIC atau BIC2. Untuk transaksi yang menggunakan Bank Id BIC, pencatatan transaksi ke account Bank Incoming
Clearing 00-1-1211-00-90. Sedangkan tranksaksi yang menggunakan Bank Id BIC2,
pencatatan transaksi ke account Bank Incoming Clearing 00-1-1211-00-70. Account Bank Incoming Clearing yang mana yang akan dipakai ditetapkan berdasarkan pada kebijakan yang dikeluarkan dari Headoffice kepada Direct Cover.
B. Pencatatan PPN Keluaran untuk transaksi retur harus dicatat sebesar jumlah retur. Nilai jumlah transaksi retur harus ditampilkan dalam tanda kurung sebagai pengurang nilai PPN Keluaran.
Setiap transaksi penjualan yang dilakukan oleh PT M IE Tbk , akan dilakukan perhitungan PPN Keluaran. Nilai PPN ini adalah 10% dari nilai penjualan yang dilakukan. PPN ini akan dikenakan kepada outlet yang membeli barang dari PT M IE Tbk . PPN tersebut akan dibayarkan terlebih dahulu oleh outlet ke PT M IE Tbk , dan selanjutnya PT M IE Tbk akan melaporkan dan membayar PPN ke pihak Dirjen Pajak. Oleh karena itu, nilai PPN setiap transaksi penjualan PT M IE Tbk harus dicatat dalam sistem ERP TSD.
Dalam sistem ERP TSD, PPN Keluaran dicatat dalam kode transaksi SDT92 (Print Form 1107 A) secara terpisah dengan tujuan untuk memudahkan pelaporan ke Dirjen Pajak. Selain itu, PPN Keluaran juga dicatat dalam Balance Sheet dengan nama
account Hutang pajak dan di Trial Balance dengan nama account Hutang Pajak PPN
Keluaran.
M enurut Petunjuk Pengisian Formulir 1107 A Lampiran 1 – Daftar Pajak Keluaran dan PPN BM , untuk transaksi retur, transaksi tetap dilaporkan. Kolom kode dan nomor serta tanggal nota retur diisi dengan nomor dan tanggal nota retur. Sedangkan kolom DPP (Dasar Pengenaan Pajak) dan PPN diisi dengan nilai BKP (Barang Kena Pajak) yang diretur dan PPN atas BKP (Barang Kena Pajak) yang diretur tersebut. Nilai ditulis dalam tanda kurung sebagai pengurang.
Formulir 1107 A. Pada SDT92, transaksi retur diberi nilai 0, sedangkan menurut petunjuk pengisian formulir 1107 A lampiran 1 – daftar pajak keluaran dan PPn BM (Pajak Pertambahan Nilai Barang M ewah), transaksi retur tersebut harus dicatat dengan nilai retur dan diberi tanda kurung sebagai pengurang nilai PPN Keluaran.
Nilai retur transaksi penjualan tidak dimasukkan ke formulir 1107A karena pada awal pengembangan sistem ERP TSD, user tidak men-define requirement untuk memasukkan nilai retur ke dalam Formulir 1107 A. Hal ini dikarenakan pelaporan dan pembayaran pajak masih menggunakan pencatatan yang ada pada sistem ERP SAP sehingga nilai yang dilaporkan adalah benar. PPN Keluaran pada sistem ERP TSD pada formulir 1107 A ini nantinya akan digunakan sebagai pembanding dengan nilai PPN Keluaran dari sistem ERP SAP serta mempersiapkan sistem ERP TSD bila di masa yang akan datang dipakai sepenuhnya.
Pencatatan PPN Keluaran yang tidak tepat pada formulir 1107 A dapat berakibat pelaporan dan pembayaran PPN Keluaran berlebih dimana PT M IE Tbk seharusnya tidak membayar pajak untuk transaksi retur tersebut. Hal ini dapat diatasi dengan cara menambahkan nilai retur yang seharusnya ada pada formulir 1107 A dan dicatat sebagai pengurang (dalam tanda kurung) terhadap nilai PPN secara keseluruhan. Penambahan nilai retur seperti yang disebutkan di atas dilakukan dengan melakukan customize terhadap parameter pada Report Setup Parameter (G ST18) dimana sebelumnya pengaturan terhadap parameter untuk PPN Keluaran belum tepat. Untuk melakukan customize terhadap parameter pada Report Setup Parameter (G ST18) terdapat pada submodul General Sistem – Modul - Report Setup Parameter (GST18).
Gambar 4.8 M enu sistem ERP TSD
Pada Report Setup Parameter, tab Report Setting diberi check list pada field Pencetakan Retur dengan negatif (-). Di bawah ini adalah tampilan sebelum dilakukan customize.
Gambar 4.9 Report Setup Parameter sebelum customize
Dibawah ini adalah tampilan setelah dilakukan customize.
Customize parameter di atas akan berpengaruh pada laporan pada form 1107 A (SDT92), sehingga sistem akan memperhitungkan PPN atas transaksi retur dengan memberi tanda kurung terhadap perhitungan PPN retur dan secara otomatis akan mengurangi total PPN yang dikenakan terhadap barang.
C. Melakukan penambahan parameter account piutang klaim promo yang dibedakan berdasarkan prinsipal.
Pada awal pengembangan sistem ERP TSD, user tidak menentukan requirement untuk pemisahan diskon berdasarkan prinsipal. Diskon yang berasal dari beberapa prinsipal dicatat dalam satu account piutang klaim promo. Pada sistem ERP TSD yang berjalan sekarang ini, pencatatan diskon dilakukan secara general dimana nilai diskon dicatat tanpa dialokasikan berdasarkan prinsipal. Pada pemisahan account piutang klaim promo per prinsipal, setting-an discount – 1 line account masih menggunakan kode account 00 1 1663 20 30 – piutang klaim promo yang mencatat diskon-diskon yang diberikan oleh prinsipal secara total, tanpa melakukan pemisahan account-nya per prinsipal.
Gambar 4.11 merupakan form parameter account piutang klaim promo yang sedang berjalan sekarang ini, dimana pencatatan account piutang klaim promo masih di catat secara general atau belum adanya pemisahan account piutang klaim promo per prinsipal:
Gambar 4.11 Pengaturan Parameter Account
Tidak adanya pengalokasian diskon ini dapat menyebabkan jumlah diskon terakumulasi dan sulit untuk mengetahui secara detail jumlah diskon yang diberikan oleh prinsipal tertentu secara spesifik. Hal ini mengakibatkan perusahaan menjadi sulit untuk mengetahui prinsipal mana yang dapat memberikan keuntungan ataupun fasilitas yang lebih menguntungkan serta sulit untuk mengambil keputusan yang terbaik sehubungan dengan kerja sama yang dilakukan antara PT M IE Tbk dan pihak prinsipal. Oleh karena itu, muncul sebuah requirement baru dari perusahaan terkait pemisahaan diskon berdasarkan prinsipal.
Untuk memenuhi requirement perusahaan maka diperlukan customizing pada sistem agar sistem dapat mencatat nilai diskon yang dibedakan berdasarkan prinsipal secara otomatis. Solusi yang terbaik yaitu dengan menambahkan parameter account piutang klaim promo. Account piutang klaim promo merupakan account yang digunakan untuk mencatat semua transaksi yang terkait dengan diskon yang diberikan oleh prinsipal kepada outlet melalui PT M IE Tbk. Penambahan parameter account piutang klaim promo ini dilakukan dengan mengambil 7 digit pertama account piutang klaim promo umum, yang mana di dalam account piutang klaim promo tersebut terdapat sub-account piutang klaim promo yang dibedakan berdasarkan prinsipal.
Untuk melakukan pemecahan account piutang klaim promo secara prinsipal dapat dilakukan dengan menambah parameter account piutang klaim promo dengan langkah –langkah sebagai berikut :
a. M enambahkan Account pada Chart of Account untuk piutang klaim promo untuk setiap prinsipal melalui menu aplikasi GM 7- GL Account Editor & Listing, lalu klik new untuk men-create Account baru.
Gambar 4.12 GL Account Editor & Listing
Window untuk melakukan input data yang diperlukan sehubungan dengan
Gambar 4.13 Window Pembuatan Account Baru
Setelah dilakukan create, maka account yang ditambahkan akan muncul pada Listing GL ketika di-execute.
Account-account yang di tambahkan sebagai contoh :
Chart of Account Keterangan
00-1-1663-20-31 Piutang klaim promo WYETH
00-1-1663-20-32 Piutang klaim promo Kaori
b. Setelah account untuk setiap prinsipal dibuat, maka langkah selanjutnya adalah melakukan penambahan dan setting parameter.
Gambar 4.14 merupakan form parameter account piutang klaim promo untuk pemecahan account piutang klaim promo yang dibedakan secara prinpisal.
Gambar 4.14 Form Parameter Account Piutang Klaim Promo
Untuk transaksi yang memperoleh diskon dari prinsipal maka kode account piutang klaim promo pada discount –1 line account akan mengambil 7 digit dari 11 digit, yang menandakan bahwa account tersebut merupakan account piutang klaim
promo. Pada piutang klaim promo ini, ditambahkan sebuah button yang akan memunculkan sebuah Form Detail.
Form Detail Berfungsi untuk menampung sub-account piutang klaim promo yang dibedakan secara prinsipal. Pada Form Detail terdapat kode account piutang untuk setiap prinsipal dan juga button browse yang ketika diklik akan memunculkan form baru yang berisi list dari chart of account. Pada form detail ini juga diberi validasi query yang berfungsi ketika perusahaan mendapatkan diskon dari prinsipal, maka sistem akan dapat mencatat secara otomatis dari prinsipal mana diskon tersebut berasal.
D. Melakukan recalculation pada Modul Cash and Bank sehingga sistem akan melakukan perhitungan ulang atas transaksi yang pernah dilakukan.
Kas kecil digunakan untuk pencatatan transaksi yang berhubungan dengan pengeluaran dana yang digunakan untuk keperluan–keperluan operasional seperti biaya BBM , biaya perjalanan dinas, pembelian air mineral, dll. Transaksi tersebut dilakukan pada transaksi receipt entry dan payment entry, dimana setelah dilakukannya transaksi ini diharuskan dilakukan interface yang berguna untuk pencatatan di Balance Sheet, Trial Balance, dan Cash and Bank Statement.
M etode Pencatatan Kas Kecil pada PT M IE Tbk, pada awal nya menggunakan metode pencatatan kas kecil fluktuasi. Kas kecil fluktuasi adalah yang pencatatan dan pengendalian kas kecil, dimana jumlah kas kecil akan selalu berubah karena pengisian kembali kas kecil selalu sama dari waktu ke waktu. M etode ini hanya di gunakan sampai Agustus 2010,yang kemudian di gantikan dengan menggunakan M etode Pencatatan Kas Kecil Imprest. Kas kecil Imprest adalah suatu metode pengisian dan pengendalian kas kecil dimana jumlah kas kecil selalu tetap dari waktu ke waktu, karena pengisian
kembali kas kecil akan selalu sama dengan jumlah yang telah dikeluarkan. M etode Kas Kecil Imprest ini yang digunakan sampai sekarang.
Untuk memastikan bahwa semua laporan tercatat dengan baik,maka dilakukan rekonsiliasi setiap bulannya terhadap pencatatan laporan pada sistem ERP TSD M odul Financial Accounting.
Pada saat dilakukannya rekonsiliasi terhadap kas kecil yang ada di Balance Sheet dan Cash and Bank Statement terdapat selisih nilai kas kecil antara kedua laporan tersebut. Selisih ini terjadi dikarenakan sistem ERP TSD tidak meng-capture nilai saldo beginning balance dari bulan sebelumnya dengan tepat. Seharusnya setiap Cash and Bank Statement diawali dengan beginning saldo. Beginning saldo ini berasal dari saldo terakhir bulan sebelumnya. Namun, pada bulan Januari 2011 beginning saldo yang ditampilkan tidak sesuai dengan saldo akhir bulan Desember 2010. Hal ini menyebabkan terjadi selisih nilai kas kecil pada bulan-bulan selanjutnya.
Untuk mengatasi masalah tersebut, perlu dilakukan system recalculation. System
recalculation akan melakukan update table
CB_RPT_BANK_BALANCE_STATEM ENT berdasarkan table CB_VOUCHER_TXN sehingga seluruh data dan nilai pada kedua table sesuai satu sama lain. System
recalculation secara otomatis secara berkala setiap bulan dapat digunakan untuk
mengatasi masalah ini, dimana dengan system recalculation secara otomatis akan dilakukan penyesuaian ulang terhadap seluruh transaksi dan update terhadap fungsi sistem dan juga pencatatan di beberapa laporan yang terkait. Dengan demikian, pada saat dilakukan rekonsiliasi antara Balance Sheet, Trial Balance, dan Cash and Bank
Gambar 4.17 merupakan tampilan system recalculation yang ada pada sistem ERP TSD saat ini:
Gambar 4.17 System recalculation
Selain itu, untuk membantu mengatasi masalah sistem yang tidak meng-capture data transaksi secara sempurna yang salah satunya dapat disebabkan oleh putusnya aliran listrik secara tiba-tiba maka perusahaan membutuhkan solusi yang dapat mengatasi masalah tersebut dengan menggunakan UPS (Uniterruptible Power Supply) didukung dengan penstabil tegangan listrik (Stabilizer). UPS sendiri digunakan untuk menyimpan sejumlah arus listrik agar saat terjadinya pemutusan arus listrik secara tiba-tiba, maka sistem masih tetap bertahan selama beberapa saat untuk melakukan roll back. Roll back di sini dipahami sebagai penarikan kembali transaksi yang tidak terproses sempurna sehingga pencatatannya pada table database tidak lengkap.
E. Mengotomatisasikan fungsi Batch Poster yang mana fungsi Batch Poster digabungkan dalam fungsi Subledger Interface A/R, sehingga kemungkinan transaksi tidak dilakukan Batch Poster dapat diminimalisir.
Pada sistem ERP TSD, setiap terjadi transaksi penjualan baik penjualan yang dilakukan secara kredit maupun penjualan secara tunai, akan menyebabkan timbulnya account receivable yang dicatat pada M odul Account Receivable. Proses ini dimulai
dengan penginterfacean transaksi-transaksi sales agar untuk dicatat sebagai account receivable yang akan dilaporkan pada laporan keuangan. Proses ini dimulai dengan melakukan Interface Sales to Account Receivable dari modul account recevaible yang kemudian diikuti dengan proses Interface Subledger A/R yang akan mem-posting ke
Account Receivable Balance. Account Receivable Balance merupakan laporan account
receivable yang mencatat piutang untuk setiap outlet yang mana Account Receivable Balance mencatat saldo awal, penjualan, retur, tagihan dan saldo akhir piutang. Sedangkan untuk mem-posting ke laporan keuangan maka harus dilakukan proses Batch Poster.
Pada sistem ERP TSD sekarang ini, ketika dilakukan rekonsiliasi, terdapat selisih pada Account Receivable Balance dan Balance Sheet. Hal ini dikarenakan terjadi kesalahan pencatatan transaksi dimana transaksi tidak di-interface-kan pada bulan yang seharusnya pada Batch Poster, melainkan di-interface pada bulan berikutnya.
Dengan adanya perbedaan ini dapat menyebabkan data – data piutang perusahaan menjadi tidak akurat dan mempengaruhi laporan keuangan. Oleh karena itu, kesalahan ini harus segera diperbaiki dengan melakukan otomatisasi pada Batch Poster sehingga urutan untuk pencatatan jurnal account receivable ini dimulai dari interface Sales Data to Account Receivable kemudian dilakukan interface Subledger A/R. Proses Batch Poster diotomatiskan, sehingga pada saat interface Sublegder A/R sekaligus dijalankan proses yang biasanya dilakukan pada fungsi Batch Poster.
Gambar 4.18 merupakan flowchart modul General Ledger untuk menunjukkan urutan proses interface jurnal-jurnal setiap modul agar masuk ke laporan, dimana proses
Gambar 4.18 M odul General Ledger
Dengan adanya proses otomatisasi Batch Poster, maka akan mempersingkat waktu pemrosesan data dan juga dapat meminimalkan terjadinya kesalahan-kesalahan user.
F. Mendokumentasikan table-table database modul Financial Accounting sistem ERP TS D dalam bentuk ERD.
Belum adanya dokumentasi table-table database M odul Financial Accounting sistem ERP TSD menyebabkan sulit untuk mengetahui relasi antar table serta pengecekan saat terjadi kesalahan terkait sistem. Relasi antar table menggambarkan hubungan yang terjadi antara satu entitas dengan entitas lain. Relasi ini juga sangat erat hubungannya dengan database relational, dimana memberikan solusi terbaik dalam mengintegrasikan beberapa kegiatan yang saling terkait . Oleh sebab itu perusahaan membutuhkan pendokumentasikan relasi dalam pengintegrasian table-table yang ada pada sistem ERP TSD khususnya M odul Financial Accounting. Pendokumentasian ini dikarenakan adanya requirement dari divisi IT Finance, divisi Developer dan divisi Implementor. Dokumentasi ini berguna dalam memahami fungsi-fungsi yang terdapat pada sistem tersebut serta melihat permasalah sistem yang terkait dengan relasi dalam database.
Pendokumentasian menggunakan konsep dari perancangan database dalam bentuk ERD (Entity Relationship Diagram) ,dimana penggunaan ERD (Entity Relationship Diagram) dapat memudahkan pengguna dalam memahami keterkaitan antar table-table database sistem ERP TSD M odul Financial Accounting. Perancangan relasi database dalam bentuk ERD (Entity Relationship Diagram) terbatas pada M odul Financial Accounting seperti: Cash and Bank , Account Payable, Account Receivable .
Berikut Perancangan yang telah dibuat : a. Cash and Bank
Cash and Bank merupakan modul pencatatan transaksi yang berhubungan dengan penerimaan dan pengeluaran dana yang digunakan untuk keperluan – keperluan operasional. Pencatatan penerimaan dan pengeluaran dana dilakukan oleh kasir.
b. Account Payable
Account Payable terkait dengan penambahan hutang , dimana terjadi ketika dilakukan pembelian (purchase) . M odul Financial Accounting dan M odul Material Management (Purchase) memiliki hubungan yang sangat erat. Transaksi yang ada pada Account Payable terkait dengan penambahan/pengurangan hutang setelah dilakukannya pembelian kepada Vendor .
c. Account Receivable
Account Receivable terkait dengan penambahan piutang pelanggan, dimana terjadi ketika dilakukan penjualan (sales). M odul Financial Accounting dan Sales and Distribution memiliki hubungan yang sangat erat. Transaksi yang ada pada Account Receivable terkait dengan pengurangan/penambahan piutang pelanggan setelah dilakukannya penjualan terhadap pelanggan.
